3、资源管理
3.1 资源类型
- pod
- pod控制器
- service
- 存储
3.2 YAML语言介绍
3.3 资源管理方式
3.3.1 命令式对象管理
(1)用命令对资源进行操作
kubectl
[command] : create、delete、get
[type] :资源类型 pod、service、deployment
[name]
[flags]:额外参数
案例:
#查看所有pod
kubectl get pod
#查看单个pod
kubectl get pod pod的名字
#查看单个pod,结果以yaml的形式展示
kubectl get pod pod的名字 -o yaml
#补充:查看当前kubenet中所有的资源
kubectl api-resources
(2)实验:创建namespace、pod
查看现有的namespace
代码
kubectl get namespace
结果
创建一个新的namespace
代码
kubectl create namespace yzw
kubectl get namespace
结果
查询namespace下的Pod
代码
kubectl get pod -n yzw
结果
在此namespace下创建并运行一个nginx的Pod
代码
kubectl run pod --image=nginx:latest -n yzw
结果
查看刚刚创建的Pod
代码
kubectl get pod -n yzw
结果
删除pod
kubectl delete pod pod名字
删除namespace
kubectl delete namespace namespace名字
3.3.2 命令式对象配置
将多个同一类命令放到同一个yaml文件中,比如上面的创建pod和创建namespace,都属于创建,可以放到一个yaml文件中
(1)先创建yaml文件
nginx_yzw.yaml
#创建一个新的namespace
apiVersion: v1
kind: Namespace
metadata:
name: yzw1
---
#创建一个新的pod
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod1
namespace: yzw1
spec:
containers:
- name: nginx-container
image: nginx:latest
(2)创建命令-批量新增
kubectl create -f nginx_yzw.yaml
(3)查询命令-查询多个
kubectl get -f nginx_yzw.yaml
(4)删除命令-批量删除
kubectl delete -f nginx_yzw.yaml
3.3.3 声明式对象配置(后期补充)
使用apply描述一个资源最终的状态(在yaml中定义状态)
4 实战
4.1 Namespace
4.2 Pod
4.2.1 创建namespace和pod
#创建(绑定namespace)
#要先创建namespace,才能创建pod与之绑定
kubectl run 名字 --image=nginx:latest --port=80 -n namespace名
kubectl run nginx-01 --image=nginx:latest --port=80 -n nginx-space
4.2.2 查看pod
#查看(绑定namespace)
kubectl get pods -n nginx-space
4.2.3 查看pod详情
#查看详情(绑定namespace)
kubectl describe pod pod名 -n namespace名
4.2.4 删除pod
#删除指定Pod
kubectl delete pod pod名 -n namespace名
# 需要注意:
# 由于k8s中pod是由控制器管理的,直接删除的话,控制器立马会新生成一个新的pod代替它,所以删除的时候要先删
# 此时要想删除Pod,必须删除Pod控制器
直接删除pod是删不掉的
直接删不掉
需要采取两步:
(1)删控制器
- 查控制器(带namespace查询):
kubectl get deploy -n nginx-space
- 删除控制器
kubectl delete deploy 控制器名 -n namespace名
- (2)删pod
查看pod(绑定namespace),可以看到pod自动被删掉了
kubectl get pod -n nginx-space
4.3 Label(后续补充)
4.4 Deployment
4.4.1 创建
#新增(带namespace)
kubectl run 控制器名 --image=nginx:latest --port=80 --replicas=3 -n nginx-space
4.4.2 查看控制器
#查(带namespace)
kubectl get deploy -n nginx-space
4.4.3 查看控制器详情
#查看单个详情(带namespace)
kubectl describe deploy 控制器名 -n nginx-space
4.4.4 删除控制器
#删(带namespace)
kubectl delete deploy 控制器名 -n nginx-space
4.4.5 配置文件(后续补充)
4.5 Service
pod虽然会分配由ip,但是这个ip
- 是集群内部才能访问的
- 会随着Pod重建产生变化
4.5.0 前提:
创建了pod和对应的pod控制器
kubectl run nginx --image=nginx:latest --port=80 --replicas=3 -n nginx-space
4.5.1 创建集群内部可访问的Service—ClusterIP
#暴露service
kubectl expose deploy nginx --name svc-nginx-1 --type ClusterIP --port 80 --target-port 80 -n nginx-space
# 查看service
kubectl get svc -n nginx-space
#集群内的机子访问
curl ip:80
4.5.2 创建集群外部可访问的Service—NodePort
#创建
kubectl expose deploy nginx --name=nginx-service-2 --type=NodePort --port=80
--target-port=80 -n nginx-space
#查看,会发现出现了NodePort类型的Service,而且有一对Port(80:30120)
kubectl get svc -n nginx-space
#外网浏览器去访问master的ip:端口号(30120)是随机的,访问成功
4.5.3 删除服务
# kubectl delete svc 服务名 -n 空间名
kubectl delete svc nginx-service-01 -n nginx-space
4.5.4 配置文件(后续补充)
5 Pod详解
5.1 介绍
5.1.1 结构
分为两类:
- 用户容器(运行程序的,一个或者多个)
- 根容器(ip地址给同一个pod中的其他用户容器共享)
5.1.2 定义
kubernetes中,所有资源都包括5个一级属性
kubectl explain deploy
或者kubectl explain pod
FIELDS表示属性:(5个一级属性)
- apiVersion 版本,由kubernetes内部定义,版本号必须可以用 kubectl api-versions 查询到
- kind 类型,由kubernetes内部定义,版本号必须可以用 kubectl api-resources 查询到
- metadata 元数据,主要是资源标识和说明,常用的有name、namespace、labels等
- spec 描述(重点),这是配置中最重要的一部分,里面是对各种资源配置的详细描述
- status 状态信息,里面的内容不需要定义,由kubernetes自动生成
其中spec最重要,其又有几个子属性
- containers:定义容器的详细信息
- nodeName:调度
- nodeSelector <map[]> :根据NodeSelector中定义的信息选择将该Pod调度到包含这些label的Node 上
- hostNetwork:是否使用主机网络模式,默认为false,如果设置为true,表示使用宿主机网络
- volumes :定义Pod上面挂在的存储信息
- restartPolicy: 重启策略,表示Pod在遇到故障的时候的处理策略
5.2 Pod配置( 主要是pod.spec.containers 属性)
查询指令kubectl explain pod.spec.containers
KIND: Pod
VERSION: v1
RESOURCE: containers <[]Object>
DESCRIPTION:
FIELDS:
args <[]string>
command <[]string>
env <[]Object>
envFrom <[]Object>
image <string>
imagePullPolicy <string>
lifecycle <Object>
livenessProbe <Object>
name <string> -required-
ports <[]Object>
readinessProbe <Object>
resources <Object>
securityContext <Object>
startupProbe <Object>
stdin <boolean>
stdinOnce <boolean>
terminationMessagePath <string>
terminationMessagePolicy <string>
tty <boolean>
volumeDevices <[]Object>
volumeMounts <[]Object>
workingDir <string>
5.2.1 基本配置
创建pod-base.yaml文件
apiVersion: 1.0
kind: pod
metadata:
name: pod-base
namespace: nginx-space
labels:
user: yzw
spec:
containers:
- name: nginx
image: nginx:1.17.1
- name: busybox
image: busybox:1.30
在pod中创建两个容器:
- nginx:用1.17.1版本的nginx镜像创建,(nginx是一个轻量级web容器)
- busybox:用1.30版本的busybox镜像创建,(busybox是一个小巧的linux命令集合)
(1)创建podkubectl apply -f pod-base.yaml
#创建命名空间
kubectl create namespace dev
#配置脚本创建
kubectl apply -f pod-base.yml
(2)查看pod
kubectl get pod -n dev
其中pod有两个容器,
READY 1/2 ——表示两个容器中有一个启动成功了
RESTARTS 2——表示另一个容器一直没启动成功,在尝试重启的次数
(3)查看pod详情 kubectl describe pod pod-base -n dev
5.2.2 镜像拉取
3种策略:
- Always:总是从远程仓库拉取镜像(一直远程下载)
- IfNotPresent:本地有则使用本地镜像,本地没有则从远程仓库拉取镜像(本地有就本地,本地没远程下载)
- Never:只使用本地镜像,从不去远程仓库拉取,本地没有就报错 (一直使用本地)
默认值说明:
- 如果镜像tag为具体版本号, 默认策略是:IfNotPresent
- 如果镜像tag为:latest(最终版本) ,默认策略是always
5.2.3 启动命令
前面的pod-base中只有一个容器nginx启动成功了,另一个busybox运行结束的
原来busybox并不是一个程序,而是类似于一个工具类的集合,kubernetes集群启动管理后,它会自动关闭。解决方法就是让其一直在运行,这就用到了command配置
加上command命令,创建pod-command.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-comand
namespace: dev
labels:
user: yzw
spec:
containers:
- name: nginx
image: nginx:1.17.1
- name: busybox
image: busybox:1.30
command: ["/bin/sh","-c","touch /tmp/hello.txt;while true;do /bin/echo
$(date +%T) >> /tmp/hello.txt; sleep 3; done;"]
5.2.4 环境变量
在配置文件里加上env
apiVersion: v1
kind: Pod
metadata:
name: pod-env
namespace: dev
labels:
user: yzw
spec:
containers:
- name: nginx
image: nginx:1.17.1
- name: busybox
image: busybox:1.30
command: ["/bin/sh","-c","touch /tmp/hello.txt;while true;do /bin/echo
$(date +%T) >> /tmp/hello.txt; sleep 3; done;"]
env:
- name: "username"
value: "admin"
- name: "password"
value: "1233456"
进入pod中的容器并查看环境变量
5.2.5 端口设置
apiVersion: v1
kind: Pod
metadata:
name: pod-port
namespace: dev
labels:
user: yzw
spec:
containers:
- name: nginx
image: nginx:1.17.1
ports:
- name: nginx-ports
containerPort: 80
protocol: TCP
5.2.6 资源配额
- limits:用于限制运行时容器的最大占用资源,当容器占用资源超过limits时会被终止,并进行重启
- requests :用于设置容器需要的最小资源,如果环境资源不够,容器将无法启动
apiVersion: v1
kind: Pod
metadata:
name: pod-resources
namespace: dev
labels:
user: yzw
spec:
containers:
- name: nginx
image: nginx:1.17.1
resources: # 资源配额
limits: # 限制资源(上限)
cpu: "2" # CPU限制,单位是core数
memory: "10Gi" # 内存限制
requests: # 请求资源(下限)
cpu: "1" # CPU限制,单位是core数
memory: "10Mi" # 内存限制
补充说明:cpu和memory的单位
- cpu:core数,可以为整数或小数
- memory: 内存大小,可以使用Gi、Mi、G、M等形式
(1)先正常启动pod
(2)停止并删除pod
方式1:根据创建的配置文件来删除kubectl delete -f pod-resources.yaml
方式2:直接删除pod(因为配置文件创建的pod不是用控制器管理的,所以没有控制器需要删除)kubectl delete pod pod-resource -n dev
(3)修改启动所需的内存:由10Mi改为10Gi
修改resources.requests.memory的值为10Gi
(4)再次启动pod,发现pending
(5)查看pod处于pending原因,最下面提示内存不足
kubectl describe pod pod-resource -n dev
5.3 生命周期
- 创建
- 初始化
- 主容器:
前钩子
存活性探测(liveness probe)
就绪性探测(readiness probe
后钩子 - 终止
5.3.1 创建和终止过程
pod的创建过程
- 用户通过kubectl或其他api客户端提交需要创建的pod信息给apiServer
- apiServer开始生成pod对象的信息,并将信息存入etcd,然后返回确认信息至客户端
- apiServer开始反映etcd中的pod对象的变化,其它组件使用watch机制来跟踪检查apiServer上的变动
- scheduler发现有新的pod对象要创建,开始为Pod分配主机并将结果信息更新至apiServer
- node节点上的kubelet发现有pod调度过来,尝试调用docker启动容器,并将结果回送至apiServer
- apiServer将接收到的pod状态信息存入etcd中
pod的终止过程
- 用户向apiServer发送删除pod对象的命令
- apiServcer中的pod对象信息会随着时间的推移而更新,在宽限期内(默认30s),pod被视为dead
- 将pod标记为terminating状态
- kubelet在监控到pod对象转为terminating状态的同时启动pod关闭过程
- 端点控制器监控到pod对象的关闭行为时将其从所有匹配到此端点的service资源的端点列表中移除
- 如果当前pod对象定义了preStop钩子处理器,则在其标记为terminating后即会以同步的方式启动
执行 - pod对象中的容器进程收到停止信号
- 宽限期结束后,若pod中还存在仍在运行的进程,那么pod对象会收到立即终止的信号
- kubelet请求apiServer将此pod资源的宽限期设置为0从而完成删除操作,此时pod对于用户已不可见
5.3.2 初始化容器 (后续补充)
5.3.3 钩子函数
- post start:容器创建之后执行,如果失败了会重启容器
- pre stop :容器终止之前执行,执行完成之后容器将成功终止,在其完成之前会阻塞删除容器的操作
函数中由3种:
- EXEC:容器内执行一次命令
……
ports:
- name: nginx-ports
containerPort: 80
protocol: TCP
lifecycle:
postStart:
exec:
command:
- cat
- /tmp/healthy
- TCPSocket:在当前容器尝试访问指定的socket
lifecycle:
postStart:
tcpSocket:
port: 8080
- HTTPGet:在当前容器中向某url发起http请求
……
lifecycle:
postStart:
httpGet:
path: / #URI地址
port: 80 #端口号
host: 192.168.5.3 #主机地址
scheme: HTTP #支持的协议,http或者https
……
5.3.4 容器探测
- liveness probes:存活性探针,用于检测应用实例当前是否处于正常运行状态,如果不是,k8s会重启容器
- readiness probes:就绪性探针,用于检测应用实例当前是否可以接收请求,如果不能,k8s不会转发流量
也只持三种探测方式:
- Exec命令:在容器内执行一次命令,如果命令执行的退出码为0,则认为程序正常,否则不正常
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
- TCPSocket:将会尝试访问一个用户容器的端口,如果能够建立这条连接,则认为程序正常,否则不正常
livenessProbe:
tcpSocket:
port: 8080
- HTTPGet:调用容器内Web应用的URL,如果返回的状态码在200和399之间,则认为程序正常,否则不正常
livenessProbe:
httpGet:
path: / #URI地址
port: 80 #端口号
host: 127.0.0.1 #主机地址
scheme: HTTP #支持的协议,http或者https
5.3.5 重启策略
- Always (默认值):容器失效时,自动重启该容器
- OnFailure : 容器终止运行且退出码不为0时重启
- Never :不论状态为何,都不重启该容器
(重启操作的延迟时长依次为10s、20s、40s、80s、160s和300s,300s是最大延迟时长。)
5.4 Pod调度
四类调度算法:
- 自动调度:运行在哪个节点上完全由Scheduler经过一系列的算法计算得出
- 定向调度:NodeName、NodeSelector
- 亲和性调度:NodeAffinity、PodAffinity、PodAntiAffinity
- 污点(容忍)调度:Taints、Toleration
5.4.1 定向调度
- nodeName
- nodeSelector
(1)nodeName
直接跳过Scheduler的调度逻辑,直接将Pod调度到指定名称的节点
创建pod-nodename.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-nodename
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
nodeName: node1
实验1:指定存在的node节点 slave1
#创建pod
kubectl apply -f pod-nodename.yaml
#查看pod详情
kubectl get pod pod-nodename -n dev -o wide
注意:如果指定的是不存在node3节点,pod生成后又消失了
实验2:指定不存在的node节点node-yzw(pod会先创建,之后自动删除了)
(1)删除pod-nodename
kubectl delete -f pod-nodename.yaml
(2)修改绑定的节点为node-yzw
(3)创建pod,并查看
kubectl create -f pod-nodename.yaml
再过十几秒再次查看,发现pod-nodename消失了
(2)NodeSelector(与label配合使用)
实验1:打标签,指定存在的标签(pod有效)
- 1、利用label为node节点打上标签
# slave1属于dev,slave2属于dev
kubectl label node slave1 nodeenv=dev
kubectl label node slave2 nodeenv=pro
- 2、创建一个pod-nodeselector.yaml文件
apiVersion: v1
kind: Pod
metadata:
name: pod-nodeselector
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
# nodeName: slave1
nodeSelector:
nodeenv: pro # 指定调度到具有nodeenv=pro标签的节点上
- 3、创建pod及查看
# 创建
kubectl create -f pod-nodeselector.yaml
#查看
kubectl get pod -n dev -o wide
- 4、查看详情,pod有效
kubectl describe pod pod-nodeselector -n dev
实验2:指定不存在的标签label-yzw(pod无效)
- 1、删除上面创建的pod
kubectl delete -f pod-nodeselector.yaml
- 2、创建一个pod-nodeselector.yaml文件
apiVersion: v1
kind: Pod
metadata:
name: pod-nodeselector
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
nodeSelector:
nodeenv: label-yzw# 指定调度到具有nodeenv=label-yzw标签的节点上
- 3、创建pod及查看
# 创建
kubectl create -f pod-nodeselector.yaml
#查看
kubectl get pod -n dev -o wide
- 4、查看详情,pod无效(挂起状态),提示没有节点的标签是labell-yzw
5.4.2 亲和性调度(解决上面出现没有匹配条件的情况下,想办法用到其他节点上)(后续补充)
- nodeAffinity(node亲和性): 以node为目标,解决pod可以调度到哪些node的问题
- podAffinity(pod亲和性) : 以pod为目标,解决pod可以和哪些已存在的pod部署在同一个拓扑域中的问题
- podAntiAffinity(pod反亲和性) : 以pod为目标,解决pod不能和哪些已存在pod部署在同一个拓扑域中的问题
5.4.3 污点和容忍(理解就是拦截与反拦截)
污点(操作节点)
节点设置规则,拦截pod到node上来,甚至将已经在的pod赶出去)
3种污点:
- PreferNoSchedule:尽量不让来(满足条件的)
- NoSchedule:不允许新来,有的不让走(满足条件的)
- NoExecute:不让来,现有的全部赶走(满足条件的)
污点命令:
- 设置污点
kubectl taint nodes node1 key=value:effect
- 去除污点
kubectl taint nodes node1 key:effect-
- 去除所有污点
kubectl taint nodes node1 key-
实验
- (1)准备节点slave1(为了演示效果更加明显,暂时停止slave2节点)
- (2)为slave1节点设置一个污点: tag=heima:PreferNoSchedule ; 然后创建pod1( pod1 可以)
#为节点slavel1设置污点
kubectl taint nodes slave1 tag=heima:PreferNoSchedule
#创建pod1
kubectl run pod1 --image=nginx:1.17.1 -n dev
#查看pod
kubectl get pod -n dev -o wide
结论:pod1在slave1节点上创建成功了
- (3) 修改为slave1节点设置一个污点: tag=heima:NoSchedule; 然后创建pod2( pod1 正常 pod2 失败 )
# 为slave1设置污点(取消PreferNoSchedule,设置NoSchedule)
kubectl taint nodes slave1 tag:PreferNoSchedule-
kubectl taint nodes slave1 tag=heima:NoSchedule
#创建pod2
kubectl run pod2 --image=nginx:1.17.1 -n dev
#查看pod
kubectl get pod -n dev -o wide
结论:pod2创建失败,pod1还在slave1上没有被赶走
- (4)修改为slave1节点设置一个污点: tag=heima:NoExecute ;然后创建pod3 ( 3个pod都失败 )
# 为slave1设置污点(取消NoSchedule,设置NoExecute)
kubectl taint nodes slave1 tag:NoSchedule-
kubectl taint nodes slave1 tag=heima:NoExecute
#创建pod3
kubectl run pod3 --image=nginx:1.17.1 -n dev
#查看pod
kubectl get pod -n dev -o wide
结论:3个pod全都失效了,被从slave1上赶走了
补充:创建的时候master节点就有一个污点
使用kubeadm搭建的集群,默认就会给master节点添加一个污点标记,所以pod就不会调度到master节点上.
- 查看master1节点的详情,可以看到master节点默认的是NoSchedule,就是没有其它节点的时候,pod才会被放到master上
kubectl describe node master1
容忍(在pod上配置)
给pod设置容忍,就可以按照规则放到对应的节点上
实验:
前提:上面的slave1节点设置的是 NoExecute 的污点,此时pod是创建不上去的
步骤:给新建的pod设置容忍,也是NoExecute,然后发现能创建到slave1上
- (1)创建pod-toleration.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-toleration
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
tolerations: #添加容忍
- key: "tag" # 要容忍的污点的key
operator: "Equal" # 操作符
value: "heima" # 容忍的污点的value
effect: "NoExecute" # 添加容忍的规则,这里必须和标记的污点规则相同
- (2)添加容忍之前
- (3)添加容忍之后
先删pod-toleratio:kubectl delete -f pod-toleration.yaml
后创建pod-toleration
结论:成功了,说明容忍生效
6 Pod控制器详解
Pod有两种:
- (1)配置文件直接生成的,删除就会直接删除
- (2)控制器生成的kubectl run生成的,删除还会被重建(除非先删掉控制器,再删Pod)
6.1 控制器类别:
- ReplicationController:比较原始的pod控制器,已经被废弃,由ReplicaSet替代
- ReplicaSet:保证副本数量一直维持在期望值,并支持pod数量扩缩容,镜像版本升级
- Deployment:通过控制ReplicaSet来控制Pod,并支持滚动升级、回退版本
- Horizontal Pod Autoscaler:可以根据集群负载自动水平调整Pod的数量,实现削峰填谷
- DaemonSet:在集群中的指定Node上运行且仅运行一个副本,一般用于守护进程类的任务
- Job:它创建出来的pod只要完成任务就立即退出,不需要重启或重建,用于执行一次性任务
- Cronjob:它创建的Pod负责周期性任务控制,不需要持续后台运行
- StatefulSet:管理有状态应用
6.2 ReplicaSet(RS)——保证一定数量的pod正常运行
6.2.1 作用:
- (1)监听这些Pod的运行状态
- (2)Pod发生故障,就会重启或重建
- (3)pod数量的扩缩容
- (4)镜像版本的升降级
6.2.2 资源清单文件
重点关注spec下面的几个配置选项:
- replicas:指定副本数量,创建出来的pod的数量,默认为1
- selector:选择器,建立pod控制器和pod之间的绑定关系,采用的Label Selector机制在pod模板上定义label,在控制器上定义选择器,就可以表明当前控制器能管理哪些pod了
- template:模板,就是当前控制器创建pod所使用的模板,里面其实就是前一章学过的pod的定义
6.2.3 实战
(1)新建控制器
新建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
#创建ReplicaSet
[root@master1 ~]# kubectl create -f pc-replicaset.yaml
replicaset.apps/pc-replicaset created
# 查看rs
# DESIRED:期望副本数量
# CURRENT:当前副本数量
# READY:已经准备好提供服务的副本数量
kubectl get rs pc-replicaset -n dev -o wide
# 查看当前控制器创建出来的pod
# 这里发现控制器创建出来的pod的名称是在控制器名称后面拼接了-xxxxx随机码
kubectl get pod -n dev
(2)扩缩容pod
方式1: 编辑配置文件
kubectl edit rs pc-replicaset -n dev
扩容成10个
查看效果:
kubectl get pods -n dev -o wide
方式2:scale命令实现扩缩容
变成2
kubectl scale rs pc-replicaset -replicas=2 -n dev
(3)镜像升降级
方式1: 编辑配置文件
编辑rs的容器镜像 - image: nginx:1.17.2
kubectl edit rs pc-replicaset -n dev
查看pc-replicaset,镜像已经更新了,变成了nginx:1.17.2
kubectl get rs pc-replicaset -n dev -o wide
方式2: 命令set image
设置rs的容器镜像 - image: nginx:1.17.1
kubectl set image rs rs名称 容器=镜像版本 -n namespace
查看pc-replicaset,镜像已经更新了,变成了nginx:1.17.1
kubectl get rs pc-replicaset -n dev -o wide
(4)删除控制器
方式1:删除控制器,删除pod(关联删除)
delete命令会删除此ReplicaSet以及它管理的Pod
删除了ReplicaSet
kubectl delete rs pc-replicaset -n dev
关联的pod会自动被关联删除
方式2:删除控制器,不删除pod(取消关联删除)
查看
删除(不关联pod)—加上–cascade=false
kubectl delete rs pc-replicaset -n dev --cascade=false
结果:
控制器被删除了
但是pod还有效,未被关联删除
方式3:yaml直接删除
kubectl delete -f pc-replicaset.yaml
6.3 Deployment(ReplicaSet的上一层)
Deployment管理ReplicaSet,ReplicaSet管理Pod。所以Deployment比ReplicaSet功能更加强大。
6.3.1 功能
- 支持ReplicaSet的所有功能(扩缩容、镜像版本升级)
- 支持发布的停止、继续
- 支持滚动升级和回滚版本
6.3.2 实战
(1)新建控制器
新建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
用yaml文件创建控制器pc-deployment,并查看
(2)扩缩容
方式1:scale命令
副本数变成10
kubectl scale deploy pc-deployment --replicas=10 -n dev
查看deployment
查看pod
方式2:编辑配置文件
编辑配置文件,修改副本数为5
kubectl edit deply pc-deployment -n dev
查看deployment
查看pod
(3) 镜像更新
两种更新策略:
- 重建更新 (Recreate)——创建pod前先kill掉所有的旧pod
- 滚动更新 (RollingUpdate)——滚动更新,就是kill一部分,就创建一部分
方式1:重建更新
(1)编辑pc-deployment,在spec节点下添加更新策略kubectl edit deploy pc-deployment -n dev
spec:
strategy: # 策略
type: Recreate # 重建更新
(2)修改控制器里的镜像版本,进行验证
变更版本为nginx:1.17.2kubectl set image deployment pc-deployment nginx=nginx:1.17.2 -n dev
观察pod,先全部关闭,再全部重建
方式2:滚动更新
(1)编辑pc-deployment,在spec节点下添加更新策略kubectl edit deploy pc-deployment -n dev
spec:
strategy: # 策略
type: RollingUpdate # 滚动更新策略
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
(2)修改控制器里的镜像版本,进行验证
变更版本改回nginx:1.17.1kubectl set image deployment pc-deployment nginx=nginx:1.17.1 -n dev
观察pod,先全部关闭,再全部重建
版本号改回来了:
(4) 版本回退(kubectl rollout)
功能
- 暂停
- 继续
- 回退
命令
- status 显示当前升级状态
- history 显示 升级历史记录
- pause 暂停版本升级过程
- resume 继续已经暂停的版本升级过程
- restart 重启版本升级过程
- undo 回滚到上一级版本(可以使用–to-revision回滚到指定版本)
(5) 金丝雀发布
- 比如有一批新的Pod资源创建完成后立即暂停更新过程,
- 此时,仅存在一部分新版本的应用,主体部分还是旧的版本。
- 然后,再筛选一小部分的用户请求路由到新版本的Pod应用,继续- - 观察能否稳定地按期望的方式运行。
- 确定没问题之后再继续完成余下的Pod资源滚动更新,否则立即回滚更新操作。这就是所谓的金丝雀发布。
# 更新deployment的版本,并配置暂停deployment
kubectl set image deploy pc-deployment nginx=nginx:1.17.4 -n dev && kubectl rollout pause deployment pc-deployment -n dev
#观察更新状态
kubectl rollout status deploy pc-deployment -n dev
# 监控更新的过程,可以看到已经新增了一个资源,但是并未按照预期的状态去删除一个旧的资源,就是因为使用了pause暂停命令
kubectl get rs -n dev -o wide
kubectl get pods -n dev
# 确保更新的pod没问题了,继续更新
kubectl rollout resume deploy pc-deployment -n dev
# 查看最后的更新情况
kubectl get rs -n dev -o wide
kubectl get pods -n dev
(6) 删除(关联的rs和pod也会被删除)
kubectl delete -f pc-deployment.yaml
6.4 Horizontal Pod Autoscaler(HPA)(后续补充)
通过监测Pod的使用情况,实现pod数量的自动调整,于是就产生了Horizontal Pod Autoscaler(HPA)这种控制器
6.5 DaemonSet(DS)——守护控制器
创建了之后,就会在每个node节点上安装一个Pod
前提:重启slave2
实验:
(1)创建pc-daemonset.yaml,创建一个DaemonSet,
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
(2)查看daemonset pod
(3)查看pod,发现在每个Node上都运行一个pod
(4)删除daemonset
kubectl delete -f pc-daemonset.yaml
6.6 Job——一次性任务
6.7 CronJob——定时任务
7 service详解(后续补充)
7.1 介绍——3种模式
7.1.1 userspace模式
7.1.2 iptables模式
7.1.3 ipvs模式
7.2 —4种类型
- ClusterIP:默认值,它是Kubernetes系统自动分配的虚拟IP,只能在集群内部访问
- NodePort:将Service通过指定的Node上的端口暴露给外部,通过此方法,就可以在集群外部访问服务
- LoadBalancer:使用外接负载均衡器完成到服务的负载分发,注意此模式需要外部云环境支持
- ExternalName: 把集群外部的服务引入集群内部,直接使用
7.3 Service使用
7.4 Ingress使用
未完待续