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）创建pod
kubectl 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.2
kubectl 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.1
kubectl 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： 把集群外部的服务引入集群内部，直接使用
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
