Kubernetes学习(六)—— Pod控制器

颠峰战犯

本章节次要介绍经常使用的Pod掌握器。
1. Pod掌握器介绍

正在kubernetes中，根据pod的创立安方法能够将其分为两类：

自立式pod：kubernetes间接创立出去的pod，这类pod删除后便出有了，也没有会重修
掌握器创立的pod：经由过程掌握器创立的pod，这类pod删除以后借会主动重修

甚么是Pod掌握器
Pod掌握器是办理pod的中心层，利用了pod掌握器以后，我们只需求报告pod掌握器，念要几个甚么样的pod就能够了，它便会创立出满意前提的pod并确保每一个pod处于用户希冀的形态，假如pod正在运转中呈现毛病，掌握器会基于指定战略重启动大概重修pod。

正在kubernetes中，有许多规范的pod掌握器，每种皆有本人的合适的场景，常睹的有上面那些：

ReplicationController：比力本初的pod掌握器，曾经被烧毁，由ReplicaSet替换
ReplicaSet：包管指定数量的pod运转，并撑持pod数目变动，镜像版本变动
Depployment：经由过程掌握ReplicaSet去掌握pod，并撑持转动晋级、版本回退
Horizontal Pod AutoScaler：能够按照散群背载主动调整Pod的数目，熟习爱您削峰挖谷
DaemonSet：正在散群中的指定Node上运转一个副本，普通用于保护历程类的使命
Job：它创立出去的pod只需完成使命便立刻退出，用于施行一次性使命
Cronjob：他创立的pod会周期性的施行，用于施行周期使命

2. ReplicaSet

ReplicaSet的次要感化是包管必然命量的pod可以一般运转，它会持续监听那些pod的运转形态，一旦pod发作毛病，便会重启或重修。同时它借撑持对pod数目的扩缩容战版本镜像的晋级。

ReplicaSet的资本浑单文件：

apiVersion: v1
kind: ReplicaSet # 范例
metadata: #
name: # rs称号
namespace: # 所属定名空间
labels: # 标签
controller: rs
spec: # 详情形貌
replicas: 3 # 副本数目
selector: # 挑选器，经由过程它指定该掌握器办理那些pod
matchLabels: # Labels婚配划定规矩
app: nginx-pod
matchExpressions: # Expression婚配划定规矩
- {key: app, operator: In, values: [nginx-pod]}
template: # 模本，当副本数目不敷时，会按照上面的模板创立pod副本
metadata:
labels:
app: nginx-pod
spec:
containers:
- name: nginx
image: nginx:1.17.1
ports:
- containerPort: 80

复造代码

正在那里面，需求新了解的设置项即便spec上面几个选项：

replicas：指定副本数目，实在便是当前rs创立出去的pod的数目，默许为1
selector：挑选器，它的感化便是成立pod掌握器战pod之间的联系关系干系，接纳的Label Selector机造，正在pod模板上定义label，正在掌握器上定义挑选器，就能够表白当期那掌握器就可以办理哪些pod了
template：模板，便是当前掌握器创立pod所利用的模板，里面实在即便前一章教过的pod的定义

创立ReplicaSet
创立pc-replicaset.yaml文件，内乱容以下：

apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: pc-replicaset
namespace: dev
spec:
replicas: 3
selector:
matchLabels:
app: nginx-pod
template:
metadata:
labels:
app: nginx-pod
spec:
containers:
- name: nginx
image: nginx:1.17.1

复造代码

# 创立rs
[root@master ~]# kubectl create -f pc-replicaset.yaml
replicaset.apps/pc-replicaset created
# 检察rs
# DESIRED:希冀副本数目
# CURRENT:当前副本数目
# READY:曾经筹办好供给效劳的副本数目
[root@master ~]# kubectl get rs pc-replicaset -n dev -o wide
NAME DESIRED CORRENT READY AGE CONTAINERS IMAGES SELECTOR
pc-replicaset 3 3 3 22s nginx nginx:1.17.1 app=nginx-pod
# 检察当前掌握器创立出去的pod
# 那里发明掌握器创立出去的pod的称号是正在掌握器称号前面拼接了-xxxx随机码
[root@master ~]# kubectl get pod -n dev
NAME READY STATUS RESTARTS AGE
pc-replicaset-6vmvt 1/1 Running 0 54s
pc-replicaset-fm8f 1/1 Running 0 54s
pc-replicaset-snrk 1/1 Running 0 54s

复造代码

扩缩容

# 编纂rs的副本数目，修正spec:replicas: 6 便可
[root@master ~]# kubectl edit rs pc-replicaset -n dev
replicaset.apps/pc-replicaset edited
# 检察pod
[root@master ~]# kubectl get pod -n dev
NAME READY STATUS RESTARTS AGE
pc-replicaset-6vmvt 1/1 Running 0 114s
pc-replicaset-cftnp 1/1 Running 0 10s
pc-replicaset-fjlm6 1/1 Running 0 10s
pc-replicaset-fmb8f 1/1 Running 0 114s
pc-replicaset-s2whj 1/1 Running 0 10s
pc-replicaset-snrk2 1/1 Running 0 114s
# 固然也能够间接利用号令完成
# 利用scale号令完成扩缩容，前面--replias=n间接指定目的数目便可
[root@master ~]# kubectl scale rs pc-replicaset --replicas=2 -n dev
replicaset.apps/pc-replicaset scale
# 号令运转终了，立刻检察，发明曾经有4个开端筹办退出了
[root@master ~]# kubectl get pod -n dev
NAME READY STATUS RESTARTS AGE
pc-replicaset-6vmvt 0/1 Terminatin 0 118s
pc-replicaset-cftnp 0/1 Terminatin 0 4m17
pc-replicaset-fjlm6 0/1 Terminatin 0 4m17
pc-replicaset-fmb8f 1/1 Running 0 118s
pc-replicaset-s2whj 0/1 Terminatin 0 4m17
pc-replicaset-snrk2 1/1 Running 0 118s
# 稍等片晌，便只剩下2个了
[root@master ~]# kubectl get pod -n dev
NAME READY STATUS RESTARTS AGE
pc-replicaset-fmb8f 1/1 Running 0 119s
pc-replicaset-snrk2 1/1 Running 0 119s

复造代码

镜像晋级

# 编纂rs的容器镜像 - image: nginx:1.17.2
[root@master ~]# kubectl edit rs pc-replicaset -n dev
replicaset.apps "pc-replicaset" edited
# 再次检察，发明镜像版本曾经变动了
[root@master ~]# kubectl get rs -n dev -o wide
NAME DESIRED CORRENT READY AGE CONTAINERS IMAGES
pc-replicaset 2 2 2 140m nginx nginx:1.17.2
# 一样的原理，也能够利用号令完成那个事情
# kubectl set image rs rs称号容器=镜像版本 -n namespace
[root@master ~]# kubectl set image rs pc-replicaset nginx=nginx:1.17.1 -n dev
# 再次检察，发明镜像版本曾经变动了
[root@master ~]# kubectl get rs pc-replicaset -n dev -o wide
NAME DESIRED CORRENT READY AGE CONTAINERS IMAGES
pc-replicaset 2 2 2 145m nginx nginx:1.17.1

复造代码

删除ReplicaSet

# 利用kubectl delete号令会删除此RS和它办理的pod
# 正在kubernetes删除RS前，会将RS的replicascalear调解为0，等候一切的pod被删除后，正在施行RS工具的删除
[root@master ~]# kubectl delete rs pc-replicaset -n dev
replicaset.apps "pc-replicaset" deleted
[root@master ~]# kubectl get pod -n dev -o wide
No resources found in dev namespace.
# 假如期望仅仅删除RS工具(保存Pod),可使用kubectl delete 号令时增加--cascade=false选项(没有保举)
[root@master ~]# kubectl delete rs pc-replicaset -n dev --cascade=false
replicaset.apps "pc-replicaset" deleted
[root@master ~]# kubectl get pods -n dev
NAME READY STATUS RESTARTS AGE
pc-replicaset-cl82j 1/1 Running 0 75s
pc-replicaset-fslhb 1/1 Running 0 75s
# 也能够利用yaml间接删除(保举)
[root@master ~]# kubectl delete -f pc-replicaset.yaml
replicaset.apps "pc-replicaset" deleted

复造代码

3. Deployment

为了更好的处理效劳编排的成绩，kubernetes正在v1.2版本开端，引进了Deployment掌握。值得一提的是，这类掌握器其实不间接受理pod，而是经由过程办理ReplicaSet去直接受理Pod,即：Deployment办理ReplicaSet，ReplicaSet办理Pod。以是Deployment比ReplicaSet功用更加强年夜。

Deployment次要功用有上面几个：

撑持ReplicaSet的一切功用
撑持公布的截至、持续
撑持版本转动晋级战版本回退

Deployment的资本浑单文件：

apiVersion: apps/v1 # 版本号
kind: Deployment # 范例
metadata: # 元数据
name: # rs称号
namespace: # 所属定名空间
labels: # 标签
controller: deploy
spec: # 详情形貌
replicas: 3 # 副本数目
revisionHistoryLimit: 3 # 保存汗青版本，默许为是10
pause: false # 停息布置，默许是false
progressDeadlineSeconds: 600 # 布置超不时间(s),默许是600
strategy: # 战略
type: RollingUpdate # 转动更新战略
rollingUpdate: # 转动更新
maxSurge: 30% # 最年夜分外能够存正在的副本数，能够为百分比，也能够为整数
maxUnavailable: 30% # 最年夜不成用形态的Pod的最年夜值，能够为百分比，也能够为整数
selector: # 挑选器，经由过程他指定该掌握器办理哪些Pod
matchLabels: # Labels婚配划定规矩
app: nginx-pox
matchExpressions: # Expressions婚配划定规矩
- {key: app, operator: In, values: [nginx-pod]}
template: # 模板，当副本数目不敷时，会按照上面的终班创立pod副本
metadata:
labels:
app: nginx-pod
spec:
containers:
- name: nginx
image: nginx:1.17.1
ports:
- containerPort: 80

复造代码

创立deployment
创立pc-deployment.yaml,内乱容以下：

apiVersion: apps/v1
kind: Deployment
metadata:
name: pc-deployment
namespace: dev
spec:
replicas: 3
selector:
matchLabels:
app: nginx-pod
template:
metadata:
labels:
app: nginx-pod
spec:
containers:
- name: nginx
image: nginx:1.17.1

复造代码

# 创立deployment
# --record=true 记载每次的版本变革
# 创立rs
[root@master ~]# kubectl create -f pc-deployment.yaml
replicaset.apps/pc-deployment created
# 检察deployment
# UP-TO-DATE 最新版本的pod的数目
# AVAILABLE 当前可用的pod的数目
[root@master ~]# kubectl get deploy pc-deployment -n dev
NAME READY UP-TO-DATE AVAILABLE AGE
pc-deployment 3/3 3 3 15s
# 检察rs
# 发明rs的称号是正在本来的deployment的名字前面增加了一个10位数的随机串
[root@master ~]# kubectl get rs -n dev
NAME DESIRED CURRENT READY AGE
pc-deployment-6696798B78 3 3 3 23s
# 检察pod
[root@master ~]# kubectl get pod -n dev
NAME READY STATUS RESTARTS AGE
pc-deployment-6696798B78-d2c8n 1/1 Running 0 107s
pc-deployment-6696798B78-smpvp 1/1 Running 0 107s
pc-deployment-6696798B78-wvjd8 1/1 Running 0 107s

复造代码

扩缩容

# 变动副本数目为5个
[root@master ~]# kubectl scale deploy pc-deployment --replicas=5 -n dev
replicaset.apps/pc-deployment scale
# 检察deployment
[root@master ~]# kubectl get deploy pc-deployment -n dev
NAME READY UP-TO-DATE AVAILABLE AGE
pc-deployment 5/5 5 5 15s
# 检察pod
[root@master ~]# kubectl get pod -n dev
NAME READY STATUS RESTARTS AGE
pc-deployment-6696798B78-d2c8n 1/1 Running 0 107s
pc-deployment-6696798B78-jxmdq 1/1 Running 0 94s
pc-deployment-6696798B78-mktqv 1/1 Running 0 93s
pc-deployment-6696798B78-smpvp 1/1 Running 0 107s
pc-deployment-6696798B78-wvjd8 1/1 Running 0 107s
# 编纂deployment的副本数目，修正spec:replicas: 4 便可
[root@master ~]# kubectl edit deploy pc-deployment -n dev
replicaset.apps/pc-deployment edited
# 检察pod
[root@master ~]# kubectl get pod -n dev
NAME READY STATUS RESTARTS AGE
pc-deployment-6696798B78-d2c8n 1/1 Running 0 5m23s
pc-deployment-6696798B78-jxmdq 1/1 Running 0 2m38s
pc-deployment-6696798B78-smpvp 1/1 Running 0 5m23s
pc-deployment-6696798B78-wvjd8 1/1 Running 0 5m23s

复造代码

镜像更新
Deployment撑持两种镜像更新战略：重修更新战转动更新(默许)，能够经由过程strategy选项停止设置。

strategy: # 施行新的pod交换旧的Pod的战略，撑持两个属性
type: # 指定战略范例，撑持两种战略
Recreate: # 正在创立出新的Pod之前会先杀失落一切已存正在的Pod
RollingUpdate: # 转动更新，便是杀逝世一部门，便启动一部门，正在更新过程当中，存正在两个版本的Pod
rollingUpdate: # 当type为RollingUpdate时见效，用于为RollingUpdate设置参数，撑持两个属性
maxUnavailable: # 用去指定正在晋级过程当中不成用Pod的最年夜数目，默许为25%
maxSurge: # 用去指定晋级过程当中能够超越希冀的Pod的最年夜数目，默许为25%

复造代码

重修更新
1）编纂pc-deployment.yaml,正在spec节面下增加更新战略

spec:
strategy: # 战略
type: Recreate: # 重修更新战略

复造代码

2）创立deploy停止考证

# 变动镜像
[root@master ~]# kubectl set image deployment pc-deployment nginx-nginx:1.17.2 -n dev
replicaset.apps/pc-deployment image updated
# 察看晋级历程
[root@master ~]# kubectl get pods -n dev -w
NAME READY STATUS RESTARTS AGE
pc-deployment-5d89bdfbf9-cl82j 1/1 Running 0 78s
pc-deployment-5d89bdfbf9-kkhr9 1/1 Running 0 78s
pc-deployment-5d89bdfbf9-vznbl 1/1 Running 0 78s
pc-deployment-5d89bdfbf9-cl82j 1/1 Terminating 0 97s
pc-deployment-5d89bdfbf9-vznbl 1/1 Terminating 0 97s
pc-deployment-5d89bdfbf9-kkhr9 1/1 Terminating 0 97s
pc-deployment-5d89bdfbf9-g9f85 0/1 Pending 0 0s
pc-deployment-5d89bdfbf9-qz48q 0/1 Pending 0 0s
pc-deployment-5d89bdfbf9-9sw59 0/1 Pending 0 0s
pc-deployment-5d89bdfbf9-g9f85 0/1 ContainerCreating 0 0s
pc-deployment-5d89bdfbf9-qz48q 0/1 ContainerCreating 0 0s
pc-deployment-5d89bdfbf9-9sw59 0/1 ContainerCreating 0 0s
pc-deployment-5d89bdfbf9-g9f85 1/1 Running 0 2s
pc-deployment-5d89bdfbf9-qz48q 1/1 Running 0 2s
pc-deployment-5d89bdfbf9-9sw59 1/1 Running 0 28s

复造代码

转动更新

编纂pc-deployment.yaml，正在spec节面下增加更新战略

strategy: # 战略
type: RollingUpdate # 转动更新战略
rollingUpdate:
maxUnavailable: 25%
maxSurge: 25%

复造代码

创立deploy停止考证

# 变动镜像
[root@master ~]# kubectl set image deployment pc-deployment nginx=nginx:1.17.3 -n dev
replicaset.apps/pc-deployment image updated
# 察看晋级历程
[root@master ~]# kubectl get pods -n dev -w
NAME READY STATUS RESTARTS AGE
pc-deployment-5d89bdfbf9-4b7nw 1/1 Running 0 49s
pc-deployment-5d89bdfbf9-95hdx 1/1 Running 0 50s
pc-deployment-5d89bdfbf9-wf2b7 1/1 Running 0 47s
pc-deployment-7865c58bdf-8rxj5 0/1 Pending 0 0s
pc-deployment-7865c58bdf-8rxj5 0/1 ContainerCreating 0 0s
pc-deployment-7865c58bdf-8rxj5 1/1 Running 0 28s
pc-deployment-5d89bdfbf9-wf2b7 1/1 Terminating 0 80s
pc-deployment-7865c58bdf-6tk5r 0/1 Pending 0 0s
pc-deployment-7865c58bdf-6tk5r 0/1 ContainerCreating 0 0s
pc-deployment-7865c58bdf-6tk5r 1/1 Running 0 34s
pc-deployment-5d89bdfbf9-95hdx 0/1 Terminating 0 81s
pc-deployment-7865c58bdf-ttwgg 0/1 Pending 0 0s
pc-deployment-7865c58bdf-ttwgg 0/1 ContainerCreating 0 0s
pc-deployment-7865c58bdf-ttwgg 1/1 Running 0 1s
pc-deployment-5d89bdfbf9-4b7nw 0/1 Terminating 0 2m1s

复造代码

转动更新的历程

镜像更新中rs的变革：

# 检察rs，发明本来的rs的照旧存正在，只是pod数目变成了0，然后又新发生了一个rs，pod数目为4
# 实在便是deploymennt可以停止版本回退的玄妙地点，前面会具体注释
[root@master ~]# kubectl get rs -n dev
NAME DESIRED CURRENT READY AGE
pc-deployment-5d89bdfbf9 0 0 0 11m
pc-deployment-675d469f8b 0 0 0 10s
pc-deployment-7865c58bdf 3 3 3 3m41s

复造代码

版本回退
deployment撑持版本晋级过程当中的停息、持续功用和版本回退等诸多功用，上面详细去看：
kubectl rollout：版本晋级相干功用，撑持上面的选项：

status 显现当前晋级形态
history 显现晋级汗青记载
pause 停息版本晋级历程
resume 持续曾经停息的版本晋级历程
restart 重启版本晋级历程
undo 回滚到上一级版本（可使用–to-revision回滚到指定版本）

# 检察当前晋级版本的形态
[root@master ~]# kubectl rollout status deploy pc-deployment -n dev
deployment "pc-deployment" successfully rolled out
# 检察晋级汗青记载
[root@master ~]# kubectl rollout history deploy pc-deployment -n dev
deployment.app/pc-deployment
REVISION CHANGE-CAUSE
1 kubectl create --filename=pc-deployment.yaml --record=true
2 kubectl create --filename=pc-deployment.yaml --record=true
3 kubectl create --filename=pc-deployment.yaml --record=true
# 能够发明有三次版本记载，阐明完成过两次晋级
# 版本回滚
# 那里间接利用--to-revision=1回滚了1版本，假如省略那个选项，便是回退到上个版本，便是2版本
[root@master ~]# kubectl rollout undo deployment pc-deployment --to-revision=1 -n dev
deployment.app/pc-deployment rolled back
# 检察发明，经由过程nginx镜像版本能够发明到初版本
[root@master ~]# kubectl get deploy -n dev -o wide
NAME READY UP-TO-DATE AVAILABLE AGE CONTANTNERS IMAGES
pc-deployment 4/4 4 4 74s nginx ginx:1.17.1
# 检察rs，发明第一个rs中有4个pod运转，前面两个版本的rs中pod为运转
# 实在deployment之以是但是完成版本的回滚，便是经由过程记载下汗青rs去完成的，
# 一旦念回滚到哪一个版本，只需求将当前版本pod数目降为0，然后将回滚版本的pod提拔为目的数目就能够了
[root@master ~]# kubectl get rs -n dev
NAME DESIRED CURRENT READY AGE
pc-deployment-6696798b78 4 4 4 78m
pc-deployment-966bf7f44 0 0 0 37s
pc-deployment-c848d767 0 0 0 71s

复造代码

金丝雀公布
Deployment撑持更新过程当中的掌握，如“停息(pause)”或“持续(resume)”更新操纵。
好比有一批新的Pod资本创立完成后立刻停息更新历程，此时，仅存正在一部门新版本的使用，主题部门仍是旧的版本。然后，正在挑选一小部门的用户恳求路由到新版的Pod使用，持续察看可否文档的定期视的方法运转。肯定出成绩以后再持续完成余下的Pod资本转动更新，不然立刻回滚更新操纵。那便是所谓的金丝雀公布。

# 更新deployment的版本，并设置停息deployment
[root@master ~]# kubectl set image deploy pc-deployment nginx=nginx:1.18.4 -n dev && kubectl rollout pause deployment pc-deployment -n dev
deployment.apps/pc-deployment iamge updated
deployment.apps/pc-deployment paused
# 察看更新形态
[root@master ~]# kubectl rollout status deploy pc-deployment -n dev
Waiting for deployment "pc-deployment" rollout to finish: 2 out of 4 new replicas have been updated...
# 监控更新的历程，能够看到曾经新删了一个资本，可是并已根据预期的形态删除一个旧的资本，便是由于利用了pause停息号令
[root@master ~]# kubectl get rs -n dev -o wide
NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES
pc-deployment-5d89bdfbf9 3 3 3 19s nginx nginx:1.17.1
pc-deployment-675d469f8b 0 0 0 14s nginx nginx:1.17.2
pc-deployment-6c9f56fcfb 2 2 2 3m16s nginx nginx:1.17.4
[root@master ~]# kubectl get pods -n dev
NAME READY STATUS RESTARTS AGE
pc-deployment-5d89bdfbf9-rj8sq 1/1 Running 0 7m33s
pc-deployment-5d89bdfbf9-ttwgg 1/1 Running 0 7m35s
pc-deployment-5d89bdfbf9-v4wvc 1/1 Running 0 7m34s
pc-deployment-5d89bdfbf9-996rt 1/1 Running 0 3m31s
pc-deployment-5d89bdfbf9-j2gtj 1/1 Running 0 3m31s
# 确保更新的pod出成绩了，持续更新
[root@master ~]# kubectl rollout resume deploy pc-deployment -n dev
deployment.apps/pc-deployment resumed
# 检察最初的更新状况
[root@master ~]# kubectl get rs -n dev -o wide
NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES
pc-deployment-5d89bdfbf9 0 0 0 21s nginx nginx:1.17.1
pc-deployment-675d469f8b 0 0 0 16s nginx nginx:1.17.2
pc-deployment-6c9f56fcfb 4 4 4 5m11s nginx nginx:1.17.4
[root@master ~]# kubectl get pods -n dev
NAME READY STATUS RESTARTS AGE
pc-deployment-5d89bdfbf9-76fwh 1/1 Running 0 37s
pc-deployment-5d89bdfbf9-996rt 1/1 Running 0 5m27s
pc-deployment-5d89bdfbf9-j2gtj 1/1 Running 0 5m27s
pc-deployment-5d89bdfbf9-rf84v 1/1 Running 0 37s

复造代码

删除Deployment

# 删除deployment,其下的rs战pod也将被删除
[root@master ~]# kubectl delete -f pc-deployment.yaml
deployment.app "pc-deployment" deleted

复造代码

4. Horizontal Pod AutoScaler(HPA)

正在前里的课程中，我们能够经由过程脚工施行kubectl scale号令完成Pod扩容，可是那明显没有契合Kubernetes的定位目的–主动化、智能化。Kubernetes希冀能够经由过程检测Pod的利用状况，完成pod数目的主动调整，因而便发生了HPA这类掌握器。
HPA能够获得每一个pod操纵率，然后战HPA中定义的目标停止比照，同时策画出需求伸缩的详细值，最初完成pod的数目的调整。实在HPA取之前的Deployment一样，也属于一种Kubernetes资本工具，它经由过程逃踪阐发目的pod的背载变革状况，去肯定能否需求针对性天调整目的pod的副本数。

1 装置metrics-server

# 装置git
[root@master ~]# yum install git -y
# 获得metrics-server,留意利用的版本
[root@master ~]# git clone -b v0.3.6 https://github.com/kubernetes-incubator/metrics-server.git
# 修正deployment,留意修正的是镜像战初初化参数
[root@master ~]# cd /root/metrics-server/deploy/1.8+/
[root@master 1.8+]# vim metrics-server-deployment.yaml
#根据图中增加以下选项
hostNetwork: true
registry.cn-hangzhou.aliyuncs.com/谷歌_containers/metrics-server-amd64:v0.3.6
- --kubelet-insecure-tls
- --kubelet-preferred-address-types=InternalIP,Hostname,InternalDNS,ExternalDNS,ExternalIP

复造代码

# 装置metrics-server
[root@master 1.8+]# kubectl apply -f ./
# 检察pod运转状况
[root@master 1.8+]# kubectl get pod -n kube-system
metrics-server-6b976979db-2xwbj 1/1 Running 0 90s
# 利用kubectl top node 检察资本利用状况(略微等候一段数工夫)
[root@master 1.8+]# kubectl top node
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
master 98m 4% 1067Mi 62%
node1 27m 1% 727Mi 42%
node2 34 1% 800Mi 46%
[root@master 1.8+]# kubectl top pod -n kube-system
NAME CPU(cores) MEMORY(bytes)
coredns-6955765f44-7ptsb 3m 9Mi
coredns-6955765f44-vcwr5 3m 8Mi
coredns-master 14m 145Mi
...
# 至此，metrics-server装置完成

复造代码

2 筹办deployment战service

为了操纵简朴，间接利用号令

# 创立deployment
[root@master 1.8+]# kubectl run nginx --image=nginx:latest --requests=cpu=100m -n dev
# 创立service
[root@master 1.8+]# kubectl expose deployment nginx --type=NodePort --port=80 -n dev
# 检察
[root@master 1.8+]# kubectl get deployment,pod,svc -n dev
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/nginx 1/1 1 1 47s
NAME READY STATUS RESTARTS AGE
pod/nginx-7df9756ccc-bh8dr 1/1 Running 0 47s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/nginx NodePort 10.109.57.248 <none> 80:31136/TCP 35s

复造代码

3 布置HPA

创立pc-hpa.yaml

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: pc-hpa
namespace: dev
spec:
minReplicas: 1 # 最小pod数目
maxReplicas: 10 # 最年夜pod数目
targetCPUUtilizationPercentage: 3 # CPU利用率目标
scaleTargetRef: # 指定要掌握的nginx疑息
apiVersion: apps/v1
kind: Deployment
name: nginx

复造代码

# 创立hpa
[root@master 1.8+]# kubectl create -f pc-hpa.yaml
horizontalpodautoscaler.autoscaling/pc-hpa created
# 检察hpa
[root@master 1.8+]# kubectl get hpa -n dev
NAME REFERENCE TARGETS NINPODS MAXPODS REPLICAS AGE
pc-hpa Deployment/nginx 0%/3% 1 10 1 62s

复造代码

4 测试

利用压测东西对service地点192.168.109.100:31136停止压测，然后经由过程掌握台检察hps战pod的变革
hpa变革

[root@master ~]# kubectl get hpa -n dev -w
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
pc-hpa Deployment/nginx 0%/3% 1 10 1 4m11s
pc-hpa Deployment/nginx 0%/3% 1 10 1 5m19s
pc-hpa Deployment/nginx 22%/3% 1 10 1 6m50s
pc-hpa Deployment/nginx 22%/3% 1 10 4 7m5s
pc-hpa Deployment/nginx 22%/3% 1 10 8 7m21s
pc-hpa Deployment/nginx 6%/3% 1 10 8 7m51s
pc-hpa Deployment/nginx 0%/3% 1 10 8 9m6s
pc-hpa Deployment/nginx 0%/3% 1 10 8 13s
pc-hpa Deployment/nginx 0%/3% 1 10 1 14s

复造代码

deployment变革

[root@master ~]# kubectl get deployment -n dev -w
NAME READY UP-TO-DATE AVAILABLE AGE
nginx 1/1 1 1 11m
nginx 1/4 1 1 13m
nginx 1/4 1 1 13m
nginx 1/4 1 1 13m
nginx 1/4 4 1 13m
nginx 1/8 4 1 14m
nginx 1/8 4 1 14m
nginx 1/8 4 1 14m
nginx 1/8 8 1 14m
nginx 2/8 8 2 14m
nginx 3/8 8 3 14m
nginx 4/8 8 4 14m
nginx 5/8 8 5 14m
nginx 6/8 8 6 14m
nginx 7/8 8 7 14m
nginx 8/8 8 8 15m
nginx 8/1 8 8 20m
nginx 8/1 8 8 20m
nginx 1/1 1 1 20m

复造代码

pod变革

[root@master ~]# kubectl get pods -n dev -w
NAME READY STATUS RESTARTS AGE
nginx-7df9756ccc-bh8dr 1/1 Running 0 11m
nginx-7df9756ccc-cpgrv 0/1 Pending 0 0s
nginx-7df9756ccc-8zhwk 0/1 Pending 0 0s
nginx-7df9756ccc-rr9bn 0/1 Pending 0 0s
nginx-7df9756ccc-cpgrv 0/1 ContainerCreating 0 0s
nginx-7df9756ccc-8zhwk 0/1 ContainerCreating 0 0s
nginx-7df9756ccc-rr9bn 0/1 ContainerCreating 0 0s
nginx-7df9756ccc-m9gsj 0/1 Pending 0 0s
nginx-7df9756ccc-g56qb 0/1 Pending 0 0s
nginx-7df9756ccc-sl9c6 0/1 Pending 0 0s
nginx-7df9756ccc-fgst7 0/1 Pending 0 0s
nginx-7df9756ccc-g56qb 0/1 ContainerCreating 0 0s
nginx-7df9756ccc-m9gsj 0/1 ContainerCreating 0 0s
nginx-7df9756ccc-sl9c6 0/1 ContainerCreating 0 0s
nginx-7df9756ccc-fgst7 0/1 ContainerCreating 0 0s
nginx-7df9756ccc-8zhwk 1/1 Running 0 19s
nginx-7df9756ccc-rr9bn 1/1 Running 0 30s
nginx-7df9756ccc-m9gsj 1/1 Running 0 21m
nginx-7df9756ccc-cpgrv 1/1 Running 0 47m
nginx-7df9756ccc-sl9c6 1/1 Running 0 33m
nginx-7df9756ccc-g56qb 1/1 Running 0 48m
nginx-7df9756ccc-fgst7 1/1 Running 0 66m
nginx-7df9756ccc-fgst7 1/1 Terminating 0 6m50s
nginx-7df9756ccc-8zhwk 1/1 Terminating 0 7m5s
nginx-7df9756ccc-cpgrv 1/1 Terminating 0 7m5s
nginx-7df9756ccc-q56gb 1/1 Terminating 0 6m50s
nginx-7df9756ccc-rr9bn 1/1 Terminating 0 7m5s
nginx-7df9756ccc-m9gsj 1/1 Terminating 0 6m50s
nginx-7df9756ccc-sl9c6 1/1 Terminating 0 6m50s

复造代码

5. DaemonSet

DaemonSet规范的掌握器能够包管散群中的每台（或指定）节面上皆运转一个副本，普通合用于日记搜集、节面监控等场景。也便是道，假如一个pod供给的功用是节面级此外（每一个节面皆需求且只需求一个），那末那类Pod便合适利用DaemonSet规范的掌握器创立。

DaemonSet掌握器的特性：

每当背散群中增加一个节面时，指定的pod副本也将增加到该节面上。
当节面从散群中移除时，pod也便被渣滓收受接管了

上面先去看下DaemonSet的资本浑单文件

apiVersion: apps/v1 # 版本号
kind: DaemonSet # 范例
metadata: # 元数据
name: pc-daemonSet # rs称号
labels: # 标签
controller: daemontset
spec:
revisionHistoryLimit: 3 # 保存汗青版本
updateStrategy: # 更新战略
type: RollingUpdate # 转动更新战略
rollingUpdate: # 转动更新
maxUnavailable: 1 # 最年夜不成用形态的pod的最年夜值，能够为百分比，也能够为正数
selector: # 挑选器，经由过程它指定该掌握器管束哪些pod
matchLabels: # Labels婚配划定规矩
app: nginx-pod
matchExpressions: # Expression婚配划定规矩
- {key: app, operator: In, values: [nginx-pod]}
template: # 终班，当副本数目不敷时，会按照上面的模板创立pod副本
metadata:
labels:
app: nginx-pod
spec:
containers:
- name: nginx
image: nginx:1.17.1
ports:
- containerPort: 80

复造代码

创立pc-daemonset.yaml，内乱容以下：

apiVersion: apps/v1
kind: DaemonSet
metadata:
name: pc-daemonset
namespace: dev
spec:
selector:
matchLabels:
app: nginx-pod
template:
metadata:
labels:
app: nginx-pod
spec:
containers:
- name: nginx
image: nginx:1.17.1

复造代码

# 创立daemontset
[root@master ~]# kubectl create -f pc-daemonset.yaml
daemonset.apps/pc-daemonset created
# 检察daemonset
[root@master ~]# kubectl get ds -n dev -o wide
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES
pc-daemont 2 2 2 2 2 24s nginx nginx:1.17.1
# 检察pod,发明正在每一个Node上皆运转一个pod
[root@master ~]# kubectl get pods -n dev -o wide
NAME READY STATUS RESTARTS AGE IP NODE
pc-daemonset-9bck8 1/1 Running 0 37s 10.244.1.43 node1
pc-daemonset-k224w 1/1 Running 0 37s 10.244.2.74 node2
# 删除daemonset
[root@master ~]# kubectl delete -f pc-daemonset.yaml
daemonset.apps "pc-daemontset" deleted

复造代码

6. Job

Job次要用于卖力批量处理惩罚长久的一次性使命。Job的特性以下：

当Job创立的pod施行成功时，Job将记载成功成果的pod数目
当成功完毕的pod到达指定的数目时，Job将完成施行

Job的资本浑单文件：

apiVersion: batch/v1 # 版本号
kind: Job # 范例
metadata: # 元数据
name: jobName # rs称号
namespace: # 所属定名空间
labels: # 标签
controller: job
spec: # 详情形貌
completions: 1 # 指定job需求陈宫运转Pods的次数。默许值：1
parallelism: 1 # 指定job正在随便时辰该当并收运转Pods的数目。默许值：1
activeDeadlineSeconds: 10 # 指定job可运转的工夫限期，超越工夫借已完毕，体系将会测验考试停止停止。
backoffLimit: 6 # 指定job失利落后止重拾的次数。默许是6
manuaSelector: true # 能否可使用selector挑选器挑选pod,默许是false
selector: # 挑选器，经由过程它指定该掌握器办理哪些pod
matchLabels: # Labels婚配划定规矩
app: counter-pod
matchExpressions: # Expressions婚配划定规矩
- {key: app, operator: In, values: [counter -pod]}
template: # 模板，当副本数目不敷时，会按照上面的模板创立pod副本
metadata:
labels:
app: counter-pod
spec:
restartPolicy: Never # 重启战略只能设置为Never大概OnFailure
containers:
- name: counter
image: busybox:1.30
command: ["bin/sh","-c","for i in 9 8 7 6 5 4 3 2 1; do echo $i;sleep 3;done"]

复造代码

闭于重启战略设置的阐明：

假如指定为OnFailure，则job会正在pod呈现毛病时重启容器，而没有是创立pod，failed次数稳定

假如指定为Never,则job会正在pod呈现毛病时创立新的pod，而且毛病pod没有会消逝，也没有会重启，failed次数+1

假如指定为Always的话，便意味着不断重启，意味着job使命会反复来施行了，固然不合错误，以是不克不及设置为Always

创立pc-job.yaml，内乱容以下：

apiVersion: batch/v1
kind: Job
metadata:
name: pc-job
namespace: dev
spec:
manualSelector: true
selector:
matchLabels:
app: counter-pod
template:
metadata:
labels:
app: counter-pod
spec:
restartPolicy: Never
containers:
- name: counter
image: busybox:1.30
command: ["bin/sh","-c","for i in 9 8 7 6 5 4 3 2 1; do echo $i;sleep 3;done"]

复造代码

# 创立job
[root@master ~]# kubectl create -f pc-job.yaml
# 检察job
[root@master ~]# kubectl get job -n dev -o wide -w
NAME COMPLETIONS DURATION AGE CONTAINERS IMAGES SELECTOR
pc-job 0/1 21s 21s counter busybox:1.30 app=counter-pod
pc-job 1/1 31s 79s counter busybox:1.30 app=counter-pod
# 经由过程察看pod形态能够看到，pod正在运转终了使命后，便会酿成Completed形态
[root@master ~]# kubectl get pods -n dev -w
NAME READY STATUS RESTARTS AGE
pc-job-rxg96 1/1 Running 0 29s
pc-job-rxg96 0/1 Completed 0 33s
# 接下去，调解pod运转的总数目战并止数目，即：正在spec下设置上面两个选项
# completions: 6 指定job需求胜利运转Pods的次数为6
# parallelism: 3 指定job并收运转Pods的数目为3
# 然后从头运转job，察看结果，此时会发明，job会每次运转3个pod，统共施行了6个pod
[root@master ~]# kubectl get pods -n dev -w
NAME READY STATUS RESTARTS AGE
pc-job-684ft 1/1 Running 0 5s
pc-job-jhj49 1/1 Running 0 5s
pc-job-pfcvh 1/1 Running 0 5s
pc-job-684ft 0/1 Completed 0 11s
pc-job-v7rhr 0/1 Pending 0 0s
pc-job-v7rhr 0/1 Pending 0 0s
pc-job-v7rhr 0/1 ContainerCreating 0 0s
pc-job-jhj49 0/1 Completed 0 11s
pc-job-fhwf7 0/1 Pending 0 0s
pc-job-fhwf7 0/1 Pending 0 0s
pc-job-pfcvh 0/1 Completed 0 11s
pc-job-5vg2j 0/1 Pending 0 0s
pc-job-fhwf7 0/1 ContainerCreating 0 0s
pc-job-5vg2j 0/1 Pending 0 0s
pc-job-5vg2j 0/1 ContainerCreating 0 0s
pc-job-fhwf7 1/1 Running 0 2s
pc-job-v7rhr 1/1 Running 0 2s
pc-job-5vg2j 1/1 Running 0 3s
pc-job-fhwf7 0/1 Completed 0 12s
pc-job-v7rhr 0/1 Completed 0 12s
pc-job-5vg2j 0/1 Completed 0 12s
# 删除job
[root@master ~]# kubectl delete -f pc-job.yaml
job.batch "pc-job" deleted

复造代码

7. Cronjob

CronJob掌握器以Job掌握器资本为其管控工具，并借助它办理pod资本工具，Job掌握器定义的功课使命正在其掌握器资本创立以后便会立刻施行，但CronJob能够以相同于Linux操纵体系的周期性使命功课谋划的方法掌握其运转世家您面及反复运转的方法。也便是道，CroonJob能够正在特定的工夫面(重复的)来运转job使命。

CronJob的资本浑单文件：

apiVersion: batch/v1beta1 # 版本号
kind: CronJob # 范例
metadata: # 元数据
name: cronJob # rs称号
namespace: dev # 所属定名空间
labels: # 标签
controller: cronjob
spec: # 详情形貌
schedule: # cron格局的功课调理运转工夫面，用于掌握使命正在甚么工夫施行
concurrencyPolicy: # 并收施行战略，用于界说前一次功课运转还没有完成时能否一级怎样运转后一次的功课
failedJobHistoryLimit: # 为失利的使命施行保存的汗青记载数，默许为1
successfulJobHistoryLimit: # 为胜利的使命施行保存的汗青记载数，默许为3
startingDeadlineSeconds: # 启行动业毛病的超不时少
jobTemplate: # job掌握器模板，用于为cronjob掌握器天生job工具；上面实在便是job的界说
metadata:
spec:
completioins: 1
parallelism: 1
activeDeadlineSeonds: 30
backoffLimit: 6
manualSelector: true
selector:
matchLabels:
app: counter-pod
matchExpressions: 划定规矩
- {key: app, operator: In, values: [counter-pod]}
template:
metadata:
labels:
app: counter-pod
spec:
restartPolicy: Never
containers:
- name: counter
image: busybox:1.30
command: ["bin/sh","-c","for i in 9 8 7 6 5 4 3 2 1; do echo $i;sleep 2;done"]

复造代码

需求重面注释的几个选项：
schedule: cron表达式，用于指定使命的施行工夫
*/1 * * * *
<分钟> <小时> <日> <月份> <礼拜>
分钟值从0到59
小时值从0到23
日值从1到31
月值从1到12
礼拜值从0到6，0代表日曜日
多个工夫能够用逗号离隔，范畴能够用连字符给出；*能够做为通配符；/暗示每。。。
concurrencyPolicy:
Allow: 许可Jobs并收运转(默许)
Forbid: 制止并收运转，假如上一次运转还没有完成，则跳过下一次运转
WordStr: 交换，打消当前正正在运转的功课并用新功课交换它

复造代码

创立pc-cronjob.yaml，内乱容以下：

apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: pc-cronjob
namespace: dev
labels:
controller: cronjob
spec:
schedule: "*/1 * * * *"
jobTemplate:
metadata:
spec:
template:
spec:
restartPolicy: Never
containers:
- name: counter
image: busybox:1.30
command: ["bin/sh","-c","for i in 9 8 7 6 5 4 3 2 1; do echo $i;sleep 2;done"]

复造代码

# 创立cronjob
[root@master ~]# kubectl create -f pc-cronjob.yaml
cronjob batch/pc-cronjob created
# 检察cronjob
[root@master ~]# kubectl get cronjobs -n dev
NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE
pc-cronjob */1 * * * * False 0 <none> 6s
# 检察job
[root@master ~]# kubectl get jobs -n dev
NAME COMPLETIONS DURATION AGE
pc-cronjob-1592587800 1/1 28s 3m26s
pc-cronjob-1592587860 1/1 28s 2m26s
pc-cronjob-1592587920 1/1 28s 86s
# 检察pod
[root@master ~]# kubectl get pods -n dev
pc-cronjob-1592587800-x4tsm 0/1 Completed 0 2m24s
pc-cronjob-1592587860-r5gv4 0/1 Completed 0 84s
pc-cronjob-1592587920-9dxxq 1/1 Running 0 24s
# 删除cronjob
[root@master ~]# kubectl delete -f pc-cronjob.yaml
cronjob batch/pc-cronjob deleted

复造代码

免责声明：假如进犯了您的权益，请联络站少，我们会实时删除侵权内乱容，感谢协作！

Kubernetes学习(六)—— Pod控制器

浏览过的版块