【云驻共创】华为云云原生钻石课程之Kubernetes运维管理详解(上)
【摘要】本文介绍的内容主要有：云原生，K8S运维管理，K8S负载更新和回滚机制，还有应用探针健康检查与K8S弹性伸缩原理。
一 🦄 K8S的基础
它简称 K8s，8是干啥的啊？ 原来是用 8 代替中间 8 个字符 “ubernete” 而成的缩写，就是一个开源的，用于管理云平台中多个主机上的容器化应用。
-
目标是把部署容器化的应用简单并且高效 (powerful)，它提供了应用部署，规划，更新，维护的一系列操作机制，比普通的Docker要强不少。
-
它是一个分布式系统，简单来说有一台控制工作机器的主机器，工作被安排在不同的工作机器上。然后，每台机器在容器中运行工作。
其次 Kubernetes 对计算资源进行了更高层次的抽象，把容器进行更细致的组合，最终的应用服务交给用户。Kubernetes在模型建立之初就考虑了容器跨机连接的要求，支持多种网络解决方案，同时在Service层次构建集群范围的SDN网络。其目的是将服务发现和负载均衡放置到容器可达的范围，这种透明的方式方便了各个服务间的通信，并为微服务架构的实践提供了平台基础。而在Pod层次上，作为Kubernetes可操作的最小对象，其特征更是对微服务架构的原生支持。
1 看下背景
Kubernetes项目来源于Borg，可以说是集结了Borg设计思想的精华，并且吸收了Borg系统中的缺陷与教训。
Kubernetes作为容器集群管理工具，于2015年7月22日迭代到 v 1.0并正式对外公布，这意味着这个开源容器编排系统可以正式在生产环境使用。
- 谷歌联合Linux基金会及其他合作伙伴共同成立了CNCF基金会( Cloud Native Computing Foundation)，并将Kuberentes 作为首个编入CNCF管理体系的开源项目，助力容器技术生态的发展进步。
- Kubernetes项目凝结了Google过去十年间在生产环境的经验和教训，从Borg的多任务Alloc资源块到Kubernetes的多副本Pod，从Borg的Cell集群管理，到Kubernetes设计理念中的联邦集群，在Docker等高级引擎带动容器技术兴起和大众化的同时，为容器集群管理提供独了到见解新思路。
2 仅自己理解
千万就是不要为了使用k8s 而去使用k8s，我感觉可能不一定明白k8s的真正的威力。生产环境用k8s大多看中了它的故障漂移、故障自愈、弹性伸缩(这里先打一个问号)、云交付、资源编排/ 治理 等等，我想说用 k8s 这些都没问题，但是不用k8s 这些照样也有N种办法来解决，那么为何要用k8s呢？ 你可以说你的k8s就是个“工厂”，其实意义不大，不建议这么干。
一个公司生产环境共有20台ECS，部署了一个k8s集群，然后他们发现一个问题，就是他们的资源老不够用咋办，动不动CPU和内存就告警，请我帮忙排查了下，发现问题原来很严重，他们这个DevOps场景是 伪DevOps场景， k8s最怕的就是在一个固定的资源池里玩，他们的 资源池20台服务器减去1台master，19台资源，所有 deployment和statefulset 都在在19台ECS里玩，这里我发现问题所在，他们做了弹性伸缩，资源监控，一旦CPU、内存、网络达到阈值就立马扩容出一个pod出来，20台ecs的资源池说多也不多，他们是一个流量型的应用，用户访问的频率取决于当下的热门实事的采集流量，这种类型的应用APP肯定不能基于固定资源池内玩了啊， 需要非固定的资源进行动态伸缩。
在重复一遍，不能基于固定的资源池内玩 资源动态伸缩，这不是k8s的初衷；k8s的优势之一是资源动态伸缩，那么我问问大家，在固定的资源池内如何玩动态伸缩，还不如直接把所有的服务都部署在20台服务器上呢，直接walle + haproxy + keepalived + zookeeper + consul 等等的不就搞定了？ 何必整一些花样 玩k8s呢 对吧！
下面我来说说是怎么高效玩k8s部署
-
1 DevOps体系打通私有云和公有云的接口，内部自研一个DevOps平台做到 管理K8S集群所有的节点 、管理服务器（裸金属、ECS）、有效纳管公有云平台（接口打通，取决于你用哪些平台，比如华为云、阿里云、腾讯云 等等）；
-
2 做整体的资源监控，不仅仅局限于 k8s的监控，而是全局资源监控，及时发现资源即将达到阈值的风险；
-
3 提前做好服务器镜像，做好服务器相关配置的编排脚本或者服务；
-
4 做好k8s集群的管理和控制，譬如弹性伸缩 node；
-
5 一旦全局资源发生告警，DevOps平台会立刻调用公有云平台的接口，创建出一台或者多台服务器出来，镜像就用你们之前打好的，调用相关服务或者脚本 及时加入到 k8s集群里来，设置相关的标签；
-
6 这样只要你们的固定服务器资源不够了，随时扩容，我经过测试 接口创建一台ECS服务器一分钟左右吧 加上相关的自动化配置，共用了3分钟左右搞定；假设你的阈值设定为80%，那么你的服务器可能在阈值上限后还能支撑几分钟，足够给扩容服务器留出时间，这时候你可能会较真了，我这样多繁琐，直接人工扩容不行吗？ 我回答你，可以 只要你的运维没意见就行，实时盯着监控大屏就行；
-
7 这么一来不管你们的流量怎么激增，都不会给你的线上业务造成宕机或者大范围卡顿现象； 前提是你的公有云账户里必须有钱，没钱啥都干不了； 然后等流量下来了 不再需要了，按照你们制定的相关策略 可以自动让devops平台调用公有云接口释放掉新购买多余的服务器，然后调用k8s服务的API 删除新增进来的node节点；
3 基础命令
这个查看帮助,没什么好说
[root@master1 ~]# kubectl --help
查看版本，也是一样
至此，这里yum安装的版本还是1.5.2，这两天我准备升级到1.8.x的，你也可以去升级下
[[email protected] ~]# kubectl --version
Kubernetes v1.5.2
get
get命令用在获取集群的一个或一些resource信息。 使用–help查看详细信息。
Ps：kubectl的帮助信息、示例相当详细，并且简单易懂。建议大家习惯使用帮助信息。kubectl可以列出集群所有resource的详细。resource包括集群节点、运行的pod，ReplicationController，service等，能够一目了然。
[[email protected] ~]# kubectl get po //查看所有的pods
NAME READY STATUS RESTARTS AGE
pod-redis 1/1 Running 0 24s
[[email protected] ~]# kubectl get nodes //查看所有的nodes
NAME STATUS AGE
node1 Ready 2d
node2 Ready 2d
[[email protected] ~]# kubectl get pods -o wide //查看所有的pods更详细些
NAME READY STATUS RESTARTS AGE IP NODE
pod-redis 1/1 Running 0 1m 10.0.8.2 node1
[[email protected] ~]# kubectl get nodes -o wide
NAME STATUS AGE EXTERNAL-IP
node1 Ready 2d <none>
node2 Ready 2d <none>
[[email protected] ~]# kubectl get po --all-namespaces //查看所有的namespace
NAMESPACE NAME READY STATUS RESTARTS AGE
default pod-redis 1/1 Running 0 6m
这里有3种方式查看一个pod的详细信息与参数
第一种方式
用yaml文件形式显示一个pod的详细信息
[[email protected] ~]# kubectl get po pod-redis -o yaml
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: 2018-03-02T08:02:42Z
labels:
name: redis
name: pod-redis
namespace: default
resourceVersion: "112273"
selfLink: /api/v1/namespaces/default/pods/pod-redis
uid: 15b3d4e9-1df0-11e8-9d2d-000c2926e9ae
spec:
containers:
- image: docker.io/redis
imagePullPolicy: Always
name: pod-redis
ports:
- containerPort: 6379
hostPort: 6379
protocol: TCP
resources: {}
terminationMessagePath: /dev/termination-log
dnsPolicy: ClusterFirst
nodeName: node1
nodeSelector:
zone: node1
restartPolicy: Always
securityContext: {}
terminationGracePeriodSeconds: 30
status:
conditions:
- lastProbeTime: null
lastTransitionTime: 2018-03-02T08:02:44Z
status: "True"
type: Initialized
- lastProbeTime: null
lastTransitionTime: 2018-03-02T08:02:55Z
status: "True"
type: Ready
- lastProbeTime: null
lastTransitionTime: 2018-03-02T08:02:42Z
status: "True"
type: PodScheduled
containerStatuses:
- containerID: docker://bd7ebb1017042a5f7cfb20daf96d8517a238bcefc3b850591ba2ed8ef8ffea2b
image: docker.io/redis
imageID: docker-pullable://docker.io/[email protected]:e55dff3a21a0e7ba25e91925ed0d926d959dac09f9099fd1bcc919263305f1e4
lastState: {}
name: pod-redis
ready: true
restartCount: 0
state:
running:
startedAt: 2018-03-02T08:02:54Z
hostIP: 192.168.161.163
phase: Running
podIP: 10.0.8.2
startTime: 2018-03-02T08:02:44Z
第二种方式
用json格式输出pod的详细信息。
kubectl get po <podname> -o json
describe
describe类似于get操作，它同样用于获取resource的相关信息。但不同的是，get获得的更详细resource个性的详细信息，所以更牛皮些。describe获得的是resource集群相关的信息。describe命令同get类似，但是describe是不支持-o选项，对于同一类型resource，describe输出的信息格式，内容域相同。
敲黑板：如果你发现是查询某个resource的信息，使用get命令它能够获取更加详尽的信息。但是如果想要查询某个resource的状态，譬如某个pod它并不是在running状态，这时需要获取更详尽的状态信息时，就应该使用describe命令才行。
[root@master1 ~]# kubectl describe po rc-nginx-3-l8v2r
create
不多讲了，前面已经说了很多次了。 直接使用create则可以基于rc-nginx-3.yaml文件创建出ReplicationController（rc），rc会创建出两个副本
[root@master1 ~]# kubectl create -f rc-nginx.yaml
replace
replace命令用于对已有资源进行更新、替换。如前面create中创建出来的nginx，当我们需要更新resource的一些属性的时候，如果修改副本数量，增加、修改label，更改image版本，修改端口等。都可以直接修改原yaml文件，然后执行replace命令。
敲黑板：名字不能被更更新。另外，如果是更新label，原有标签的pod将会与更新label后的rc断开联系，有新label的rc将会创建指定副本数的新的pod，但是默认并不会删除原来的pod。所以此时如果使用get pod,你会发现pod数已经翻倍，进一步check会发现原来的pod已经不会被新rc进行控制， 此处只介绍命令不详谈此问题，好奇者可自行实验。
[root@master1 ~]# kubectl replace -f rc-nginx.yaml
patch
如果一个容器已经在运行，这时需要对一些容器属性进行修改，又不想删除容器，或不方便通过replace的方式进行更新。kubernetes还提供了一种在容器运行时，直接对容器进行修改的方式，那就是patch命令了。
如前面创建pod的label是app=nginx-2，那如果在运行过程中，我们需要把其label改成app=nginx-3，这patch命令如下这种
kubectl patch pod rc-nginx-2-kpiqt -p '{"metadata":{"labels":{"app":"nginx-3"}}}'
edit
edit提供了另一种更新resource源的操作，通过edit能够灵活的在一个common的resource基础上，发展出更好的significant resource。例如，使用edit直接更新前面创建的pod的命令下面这种
[root@master1 ~]# kubectl edit po rc-nginx-btv4j
二 🐡 无状态工作负载更新
在我们生产环境中，它是一种非常常见的工作负载更新类型，特点是它的更新与回滚机制非常的方便，Deployment可以设置不同的更新策略，有如下两种：
- Recreate:停止所有旧版本然后部署新版本（最好在开发环境使用，但是让Deployment所有的Pod先删除掉，让Deployment不可用，在生产环境这是不可接受）
- RollingUpdate:这是第二种，也就是滚动更新，即逐步创建Pod然后再删除旧Pod，它为默认策略。
Deployment可以通过maxSurge和maxUnavailable两个参数，来控制升级过程中重新创建Pod的比例
- maxSurge:与Deployment中spec.replicas（副本数）相比，可以有多少个Pod存在呢？默认值是25%，比如spec.replicas为4，升级过程中就不能超过5个Pod存在，即按照1个的步伐升级。
- maxUnavailable:与Deployment中spec_replicas相比，可以有多少个Pod失效呢？也就是删除的比例值，默认值也是25%，比如spec.replicas为4，那升级过程汇总就至少有3个Pod存在，即删除Pod的步伐是1；
1 deployment的回滚机制
在更新出现问题之前，可能需要对应用进行回滚，k8s支持更具deployment的历史版本进行回滚操作
查看deployment升级历史
$ kubectl rollout history deployment/nginx
deployment.apps/nginx
REVISON CHAMGE-CAUSE
1 <none>
2 <none>
//回滚到上一个版本
$ kubectl rollout undo deployment/nginx
//回滚到指定版本
$ kubectl rollout undo deployment/nginx--to-revision=2
不懂也没关系哈，来举例子，华为云CCE平台，这个平台我们有已经创建好CCE的k8s集群，里面
有工作负载类型有以下几种，其中第一种是无状态负载，其中这里有创建好的基于nginx工作负载；
2 演示deployment的更新回滚机制
我们先来看下更新机制，通过页面更多选择编辑YAML，比如说修改内存limit配置改成110看看效果咋样
之后将会触发一次nginx更新，我们看下会有什么效果，nginx在实例列表中进行滚动更新操作，它删除旧的节点时候，创建新的节点则它的步伐是1，因为我们在deployment配置中设置有maxhowvalue是1，现在配置升级操作已经完成了，看下他更新配置；
在CCE集群里面选择命令行工具CloudShell如下所示
现在有4个节点正在运行中，我们要对其中节点进行回滚我们看下他的历史版本,可以看出deployment nginx是有两个版本，我们想回退到第一个版本，现在已经提示我们节点已经开始回滚，我们可以看一下当前节点情况，节点已经开始滚动回滚，回到页面YAML编辑中看到，CPU limit已经回滚到100;
3 有状态工作负载更新
一共有下面下面几种情况
- OnDelete:用户必须手动删除 Pod 以便让控制器创建新的 Pod
- RollingUpdate:滚动更新过程也跟Deployment大致相同。
区别就在于：
- 滚动更新的过程是有序的，index从N-1到0逐个依次进行，并且下一个Pod创建是前一个Pod Ready为前提，下 一个Pod伤处必须是前一个Pod shutdown并完全删除为前提。
- 支持部分实例滚动更新，部分不更新，通过spec.updateStreategy.rollingUpdate.partition指定一个index分界点，所有id大于等于partition指定的值的Pods将会进行滚动更新；所有id小于partition指定的指的Pods将保持不变
4 有状态工作负载（StatefulSet）回滚
statefulset 和 deployment一样也支持回滚操作，statefulset也保存了历史版本， 和deployment 一样利用spec.revisionHistoryLimit字段设置保存多少个历史版本
# 查看StatefulSet升级历史
$ kubectl rollout histroy statefulest nginx-ss -n monthitoring
statefulset.apps/nginx-ss
REVISION
#回滚到指定版本
$ kubectl rollout undo statefulest nginx-to-revision=3-n monitoring statefulest.apps/nginx-ss rolled back
敲黑板,因为 statefulset 的使用是有状态服务，大部分有状态副本集都会用到持久存储，statefulest下的每个pod正常情况下都会关联一个pv对象，对statefulsetg对象回滚非常容易，但其使用的py中保存的数据无法回滚，所以在生产环境中进行回滚是需要谨慎操作。
回到CCE工作台，先点有状态负载，我们这里创建了nginx的有状态工作负载，这里用它演示有
现在我们把patition设为2，含义是所有大于等于2的pod在本次都会更新，小于2将不会更新。
三 🐧 应用探针健康检查机制详解
在生产环境中，一个应用健康状态对我们的业务非常重要，如果流量进入不健康Pod，会导致我们业务受损，这里就需要引入探针去进行检测，如下
这里必须引入TCP Socket检查端口是8080，至于这个TCP socket后续来讲解
aplVersion:v1
kind:Pod
metadata:
name:goproxy
labels:
app:goproxy
spec:
containers:
-name:goproxy
image: k8s.gcr.io/goproxy:0.1
port:
- containerPort:8080
readinessProbe:
tcpSocket:
port: 8080
initialDeploySeconds: 5
periodSeconds: 10
livenessProbe:
tcpSocket:
port:8080
initialDelaySeconds: 10
livenessProbe:
tcpSocket:
port:8080
initialDelaySeconds: 15
periodSeconds: 20
k8s 支持下面三种探测机制：
- HTTP GET： 向容器发送HTTP GET请求，如果Probe收到2xx或3xx,说明容器是健康的。
- TCP Socket: 尝试与容器指定端口建立TCP连接，如果连接成功建立，说明容器是健康的。
- Exec: Probe 执行容器中的命令会坚持命令退出的状态码，如果状态码为0则说明容器是健康的。
这里补充两个通用的时间名词，但是应用时容易忽略的东西概念，请你务必要记住
这两个东西
- 延时时间：延迟检查时间，单位为秒，
- 超时时间：例如，设置为10，表明执行健康检查的超时等待时间为10秒，如果超过这个事件，本次健康检查被视为失败，若设置为0或不设置，默认超时等待时间为1秒。
还是通过的那个例子演示下探针检查机制是咋样，回到华为云CCE的操作页面，还是用Deployment的nginx K8S集群为例；
看下当前nginx探针，查看yaml文件配置，可以明显看到livenessProbe也就是存活探针配置是七层的HTTP探针，它的PATH是根，端口是80，然后你看下面是readinessProbe这是业务探针也是一样的，业务也是正常运行。如果现在我们把业务探针改为一个错误的PATH路径，比如说改成/test,这个路径是不存在七层的HTTP接口，这个时候返回的状态码是404才对
这个业务理论上说，它业务探针会检查失败，我们看下他在检查失败情况下会产生什么现象。
因为我们修改yaml，后会触发滚动升级，当它第一个Pod进行滚动升级过程中它会等待业务探针给它返回一个正确值让它处于正确状态，这里显示的实例异常。看下后台什么状况，我们看到第一个pod它容器它一直没有起来，这个就是现象
那是因为它业务探针健康检查失败，又因为设置maxonValue为1，当前滚动更新没办法运行，这个时候往往需要我们的开发与运维进入看下我们容器是否发生异常，导致业务探针无法继续执行，所以我们现在把我们的路径改成根路径，这个时候我们所有的Pod恢复正常。
我们再来看下存活探针的测试，我们把存活探针PATH改为/test，这是不正确的PATH。
这个时候理论上会发生存活探针探测失败，它会认为这个Pod是已经不存活状态，会对这个Pod进行重启，我们看下会发生什么情况。我们看到当前Pod正在滚动更新，但是过程中我们看到Pod会一直重启，我们后台终端直观看下，下面有重启次数描述，我们会看到当前几个Pod会逐步重启，但是因为的存活探针发现当前的Pod没有存活，它会不停地重启该Pod,现在所有Pod已经重启两次。这个场景下在现有环境Pod进行还存在，因为某些原因导致我们接口无法响应，这个时候我们配置存活探针，K8S就能帮助我们重启该Pod回复业务，这个重启一直会持续因为健康检查一直会失败，最后我们把CCE基于nginx的K8S集群恢复正常。
四 🐺 应用弹性伸缩原理详解
弹性伸缩说白点，就是根据业务需求和策略，经济地自动调整弹性计算资源的服务。
弹性伸缩能力分为两个维度：
工作负载弹性伸缩：就是说调度层弹性，主要是负责修改负载的调度容量变化，例如,HPA是典型的调度层弹性组件，通过HPA可以调整应用的副本数，调整的副本数会改变当前负载占用的额调度容量，从而实现调度层的伸缩。
节点弹性伸缩：即资源层弹性，主要是集群的容量规划不满足集群调度容量时，会通过弹出ECS或CCL等资源的方式进行调度容量的补充，CCE容器实例弹性到CCI服务的方法请参见CCE容器实例弹性伸缩到CCI服务。
两个维度的弹性组件与能力可以分开用，也可以结合在一起用。
1 HPA工作负载伸缩原理解析
HPA（Horizontal Pod Autoscaler）是用来控制Pod水平伸缩的控制器，HPA周期性检查Pod的度量数据，计算满足HPA资源所配置的目标数值锁需要的样本数量，进行调整目标资源(如Deployment)的replicas字段。
想要做到自动弹性伸缩，先决条件就是能感知到各种运行数据，例如集群结点Pod，容器的CPU，内存使用率等等。而这些数据的监控能力Kubemetes也没有实现，而是通过其他项目来扩展Kubemetes的能力，CCE提供如下两个插件来实现该能力：
-
Promethus是一套开源的系统监控报警框架，能够采集丰富的Metrics(度量数据)，目前已经基本是Kubemetes的标准监控方案。
-
Metriccs Server是Kubemetes集群范围资源使用数据的聚合器，Metrics Server从Kubelet公开的Summary API中采集度量数据，能够收集包括了Pod, Node, 容器，Service等主要Kubemetes核心资源的度量数据，且对外提供一套标准的API。
使用HPA配合Metrics Server可以实现基于CPU和内存的自动弹性伸缩，再配合Prometheus还可以实现自定义监控指标的自动弹性伸缩。
2 使用HPA+CA实现工作负载和结点联动弹性伸缩
弹性伸缩最主要的就是HPA和CA（Cluster AutoScaling)两种弹性伸缩策略，HPA负责工作负载弹性伸缩，也就是应用蹭饭面的弹性伸缩。
通常情况下，两者需要配合使用才行，因为HPA需要集群有足够的资源才能扩容成功，当集群资源不够是需要CA扩容节点，使得集群有足够资源，而当HPA缩容后集群会有大量空余资源，这时需要CA缩容节点释放资源，才不至于造成浪费。
好我们这里有个HPA示例，创建一个HPA，期望CPU的利用率是70%，副本数的范围是1-10，如下图所示
上面有几个字段，比如有最大副本数量，最小副本数量，还有需要的资源，CPU，目标值是70%，配置后给一个工作负载Pod来创建它的HPA,当我们创建后查看HPA,命令如下这种
显示结果下图：
本次实验还是通过无状态负载Deployment的基于nginx K8S集群结点来进行测试弹性伸缩的HPA，先点击左侧弹性伸缩页面，然后创建工作负载HPA策略，然后我们这里选择工作负载为nginx,实例范围希望工作负载，能够在哪个范围内进行弹性伸缩，选择1-5即可，冷却时间缩容5分钟，扩容3分钟，加一个策略可以基于CPU的利用率，期望值是60%哈
阈值，这里具体含义是当指标值大于缩容阈值且小于扩容阈值是，不会触发扩容或缩容。为什么，防止缩扩容过于敏感才这样做。
然后我们到后台终端看下，命令是 kubectl get hpa 当前它的策略，当前我们的tangets是60% CPU利用率1%，还有最小缩容Pod数是1，最大是5。当前值是4，因为它有一定的冷却时间，我们要再观察一下，还要说一下这个冷却时间前面说了是为弹性伸缩过于敏感，导致deployment的pod数抖动频繁，反而影响业务。这里你可以看下当前状态，这里缩容时间为5分钟。如果要使用弹性伸缩功能，必须还要安装下面我画出三个插件。
第一个插件提供CPU与内存的弹性伸缩，第二个是自定义指标的弹性伸缩。
可以看到nginx的副本数已经变为1，所以说我们在到后台终端去看当前副本数已经从4变成1，这样我们就完成一次HPA弹性伸缩实验啦。
五 🌺 再来总结
-
1 K8S目标是把部署容器化的应用简单并且高效(powerful)，它提供了应用部署，规划，更新，维护的一系列操作机制；
-
2 对计算资源进行了更高层次的抽象，把容器进行细致的组合，最终的应用服务交给用户。Kubernetes在模型建立之初就考虑了容器跨机连接的要求，支持多种网络解决方案，同时在Service层次构建集群范围的SDN网络。
-
3 做了弹性伸缩，资源监控，一旦CPU、内存、网络达到阈值立马扩容出一个pod出来，20台ecs的资源池说多不多，他们是一个流量型的应用，用户访问的频率取决于当下的热门实事，这种类型的应用APP肯定不能基于固定资源池内玩 资源动态伸缩。
-
4 更新与回滚机制非常的方便，Deployment可以设置不同的更新策略，在更新出现问题之前，可能需要对应用回滚，k8s支持更具deployment的历史版本进行回滚。
-
5 在生产环境中，一个应用健康状态对我们的业务非常重要，如果流量进入不健康Pod，会导致我们业务受损，这里就需要引入探针去进行检测；这个场景下在现有环境Pod进行还存在，因为某些原因导致我们接口无法响应，这个时候我们配置存活探针，K8S就能帮助我们重启该Pod回复业务。
-
6 弹性伸缩是根据业务需求和策略，经济地自动调整弹性计算资源的服务；HPA（Horizontal Pod Autoscaler）是用来控制Pod水平伸缩的控制器，HPA周期性检查Pod的度量数据，计算满足HPA资源所配置的目标数值锁需要的样本数量，进行调整目标资源(如Deployment)的replicas字段。
华为云官网链接:
- https://support.huaweicloud.com/usermanual-cce/cce_01_0249.html
- https://support.huaweicloud.com/usermanual-cce/cce_01_0094.html
Kubernetes官方文档:
- https://kubernetes.io/docs/concepts/services-networking/servicel
- https://kubernetes.io/docs/concepts/services-networking/ingress
本文整理自华为云社区【内容共创】活动第14期。
查看活动详情：https://bbs.huaweicloud.com/blogs/336904
相关任务详情：任务18.华为云云原生钻石课程08：Kubernetes运维管理深度详解（上）
- 点赞
- 收藏
- 关注作者
评论（0）