标签：kubectl name Kubernetes 容器 nginx 深入 Pod metadata

1.获取资源

kubectl get <reousrce_type>

2.查看资源详情

kubectl describe <reousrce_type> <reousrce_name>

3.kubernetes设计Pod中为何要有pause根容器

• Pause作为Pod的根容器，可以代表整个容器组的状态
• Pod里的多个业务容器共享Pause容器的IP，共享Pause容器挂接的Volume，简化了业务容器之间的通信问题，也解决了它们之间文件共享问题

4.修改RC（Replication Controller）的副本数量来实现Pod的动态缩放

# 维持三个副本
kubectl scale rc <pod_name> --replicas=3

5.创建Horizontal Pod Autoscaler

# 自动进行副本数量管理，当cpu占用大于90%，pod副本数量为1~10
kubectl autoscale deployment <deployment_name> --cpu-percent=90 --min=1 --max=10

6.StatefulSet

管理有状态服务，如mysql集群、kafka集群、zookeeper集群等
StatefulSet可以看作Deployment/RC的变种
如果StatefulSet名称为kafka，那么第一个Pod叫kafka-0，第二个叫kafka-1，以此类推

7.查看资源yaml

kubectl get <resource_type> <resource_name> -o=yaml

8.删除资源

# 删除所有Pod
kubernetes delete pods --all
# 删除包含某个Label的Pod和Service
kubernetes delete pods,services -1 name=<label-name>

9.执行容器的命令

# 执行Pod的date命令，默认使用Pod中的第一个容器执行
kubectl exec <pod_name> date
# 指定Pod中的某个容器执行date命令
kubectl exec <pod_name> -c <container_name> date
# 通过bash获得Pod中某个容器的TTY，相当于登录容器
kubectl exec -ti <pod_name> -c <container_name> /bin/bash

10.查看容器的日志

# 查看容器输出到stdout的日志
kubectl logs <pod_name>
# 跟踪查看容器的日志，相当于tail -f命令的结果
kubectl logs -f <pod_name> -c <container_name>

11.创建资源对象

# 根据yaml配置文件一次性创建Service和RC
kubectl create -f my-service.yaml -f my-rc.yaml
# 根据<directory>目录下的所有.yaml、.yml、.json文件的定义进行创建
kubectl create -f <directory>

12.创建或更新资源对象

# 用法与kubectl create类似，但是create不能做更新
kubectl apply -f app.yaml

13.在线编辑运行中的资源对象

# 编辑运行中的deployment
kubectl edit deploy nginx

14.将Pod的开放端口映射到本地

# 将集群上Pod的80端口映射到本地的8888端口，浏览器可通过localhost:8888进行访问
kubectl port-forward --address 0.0.0.0 \ pod/<pod_name> 8888:80

15.在Pod和本地之间复制文件

# 把Pod上的/etc/fstab 复制到本地的/tmp
kubernetes cp <pod_name>:/etc/fstab /tmp

16.资源对象的标签设置

# 为default namespace设置testing=true
kubectl label namespaces default testing=true

17.检查可用的API资源类型列表

# 该命令经常用于检查特定类型的资源是否已经定义，列出所有资源对象类型
kubectl api-resources

18.通过kubectl创建ConfigMap

# 通过--from-file，指定文件，key就是文件名，value就是文件内容
kubectl create configmap <cm_name> --from-file=<file_name> --from-file=<file_name>
# 通过--from-file参数从目录中进行创建，该目录下的每个配置文件名都被设置为key，文件的内容被设置为value
kubectl create configmap <cm_name> --from-file=<config_file_dir>
# 使用--from-literal，直接将指定key和value
kubectl create configmap <cm_name> --from-literal=key1=value1 --from-literal=key2=value2

19.Pod挂载ConfigMap

# 环境变量方式（1）
apiVersion: v1
kind: Pod
metadata:
  name: cm-test-pod
spec:
  containers:
    - name: cm-test
      image: busybox
      command: ["/bin/sh", "-c", "env | grep APP"]
      env:
        # 定义环境变量名称
        - name: APPLOGLEVEL
          # key"apploglevel"对应的值
          valueFrom:
            configMapKeyRef:
              # configmap的名称
              name: cm-appvars
              # key为apploglevel
              key: apploglevel
        - name: APPDATADIR
          valueFrom:
            configMapKeyRef:
              name: cm-appvars
              key: appdatadir
  restartPolicy: Never
  
# 环境变量方式（2），k8s1.6开始，引入了一个新字段evnFrom，会自动将ConfigMap种所有定义的key-value生成为环境变量
apiVersion: v1
kind: Pod
metadata:
  name: cm-test-pod
spec:
  containers:
    - name: cm-test
      image: busybox
      command: ["/bin/sh", "-c", "env"]
      envFrom:
        - configMapRef:
          # configmap名称
          name: cm-appvars
  restartPolicy: Never
  
# 通过volumeMount使用ConfigMap
apiVersion: v1
kind: Pod
metadata:
  name: cm-test-pod
spec:
  containers:
    - name: cm-test
      image: busybox
      ports:
      - containerPort: 8087
      volumeMounts:
        # 引用volume名称
        - name: vname
          # 挂载到容器内的目录
          mountPath: /configfiles
  volumes:
    # 定义volume名称
    - name: vname
      configMap:
        # configmap名称
        name: cm-appvars

20.进入容器内部

kubectl exec -ti <pod_name> bash

21.在容器内获取Pod信息(Downward API)

可以获取Pod名称、命名空间、IP等；通过查看Pod日志获取信息

# 环境变量方式：将Pod信息注入为环境变量
# metadata.name：Pod的名称，当Pod通过RC生成时，其名称是RC随机产生的唯一名称。
# status.podIP：Pod的IP地址，之所以叫作status.podIP而非metadata.IP，是因为Pod的IP属于状态数据，而非元数据。
# metadata.namespace：Pod所在的Namespace
apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: dapi-test
      image: busybox
      command:
        - /bin/sh
        - '-c'
        - env
      env:
        - 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
# 环境变量方式：将容器资源信息注入为环境变量
apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: dapi-test
      image: busybox
      imagePullPolicy: Never
      ports:
        - containerPort: 8087
      command:
        - /bin/sh
        - '-c'
      env:
        - name: MY_CPU_REQUEST
          valueFrom:
            resourceFieldRef:
              containerName: dapi-test
              resource: requests.cpu
        - name: MY_CPU_LIMIT
          valueFrom:
            resourceFieldRef:
              containerName: dapi-test
              resource: limits.cpu
        - name: MY_MEM_LIMIT
          valueFrom:
            resourceFieldRef:
              containerName: dapi-test
              resource: limits.memory
# 挂载volume方式
---

22.Pod状态

Pending：API Server已经创建该Pod，但在Pod内还有一个或多个容器的镜像还没被创建，包括正在下载镜像的过程；
Running：Pod内所有的容器均已创建，且至少有一个容器处于运行状态，正在启动状态或正在重启状态；
Succeeded：Pod内所有容器均已成功执行后退出，且不会重启；
Failed：Pod内所有容器均已退出，但至少有一个容器退出为失败状态；
Unknow：由于某种原因无法获取该Pod状态，可能由于网络通信不畅导致。

23.Pod重启策略

Pod重启策略（RestartPolicy）应用于Pod内的所有容器，并且在Pod所处的Node上由kubelet进行判断和重启操作。当某个容器异常退出或健康检查失败时，kubelet将根据RestartPolicy的设置来进行相应的操作。

Pod的重启策略包括 Always(默认)、OnFailure、Never：

• Always：当容器失败时，由kubelet自动重启该容器；
• OnFailure：当容器终止运行且退出码不为0时，由kubelet重启该容器；
• Never：不论容器运行状态如何，kubelet都不会重启该容器。

kubelet重启失效容器的时间间隔以sync-frequnecy乘以2n来计算，例如1、2、4、8倍等，最长延迟5min，并且在重启后10min后重置该时间。

Pod重启策略与控制方式：

• RC和DaemonSet：必须设置为Always，需要保证该容器持续运行；
• Job：OnFailure或Never，确保容器执行完后不会再运行；
• Kubelet：在Pod失效时自动重启它，不论将RestartPolicy设置为什么值，也不会对Pod进行健康检查。

24.Pod健康检查和服务可用性检查

Kubernetes对Pod的健康检查可以通过两类探针来检查：LivenessProbe和ReadinessProbe。
LivenessProbe探针：用于判断容器是否存活（Running状态），如果LivenessProbe探测到容器不健康，则kubelet将杀死该容器，并根据容器的重启策略进行相应的处理。如果一个容器不包括LivenessProbe探针，那么kubelet则会认为该容器的LivenessProbe探针返回的结果永远是success。
ReadinessProbe探针：用于判断容器是否可用（Ready状态），达到Ready状态的Pod才可以接收请求。对于背Service管理的Pod，Service与Pod Endpoint的关联关系也将基于Pod受否Reday进行设置。如果在运行过程中Ready变为Flase，则系统自动将其从Service的后端Endpoint列表中隔离出去，后续再把恢复到Ready状态的Pod加入到Endpoint列表。这样可以保证客户端再访问Service时不会被转发到不可用的Pod实例上。
LivenessProbe和ReadinessProbe均可配置以下三种实现方式：

• ExecAction：在容器内执行一个命令，如果该命令返回值为0，则表明容器健康。

# initialDelaySeconds 启动容器后进行首次健康检查的时间
# timeoutSeconds 健康检查发送请求后等待响应的超时时间
# 通过执行“cat /tmp/health”命令来判断一个容器运行是否正常。在该Pod运行后，将在创建/tmp/health文件10s后删除该文件，而LivenessProbe健康检查的初始探测时间（initialDelaySeconds）为15s，探测结果是Fail，将导致kubelet杀掉该容器并重启它
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
    - name: liveness
      image: nginx
      args:
        - /bin/sh
        - '-c'
        - echo ok > /temp/healthy; sleep 10; rm -rf /temp/healthy; sleep 600
      livenessProbe:
        exec:
          command:
            - cat
            - /temp/healthy
        initialDelaySeconds: 15
        timeoutSeconds: 1

• TCPSocketAction：通过容器的IP地址和端口号执行TCP检查，如果能够建立TCP连接，则表明容器健康。

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
    - name: liveness
      image: nginx
      ports:
        - containerPort: 80
      livenessProbe:
        tcpSocket:
          port: 80
        initialDelaySeconds: 15
        timeoutSeconds: 1

• HTTPGetAction：通过容器的IP地址、端口号及路径调用HTTP
  GET方法，如果响应的状态码大于等于200小于400，认为容器健康。

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
    - name: liveness
      image: nginx
      ports:
        - containerPort: 80
      livenessProbe:
        httpGet:
          path: /_status/heathz
          port: 80
        initialDelaySeconds: 15
        timeoutSeconds: 1

Kubernetes的ReadinessProbe机制可能无法满足某些复杂应用对容器内服务可用状态的判断，1.11版本开始，引入Ready++，1.14版本达到稳定版，称其为Pod Readiness Gates。

25.Deployment全自动调度

# 会创建3个Nginx应用的Pod
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-server
  template:
    metadata:
      labels:
        app: nginx-server
    spec:
      containers:
        - name: nginx-deployment
          image: nginx
          ports:
            - containerPort: 80

26.NodeSelector定向调度

Kubernetes Master上的Scheduler服务（kubernetes-scheduler进程）负责实现Pod的调度，整个调度过程通过执行一系列复杂的算法，最终为每个Pod都计算出一个最佳的目标节点，这一过程是自动完成的，通常我们无法知道Pod最终会调度到哪个节点上。如果需要将Pod调度到指定节点上，可以通过Node标签（Label）和Pod的nodeSelector属性相匹配 。

# 1.通过kubectl label命令给目标Node打上标签
kubectl label nodes <node_name> <label_key>=<label_value>

# 2.在Pod的定义中加上nodeSelector的设置
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: nginx
          image: nginx
          ports:
            - containerPort: 80
      nodeSelector:
        <label_key>: <label_value>

27.NodeAffinity亲和性调度

NodeAffinity意为Node亲和性的调度策略，适用于替换NodeSelector的全新调度策略。目前有两种节点亲和性表达。

• RequiredDuringSchedulingIgnoredDuringExecution：必须满足指定规则才可以调度Pod到Node上，相当于硬限制。
• PreferredDuringSchedulingIgnoredDuringExecution：强调优先满
  足指定规则，调度器会尝试调度Pod到Node上，但并不强求，相当于软 限制。多个优先级规则还可以设置权重（weight）值，以定义执行的先
  后顺序。

IgnoredDuringExecution的意思是：如果一个Pod所在的节点在Pod运 行期间标签发生了变更，不再符合该Pod的节点亲和性需求，则系统将 忽略Node上Label的变化，该Pod能继续在该节点运行。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-server
  template:
    metadata:
      labels:
        app: nginx-server
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                  # kubernetes预定义标签
                  - key: beta.kubernetes.io/arch
                    # 也有NotIn
                    operator: In
                    values:
                      - amd64
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 1
              preference:
                matchExpressions:
                  - key: disk-type
                    operator: In
                    values:
                      - ssd
      containers:
        - name: nginx-deployment
          image: nginx
          ports:
            - containerPort: 80

注意：如果同时定义了nodeSelector和nodeAffinity，那么必须都得到满足；如果nodeAffinity指定了多个nodeSelectorTerms，那么满足其中一个就可以；如果nodeSelectorTerms种有多个matchExpressions，则一个点满足matchExpressions才能运行该Pod。

28.PodAffinity亲和与互斥调度策略

PodAffinity根据节点上正在运行的Pod的标签而不是节点的标签进行判断和调度，要求对节点和Pod两个条件进行匹配。
例如：如果在具有标签X的Node上运行了一个或多个符合条件Y的Pod，那么Pod应该运行在这个Node上；
这里X指的是一个集群中的节点、机架、区域等概念，通过Kubernetes内置节点标签中的key来进行声明，这个key的名字为topologyKey，意为表达节点所属的topology范围。与节点不同的是，Pod是属于某个命名空间的，所以条件Y表达的是一个或者多个命名空间中的一个Label Selecotr。
和节点亲和性相同，Pod亲和与互斥的条件设置也是 requiredDuringSchedulingIgnoredDuringExecution和
preferredDuringSchedulingIgnoredDuringExecution。Pod的亲和性被定义于PodSpec的affinity字段下的podAffinity子字段中。Pod间的互斥性则被定义于同一层次的podAntiAffinity子字段中。

# 1.创建一个名为pod-flag的Pod，带有标签security=S1和app=nginx，使用该Pod作为其他Pod亲和于互斥的目标Pod
apiVersion: v1
kind: Pod
metadata:
  name: pod-flag
  labels:
    security: S1
    app: nginx
spec:
  containers:
    - name: nginx
      image: nginx
# 2.创建第二个pod来说明pod的亲和性，亲和标签为security=S1，对应目标pod，创建后与pod-flag在同一node
apiVersion: v1
kind: Pod
metadata:
  name: pod-affinity
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
              - key: security
                operator: In
                values:
                  - S1
          topologyKey: kubernetes.io/hostname
  containers:
    - name: with-pod-affinity
      image: nginx
# 3.pod的互斥性调度，该pod不与目标pod运行在同一节点
# 要求该pod与security=S1的pod为同一个zone，但不与app=nginx的pod为同一个node
apiVersion: v1
kind: Pod
metadata:
  name: anti-affinity
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
              - key: security
                operator: In
                values:
                  - S1
          topologyKey: failure-domain.beta.kubernetes.io/zone
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
           matchExpressions:
              - key: app
                operator: In
                values:
                  - nginx
          topologyKey: kubernetes.io/hostname
  containers:
    - name: with-pod-affinity
      image: nginx

29.Taints和Tolerations（污点和容忍）

Taint需要和Toleration配合使用，让Pod避开那些不适合的Node。在Node上设置一个或多个Taint之后，除非Pod明确声明能够容忍这些污点，否则无法在这些Node上运行。Toleration是Pod的属性，让Pod能够运行在标注了Taint的Node上。

# 污点值：NoSchedule(一定不被调度) PreferNoSchedule(尽量不被调度) NoExecute(不被调度，并且驱除已有pod)
# 设置污点，key、value随便写
kubectl taint node <node_name> <key>=<value>:污点值
# 删除污点
kubectl taint node <node_name> <key>:NoSchedule-  # 这里的key可以不用指定value
kubectl taint node <node_name> <key>:NoExecute-
kubectl taint node <node_name> <key>-
kubectl taint node <node_name> <key>:NoSchedule-
这个设置为node加上了一个Taint，该Taint的键为key，值为value，Taint的效果是NoSchedule。意味着除非Pod明确声明可以容忍该Taint，否则不会被调度到该node上。

# 设置污点容忍，该Pod可以运行在污点为<key>的node上
apiVersion: v1
kind: Pod
metadata:
  name: taint-pod
spec:
  tolerations:
    - key: <key>
      operator: Equal
      value: value
      # operator: Exists 效果与以上相同
      effect: NoSchedule
  containers:
    - name: nginx
      image: nginx

Pod的Toleration声明中的key和effect需要与Taint的设置保持一致，并且满足以下条件之一：

• operator的值是Exists（无需指定value）。
• operator的值是Equal并且value相等。

如果不指定operator，则默认为Equal，另外，有如下两个特例：

• 空的key配合Exists操作符能够匹配所有的键和值。
• 空的effect匹配所有的effect。

effect取值：

• NoSchedule：Pod没有声明容忍该taint，则调度器不会把该Pod调度到这一节点上。
• PreferNoSchedult：调度器会尝试不把该Pod调度到这个节点上（不强制）。
• NoExecute：如果该Pod已经在该节点运行，则会被驱逐；如果没有，则调度器不会把该Pod调度到这一节点（
  可以设置驱逐时间，eg:tolerationSeconds =5000，在5s钟后被驱逐）。

30.Pod Priority Preemption：Pod优先级调度

当发生资源不足的情况时，系统可以选择释放一些不重要的负载（优先级最低的），保障最重要的负载能够有足够的资源稳定运行。

# 1.定义一个名为high-priority的优先级类别，优先级为1000000，数字越大，优先级越大，超过一亿的数字被系统保留，用于指派给系统组件
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
globalDefault: false
description: This priority class should be used for XYZ service pods only
# 2.在Pod上引用上述Pod优先级类别，priorityClassName: high-priority
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
    - name: nginx
      image: nginx
      imagePullPolicy: IfNotPresent
  priorityClassName: high-priority
31.DaemonSet：在每个Node上都调度一个Pod
DaemonSet的Pod调度策略与RC类似，除了使用系统内置的算法在每个Node上进行调度，也可以在Pod的定义中使用NodeSelector或NodeAffinity来指定满足条件的Node范围进行调度。
# 每个Node上都启动一个fluentd容器，其中挂载了物理机的两个目录/var/log和/var/lib/docker/containers
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-cloud-logging
  namespace: kube-system
  labels:
    k8s-app: fluentd-cloud-logging
spec:
  selector:
    matchLabels:
      k8s-app: fluentd-cloud-logging
  template:
    metadata:
      namespace: kube-system
      labels:
        k8s-app: fluentd-cloud-logging
    spec:
      containers:
        - name: fluentd-cloud-logging
          image: ist0ne/fluentd-elasticsearch
          imagePullPolicy: IfNotPresent
          resources:
            limits:
              cpu: 100m
              memory: 200Mi
          env:
            - name: FLUENTD_ARGS
              value: '-q'
          volumeMounts:
            - name: varlog
              mountPath: /var/log
              readOnly: false
            - name: containers
              mountPath: /var/lib/docker/containers
              readOnly: false
      volumes:
        - name: containers
          hostPath:
            path: /var/lib/docker/containers
        - name: varlog
          hostPath:
            path: /var/log

32.Init Container：初始化容器

用于在启动应用容器之前启动一个或多个初始化容器，完成应用容器所需的预置条件。init container与应用容器在本质上是一样的，但它们是仅运行一次就结束的任务。根据Pod的重启策略（RestarPolicy），当init container执行失败，而且设置了RestartPolicy=Never时，Pod将会启动失败；而设置RestartPolicy=Always时，Pod将会被系统重启。

# initContainers
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  initContainers:
    - name: install
      image: busybox
  containers:
    - name: nginx
      image: nginx
      ports:
        - containerPort: 80

33.Deployment的升级与回滚

# 修改镜像名称
kubectl set image deployment <deployment_name> <container_name>=<image_name>:<version>
# 查看修改状态
kubectl rollout status deployment <deployment_name>
# 查看历史版本
kubectl rollout history deployment <deployment_name>
# 回滚到上个版本
kubectl rollout undo deployment <deployment_name>
# 回滚到指定版本（3是查看历史版本里面的版本号）
kubectl rollout undo deployment <deployment_name> --to-revision=3

34.暂停和恢复Deployment的部署操作，以完成复杂的修改

对于一次复杂的Deployment配置修改，为了避免频繁触发Deployment的更新操作，可以先暂停Deployment的更新操作，然后进行配置修改，再恢复Deployment，一次性触发完整的更新操作，就可以避免不必要的Deployment更新操作。

# 暂停deployment更新操作
kubectl rollout pause deployment <deployment_name>
# 修改deployment镜像信息
kubectl set image deployment <deployment_name> <container_name>=<image_name>:<version>
# 查看修改deployment的历史记录，发现并没有触发新的deployment部署操作
kubectl rollout history deploy <deploy_name>
# 再次更新容器资源限制
kubectl set resources deploy <deploy_name> -c=<container_name> --limits=cpu=200m,memory=512Mi
# 最后，恢复这个deployment的部署操作
kubectl rollout resume deploy <deploy_name>

注意：暂停状态的Deployment无法回滚！

35.使用kubectl rolling-update命令完成RC的滚动升级

kubectl rolling-update <rc_name> --image=<image_name>:<version>

36.Pod手动扩容机制

# 将pod数量维持在10个
kubectl scale deploy <deploy_name> --replicas 10

37.Pod自动扩容机制

Kubernetes从1.1版本开始，新增了名为Horizontal Pod AutoScaler（HPA）的控制器，用于实现基于CPU使用率进行自动Pod扩缩容的功能。HPA控制器基于Master的kube-controller-manager服务启动参数–horizontal-pod-autoscaler-sync-period定义探测周期（默认为15s），周期性地检测目标Pod的资源性能指标，并与HPA资源对象中的扩缩容条件进行对比，在满足条件时对Pod副本数量进行调整。
HPA工作原理：
Kubernetes中的某个Metrics Server（Heapster或自定义Metrics Server）持续采集所有Pod副本的指标数据。HPA控制器通过Metrics Server的API（Heapster的API或聚合API）获取这些数据，基于用户定义的扩缩容规则进行计算，得到目标Pod副本数量。当目标Pod数量与当前副本数量不同时，HPA控制器就向Pod的副本控制器（Deployment、RC或ReplicaSet）发起scale操作，调整Pod的副本数量，完成扩缩容操作。
HPA配置详解：
Kubernetes将HPA资源对象提供给用户来定义扩缩容的规则。
HPA资源对象处于Kubernetes的API组“autoscaling”中，目前包括v1和v2两个版本。其中autoscaling/v1仅支持CPU使用率的自动扩缩容，autoscaling/v2则用于支持基于任意指标的自动化扩缩容配置，包括基于资源使用率、Pod指标、其他指标等类型的指标数据。
（1）基于autoscaling/v1版本的HPA配置，仅可设置CPU使用率：

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
spec:
  # 目标作用对象，可以是Deployment、ReplicationController或ReplicaSet
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  # Pod副本数量的最小值和最大值
  minReplicas: 1
  maxReplicas: 10
  # 期望每个Pod的CPU使用率都为50%，该使用率基于Pod设置的CPU Request值进行计算
  targetCPUUtilizationPercentage: 50

注意：使用autoscaling/v1版本的HPA，需预先安装Heapster组件或Metrics Server，用于采集CPU使用率。
（2）基于autoscaling/v2beta2的HPA配置：

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
spec:
  # 目标作用对象，可以是Deployment、ReplicationController或ReplicaSet
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  # Pod副本数量的最小值和最大值
  minReplicas: 1
  maxReplicas: 10
  # 目标指标。在metrics中通过参数type定义指标类型；通过参数target定义响应的指标目标值，系统将在指标数据达到目标值触发扩缩容操作
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 50

可以将metrics中的type（指标类型）设置为以下三种：

• Resource：基于资源的指标值，可以设置的资源为CPU和内存。
• Pods：基于Pod的指标，系统将对全部Pod副本的指标值进行平均值计算。
• Object：基于某种资源对象（如Ingress）的指标或应用系统的任意自定义指标。

Resource类型的指标可以设置CPU和内存。对于CPU使用率，在target参数中设置averageutilization定义目标平均CPU使用率。对于内存资源，在target参数中设置AverageValue定义目标平均内存使用值。指标数据可以通过API“metrics.k8s.io”进行查询，要求预先启动Metrics Server服务。
Pods类型和Object类型都属于自定义指标类型，指标的数据通常需要搭建自定义Metrics Server和监控工具进行采集和处理。指标数据可以通过API“custom.metrics.k8s.io”进行查询，要求预先自定义Metrics Server服务。
类型为Pods的指标数据来源于Pod对象本身，其target类型只能使用AverageValue。

# 其中Pod的指标名为packets-per-second，在目标指标平均值为1000时触发扩缩容操作
metircs:
  - type: Pods
    pods:
      metric:
        name: packets-per-second
      target:
        type: AverageValue
        averageValue: 1k

类型为Object的指标数据来源于其他资源对象或任意自定义指标，其target指标类型可以使用Value或Average Value（根据副本数计算平均平均值）进行设置。

# 例1：设置指标的名称为requests-per-second，其值来源于Ingress“main-route”，将目标值设置为2000，即在Ingress的每秒请求达到2000时触发扩缩容操作。
metircs:
  - type: Object
    object:
      metric:
        name: requests-per-second
      describedObject:
        apiVersion: extensions/v1Beta1
        kind: Ingress
        name: main-route
      target:
        type: value
        value: 2k
# 例2：设置指标的名称为http_requests，并且在该资源对象具有标签“verb=GET”，在指标平均值达到500时触发扩缩容操作。
metircs:
  - type: Object
    object:
      metric:
        name: http_requests
        selector: verb=GET
      target:
        type: AverageValue
        averageValue: 500

在同一个HorizontalPodAutoscaler资源对象中定义多个类型的指标，系统将针对每种类型的指标都计算副本的目标数量，以最大值为准进行扩缩容准备。

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
  namespace: default
spec:
  # HPA的伸缩对象描述，HPA会动态修改该对象的pod数量
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  # HPA的最小pod数量和最大pod数量
  minReplicas: 1
  maxReplicas: 10
  # 监控的指标数组，支持多种类型的指标共存
  metrics:
    # Object类型的指标
    - type: Object
      object:
        metric:
          # 指标名称
          name: requests-per-second
        # 监控指标的对象描述，指标数据来源于该对象
        describedObject:
          apiVersion: networking.k8s.io/v1beta1
          kind: Ingress
          name: main-route
        # Value类型的目标值，Object类型的指标只支持Value和AverageValue类型的目标值
        target:
          type: Value
          value: 10k
    # Resource类型的指标
    - type: Resource
      resource:
        name: cpu
        # Utilization类型的目标值，Resource类型的指标只支持Utilization和AverageValue类型的目标值
        target:
          type: Utilization
          averageUtilization: 50
    # Pods类型的指标
    - type: Pods
      pods:
        metric:
          name: packets-per-second
        # AverageValue类型的目标值，Pods指标类型下只支持AverageValue类型的目标值
        target:
          type: AverageValue
          averageValue: 1k
    # External类型的指标（用于对外部系统指标的支持）
    - type: External
      external:
        metric:
          name: queue_messages_ready
          # 该字段与第三方的指标标签相关联
          selector:
            matchLabels:
              env: stage
              app: myapp
        # External指标类型下只支持Value和AverageValue类型的目标值
        target:
          type: AverageValue
          averageValue: 30

详细使用
《Kubernetes权威指南》笔记

标签：kubectl,name,Kubernetes,容器,nginx,深入,Pod,metadata
来源： https://blog.csdn.net/weixin_43802117/article/details/116303061

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。