linux12k8s --> 04命令行优化Pod介绍label标签控制器
Posted FikL-09-19
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了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
以上是关于linux12k8s --> 04命令行优化Pod介绍label标签控制器的主要内容,如果未能解决你的问题,请参考以下文章
linux12k8s -->16 kubernetes必备面试题
linux12k8s --> 04资源管理和YAML 文件详解