kubernetes 的deployment类型控制器yaml个人理解

旧城等待， 2023-07-13 15:30 51阅读 0赞

2020.4.16更新：

最近有同学问我为啥要起deploy、service等等服务，K8S单pod启动docker镜像也能正常使用。

一般来说问道这个问题：

说明了两点：1、已经会安装K8S，且K8S已经再运行  2、已经能够成功的起pod并初步理解了pod运行

那么为什么要定义deploy、service等yaml启动文件？

首先要明白此类配置文件类型统称K8S的控制器，控制器有很多种，比如secret：管理安全的

service：管理网络的

deploy：管理pod副本的

等等一系列控制器分别担负着K8S各种管理功能；

这里需要理解管理功能；

docker 镜像通过 docker本省启动后，运行中一般只会和容器里面部署的业务代码相关，那么当容器因各种意外挂掉了，如何保证高可用？

因此刚开始出现了docker swarm集群，通过集群的方式管理，docker swarm很多容器存储卷、网段等等都需要手动处理并且后期维护需要大量的人工操作，随着容器服务部署越来越多，网段、机器性能等等各种资源需要相互竞争和高利用，需要一个更加智能的管理容器的服务出现，而这些管理服务在K8S上就是控制器；

所以K8S可以单pod启动，他的效果就和单docker镜像直接启动一样，如果正常，没什么问题；但是扩展？那么就需要像单docker一样手动再起一个pod；所以使用K8S上运行docker，目的就是为了高可用、便捷的管理容器服务；当通过deploy创建pod，那么更改pod数量直接修改deploy配置文件参数，容器服务的pod会被deploy自动的管理增减，同样的网络服务直接修改service可以实现pod批量的管理而不需要一个个手动修改；所以K8S的核心是控制器，通过控制器来管理服务的pod；

刚开始接触K8S可能会觉得控制器的yaml文件又难懂又麻烦，其实根据网络上的很多教程，多起几个服务，慢慢的就会思路清晰，K8S的配置文件都是有固定形式的，里面的参数只是有的可以不写导致看起来有的长有的短，初学的时候可以先通过全部参数都显示的带上更能快速的学习yaml配置文件；

列子：

如下是一个使用deploy控制器创建的nginx集群
    
    #资源组，必须
    apiVersion: apps/v1
    
    #资源类型，必须
    kind: Deployment
    
    #资源信息，必须
    metadata:
      #定义deploy资源启动后的名称
      name: nginxtest-deploy
      #定义该资源所属的名称空间
      namespace: test
    
    #资源期望定义
    spec:
    
      #资源的管理标签，该控制器只会管理定义的标签相同的pod
      selector:
        #定义以KEY value形式映射类型
        matchLabels:
          #定义标签内容
          app: nginx
    
      #定义资源运行后管理的pod副本数
      replicas: 2
      
      #定义资源启动的pod模板
      template: 
        
        metadata:
          #定义模板启动的镜像标签，注意这里的pod模板的标签KV值必须和定义的控制器标签的KV值一致，即和selector的标签一致，否则该控制器找不到创建的pod会报错
          labels:
            app: nginx
        
        #定义模板启动的镜像信息    
        spec:
          #镜像名称和容器名称，启动后端口等等
          containers:
          - name: nginx-t
            image: 192.168.1.2:5000/nginx:latest
            #ports:
              #- containerPort:80
    
          #定义从私仓拉取的secret，前提是首先已经有了secret    
          imagePullSecrets:
          - name: regs
    
    
    关于K8S配置文件：基本格式的一级参数一般有：apiVersion kind metadata spec status
    这五个参数中前面四个是手写配置文件一般来说需要手动填写的
    
    apiVersion:资源组，创建的资源类型属于K8S哪个组，该信息可以通过命令查询，例如：
    root@k8smaster:/app/k8s/conf/ym# kubectl api-resources | grep deployment
    deployments                       deploy       apps                           true         Deployment
    
    可以看到deployments资源在K8S中属于apps组，简写命令可以是deploy，类型是Deployment
    apiVersion是必填项目，根据K8S版本不同，所属的资源类型在K8S中所属组不一定相同，需要根据该版本的资源类型组分类填写
    
    kind：K8S资源类型，包括pod deploy service secret等等一些了组件，在K8S中都属于资源，而kind则是配置文件中区分创建的进程属于哪种资源类型
    如上的配置文件，创建的就是deploy类型的资源
    
    
    metadata：指定创建的资源在K8S中的相关属性，注意该属性大多数和K8S本身相关，比如创建的资源在K8S中属于哪个namespace名称空间，该资源运行后名称是啥等等
    
    spec：是一个非常核心的参数，里面定义了我们所期望服务运行的状态，从哪里运行，怎么运行等等一些列规则
          里面一般基于容器，包含其相关启动后构建出pod的信息，
          在这里能够定义组件多少个副本的pod集群：运行两个 三个 或是多个
          或是定义几个镜像来构成一个pod：如一个pod运行nginx 在配合一个日志收集服务镜像
          或是定义镜像拉取方式：从本地私仓还是docker hub拉取
          或是定义是否使用secret
          或是定义资源标签等等一些列对资源管理和容器管理的属性
    
    status：K8S自行打出的资源状态，一般不由人工填写
    
    K8S很多参数都可以省略，它会自动填写，比如labels标签，namespace，但是有些参数为了方便人员的记忆与管理，最好还是自定义
    在K8S，可以直接创建pod而不是用控制器，可以使用控制器通过控制器来创建pod，不使用控制器，操作起来和用docker单机感觉差不多，就体现不出K8S的强大
    K8S控制器才是容器服务的核心，通过控制器可以快速并智能的管理多个容器集群，能快速扩展或是变更网络服务等等，同样的可以创建RC类型控制器的pod集群或其他控制器的集群，模板都差不多