k8s~关于非常啰嗦的标签和选择器

总感觉k8s中定义的deplyment和service非常的啰嗦，尤其是在选择器的定义上，但没办法，它的设计总有它的道理。

• svc(spec.selector.app)
  • deployment(metadata.labels.app,spec.selector.matchLabels.app)
    • pods(metadata.labels.app)

nginx的部署

下面是一个 Kubernetes YAML 文件示例，用于部署一个 Nginx 服务。该文件包括 Deployment 和 Service 的定义，Service 类型设置为 ClusterIP。

Nginx 部署 YAML 示例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 1  # 设置副本数为 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:stable-alpine  # 使用最新的 Nginx 镜像
        ports:
        - containerPort: 80   # 容器内部的端口
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  type: ClusterIP  # 使用 ClusterIP 类型
  selector:
    app: nginx  # 根据标签选择 Pod
  ports:
    - port: 80          # Service 的端口
      targetPort: 80    # 转发到容器的端口

说明

• Deployment：

  • apiVersion: apps/v1：指定 API 版本。
  • kind: Deployment：表示这是一个 Deployment 对象。
  • metadata：包含对象的元数据，如名称和标签。
  • spec：定义 Deployment 的规格，包括副本数量、选择器和 Pod 模板。
  • replicas：设置运行的 Pod 副本数量。
  • selector：用于选择与 Deployment 相关的 Pods。
  • template：定义 Pod 的模板，包括元数据和容器规格。
  • containers：定义容器的名称、镜像和要暴露的端口。

• Service：

  • apiVersion: v1：指定 API 版本。
  • kind: Service：表示这是一个 Service 对象。
  • metadata：包含对象的元数据，如名称。
  • spec：定义 Service 的规格，包括类型、选择器和端口配置。
  • type: ClusterIP：指定 Service 类型为 ClusterIP，表示只在集群内部可访问。
  • selector：根据标签选择与之关联的 Pods。
  • ports：定义 Service 的端口和目标端口。

部署步骤

1. 将上述 YAML 内容保存到一个文件中，例如 nginx-deployment.yaml。

2. 使用以下命令在 Kubernetes 集群中应用该配置：

   kubectl apply -f nginx-deployment.yaml
   

3. 检查 Deployment 和 Service 是否成功创建：

   kubectl get deployments
   kubectl get services
   

通过以上步骤，你将能够在 Kubernetes 中成功部署一个 Nginx 服务，并通过 ClusterIP 类型的 Service 来访问它。如果你有其他问题或需要进一步的帮助，请随时告诉我！

关于特别啰嗦的labels的解释

在 Kubernetes 中，Deployment 的定义中确实存在多个地方使用了相同的标签（如 metadata.labels.app=nginx），这有其特定的目的和意义。下面是对这些标签的详细解释及其用意：

1. Metadata Labels

• 位置：在 metadata 部分。
• 作用：
  • 用于为 Deployment 对象本身打标签，这些标签可以用于标识、选择或组织 Kubernetes 对象。
  • 可以通过这些标签来查询和过滤 Deployment 对象，例如使用 kubectl get deployments -l app=nginx 来列出所有带有 app=nginx 标签的 Deployments。
  • 在service定义时，它的spec.selector.app会指向被关联的deployment的.metadata.labels.app的名字

2. Spec Selector

• 位置：在 spec.selector 部分。
• 作用：
  • 定义了该 Deployment 控制器所管理的 Pods 的选择标准。
  • Kubernetes 使用此选择器来确定哪些 Pods 是由这个 Deployment 创建和管理的。
  • 选择器中的标签必须与 Pods 的标签匹配，以确保 Deployment 能够正确地找到和管理这些 Pods。

3. Template Metadata Labels

• 位置：在 template.metadata.labels 部分。
• 作用：
  • 定义将要创建的 Pods 的标签。
  • 当 Deployment 创建 Pods 时，这些标签会被附加到新创建的 Pods 上。
  • 这些标签用于与 spec.selector 中定义的选择器进行匹配，从而使 Deployment 能够跟踪并管理这些 Pods。

为什么要重复定义？

1. 一致性：

   • 在 Deployment 的不同部分使用相同的标签确保了它们之间的一致性。这种一致性对于 Kubernetes 的操作至关重要，因为它依赖于这些标签来管理对象。

2. 可管理性：

   • 通过使用相同的标签，可以更方便地进行筛选和管理。例如，你可以快速找到所有与特定应用程序（如 nginx）相关的 Deployments、Pods 和 Services。

3. 避免错误：

   • 确保 Pods 的标签与 Deployment 的选择器相匹配，可以避免由于标签不一致导致的管理问题。如果选择器未能正确匹配 Pods，Deployment 将无法管理这些 Pods。