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 示例

1. apiVersion: apps/v1
2. kind: Deployment
3. metadata:
4.   name: nginx-deployment
5.   labels:
6.     app: nginx
7. spec:
8.   replicas: 1  # 设置副本数为 1
9.   selector:
10.     matchLabels:
11.       app: nginx
12.   template:
13.     metadata:
14.       labels:
15.         app: nginx
16.     spec:
17.       containers:
18.       - name: nginx
19.         image: nginx:stable-alpine  # 使用最新的 Nginx 镜像
20.         ports:
21.         - containerPort: 80   # 容器内部的端口
22. ---
23. apiVersion: v1
24. kind: Service
25. metadata:
26.   name: nginx-service
27. spec:
28.   type: ClusterIP  # 使用 ClusterIP 类型
29.   selector:
30.     app: nginx  # 根据标签选择 Pod
31.   ports:
32.     - port: 80          # Service 的端口
33.       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 的端口和目标端口。
    
  
  

部署步骤

• 将上述 YAML 内容保存到一个文件中，例如 nginx-deployment.yaml。
  
• 使用以下命令在 Kubernetes 集群中应用该配置：
  1. kubectl apply -f nginx-deployment.yaml

  复制代码
• 检查 Deployment 和 Service 是否成功创建：
  1. kubectl get deployments
  2. 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。
    
  
  

为什么要重复定义？

• 同等性：
  
  
  
  • 在 Deployment 的不同部分使用雷同的标签确保了它们之间的同等性。这种同等性对于 Kubernetes 的操作至关紧张，由于它依赖于这些标签来管理对象。
    
  
  
• 可管理性：
  
  
  
  • 通过使用雷同的标签，可以更方便地进行筛选和管理。例如，你可以快速找到所有与特定应用步伐（如 nginx）相干的 Deployments、Pods 和 Services。
    
  
  
• 避免错误：
  
  
  
  • 确保 Pods 的标签与 Deployment 的选择器相匹配，可以避免由于标签不同等导致的管理标题。假如选择器未能正确匹配 Pods，Deployment 将无法管理这些 Pods。
    
  
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。