记一次rancher导入yaml生成k8s异常

公司使用rancher来部署k8s集群，最近因为有一个新的项目开发完成需要搭建环境，因此我编写了k8s的yaml来导入到rancher中，生成一个测试环境，一个演示环境，测试环境用于测试，演示环境用于给客户演示。导入之后namespace等成功生成，测试环境没有问题，但是demo环境出现了问题。

demo环境的yaml如下:

---
apiVersion: apps/v1 #接口版本
kind: Deployment  #接口类型
metadata:
  name: xxxx-demo #Deployment名称
  namespace: xxxx-demo           #命名空间
spec:
  selector:
    matchLabels:
      app: xxxx
      tier: frontend
  replicas: 1
  strategy:
    rollingUpdate:  ##由于replicas为1,则整个升级,pod个数在2-4个之间
      maxSurge: 1      #滚动升级时会先启动1个pod
      maxUnavailable: 1 #滚动升级时允许的最大Unavailable的pod个数
  template:
    metadata:
      labels:
        app: xxxx
        tier: frontend
    spec:
      containers:
        - name: xxxx
          image: xxxxx.com:/xxxx-demo/xxxx
          env:
            - name: SPRING_PROFILE
              value: demo
          resources:
            requests:
              cpu: 200m
              memory: 200Mi
          ports:
            - containerPort: 8080
      imagePullSecrets:
        - name: xxxx
---
kind: Service
apiVersion: v1
metadata:
  name: xxxx-service
  namespace: xxxx-demo           #命名空间
spec:
  selector:
    app: xxxx-demo
  type: NodePort
  ports:                                 #service需要暴露的端口列表
    - name: string                         #端口名称
      protocol: TCP                     #端口协议，支持TCP和UDP，默认TCP
      port: 8080                            #服务监听的端口号
      targetPort: 8080                     #需要转发到后端Pod的端口号
      nodePort: 8080                        #当type = NodePort时，指定映射到物理机的端口号 The range of valid ports is 30000-32767
---

刚开始在namespace页面时看起来并没有什么问题，但是点击进入到工作负载页面后，在访问端口处展示的端口却是n/a。当时感觉不对，但是并没有在意，

查看pod日志，也能正常展示

但是通过接口进行访问时，却一直访问不到。经过多次排查，发现是因为yaml编写的问题

图中三处的APP名称必须保持一致，才能正常访问。

labels：用来定位一个或多个资源，键值对方式进行定义，下方使用的selector会与这里的键值对对应，作为selector的挑选条件

matchlabels: ** 标签选择器，与上面的标签共用，这个部分是17版本开始加的，必须与上面的labels对应,选择包含标签app:xxxx的资源

Labels的重要性

在新版的k8s中labels是非常重要的

注意：
必须在 Deployment 中指定适当的选择器和 Pod 模板标签（在本例中为app: xxxx）。不要与其他控制器（包括其他Deployments 和状态设置）重叠标签或选择器。Kubernetes不会阻止重叠，如果多个控制器具有重叠的选择器，这些控制器可能会冲突并运行意外。

matchLabels/matchExpression作用

matchLabels用于定义一组Label，与直接写在Selector中作用相同，直接给定键值；

matchExpression用于定义一组基于集合的筛选条件，基于表达式来定义使用标签选择器，{key: “KEY”, operator:
“OPERATOR”, values:[VAL1,VAL2,…]}。

可用的条件运算符包括：

In、NotIn：values字段的值必须为非空列表。
Exists、DoesNotExist：values字段的值必须为空列表。

如果同时设置了matchLabels和matchExpression，则两组条件为“AND”关系，即所有条件需要满足才能完成Selector的筛选。

matchLabels使用场景

1.kube-controller进程通过资源对象ReplicaSet上定义的Label Selector来筛选要监控的Pod副本的数量，从而实现Pod副本的数量始终符合预期设定的全自动控制流程

2.kube-proxy进程通过Service的Label Selector来选择对应的Pod，自动建立器每个Service到对应Pod的请求转发路由表，从而实现Service的智能负载均衡机制

3.通过对某些Node定义特定的Label,并且在Pod定义文件中使用NodeSelector这种标签调度策略，Kube-scheduler进程可以实现Pod定向调度的特性

Pod 选择器

.spec.selector 字段是一个标签选择器。 ReplicationController 管理标签与选择器匹配的所有 Pod。它不区分它创建或删除的 Pod 和其他人或进程创建或删除的 Pod。 这允许在不影响正在运行的 Pod 的情况下替换ReplicationController。

如果指定了 .spec.template.metadata.labels，它必须和 .spec.selector 相同，否则它将被 API拒绝。 如果没有指定 .spec.selector，它将默认为 .spec.template.metadata.labels。

另外，通常不应直接使用另一个 ReplicationController 或另一个控制器（例如 Job）来创建其标签与该选择器匹配的任何Pod。如果这样做，ReplicationController 会认为它创建了这些 Pod，就会产生冲突， Kubernetes并没有阻止你这样做。

如果在生产环境中有大量的Deployment的话，无法快速确定哪些Pod是属于哪个Deployment，这个是就体现了label标签的重要性,而我上面的yaml并没有将service中的selector与deployment中的lables对应，因此创建的pod无法与service绑定，导致访问不到。

将yaml修改成如下之后修复了这个bug

---
apiVersion: apps/v1 #接口版本
kind: Deployment  #接口类型
metadata:
  name: xxxx-demo #Deployment名称
  namespace: xxxx-demo           #命名空间
spec:
  selector:
    matchLabels:
      app: xxxx-demo
      tier: frontend
  replicas: 1
  strategy:
    rollingUpdate:  ##由于replicas为1,则整个升级,pod个数在2-4个之间
      maxSurge: 1      #滚动升级时会先启动1个pod
      maxUnavailable: 1 #滚动升级时允许的最大Unavailable的pod个数
  template:
    metadata:
      labels:
        app: xxxx-demo
        tier: frontend
    spec:
      containers:
        - name: xxxx
          image: xxxxx.com:/xxxx-demo/xxxx
          env:
            - name: SPRING_PROFILE
              value: demo
          resources:
            requests:
              cpu: 200m
              memory: 200Mi
          ports:
            - containerPort: 8080
      imagePullSecrets:
        - name: xxxx
---
kind: Service
apiVersion: v1
metadata:
  name: xxxx-service
  namespace: xxxx-demo           #命名空间
spec:
  selector:
    app: xxxx-demo
  type: NodePort
  ports:                                 #service需要暴露的端口列表
    - name: string                         #端口名称
      protocol: TCP                     #端口协议，支持TCP和UDP，默认TCP
      port: 8080                            #服务监听的端口号
      targetPort: 8080                     #需要转发到后端Pod的端口号
      nodePort: 8080                        #当type = NodePort时，指定映射到物理机的端口号 The range of valid ports is 30000-32767
---

https://blog.csdn.net/Mr1ght/article/details/118180271