【转】kubernetes 中 deployment 支持哪些键值

最近在看 kubernetes deployment 部分，按照其文档中的例子进行了一些增删改查DP(deployment 简称DP)的操作，感觉还是很有意思的官方文档。不过，其参考例子都比较简单，要是在生产环境中使用时肯定是不够的，那么问题来了： DP到底支持哪些键值呢？

我花了点时间对DP支持的键值对进行了整理(当然能力有限，不一定非常全面)，希望能对 kubernetes 初学者有所帮助。

Deloyment example yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment2
 namespace: hmm-test  labels:  app: nginx2  zone: us-est-coast  cluster: test-cluster1  rack: rack-22 # label的扩展， 通常label是给selector用的，具有识别的目的。有时候我们也需要添加一些非识别目的的数据(用来API检索等用)。 # annotations的数据没有label严格（长度、是都结构化等等），可以添加入：环境信息(build/release/image等)、code 信息(commit/repo)、user等等  annotations: # 自定义字段  build: two  builder: john-doe # init container 也是放到了annotations中 pod.beta.kubernetes.io/init-containers: '[ { "name": "install", "image": "busybox", "command": ["wget", "-O", "/work-dir/index.html", "http://kubernetes.io"], "volumeMounts": [ { "name": "workdir", "mountPath": "/work-dir" } ] }, { "name": "init-myservice", "image": "busybox", "command": ["sh", "-c", "until nslookup myservice; do echo waiting for myservice; sleep 2; done;"] }, { "name": "init-mydb", "image": "busybox", "command": ["sh", "-c", "until nslookup mydb; do echo waiting for mydb; sleep 2; done;"] } ]' spec:  hostPID: true  hostIPC: true  hostNetwork: true  replicas: 1  selector:  matchLabels:  app: nginx2  strategy:  rollingUpdate:  maxSurge: 1  maxUnavailable: 1  type: RollingUpdate  template:  metadata:  creationTimestamp: null  labels:  app: nginx2  spec:  imagePullSecrets:  - name: regsecret # 调度到满足disktype=ssd的label的一组node上  nodeSelector:  disktype: ssd # 通过nodeName创建到1台node上  nodeName: "node01.test.k8s.qihoo.net" # 还支持亲和性/反亲和性 与nodeSelector结合的还有一个亲和性和反亲和性的新特性(https://kubernetes.io/docs/user-guide/node-selection/)，目前处于alpha阶段(支持类似正则表达式的联合判断)  containers:  - image: r.addops.cn/public/nginx:1.6.3  imagePullPolicy: IfNotPresent  name: nginx21 #The command and arguments that you define in the configuration file override the default command and arguments provided by the container image. If you define args, but do not define a command, the default command is used with your new arguments.  command: ["printenv"]  args: ["HOSTNAME", "KUBERNETES_PORT"] # 资源分配  resources:  requests:  memory: "64Mi"  cpu: "250m"  limits:  memory: "128Mi"  cpu: "1"  workingDir: /data/nginx # 容器内部权限控制 # https://kubernetes.io/docs/concepts/policy/container-capabilities/  securityContext:  privileged: true  capabilities:  add:  - SYS_NICE  drop:  - KILL # 这个主要是用来调试程序用的(在开发测试环境的DP中可使用，线上就别用了)  terminationMessagePath: /dev/termination-log  ports:  containerPort: 80  containerPort: 443  volumeMounts: # POD中的每个container可以设置自己的内部挂载点 # 每个挂载点通过下面volumes中的name来指定把哪个volume挂载到哪里  - name: redis-storage  mountPath: /data/redis  readOnly: true  - name: hostpath-storage  mountPath: /data/test  env:  - name: DEMO_GREETING  value: "Hello from the environment"  dnsPolicy: ClusterFirst  restartPolicy: Always  terminationGracePeriodSeconds: 30 官方给了探活容器内服务的方案, 目前支持命令方式和HTTP方式 命令行方式  venessProbe:  exec:  command:  - cat  - /tmp/healthy  initialDelaySeconds: 5 # container 启动5s后开始执行检测  periodSeconds: 5 # 每隔 5s种执行一次  timeoutSeconds: 1 # 超时时间，默认1s  successThreshold: 1 # 几次成功才认为是成功，默认是1  failureThreshold: 3 # 几次失败认为失败(有点报警合并的感觉)默认是3 HTTP 方式  venessProbe:  httpGet:  path: /healthz  host: hostname/ip # 默认是POD/container的IP，通常你无须设置该值。有一种场景会用到，Suppose the Container listens on 127.0.0.1 and the Pod’s hostNetwork field is true. Then host, under httpGet, should be set to 127.0.0.1. If your pod relies on virtual hosts, which is probably the more common case, you should not use host, but rather set the Host header in httpHeaders  port: 8080  httpHeaders:  - name: X-Custom-Header  value: Awesome  scheme: HTTP  initialDelaySeconds: 3  periodSeconds: 3 #　container 的 HOOK 支持,可以在启停容器前做一些处理  lifecycle:  postStart:  exec:  command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]  preStop:  exec:  command: ["/usr/sbin/nginx","-s","quit"]  volumes:  - name: redis-storage # emptDir生命周期与POD相同；创建在docker damon存储backend上，也支持使用RAM(emptyDir.medium设置为Memory即可) # emptyDir一般使用在下面这3中场景中： # 1. 适用与数据的临时存储，例如归并排序程序(用到磁盘来暂时存放和处理数据) # 2. 从crashs恢复时需要的临时存储 # 3. 一个容器获取数据，POD内其它容器消费数据(共享数据)  emptyDir: {}  - name： hostpath-storage  hostPath: # directory location on host  path: /data # 对于 rbd 而言，如果设置成只读的话可以给多个使用者共享，对于RW模式而言的话，不暴增数据一致性  - name: rbd-storage  monitors: 192.168.78:6789 192.168.82:6789 192.168.83:6789  pool: kube,  image: foo,  user: admin,  keyring: /etc/ceph/keyring,  fsType: ext4,  readOnly: true # 持久卷(要先创建persistentVolumeClaim资源)  - name: task-pv-storage  persistentVolumeClaim:  claimName: task-pv-claim # 另外volume还提供了 secret volume的支持，用于对一些比较敏感的数据加密处理 # 例如：username+password啥的，需要先创建kind为secret的资源对象 # 在上面挂载点地方添加对应的挂载path就可以在容器内读写这些信息了  - name: secret-volume  secret:  secretName: test-secret 

        

          
        
        
        

          

          AI 代码解读
        
      
      

补充

卷子目录

subPth 子目录： 提供一个POD下多个container共享同一个volume下不同目录的功能 例如：一个POD中运行1个mysql 容器和1个php容器，他们共享同一个volume下的不同目录，可以如下方式使用

      - name: mysql
        image: mysql
        volumeMounts:
        # 将 site-data 卷下的 mysql 目录挂载到mysql容器内的/var/lib/mysql 目录
 - mountPath: /var/lib/mysql  name: site-data  subPath: mysql  - name: php  image: php  volumeMounts: # 将 site-data 卷下的 html 目录挂载到php容器内的/var/www/html 目录  - mountPath: /var/www/html  name: site-data  subPath: html  volumes:  - name: site-data  persistentVolumeClaim:  claimName: my-lamp-site-data 

        

          
        
        
        

          

          AI 代码解读
        
      
      

POD 内 container 与 POD 互相获取信息

官方提供了 container 获取其所属 POD 信息 和 POD 获取其内 container 信息的功能 两种方式：

1. 通过环境变量（如下所示，这里fieldPath中的spec、metadata都是POD的）

    # 以下这是container获取POD的信息
   - name: MY_NODE_NAME
     valueFrom:
       fieldRef:
 fieldPath: spec.nodeName  - name: MY_POD_NAME  valueFrom:  fieldRef:  fieldPath: metadata.name  - name: MY_POD_NAMESPACE  valueFrom:  fieldRef:  fieldPath: metadata.namespace  - name: MY_POD_IP  valueFrom:  fieldRef:  fieldPath: status.podIP  - name: MY_POD_SERVICE_ACCOUNT  valueFrom:  fieldRef:  fieldPath: spec.serviceAccountName # 以下这是 POD 获取指定container（通过name）的信息  - name: MY_CPU_REQUEST  valueFrom:  resourceFieldRef:  containerName: test-container  resource: requests.cpu  - name: MY_CPU_LIMIT  valueFrom:  resourceFieldRef:  containerName: test-container  resource: limits.cpu  - name: MY_MEM_REQUEST  valueFrom:  resourceFieldRef:  containerName: test-container  resource: requests.memory  - name: MY_MEM_LIMIT  valueFrom:  resourceFieldRef:  containerName: test-container  resource: limits.memory 

        

          
        
        
        

          

          AI 代码解读
        
      
      

1. 通过 downwardAPIVolumesFileds, 将信息以文件和卷的方式挂载到容器内部

   volumes:
    - name: podinfo
      downwardAPI:
        items:
          # 这种是将POD的信息挂载到容器内 # 在容器/etc/目录下会生成lables和annotations文件 # /etc/labels 和 /etc/annotations 里面的内容就是POD的labels值和annotations值  - path: "labels"  fieldRef:  fieldPath: metadata.labels  - path: "annotations"  fieldRef:  fieldPath: metadata.annotations # 这种是将指定container的信息挂载到容器内 # 同理会在容器内部的/etc/目录下生成相应的文件,如/etc/limits_cpu  - path: "cpu_limit"  resourceFieldRef:  containerName: client-container  resource: limits.cpu  - path: "cpu_request"  resourceFieldRef:  containerName: client-container  resource: requests.cpu  - path: "mem_limit"  resourceFieldRef:  containerName: client-container  resource: limits.memory  - path: "mem_request"  resourceFieldRef:  containerName: client-container  resource: requests.memory # downwardAPI 目前支持如下几种信息 #The following information is available to Containers through environment variables and DownwardAPIVolumeFiles: #The node’s name #The Pod’s name #The Pod’s namespace #The Pod’s IP address #The Pod’s service account name #A Container’s CPU limit #A container’s CPU request #A Container’s memory limit #A Container’s memory request #In addition, the following information is available through DownwardAPIVolumeFiles. #The Pod’s labels #The Pod’s annotations # 如果容器没有指定CPU和memory，则获取的NODE的值 
   
           
   
             
           
           
           
   
             
   
             AI 代码解读
           
         
         

持久卷

kind: PersistentVolume
apiVersion: v1
metadata:
  name: task-pv-volume
 labels:  type: local  annotations: # 支持分组(其在StorageClass定义时通过annotations指定 # 详见 https://kubernetes.io/docs/user-guide/persistent-volumes/ 中StorageClass定义 volume.beta.kubernetes.io/storage-class: "slow" spec:  capacity:  storage: 10Gi  accessModes: # ReadOnlyMany/ReadWriteMany  - ReadWriteOnce # https://kubernetes.io/docs/user-guide/persistent-volumes/ 给出了每种存储支持的类型  persistentVolumeReclaimPolicy: Recycle  rbd:  path: "/tmp/data" --- kind: PersistentVolumeClaim apiVersion: v1 metadata:  name: task-pv-claim  annotations: # 会与设置相同值的PV绑定 volume.beta.kubernetes.io/storage-class: "slow" spec:  accessModes:  - ReadWriteOnce # 选择与volume相同访问权限的persistentvolume  resources:  requests:  storage: 3Gi  selector:  matchLabels:  release: "stable"  matchExpressions:  - {key: environment, operator: In, values: [dev]} 

        

          
        
        
        

          

          AI 代码解读
        
      
      

对于 Service、PersistentVolumeClaim 等其它资源都可以放到 DP 中编排，以后补充。

未完，待续 ~~