linux12k8s --＞ 04命令行优化、Pod介绍、label标签、控制器
文章目录
一、优化命令行
yum install -y -completion
source /usr/share/-completion/_completion
source <(kubectl completion )
echo "source <(kubectl completion )" >> ~/.rc
二、kubernetes带来的变革
k8s与docker的关系：
k8s是一个容器化管理平台，docker是容器
1.对于开发人员
由于公司业务多，开发环境、测试环境、预生产环境和生产环境都是隔离的，而且除了生产环境，为了节省成本，其他环境可能是没有日志收集的，在没有用 k8s 的时候，查看线下测试的日志，需要开发或者测试人员，找到对应的机器，在找到对应的容器，然后才能查看日志，在用了 k8s 之后，开发和测试可以直接在 k8s 的dashboard 到对应的 namespace，即可定位到业务的容器，然后可以直接通过控制台查看到对应的日志，大大降低了操作时间。
目前我们使用 jenkins、gitrunner 进行发版或者回滚等，从开发环境到测试环境，到生产环境，完全遵守一次构建，多集群、多环境部署，通过不同的启动参数、不同的环境变量、不同的配置文件实现区分不同的环境。目前已经实现 Python、Java、PHP、NodeJS、Go、.NET Core、Python等多种语言的一键式发版、一键式回滚，大大提高了开发人员的开发效率。
2.对于运维人员
如果你是一名运维人员，可能经常因为一些重复、繁琐的工作感觉厌倦。比如：这个需要一套新的测试环境，那个需要一套新的测试环境，之前可能需要装系统、装依赖环境、开通权限等等。而如今，可以直接用镜像直接部署一套新的测试环境，甚至全程无需自己干预，开发人员通过 jenkins 或者自动化运维平台即可一键式创建，大大降低了运维成本。
一开始，公司业务故障，可能是因为基础环境不一致、依赖不一致、端口冲突等等问题，现在实现 Docker镜像部署，k8s 编排，所有的依赖、基础都是一样的，并且环境的自动化扩容、健康检查、容灾、恢复都是全自动的，大大减少了因为这类基础问题引发的故障。也有可能公司业务是由于服务器宕机、网络等问题，造成服务不可用，此类情况均需要运维人员及时去修复，而如今，可能在你收到告警信息的时候，k8s 已经帮你恢复了。
在没有使用 k8s 时，业务应用的扩容和缩容，都需要人工去处理，从采购服务器、上架、到部署依赖环境，不仅需要大量的人力物力，而且非常容易在中间过程出现问题，又要花费大量的时间去查找问题。成功上架后，还需要在前端反代端添加或该服务器，而如今，可以利用 k8s 的弹性计算，一键式进行扩容和缩容，不仅大大提高了运维效率，而且还节省了不少的服务器资源，提高了资源利用率。
- 对于反代配置方面，比如可能你并不会，或者对 nginx 的配置规则并不熟悉，一些高级的功能你也不会实现，而如今，利用 k8s 的 ingress 即可简单的实现那些复杂的逻辑。并且也不会在遇到 nginx 少加一个斜杠和多加一个斜杠的问题。
- 对于负载均衡方面，之前负载均衡可能是 Nginx、LVS、HAProxy、F5 等，云上可能是云服务商提供的不在均衡机制。每次添加删除节点时，都需要手动去配置前端负载均衡，手动去匹配后端节点，而如今，使用 k8s内部的 service 可以动态发现实现自动管理节点，并且支持自动扩容缩容。之前遇到高峰流量时，经常服务器性能不够，需要临时加服务器面对高峰流量，而如今对于高性能 k8s 集群加上 serverless，基本实现无需管理，自动扩容。
- 对于高可用方面，k8s 天生的高可用功能，彻底释放了双手，无需再去创建各类高可用工具、检测检查脚本。k8s 支持进程接口级别的健康检查，如发现接口超时或者返回值不正确，会自动处理该问题。
- 对于中间件搭建方面，根据定义好的资源文件，可以实现秒级搭建各类中间件高可用集群，并且支持一键式扩缩容，如 Redis、RabbitMQ、Zookeeper 等，并且大大减少了出错的概率。
- 对于应用端口方面，传统行业中，一个服务器可能跑了很多进程，每个进程都有一个端口，需要人为的去配置端口，并且还需要考虑端口冲突的问题，如果有防火墙的话，还需要配置防火墙，在 k8s 中，端口统一管理统一配置，每个应用的端口都可设置成一样的，之后通过 service 进行负载均衡，大大降低了端口管理的复杂度和端口冲突。
3.Pod
1、k8s集群中部署的最小单元。Pod最主要的功能管理是将一个业务或者一个调用链的所有服务（容器）
2、pod是k8s中最小部署单元，用来管理一个调用链的容器，它之中的主容器（pause）为整个调用链的容器提供基础网络，共享存储，监控业务容器的运行状态。
Pod是在集群中运行部署应用或服务的最小单元，他是可以支持很多容器的。Pod的设计理念是支持多个容器在一个Pod中共享网络地址和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。
比如：你运行一个操作系统发行版的软件仓库，一个nginx容器用来发布软件，另一个容器专门用来从源仓库做同步，这两个容器的镜像不太可能是一个团队开发的，但是他们一块工作才能提供一个微服务，这种情况下，不同的团队各自开发构建自己的容器镜像，在部署的时候组合成一个微服务对外提供服务。这就是k8s中的Pod。
# 目前k8s中业务主要可以分为长期伺服型（long-running）、批处理型（batch）、节点后台支撑型（node-daemon）和有状态应用型（stateful application）；分别对应的小机器人控制器为Deployment、Job、DaemonSet 和 StatefulSet。
1>Pod生命周期
2>Pod是如何管理多个容器的
Pod中可以同时运行多个进程（作为容器运行）协同工作。
同一个 Pod 中的容器会自动的分配到同一个 node上。同一个 Pod 中的容器共享资源、网络环境和依赖，所以它们总是被同时调度。在一个 Pod 中同时运行多个容器是一种比较高级的用法。只有当你的容器需要紧密配合协作的时候才考虑用这种模式。
3>Pod中数据持久性
Pod 在设计⽀持就不是作为持久化实体的。在调度失败、节点故障、缺少资源或者节点维护的状态下都会死
掉会被驱逐。通常，我们是需要借助类似于 Docker 存储卷这样的资源来做 Pod 的数据持久
4>Pod的状态
# 1、挂起（Pending）：
API Server 创建了 pod 资源对象已存入 etcd 中，但它尚未被调度完成，或者仍处于从仓库下载镜像的过程中。
# 2、运行中（Running）：
Pod 已经被调度至某节点，并且所有容器都已经被 kubelet 创建完成
# 3、成功（Succeeded）：
Pod 中的所有容器都已经成功终止并且不会被重启。
# 4、失败（Failed）：
Pod 中的所有容器都已终止了，并且至少有一个容器是因为失败终止。即容器以非 0 状态退出或者被系统禁止。
# 5、未知（Unknown）：
Api Server 无法正常获取到 Pod 对象的状态信息，通常是由于无法与所在工作节点的kubelet 通信所致。
# 6、ImgPullErr :
镜像拉取失败
# 7、ContainerCreating ：
容器创建中
5>Pod的资源清单详解
apiVersion：v1 #必选，指定K8s部署的API的版本号
kind:Pod #必选，资源类型Pod
metadata: # 必选，记录部署应用的元数据
name: nginx # 必选，符合 RFC 1035 规范的 Pod 名称
namespace: web-testing # 可选，不指定默认为 default，Pod 所在的命名空间
labels: # 可选，标签选择器，一般用于 Selector
- app: nginx
annotations: # 可选，注释列表
- app: nginx
spec: # 必选，用于部署容器的详细信息
containers: # 必选，容器列表
- name: nginx # 必选，符合 RFC 1035 规范的容器名称
image: nginx:v1 # 必选，容器所用的镜像的地址
imagePullPolicy: Always # 可选，镜像拉取策略
workingDir: /usr/share/nginx/html # 可选，容器的工作目录
volumeMounts: # 可选，存储卷配置
- name: webroot # 存储卷名称
mountPath: /usr/share/nginx/html # 挂载目录
readOnly: true # 只读
ports: # 可选，容器需要暴露的端口号列表
- name: http # 端口名称
containerPort: 80 # 端口号
protocol: TCP # 端口协议，默认 TCP
env: # 可选，环境变量配置
- name: TZ # 变量名
value: Asia/Shanghai
- name: LANG
value: en_US.utf8
resources: # 可选，资源限制和资源请求限制
limits: # 最大限制设置
cpu: 1000m
memory: 1024MiB
requests: # 启动所需的资源
cpu: 100m
memory: 512MiB
readinessProbe: # 可选，容器状态检查
httpGet: # 检测方式
path: / # 检查路径
port: 80 # 监控端口
timeoutSeconds: 2 # 超时时间
initialDelaySeconds: 60 # 初始化时间
livenessProbe: # 可选，监控状态检查
exec: # 检测方式
command:
- cat
- /health
httpGet: # 检测方式
path: /_health
port: 8080
httpHeaders:
- name: end-user
value: jason
tcpSocket: # 检测方式
port: 80
initialDelaySeconds: 60 # 初始化时间
timeoutSeconds: 2 # 超时时间
periodSeconds: 5 # 检测间隔
successThreshold: 2 # 检查成功为 2 次表示就绪
failureThreshold: 1 # 检测失败 1 次表示未就绪
securityContext: # 可选，限制容器不可信的行为
provoleged: false
restartPolicy: Always # 可选，默认为 Always
nodeSelector: # 可选，指定 Node 节点
region: subnet7
imagePullSecrets: # 可选，拉取镜像使用的 secret
- name: default-dockercfg-86258
hostNetwork: false # 可选，是否为主机模式，如是，会占用主机端口
volumes: # 共享存储卷列表
- name: webroot # 名称，与上述对应
emptyDir: {} # 共享卷类型，空
hostPath: # 共享卷类型，本机目录
path: /etc/hosts
secret: # 共享卷类型，secret 模式，一般用于密码
secretName: default-token-tf2jp # 名称
defaultMode: 420 # 权限
configMap: # 一般用于配置文件
name: nginx-conf
defaultMode: 420
================================================================================================
[root@k8s-m-01 ~]# kubectl explain pod.spec #查看参数
string : 跟字符串
Object ：
[]Object :
- name
案例：
# 实例1：部署nginx、tomcat容器
# kubectl explain Pod #查apiVersion版本号 v1
[root@k8s-m-01 ~]# cat pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: test-pod
spec:
containers:
- name: nginx
image: nginx
- name: tomcat
image: tomcat
# 实例2：部署wordpress
# 1、nginx PHP MySQL
# 2、 制作镜像
# 3、创建nginx配置文件，然后构建镜像
# 4、编写配置清单，部署
[root@k8s-m-01 ~]# vim wordpress.yaml
apiVersion: v1
kind: Pod
metadata:
name: wordpress
spec:
containers:
- name: nginx
image: nginx
- name: php
image: alvinos/php:v2-fpm-mysql
- name: mysql
image: mysql:5.7
env:
- name: MYSQL_ROOT_PASSWORD
value: "123"
# k8s部署一个yaml的应用：kubectl apply -f [配置清单]
[root@k8s-m-01 ~]# kubectl apply -f pod.yaml
pod/test-pod create
ImgPullErr : 镜像拉取失败
ContainerCreating ： 容器创建中
6>Pod的重启策略
Pod 重启策略（ RestartPolicy ）应用于 Pod 内的所有容器，井且仅在 Pod 所处的 Node 上由 kubelet 进行判断和重启操作。
当某个容器异常退出或者健康检查失败时， kubelet 将根据 RestartPolicy 设置来进行相应的操作。Pod 的重启策略包括：Always、OnFailure 和 Never，默认值为 Always
# 1. Always： (默认)
当容器失效时，由 kubelet 自动重启该容器。
# 2. OnFailure：
当容器终止运行且退出码不为 0 时，由 kubelet 自动重启该容器
# 3. Never：
不论容器运行状态如何，kubelet 都不会重启该容器。
kubelet 重启失效容器的时间间隔以 sync-frequency 乘以 2n 来计算；例如 1、2、4、8 倍等，最长延时5min ，并且在成功重启后的 10 min 后重置该时间。
Pod 的重启策略与控制方式息息相关，当前可用于管理 Pod 的控制器包括 ReplicationController、Job、DaemonSet 及直接通过 kubelet 管理（静态 Pod）。每种控制器对 Pod 的重启策略要求如下：
# 1．RC 和 DaemonSet：必须设置为 Always，需要保证该容器持续运行。
# 2．Job 和 CronJob：OnFailure 或 Never，确保容器执行完成后不再重启。
# 3．kubelet：在 Pod 失效时自动重启它，不论将 RestartPolicy 设置为什么值，也不会对 Pod 进行健康检查。
三、名词介绍
1.k8s中的名称空间
k8s中名称空间是用来隔离集群资源，而k8s中的资源也分为名称空间级资源以及集群级资源。
mysql 客户端 kubectl
mysqld 服务端 kubernetes
# kubectl是k8s客户端，它跟k8s没有任何关系。
# kubectl get [资源名称] 获取集群资源的命令
# 1、获取名称空间
[root@k8s-m-01 ~]# kubectl get namespaces
NAME STATUS AGE
default Active 8d
kube-node-lease Active 8d
kube-public Active 8d
kube-system Active 8d
[root@k8s-m-01 ~]# kubectl get ns #简写
NAME STATUS AGE
default Active 8d
kube-node-lease Active 8d
kube-public Active 8d
kube-system Active 8d
# 注：部署应用一般是部署在自己的名称空间之内
# 2、k8s中的命名规范
1、必须小写
2、必须以字母开头
3、名称当中只能够包含字母、数字和中划线(-)
[root@k8s-m-01 ~]# kubectl create namespace wordpress # 创建命名空间
namespace/wordpress created
2、namespace
namespace是命名空间，用来做集群资源隔离的（业内默认的标准，一个微服务一个namespace）
k8s集群中：
1、集群级资源：所有命名空间都能够使用
2、命名空间级资源：只能在同一个命名空间内使用
3、Label标签
标签可以称之为资源的标示，一般用于发现资源
一个Label是一个key=value的键值对，其中key与value由用户自己指定。
Label可以附加到各种资源对象上，例如Node、Pod、Service、RC 等，一个资源对象可以定义任意数量的 Label，同一个 Label 也可以被添加到任意数量的资源对象上去，Label 通常在资源对象定义时确定，也可以在对象创建后动态添加或者删除。
- 1、版本标签：“release” : “stable” , “release” : “canary”
- 2、环境标签：“environment” : “dev” , “environment” : “production”
- 3、架构标签：“tier” : “frontend” , “tier” : “backend” , “tier” : “middleware”
- 4、分区标签：“partition” : “customerA” , “partition” : “customerB”
- 5、质量管控标签：“track” : “daily” , “track” : “weekly”
# docker中的TAG = 仓库URL/名称空间/仓库名称:版本号
# k8s当做标签是用来管理（识别一系列）容器，方便与管理和监控拥有同一标签的所有容器 #标签是指pod，但是pod是管理容器的
[root@k8s-m-01 ~]# vim tag.yaml
apiVersion: v1
kind: Pod
metadata:
name: test-tag
labels:
release: stable
spec:
containers:
- name: nginx
image: nginx
# 1、查看label
[root@k8s-m-01 ~]# kubectl get pod --show-labels
NAME READY STATUS RESTARTS AGE LABELS
test-tag 1/1 Running 0 67s release=stable
# 2、增加标签
kubectl label pod（资源类型） test-tag app=tag
[root@k8s-m-01 ~]# kubectl label pod test-tag app=tag
pod/test-tag labeled
[root@k8s-m-01 ~]# kubectl get pod --show-labels
NAME READY STATUS RESTARTS AGE LABELS
test-tag 0/1 ImagePullBackOff 0 2m15s app=tag,release=stable
# 3、删除标签
[root@k8s-m-01 ~]# kubectl label pod test-tag app-
pod/test-tag labeled
# 4、查看标签
[root@k8s-m-01 ~]# kubectl get pod --show-labels
NAME READY STATUS RESTARTS AGE LABELS
test-tag 1/1 Running 0 7m53s release=stable
# 5、修改标签
## 先删除后增加
kubectl label pod test-tag app=tag release-
kubectl label pod test-tag app=tag release=bate
# 6、版本
stable 稳定版本
beta 公测版本
alpha 内测版本
=================================================================================
# 查看资源标签标签
kubectl get deployment --show-labels
# 创建标签
kubectl label [资源类型] [资源名] [key=value]
# 删除标签
kubectl label [资源类型] [资源名] key-
3.k8s中常用命令
# 1.获取资源
kubectl get [资源名称]
[root@k8s-m-01 ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
test 1/1 Running 1 6d
# 2.创建资源
kubectl apply [资源类型] [资源名称]
kubectl apply -f [资源清单的路径]
[root@k8s-m-01 ~]# vim tag.yaml
[root@k8s-m-01 ~]# kubectl apply -f tag.yaml
4.控制器
k8s中控制器分为：deployment、DaemonSet、Statufluset
控制器是用来管理Pod
# 1、Deployment:一般用来部署长期运行的、无状态的应用
特点：集群之中，随机部署
# 2、DaemonSet：每一个节点上部署一个Pod，删除节点自动删除对应的POD（zabbix-agent）
特点：每一台上有且只有一台
# 3、StatudfluSet: 部署有状态应用
特点：有启动顺序
控制器使用来做什么的？
- 管理Pod
# Deploymnet:
在Deployment对象中描述所需的状态，然后Deployment控制器将实际状态以受控的速率更改为所需的状态。
1）deployment（部署长期运行、无状态应用）
# 1、deployment:在deployment对象中描述所需状态，然后deployment控制器将实际状态以受控的速率更改为所需的状态（自愈）
一般用来部署长期运行的，无状态的应用（对启动顺序没有要求的（php nginx））
总结：主要功能是保证有足够的Pod正常对外提供服务
特点：集群之中，随机部署
# 2、创建deployment.yaml
[root@k8s-m-01 ~]# vim deployment.yaml
apiVersion: apps/v1 # kubectl explain deployment查看deployment版本号：apps/v1
kind: Deployment #类型
metadata: #元数据
name: deployment #deployment的名称
spec: #定义容器的详细信息
replicas: 1 #创建Pod的副本数（默认）
selector: #标签选择器：定义Deployment 如何找到要管理的 Pod，与 template 的 label（标签）对应
matchLabels: #精确匹配
release: stable #对应Pod标签
template: #创建Pod的模板---------以下是Pod信息
metadata: #Pod元数据
name: test-tag #Pod名称（可不定义，随机生成）
labels: #标签
release: stable
spec: #定义容器详细信息
containers: #容器列表
- name: nginx
image: nginx
# 3、创建deployment
[root@k8s-m-01 ~]# kubectl apply -f deployment.yaml #创建deployment
deployment.apps/deployment created
[root@k8s-m-01 ~]# kubectl get deployment #查看deployment
NAME READY UP-TO-DATE AVAILABLE AGE
deployment 1/1 1 1 51s
# 4、查看pods
[root@k8s-m-01 ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
deployment-7bf4d6cd75-nxsjg 1/1 Running 0 2m24s
test-tag 1/1 Running 0 41m
# 5、删除deployment
[root@k8s-m-01 ~]# kubectl delete pod deployment-7bf4d6cd75-nxsjg
# 6、重新查看pods
[root@k8s-m-01 ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
deployment-7bf4d6cd75-cm2jn 1/1 Running 0 21s
test-tag 1/1 Running 0 42m
# 7、查看部署详情
[root@k8s-m-01 ~]# kubectl describe deployments.apps
Name: deployment
Namespace: default
CreationTimestamp: Sat, 24 Jul 2021 10:52:32 +0800
Labels: <none>
Annotations: deployment.kubernetes.io/revision: 1
Selector: release=stable
Replicas: 1 desired | 1 updated | 1 total | 1 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
Labels: release=stable
Containers:
nginx:
Image: nginx
Port: <none>
Host Port: <none>
Environment: <none>
Mounts: <none>
Volumes: <none>
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True NewReplicaSetAvailable
OldReplicaSets: <none>
NewReplicaSet: deployment-7bf4d6cd75 (1/1 replicas created)
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ScalingReplicaSet 75s deployment-controller Scaled up replica set deployment-7bf4d6cd75 to 1
1>弹性扩容的3种方法
# 1.修改配置清单
[root@k8s-m-01 ~]# kubectl edit deployments deployment #推荐
# deployments是资源类型 资源名称是deployment
spec:
progressDeadlineSeconds: 600
replicas: 10 # 修改这个参数
revisionHistoryLimit: 10
selector:
matchLabels:
release: stable
[root@k8s-m-01 ~]# kubectl get pods -w #监控pod状态（自动创建10个）
NAME READY STATUS RESTARTS AGE
deployment-7bf4d6cd75-cm2jn 1/1 Running 0 6m59s
test-tag 1/1 Running 0 48m
deployment-7bf4d6cd75-c25tl 0/1 Pending 0 0s
deployment-7bf4d6cd75-c25tl 0/1 Pending 0 0s
deployment-7bf4d6cd75-vvgff 0/1 Pending 0 0s
deployment-7bf4d6cd75-ghlvr 0/1 Pending 0 0s
deployment-7bf4d6cd75-j7zpk 0/1 Pending 0 0s
deployment-7bf4d6cd75-ck57d 0/1 Pending 0 0s
deployment-7bf4d6cd75-tk6sw 0/1 Pending 0 0s
deployment-7bf4d6cd75-8kljt 0/1 Pending 0 0s
deployment-7bf4d6cd75-vvgff 0/1 Pending 0 0s
deployment-7bf4d6cd75-ghlvr 0/1 Pending 0 0s
#2.命令行打标签
[root@k8s-m-01 ~]# kubectl patch deployments.apps deployment -p '{"spec":{"replicas":4}}' #自动缩容到4台-
# deployments.apps 资源全称
deployment.apps/deployment patched
[root@k8s-m-01 ~]# kubectl get pods -w #实时监控
NAME READY STATUS RESTARTS AGE
deployment-7bf4d6cd75-cm2jn 1/1 Running 0 11m
deployment-7bf4d6cd75-j7zpk 1/1 Running 0 4m21s
deployment-7bf4d6cd75-mrlj7 1/1 Running 0 4m21s
deployment-7bf4d6cd75-tk6sw 1/1 Running 0 4m21s
test-tag 1/1 Running 0 53m
[root@k8s-m-01 ~]# kubectl patch deployments.apps deployment -p '{"spec":{"replicas":40}}' #自动扩容到40台
deployment.apps/deployment patched
# 3.scale
[root@k8s-m-01 ~]# kubectl scale deployment/deployment --replicas=2
# 资源类型/资源名称
deployment.apps/deployment scaled
[root@k8s-m-01 ~]# kubectl get pods #查看pods
NAME READY STATUS RESTARTS AGE
deployment-7bf4d6cd75-cm2jn 1/1 Running 0 14m
deployment-7bf4d6cd75-j7zpk 1/1 Running 0 7m36s
test-tag 1/1 Running 0 56m
2>更新(首先要存在低版本才可以更新)
# 1.编辑django.yaml（基础版本）
[root@k8s-m-01 ~]# vi djiaogo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: django
spec:
replicas: 1
selector:
matchLabels:
app: stable
template:
metadata:
labels:
app: stable
spec:
containers:
- name: nginx1
image: nginx:1.17.10
#2.创建Pod
[root@k8s-m-01 ~]# kubectl apply -f django.yaml
deployment.apps/django created
# 1—监控中 （获取podid）
[root@k8s-m-01 ~]# kubectl get pods -w
NAME READY STATUS RESTARTS AGE
deployment-7bf4d6cd75-cm2jn 1/1 Running 0 18m
test-tag 1/1 Running 0 60m
django-54bb9d4cd6-m6pgm 0/1 Pending 0 0s
django-54bb9d4cd6-m6pgm 0/1 Pending 0 0s
django-54bb9d4cd6-m6pgm 0/1 ContainerCreating 0 0s
# 2-进入容器查看版本号
[root@k8s-m-01 ~]# kubectl exec -it django-54bb9d4cd6-m6pgm --
root@django-54bb9d4cd6-m6pgm:/# nginx -v
nginx version: nginx/1.17.10
# 3.更新镜像
方式一：打标签
## 打标签
[root@k8s-m-01 ~]# kubectl patch deployments.apps django -p '{"spec":{"template":{"spec":{"containers":[{"image":"nginx:1.18.0", "name":"nginx"}]}}}}'
deployment.apps/django patched
# 验证
[root@k8s-m-01 ~]# kubectl exec -it django-6c5b55f69f-qnb6d --
Defaulted container "nginx" out of: nginx, nginx1
root@django-6c5b55f69f-qnb6d:/# nginx -v
nginx version: nginx/1.18.0
方式二：修改配置清单
# 修改配置清单
[root@k8s-m-01 ~]# vim django.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: django
spec:
replicas: 1
selector:
matchLabels:
app: stable
template:
metadata:
labels:
app: stable
spec:
containers:
- name: nginx
image: nginx:1.19.9
##验证
[root@k8s-m-01 ~]# kubectl exec -it deployment-5849786498-6zpws --
root@deployment-5849786498-6zpws:/# nginx -v
nginx version: nginx/1.19.9
方式三：
##设置镜像（重点）
[root@k8s-m-01 ~]# kubectl set image deployment/django nginx=nginx:1.16.0
##验证
[root@k8s-m-01 ~]# kubectl exec -it django-65b6bd487f-qtrv9 --
Defaulted container "nginx" out of: nginx, nginx1
root@django-65b6bd487f-qtrv9:/# nginx -v
nginx version: nginx/1.16.0
方式四：
## edit
[root@k8s-m-01 ~]# kubectl edit deployment.apps django
template:
metadata:
creationTimestamp: null
labels:
app: stable
spec:
containers:
- image: nginx:1.19.0 #修改版本号
imagePullPolicy: IfNotPresent
name: nginx
resources: {}
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
##验证
[root@k8s-m-01 ~]# kubectl exec -it django-65c9b58dfb-zwg6z --
Defaulted container "nginx" out of: nginx, nginx1
root@django-65c9b58dfb-zwg6z:/# nginx -v
nginx version: nginx/1.19.0
3>回滚
# 1、查看资源历史
[root@k8s-m-01 ~]# kubectl rollout history deployment django
deployment.apps/django
REVISION CHANGE-CAUSE
1 <none>
2 <none>
3 <none>
4 <none>
5 <none>
6 <none>
7 <none>
# 2、回滚到上一级
[root@k8s-m-01 ~]# kubectl rollout undo deployment django
deployment.apps/django
REVISION CHANGE-CAUSE
1 <none>
2 <none>
3 <none>
4 <none>
5 <none>
8 <none>
9 <none>
注：目前是到第7级，回滚是回滚到6，回滚后7不显示，显示成6，6与7内容一样
# 3、回滚指定版本
[root@k8s-m-01 ~]# kubectl rollout undo deployment django --to-revision=1
deployment.apps/django rolled back
[root@k8s-m-01 ~]# kubectl rollout history deployment django
deployment.apps/django
REVISION CHANGE-CAUSE
2 <none>
3 <none>
4 <none>
5 <none>
8 <none>
9 <none>
10 <none>
注：回滚到1版本，1不展示，变成10
2）DaemonSet（一般用来监控、收集日志）
在集群中所有的节点上部署只部署一个Pod
# 在集群中所有的节点上部署只部署一个Pod,删除节点自动删除对应得Pod
# 特点：每台上有且只有一个
[root@k8s-m-01 ~]# vim zabbix-agent.yaml
apiVersion: apps/v1 #kubectl explain DaemonSet 查看版本号
kind: DaemonSet
metadata:
name: zabbix-agent
spec:
selector:
matchLabels:
app: zabbix-agent
template:
metadata:
labels:
app: zabbix-agent
spec:
containers:
- name: zabbix-agent
image: zabbix/zabbix-agent:5.2.6-centos
[root@k8s-m-01 ~]# kubectl apply -f zabbix-agent.yaml
# 更新
1、修改配置文件
[root@k8s-m-01 ~]# kubectl edit daemonsets.apps zabbix-agent
spec:
containers:
- image: zabbix/zabbix-agent:centos-5.2.5 #修改版本
daemonset.apps/zabbix-agent edited
2、打标签的方式
[root@k8s-m-01 ~]# kubectl patch daemonsets.apps zabbix-agent -p '{"spec":{"template":{"spec":{"containers":[{"image":"zabbix/zabbix-agent:centos-5.2.4", "name":"zabbix-agent"}]}}}}'
daemonset.apps/zabbix-agent patched
3、设置镜像
[root@k8s-m-01 ~]# kubectl set image daemonset/zabbix-agent zabbix-agent=zabbix/zabbix-agent:centos-5.2.3
daemonset.apps/zabbix-agent image updated
4、查看记录
[root@k8s-m-01 ~]# kubectl rollout history daemonset zabbix-agent
daemonset.apps/zabbix-agent
REVISION CHANGE-CAUSE
1 <none>
2 <none>
3 <none>
4 <none>
## 回滚到上一个版本
[root@k8s-m-01 ~]# kubectl rollout history daemonset zabbix-agent
daemonset.apps/zabbix-agent
REVISION CHANGE-CAUSE
1 <none>
2 <none>
4 <none>
5 <none>
## 回滚到指定版本
[root@k8s-m-01 ~]# kubectl rollout undo daemonset zabbix-agent --to-revision=1
daemonset.apps/zabbix-agent rolled back
3）扩展
# 1、k8s-m-01节点执行
[root@k8s-m-01 ~]# kubectl get nodes # master监控
NAME STATUS ROLES AGE VERSION
k8s-m-01 Ready control-plane,master 8d v1.21.2
k8s-n-01 Ready <none> 8d v1.21.2
k8s-n-02 Ready <none> 11s v1.21.2
[root@k8s-m-01 ~]# kubectl delete nodes k8s-n-02 #删除k8s-n-02节点
node "k8s-n-02" deleted
[root@k8s-m-01 ~]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8s-m-01 Ready control-plane,master 8d v1.21.2
k8s-n-01 Ready <none> 8d v1.21.2
# 2、k8s-n-2节点执行
[root@k8s-n-02 ~]# kubeadm reset
[root@k8s-n-02 ~]# rm -rf /etc/kubernetes/
# 3、k8s-m-01节点生成token
[root@k8s-m-01 ~]# kubeadm token create --print-join-command
kubeadm join 192.168.15.111:6443 --token uqvjwm.lr9e35a0brzl1r9f --discovery-token-ca-cert-hash sha256:e9a22201e9fb0575a7281b42c53377c119880e0aca5217a7134fe474e5cd7422
# 4、k8s-n-02节点重新加入集群
[root@k8s-n-02 ~]# kubeadm join 192.168.15.111:6443 --token uqvjwm.lr9e35a0brzl1r9f --discovery-token-ca-cert-hash sha256:e9a22201e9fb0575a7281b42c53377c119880e0aca5217a7134fe474e5cd7422
# 5、重新查看master节点监控
[root@k8s-m-01 ~]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8s-m-01 Ready control-plane,master 8d v1.21.2
k8s-n-01 Ready <none> 8d v1.21.2
k8s-n-02 Ready <none> 11s v1.21.2
