Kuberneres高级调度01
目录
一，初始化容器InitContainer
1，InitContainer的基本概念
2，示例 1--延迟指定时间后启动
3，示例 2--使用初始化容器修改内核参数
4，示例 3--等待依赖服务启动
（1）创建第一个 Pod
（2）创建第一个被依赖的service
（3）创建第二个被依赖的service
5，pause容器
（1）pause容器的作用
（2）使用pause容器的好处
（3）pause容器实现
二，临时容器Ephemeral containers
1，临时容器的概念
2，临时容器的使用
（1）创建一个 tomcat 的资源清单
（2）创建pod
（3）为tomcat的pod创建临时容器
（4）查看tomcat-test这个pod是否已经有临时容器
三，自动扩缩容HPA
1，什么是HPA
2，HPA的工作原理
3，HPA的工作流程
4，HPA的应用场景
5，HPA实践--实现web服务器的自动伸缩特性
（1）首先用Deployment启动一个nginx服务（须配置requests参数）
（2）配置nginx-server的Service
（3）使用kubectl autoscale命令创建HPA
（4）查看当前HPA的状态
（5）查看当前nginx的Service地址
（6）压力测试 （打开另一个终端访问）
（7）查看HPA状态
（8）再次查看pod，可以看到已经扩容（pod副本增加到了10个）
（9）停止压力测试
（10）查看pod的副本数
（11）清除
一，初始化容器InitContainer
首先来看初始化容器，顾名思义，初始化容器是用来进行初始化操作的。很多情况下，程序的启动需要依赖各类配置、资源。但是又不能继承在原有的启动命令或者镜像当中，因为程序的镜像可能并没有加载配置命令，此时 Initcontainer 就起了很大的作用。
1，InitContainer的基本概念
Initcontainer 是 Kubernetes 的初始化容器(也可称之为 Init 容器)，它是一种特殊的容器，在Pod 内的应用容器启动之前运行，可以包括一些应用镜像中不存在的使用工具和安装脚本，用以在程序启动时进行初始化，比如创建文件、修改内核参数、等待依赖程序启动等。
每个 Pod 中可以包含多个容器,同时 Pod 也可以有一个或多个先于应用程序启动的 Init 容器,在 Pod定义中和 container 同级,按顺序逐个执行,当所有的 Init 容器运行完成时,Kubernetes 才会启动 Pod内的普通容器。
Init 容器与普通的容器非常像，除了如下几点:
他们总是运行到完成。
上一个运行完成才会运行下一个。
如果 Pod 的 Init 容器失败，Kubernetes 会不断地重启该 Pod，直到 Init 容器成功为止，但是如果 Pod 对应的 restartPolicy 值为Never，Kubernetes 则不会重新启动 Pod。
为Pod 设置 Init 容器需要在Pod的spec中添加initcontainer 字段,该字段和应用的containers属组同级相邻，配置方式和 containers 中的普通容器差不多，Init 容器支持应用容器的全部字段和特性，包括资源限制、数据卷和安全设置。但是 Init 容器对资源请求和限制的处理稍有不同，Init 容器不支持 1ifecycle、livenessProbe、readinessProbe 和 startupProbe，因为他们必须在 Pod 就绪之前运行完成，
备注:
11fecycle 主要指的是容器在其运行环境中经历的不同阶段，以及Kubernetes 如何管理和响应这些阶段的能力。Kubernetes 提供了容器生命周期钩子(Container Lifecycle Hooks)，这是一种允许用户指定在容器生命周期的特定点上运行代码片段或命令的功，
容器生命周期钩子主要包括以下两个部分:
Poststart;这个钩子在容器被创建之后立即调用，但需要注意的是，在钩子执行的时候容器内的主进程尚未启动。这可以用于执行一些初始化任务，比如建立文件系统的缓存目录或其他类型的准备动作。Prestop:这个钩子在发送信号给容器内的主进程之前调用，这意味着这是在容器被终止之前可以执行一些清理工作的最后机会。它常被用来做一些资源释放的工作，比如关闭已经打开的数据库连接或网络连接等。
在生产环境中，为了应用的安全和优化镜像的体积，业务镜像一般不会安装高危工具和并不常用的运维工具，比如 cur1、sed、awk、python 或 dig 等，同时建议使用非root 用户去启动容器。但是某些应用启动之前可像需要检杏依效的服务有没有成功运行，或者需要更高的权限去修改一些系统级的配置，而这些检测或配置更改都是一次性的，所以在制作业务镜像时没有必要为了一次配置的变更去安装一个配置工具，更没有必要因为使用一次高权限而把整个镜像改成以root 身份运行。
考虑到上述问题和需求，Kubernetes 引入了初始化容器的概念，Init 容器具有与应用容器分离的单独镜像，其启动相关代码具有如下优势:
Init 容器可以包含安装过程中应用容器中不存在的实用工具或个性化代码。上
Init 容器可以安全地运行这些工具，避免这些工具导致应用镜像的安全性降低。
Init 容器可以以 root 身份运行，执行一些高权限命令。
Init 容器相关操作执行完成后就会退出，不会给业务容器带来安全隐患。
由于 Init 容器必须在应用容器启动之前运行完成，因此 Init 容器提供了一种机制来阻塞或延迟应用容器的启动，直到满足一组先决条件，Pod 内的所有应用容器才会并行启动。
2，示例 1--延迟指定时间后启动
创建一个 pod，initcontainers 指定初始化容器，command:["sh","-c”,"sleep 15"]表示初始化容器需要休眠 15 秒。
[root@k8s-master ~]# vim init01.yml
apiVersion: v1
kind: Pod
metadata:creationTimestamp: nulllabels:run: initc01name: initc01
spec:terminationGracePeriodSeconds: 0containers:- image: nginx:1.7.9imagePullPolicy: IfNotPresentname: n1resources: {}initContainers:- name: initc01image: nginx:1.7.9imagePullPolicy: IfNotPresentcommand: ["sh","-c","sleep 15"]dnsPolicy: ClusterFirstrestartPolicy: Never
status: {}
[root@k8s-master ~]# ku create -f init01.yml
查看
[root@k8s-master ~]# ku get pod
NAME READY STATUS RESTARTS AGE
initc01 0/1 Init:0/1 0 2s
[root@k8s-master ~]# ku get pod
NAME READY STATUS RESTARTS AGE
initc01 1/1 Running 0 20s3，示例 2--使用初始化容器修改内核参数
在容器里修改内核参数，实际上修改的就是物理机的内核参数，为了安全性，一般不允许在容器里修改内核参数，Seccomp 代表安全计算(Securecomputing)模式，seccomp 控制了容器能做哪些操作，添加 securitycontext 参数之后就可以修改内核参数了。
创建一个 pod，initContainers 初始化容器里的 securityContext:privileged:true 表示该容器具有特权，可以执行命令"sh","-c","/sbin/sysctl -w w.swappiness=8"，vm.swappiness 设置为8表示尽量少使用 swap 内存。
[root@k8s-master ~]# vim init02.yml
apiVersion: v1
kind: Pod
metadata:creationTimestamp: nulllabels:run: initc02name: initc02
spec:terminationGracePeriodSeconds: 0containers:- image: nginx:1.7.9imagePullPolicy: IfNotPresentname: n1resources: {}initContainers:- name: initc02image: alpineimagePullPolicy: IfNotPresentcommand: ["sh","-c","/sbin/sysctl -w vm.swappiness=0"]securityContext:privileged: truednsPolicy: ClusterFirstrestartPolicy: Never
status: {}
[root@k8s-master ~]# ku apply -f init02.yml
pod/initc02 created
[root@k8s-master ~]# ku get pod
NAME READY STATUS RESTARTS AGE
initc02 1/1 Running 0 17s
[root@k8s-master ~]# ku get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
initc02 1/1 Running 0 45s 10.244.58.197 k8s-node02 <none> <none>
查看是否为0
[root@k8s-node02 ~]# cat /proc/sys/vm/swappiness （node02上查看）
04，示例 3--等待依赖服务启动
有时某些服务需要依赖其他组件才能启动，比如后端应用需要数据库启动之后，应用才能正常启动，此时需要检测数据库实例是否正常，等待数据库可以正常使用时，在启动后端应用，此时可以使用初始化容器进行控制。
（1）创建第一个 Pod
该 Pod 内要依赖两个条件才能启动，一个是利用 busybox 容器检测 redis-service 服务是否生成,第二个是检测 mysql-server 服务是否生成。
[root@k8s-master ~]# vim myapp.yaml
apiVersion: v1
kind: Pod
metadata:name: nginxlabels:name: nginx
spec:containers:- name: nginximage: nginx:1.7.9ports:- containerPort: 80initContainers:- name: init-redisimage: busybox:1.28command: ['sh', '-c', 'until nslookup redis-service; do echo waiting for nginx01; sleep 2; done;']- name: init-mysqlimage: busybox:1.28command: ['sh', '-c', 'until nslookup mysql-service; do echo waiting for nginx02; sleep 2; done;']
[root@k8s-master ~]# ku create -f myapp.yaml
pod/nginx created
[root@k8s-master ~]# ku get pod （不正常，因为没有redis-service，mysql-service）
NAME READY STATUS RESTARTS AGE
nginx 0/1 Init:0/2 0 6s（2）创建第一个被依赖的service
[root@k8s-master ~]# cat redis-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:labels:app: redisname: redis
spec:replicas: 1selector:matchLabels:app: redistemplate:metadata:labels:app: redisspec:containers:- image: redis:5.0imagePullPolicy: IfNotPresentname: redis
---
apiVersion: v1
kind: Service
metadata:labels:app: redisname: redis-service
spec:ports:- port: 6379protocol: TCPtargetPort: 6379selector:app: redistype: NodePort
[root@k8s-master ~]# ku get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 14d
redis-service NodePort 10.107.170.167 <none> 6379:32299/TCP 9s
[root@k8s-master ~]# ku get pod
NAME READY STATUS RESTARTS AGE
nginx 0/1 Init:0/2 0 4m26s
redis-56bcf55554-k6blz 1/1 Running 0 15s（3）创建第二个被依赖的service
[root@k8s-master ~]# cat mysql-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:labels:app: mysqlname: mysql
spec:replicas: 1selector:matchLabels:app: mysqltemplate:metadata:labels:app: mysqlspec:containers:- env:- name: MYSQL_ROOT_PASSWORDvalue: 'moonfdd'image: 'mysql:8.0'imagePullPolicy: IfNotPresentname: mysqlvolumeMounts:- mountPath: /var/lib/mysqlname: volvvolumes:- hostPath:path: /root/k8s/moonfdd/mysql/var/lib/mysqltype: DirectoryOrCreatename: volv
---
apiVersion: v1
kind: Service
metadata:labels:app: mysqlname: mysql-service
spec:ports:- port: 3306protocol: TCPtargetPort: 3306selector:app: mysqltype: NodePort
[root@k8s-master ~]# ku create -f mysql-deployment.yaml
deployment.apps/mysql created
service/mysql-service created
[root@k8s-master ~]# ku get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 14d
mysql-service NodePort 10.106.189.116 <none> 3306:31138/TCP 7s
redis-service NodePort 10.107.170.167 <none> 6379:32299/TCP 2m41s
[root@k8s-master ~]# ku get pod （创建完redis-service，mysql-service后nginx就可以正常运行了）
NAME READY STATUS RESTARTS AGE
mysql-7f5d669b6c-x5hdh 1/1 Running 0 23s
nginx 1/1 Running 0 7m7s
redis-56bcf55554-k6blz 1/1 Running 0 2m56s到这里可以发现，当把 redis-service 和mysq1-service 两个服务创建出来后，nginx 的 Pod 就正常运行了。
5，pause容器
在 Kubernetes 中，pause 容器并不是指暂停容器的执行，而是指一个特殊的辅助容器，它被用于每个 Pod 以帮助实现网络命名空间，pause 容器是 Kubernetes 中每个 Pod 的第一个容器，它的主要作用是
作为 Pod 内所有其他容器共享网络命名空间的基础。每个 Kubernetes Pod 都有一个 pause 容器，它是 Pod 的第一个容器，也是唯一必须运行的容器。即使 Pod 中的其他容器都停止了，只要 pause 容器还在运行，Pod 就不会被 Kubernetes 认为是完全停止的。
（1）pause容器的作用
网络命名空问:pause 容器为 Pod 内的所有容器提供了一个共享的网络命名空间。这意味着 Pod 内的所有容器都共享同一个 IP 地址和端口空问，从而使得它们可以直接通过 1ocalhost 或者其他指定方式相互通信。
网络接口:pause 容器负责设置 Pod 的网络接口,使得 Pod 内的容器能够通过这个接口访问外部网络。稳定性:如果 Pod 中的所有声明的容器都被删除或停止，pause 容器将保持运行，从而保证 Pod 的网络命名空间不会丢失。这也意味着 Pod 的网络配置仍然保留，直到整个 Pod 被删除。
生命周期管理:pause 容器是一个非常简单的容器，其镜像只包含一个命令/pause，该命令实际上是
-个无限循环，保持容器处于运行状态。它不执行任何业务逻辑，仅仅是作为 Pod 网络基础设施的部分。
（2）使用pause容器的好处
简化了 Pod 内的网络配置。
提高了 Pod 网络的一致性。
减少了管理 Pod 网络复杂性的开销。
总的来说，pause 容器对于实现 Kubernetes Pod 的网络功能至关重要，它是 Kubernetes 网络模型的一个核心组成部分。
（3）pause容器实现
Pod 里的多个容器怎么去共享网络?下面是个例子:
比如说现在有一个 Pod，其中包含了一个容器 A 和一个容器 B，它们两个就要共享 NetworkNamespace。在 Kubernetes 里的解法是这样的:它会在每个 Pod 里，额外起一个 Infra(基础)container 小容器来共享整个Pod 的 Network Namespace。
Infra container 是一个非常小的容器，大概 780KB 左右，是一个 C 语言写的、永远处于 “暂停”状态的容器。由于有了这样一个 Infra container 之后，其他所有容器都会通过 Join Namespace的方式加入到Infra container 的Network Namespace 中.
所以说一个 Pod 里面的所有容器，它们看到的网络视图是完全一样的。即:它们看到的网络设备、IP 地址、Mac 地址等等，跟网络相关的信息，其实全是一份，这一份都来自于 Pod 第一次创建的这个Infra container。这就是 Pod 解决网络共享的一个解法。
在 Pod 里面，一定有一个 IP 地址，是这个 Pod 的 Network Namespace 对应的地址，也是这个Infra container 的 IP 地址。所以大家看到的都是同一份，而其他所有网络资源，都是一个 Pod份，并且被 Pod 中的所有容器共享。这就是Pod 的网络实现方式。
由于需要有一个相当于中间的容器存在，所以整个 Pod 里面，必然是 Infra container 第一个启动。并且整个 Pod 的生命周期是等同于 Infra container 的生命周期的，与容器 A 和 B 是无关的。这也是为什么在 Kubernetes 里而，它是允许去单独更新 Pod 里的某一个镜像的，即:做这个操作，整个 Pod 不会重建，也不会重启，这是非常重要的一个设计。
査看 nginx 的 Pod 运行在的主机
[root@k8s-master ~]# ku get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
mysql-7f5d669b6c-x5hdh 1/1 Running 0 5m24s 10.244.85.200 k8s-node01 <none> <none>
nginx 1/1 Running 0 12m 10.244.58.198 k8s-node02 <none> <none>
redis-56bcf55554-k6blz 1/1 Running 0 7m57s 10.244.85.199 k8s-node01 <none> <none>在 k8s-node01 主机上査看 Pod 中的 pause 容器
[root@k8s-node02 ~]# docker ps | grep nginx （node02上查看pod中的pause容器）
72a1c358aed6 84581e99d807 "nginx -g 'daemon of…" 6 minutes ago Up 6 minutes k8s_nginx_nginx_default_244f9cb5-f951-4873-89f3-311d3f2636f0_0
ee5afc4fc864 registry.aliyuncs.com/google_containers/pause:3.6 "/pause" 13 minutes ago Up 13 minutes k8s_POD_nginx_default_244f9cb5-f951-4873-89f3-311d3f2636f0_0
92fe589839c1 84581e99d807 "nginx -g 'daemon of…" 23 minutes ago Up 23 minutes k8s_n1_initc02_default_05099fd3-9cc7-4c3f-928f-6ff36a781914_0
77a5bc13eb4b 84581e99d807 "nginx -g 'daemon of…" 41 minutes ago Up 41 minutes k8s_n1_initc01_default_0700fb4c-3c54-4f9e-8385-7194155b65be_0二，临时容器Ephemeral containers
在生产环境中，为了优化镜像的体积和提高镜像的安全性，并不会在容器中安装太多高危工具。比如cur1、wget、dig 以及常用的 net-tools 等。这样做虽然提高了镜像的安全性，但是也带来了一些不便,比如无法査看容器内的进程情况、无法査看容器内的链接情况、服务出了问题无法很方便的进行挂査等。因为上述操作并非经常使用，所以我们并没有必要从一开始就安装这些工具，但是等到用他们的时候再安装也是一件很麻烦的事情，那么我们该如何处理这个问呢?
为了解决这类问题，在 1.16 版本后，Kubernetes 引入了Ephemeral containers 的概念，可以不用安装第三方工具即可实现在线 Debug 操作，
1，临时容器的概念
临时容器与其他容器的不同之处在于，临时容器是被临时添加到 Pod 上，用于在线调试应用的，他永远不会自动重启，因此不适用与构建应用程序，临时容器的声明和普通容器类似，但是临时容器没有端口配置，因此不能使用像 ports、1ivenessprobe、readnessprobe、resources 这样的字段，当然，临时容器只是用来调试程序的，它的状态不会影响其他正常容器，所以它并不需要这些字段配置。
临时容器使用 API 中一种特殊的 Ephemeral containers 处理器进行创建，而不是直接添加到pod.spec 字段，因此无法使用 kubect1 edit 来添加临时容寨，与常规容器一样，将临时容器添加到 Pod后，将不能更改或翻除临时容器，但是当添加了临时容器的Pod 重启后，临时容器就会被销毁。
因为临时容器是为了调试程序而设计的，所以在添加临时容器时，最好使用一个包含所有常用工具的镜像进行创建。当业务容器崩溃或容器镜像不包含调试工具而导致kubectl exec 不可用时，临时容器对于交互故障排査和在线 Debug 很有用。尤其是在使用像不包含任何 she11 和其他工具的 destroless 镜像作为基础镜像时，虽然可以减少攻击面和漏洞，但对于问的排査会变得尤为棘手，此时临时容器就可以发挥很大的作用，带来诸多便利性。
2，临时容器的使用
（1）创建一个 tomcat 的资源清单
[root@k8s-master ~]# cat pod-tomcat.yaml
apiVersion: v1
kind: Pod
metadata:name: nginx-testnamespace: defaultlabels:app: nginx
spec:containers:- name: nginx-javaports:- containerPort: 8080image: nginx:1.7.9imagePullPolicy: IfNotPresent（2）创建pod
[root@k8s-master ~]# ku create -f pod-tomcat.yaml
pod/nginx-test created
[root@k8s-master ~]# ku get pod
NAME READY STATUS RESTARTS AGE
nginx-test 1/1 Running 0 10s
（3）为tomcat的pod创建临时容器
[root@k8s-master ~]# ku debug -it nginx-test --image=busybox:1.28 --target=nginx-java
Targeting container "nginx-java". If you don't see processes from this container it may be because the container runtime doesn't support this feature.
Defaulting debug container name to debugger-b5gw7.
If you don't see a command prompt, try pressing enter.
/ # ps -ef | grep nginx1 root 0:00 nginx: master process nginx -g daemon off;7 101 0:00 nginx: worker process
（4）查看tomcat-test这个pod是否已经有临时容器
[root@k8s-master ~]# ku describe pods nginx-test
Name: nginx-test
Namespace: default
Priority: 0
Node: k8s-node02/192.168.10.103
Start Time: Fri, 11 Jul 2025 10:08:38 +0800
Labels: app=nginx
Annotations: cni.projectcalico.org/containerID: d90f73df7c8da6f6de33386de157acaf511cd8cc748536dacca6b395c77fb60fcni.projectcalico.org/podIP: 10.244.58.199/32cni.projectcalico.org/podIPs: 10.244.58.199/32
Status: Running
IP: 10.244.58.199
IPs:IP: 10.244.58.199
Containers:nginx-java:Container ID: docker://3b064b539d56348b49b950dc578858ffcb933237133f880718c78d6139185070Image: nginx:1.7.9Image ID: docker://sha256:84581e99d807a703c9c03bd1a31cd9621815155ac72a7365fd02311264512656Port: 8080/TCPHost Port: 0/TCPState: RunningStarted: Fri, 11 Jul 2025 10:08:39 +0800Ready: TrueRestart Count: 0Environment: <none>Mounts:/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-rbkzb (ro)
Ephemeral Containers:debugger-b5gw7:Container ID: docker://747f6842cc080c6a84409209f94c695a5b34d5bfbfc4214402096bb7b8f72d60Image: busybox:1.28Image ID: docker://sha256:8c811b4aec35f259572d0f79207bc0678df4c736eeec50bc9fec37ed936a472aPort: <none>Host Port: <none>State: TerminatedReason: CompletedExit Code: 0Started: Fri, 11 Jul 2025 10:13:44 +0800Finished: Fri, 11 Jul 2025 10:15:41 +0800Ready: FalseRestart Count: 0Environment: <none>Mounts: <none>
Conditions:Type StatusInitialized True Ready True ContainersReady True PodScheduled True
Volumes:kube-api-access-rbkzb:Type: Projected (a volume that contains injected data from multiple sources)TokenExpirationSeconds: 3607ConfigMapName: kube-root-ca.crtConfigMapOptional: <nil>DownwardAPI: true
QoS Class: BestEffort
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300snode.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:Type Reason Age From Message---- ------ ---- ---- -------Normal Scheduled 7m22s default-scheduler Successfully assigned default/nginx-test to k8s-node02Normal Pulled 7m22s kubelet Container image "nginx:1.7.9" already present on machineNormal Created 7m22s kubelet Created container nginx-javaNormal Started 7m22s kubelet Started container nginx-javaNormal Pulled 2m23s kubelet Container image "busybox:1.28" already present on machineNormal Created 2m21s kubelet Created container debugger-b5gw7Normal Started 2m17s kubelet Started container debugger-b5gw7三，自动扩缩容HPA
在集群安装的过程中，我们可以安装一个叫 Metrics Server 的组件，该组件在集群中负贵采集 Pod和 Node 的度量值指标，比如 Pod 的 CPU、内存使用率和节点的内存、CPU 使用率，而且安装的 Dashboard可以展示 CPU、内存信息也是依靠Metrics server 的。当然，该组件不仅仅是用来展示数据的，还可以使用 Metrics server 提供的数据结合 Kubernetes 的 HPA 功能实现 Pod 的自动扩缩容。
1，什么是HPA
HPA(Horizontal Pod Autoscaler，水平 Pod 自动伸缩器)可以根据观察到的CPU、内存使用率或自定义度量标准来自动扩展或缩容 Pod 的数量，注意HPA 不适用于无法缩放的对象,比如 Daemonset.
HPA 控制器会定期调整 RC 或 Deployment 的副本数，以使观察到的平均 CPU 利用率与用户指定的目标相匹配。
HPA 需要 Metrics server 获取度量指标,如果已经駕署了 Metrics server，本节的实践部就分无须再次安装 Metrics Server。如果没有安装Metrics server，可以参考其他实验文档自行部署。
2，HPA的工作原理
HPA 根据观察到的 CPU、内存使用率或自定义度量标准来自动扩展或缩容 Pod 的数量。
HPA 控制器会定期调整 RC(Replication controller)或 Deployment 的副本数，以使观察到的平均 CPU 利用率(或其他度量标准)与用户指定的目标相匹配。
HPA 需要 Metrics server 获取度量指标，Metrics server 负贵呆集 Pod 和 Node 的度量值指标，如 CPU、内存使用率等。
3，HPA的工作流程
配置 HPA:使用 kubectl autoscale 命令为Deployment,Replicaset 或statefulset 等资源创建 HPA 对象，并指定目标 CPU 利用率、最小副本数和最大副本数。
度量指标采集: Metrics Server 定期采集 Pod 和 Node 的度星值指标，并将这些数据提供给 HPA控制器。
伸缩决策:HPA 控制器根据当前 Pod 的度量指标和目标利用率进行比较，如果当前利用率高于目标利用率，则增加 Pod 副本数:如果当前利用率低于目标利用率，则减少 Pod 副本数(在最小副本数和最大副本数之问调整)。
Pod 伸缩:Kubernetes 根据 HPÀ 控制器的决策自动调整 Pod 的副本数，以实现自动扩缩容。
4，HPA的应用场景
应对流量波动:在 Web 服务中，流量可能会随时间变化面波动。HPA 可以根据流量变化自动调整Pod 副本数，以确保服务的稳定性和响应速度。
资源优化:通过自动扩缩容，HPA 可以在保证股务质量的同时最大化资源利用率，降低运营成本。
5，HPA实践--实现web服务器的自动伸缩特性
在生产环境中，总会有一些意想不到的事情发生，比如公司网站流量突然升高，此时之前创建的 Pod已不足以支撑所有的访问，而运维人员也不可能 24 小时守着业务服务，这时就可以通过配置 HPA，实现负载过高的情况下自动扩容 Pod 副本数以分摊高并发的流量，当流星恢复正常后，HPA 会自动缩减 Pod 的数量。
（1）首先用Deployment启动一个nginx服务（须配置requests参数）
[root@k8s-master ~]# vim nginx-deployment.yaml
piVersion: apps/v1
kind: Deployment
metadata:name: nginx-serverlabels:name: nginx-server
spec:replicas: 2selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginxresources:requests:cpu: 10mimage: nginx:1.7.9ports:- name: nginxcontainerPort: 80[root@k8s-master ~]# ku create -f nginx-deployment.yaml
deployment.apps/nginx-server created（2）配置nginx-server的Service
[root@k8s-master ~]# ku expose deployment nginx-server --port=80
service/nginx-server exposed（3）使用kubectl autoscale命令创建HPA
[root@k8s-master ~]# ku autoscale deployment nginx-server --cpu-percent=10 --min=1 --max=10
horizontalpodautoscaler.autoscaling/nginx-server autoscaled此 HPA 将根据 CPU的使用率自动增加和减少副本数量，上述设置的是 CPU 使用率超过 10%(--cpu-percent 參数指定)就会增加 Pod 的数量，以保持所有 Pod 的平均 CPU 利用率为 16%,允许最大的 Pod 数量为10(--max),最少的 Pod 数为】(--min)。
（4）查看当前HPA的状态
因为未对其发送任何请求，所以当前 CPU 使用率为 0%
[root@k8s-master ~]# ku get hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
nginx-server Deployment/nginx-server 0%/10% 1 10 2 30s备注:
如果看不到 TARGET 的 CPU 利用率，可以多等十几秒。
（5）查看当前nginx的Service地址
[root@k8s-master ~]# ku get service -n default
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 14d
mysql-service NodePort 10.106.189.116 <none> 3306:31138/TCP 62m
nginx-server ClusterIP 10.103.67.218 <none> 80/TCP 3m14s
redis-service NodePort 10.107.170.167 <none> 6379:32299/TCP 65m（6）压力测试 （打开另一个终端访问）
新开一个终端,使用-个“死”循环或其他压测工具模报访问该Servlce。从而增加该Pod的负载
[root@k8s-master ~]# while true;do wget -q -O- http://10.103.67.218 >/dev/null;done备注:
-q 是不输出 wget 的头信息。
-0-(大写字母0)选项表示将下载的内容输出到标准输出(通常是终)，而不是保存到文件。
（7）查看HPA状态
等待一分钟左右，再次查看 HPA，可以看到 Pod 的 CPU 已经升高。
[root@k8s-master ~]# ku get hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
nginx-server Deployment/nginx-server 60%/10% 1 10 2 3m37s（8）再次查看pod，可以看到已经扩容（pod副本增加到了10个）
[root@k8s-master ~]# ku get pod
NAME READY STATUS RESTARTS AGE
nginx-server-6ddcfd4c8f-49zlh 1/1 Running 0 67s
nginx-server-6ddcfd4c8f-69n7z 1/1 Running 0 67s
nginx-server-6ddcfd4c8f-f8jp6 1/1 Running 0 7m26s
nginx-server-6ddcfd4c8f-gtmvh 1/1 Running 0 52s
nginx-server-6ddcfd4c8f-jfq8w 1/1 Running 0 52s
nginx-server-6ddcfd4c8f-m4rbt 1/1 Running 0 67s
nginx-server-6ddcfd4c8f-qmjvn 1/1 Running 0 83s
nginx-server-6ddcfd4c8f-tq4qh 1/1 Running 0 83s
nginx-server-6ddcfd4c8f-ts4pr 1/1 Running 0 7m26s
nginx-server-6ddcfd4c8f-v6r6n 1/1 Running 0 67s
redis-56bcf55554-k6blz 1/1 Running 0 68m（9）停止压力测试
Ctr1+c 终止终端的测试，等待一分钟左右，再次査看 HPA 状态
[root@k8s-master ~]# ku get hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
nginx-server Deployment/nginx-server 0%/10% 1 10 10 5m58s（10）查看pod的副本数
[root@k8s-master ~]# ku get pod备注:
需要多等待几分钟后，才能看到缩容后的 pod
（11）清除
[root@k8s-master ~]# ku delete -f nginx-deployment.yaml
deployment.apps "nginx-server" deleted
[root@k8s-master ~]# ku delete -f mysql-deployment.yaml
deployment.apps "mysql" deleted
service "mysql-service" deleted
[root@k8s-master ~]# ku delete -f redis-deployment.yaml
deployment.apps "redis" deleted
service "redis-service" deleted
[root@k8s-master ~]# ku delete -f init01.yml
pod "initc01" deleted
[root@k8s-master ~]# ku delete -f init02.yml
pod "initc02" deleted