一、标签
1, “标签”,在k8s中极其重要,大多数资源的相互关联就需要使用标签;也就是说,资源的相互关联大多数时候,是使用标签进行关联的;
2,还有其他的作用,比如说,k8s集群中,node节点的一些操作比如污点及污点容忍等,都需要使用到标签;
1,标签管理
· 查看资源的标签
[root@k8s231 pod]# kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
m09 1/1 Running 0 11h <none>
m10 1/1 Running 0 10h <none>
· 创建标签
1,声明式(资源清单创建)
[root@k8s231 pod]# vim 01-pod-nginx.yaml
apiVersion: v1
kind: Pod
metadata:
name: m-nginx
#给资源添加标签
labels:
xinjizhiwa: k8s
learn: kubernetes
spec:
containers:
- name: c-nginx
image: nginx:1.20.1-alpine
创建资源
[root@k8s231 pod]# kubectl apply -f 01-pod-nginx.yaml
pod/m-nginx created
查看标签
[root@k8s231 pod]# kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
m-nginx 1/1 Running 0 42s learn=kubernetes,xinjizhiwa=k8s
2,响应式创建标签
给pod资源添加一个标签
[root@k8s231 pod]# kubectl label pods m09 room=307
pod/m09 labeled
[root@k8s231 pod]# kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
m09 1/1 Running 0 11h room=307
注意:响应式创建标签,如果重新拉取pod(删除pod后再创建pod),标签就会消失;
· 删除标签
[root@k8s231 pod]# kubectl label pods m09 room-
pod/m09 unlabeled
注意:声明式创建的标签(资源清单),删除后,如果重新拉取pod,标签会再次创建;
补充:删除全部pod【--all】
[root@k8s231 pod]# kubectl delete pods --all
pod "m-nginx" deleted
pod "m09" deleted
pod "m10" deleted
· 修改标签
[root@k8s231 pod]# kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
m-nginx 1/1 Running 0 12s learn=kubernetes,xinjizhiwa=k8s
[root@k8s231 pod]# kubectl label pods m-nginx learn=k8s --overwrite
pod/m-nginx unlabeled
[root@k8s231 pod]# kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
m-nginx 1/1 Running 0 59s learn=k8s,xinjizhiwa=k8s
2,通过标签删除pod
通过标签批量管理pod
[root@k8s231 pod]# kubectl delete pods -l learn
pod "m-nginx" deleted
二、pod的镜像拉取策略
Always:对比所有镜像来源,选择时间最新的
Never:只使用本地镜像,本地若没有,也不会去远程仓库拉取
ifNotPresent(默认策略):先看本地,本地有选择本地,本地没有,选择远程仓库
资源清单的编写方式
[root@k8s231 pods]# vim 07-pod-ipp.yaml
apiVersion: v1
kind: Pod
metadata:
name: labels-pod
labels:
school: xinjizhiwa
class: gongzheng
spec:
containers:
- image: nginx:1.20.1-alpine
name: nginx
#设置镜像拉取策略;
imagePullPolicy: ifNotPresent
三、pod中容器的重启策略
当pod中容器退出时,是否需要重新创建容器?
1,Always(默认值):当容器退出时(不论什么原因),自动拉起新的容器;
2,Never:当容器退出时(不论什么原因),都不会重新创建拉起新的容器;
3,OnFailure:当容器“意外退出”时,才会拉起新的容器;
资源清单的编写
[root@k8s231 pods]# vim pod-rp.yaml
apiVersion: v1
kind: Pod
metadata:
name: labels-pod
labels:
school: xinjizhiwa
spec:
#设置容器重启策略
restartPolicy: Always
containers:
- image: nginx:1.20.1-alpine
name: nginx
四、pod的优雅终止(了解即可)
在pod的删除时,系统会自动延迟30s,为了给pod处理未处理完的请求;
[root@k8s231 pod]# cat 01-pod-nginx.yaml
apiVersion: v1
kind: Pod
metadata:
name: m-nginx
labels:
xinjizhiwa: k8s
spec:
#pod优雅终止字段,定义延时kill信号的时间,给pod处理未完成的请求时间;
#缓期多少秒时间执行;若不设置,默认是30s;
terminationGracePeriodSeconds: 3
containers:
- name: c-nginx
image: nginx:1.20.1-alpine
#定义容器的生命周期(容器启动做什么动作,容器停止前做什么动作)
lifecycle:
#容器启动前做什么
postStart:
exec:
command:
- "sh"
- "-c"
- "echo \"postStart at $(date +%F_%T)\" >> /poststart.log "
#容器停止前做什么
preStop:
exec:
command:
- "sh"
- "-c"
- "echo \"prestop at $(date +%F_%T)\" >> /prestop.log"
[root@k8s231 pod]# kubectl exec m-nginx -it -- sh
/ # ls
bin etc mnt root sys
dev home opt run tmp
docker-entrypoint.d lib poststart.log sbin usr
docker-entrypoint.sh media proc srv var
/ # cat poststart.log
postStart at 2024-02-07_05:55:36
五、pod中容器的资源限制
顾名思义,给一个pod设置固定的硬件使用限制,例如cpu、磁盘、内存。
0,kuberneters中Request和Limit限制方式说明
Request: 容器使用的最小资源需求,作为容器调度时资源分配的判断依赖。只有当节点上可分配资源量>=容器资源请求数时才允许将容器调度到该节点。但Request参数不限制容器的最大可使用资源。
Limit: 容器能使用资源的资源的最大值,设置为0表示使用资源无上限。
Request能够保证Pod有足够的资源来运行,而Limit则是防止某个Pod无限制地使用资源,导致其他Pod崩溃。两者之间必须满足关系: 0<=Request<=Limit<=Infinity (如果Limit为0表示不对资源进行限制,这时可以小于Request)
资源需求(Requests)和限制( Limits)
对于每一个资源,container可以指定具体的资源需求(requests)和限制(limits),requests申请范围是0到node节点的最大配置,而limits申请范围是requests到无限,即0 <= requests <=Node Allocatable, requests <= limits <= Infinity。
对于CPU,如果pod中服务使用CPU超过设置的limits,pod不会被kill掉但会被限制。如果没有设置limits,pod可以使用全部空闲的cpu资源。
对于内存,当一个pod使用内存超过了设置的limits,pod中container的进程会被kernel因OOM kill掉。当container因为OOM被kill掉时,系统倾向于在其原所在的机器上重启该container或本机或其他重新创建一个pod。
1,编辑资源清单
[root@k8s231 pod]# vim 11-pod-resources.yaml
apiVersion: v1
kind: Pod
metadata:
name: m11
spec:
containers:
- name: c1
image: nginx:1.20.1-alpine
#设置资源限制
resources:
#最大资源的使用限制;最多就能用这么多的资源;
limits:
#2核心;
cpu: 2000m
#限制内存
memory: 40M
#期望资源限制;需要宿主机预留的资源,我可以不用,但是你必须要有;
requests:
#1核心
cpu: 1000m
#限制内存
memory: 20M
2,创建pod资源
[root@k8s231 pod]# kubectl apply -f 11-pod-resources.yaml
pod/m11 created
[root@k8s231 pod]# kubectl get pods -o wide
3,查看容器的资源大小是否为设置阈值
[root@k8s233 ~]# docker container ps | grep c1
[root@k8s233 ~]# docker stats 1b40c5c3dd1a
六、pod的容器类型
01-基础架构容器【pause】:运行pod中的容器时,提供容器的网络名称空间
02-初始化容器【initContainers】:
完成一些业务容器运行前的操作,如执行命令,如果初始化容器没有创建成功,将一直重启,业务容器也就无法创建出来;
它可以延后业务容器的启动时间;
1,基础架构容器pause
查看基础架构容器
[root@k8s232 ~]# docker container ps | grep pause
2,初始化容器initContainers
· 编辑带有初始化容器的pod资源清单
[root@k8s231 pod]# cat 12-pod-init.yaml
apiVersion: v1
kind: Pod
metadata:
name: m12
spec:
#声明初始化容器
initContainers:
- name: init-c1
image: alpine
#在初始化容器中执行命令
command:
- "sleep"
- "10"
- name: init-c2
image: alpine
command:
- "sleep"
- "5"
#业务容器
containers:
- name: c1
image: alpine
#给容器一个标准输入,也就是守护进程
stdin: true
· 创建pod资源
[root@k8s231 pod]# kubectl apply -f 12-pod-init.yaml
· 查看状态
七、pod中容器的守护进程
1,创建资源清单,拉取alpine最小linux系统
[root@k8s231 pod]# vim 01-pod-nginx.yaml
apiVersion: v1
kind: Pod
metadata:
name: m-alpine
spec:
containers:
- name: c1
image: alpine
2,创建pod资源
[root@k8s231 pod]# kubectl apply -f 01-pod-nginx.yaml
查看pod资源,发现,启动后会结束,因为没有守护进程
3,修改资源清单,加入标准输入stdin
[root@k8s231 pod]# vim 01-pod-nginx.yaml
apiVersion: v1
kind: Pod
metadata:
name: m-alpine
spec:
containers:
- name: c1
image: alpine
stdin: true
4,再次查看就是running了
[root@k8s231 pod]# kubectl get pods
NAME READY STATUS RESTARTS AGE
m-alpine 1/1 Running 0 29s
5,命令方式守护进程
· command
[root@k8s231 pod]# cat 01-pod-nginx.yaml
apiVersion: v1
kind: Pod
metadata:
name: m-alpine
spec:
containers:
- name: c1
image: alpine#在容器当中执行命令
command:
- "tail"
- "-f"
- "/etc/hosts"或者写:
command: ["tail","-f","/etc/hosts"]
[root@k8s231 pod]# kubectl get pods
NAME READY STATUS RESTARTS AGE
m-alpine 1/1 Running 0 50s
· args
[root@k8s231 pod]# cat 01-pod-nginx.yaml
apiVersion: v1
kind: Pod
metadata:
name: m-alpine
spec:
containers:
- name: c1
image: alpine
args:
- "tail"
- "-f"
- "/etc/hosts"
[root@k8s231 pod]# kubectl get pods
NAME READY STATUS RESTARTS AGE
m-alpine 1/1 Running 0 5s
· command与args结合
args可以当做command的参数进行命令执行;
跟docker中的守护进程命令一样;command就类似于ENTRYPOINT;args就类似于CMD;
具体详见docker课程中的Dockerfile的命令讲解;
[root@k8s231 pod]# vim 01-pod-nginx.yaml
apiVersion: v1
kind: Pod
metadata:
name: m-alpine
spec:
containers:
- name: c1
image: alpine
command:
- "tail"
- "-f"
args:
- "/etc/hosts"
[root@k8s231 pod]# kubectl get pods
NAME READY STATUS RESTARTS AGE
m-alpine 1/1 Running 0 4s
八、pod排障之二-日志查询
1,查看pod
[root@k8s231 pod]# cat 01-pod-nginx.yaml
apiVersion: v1
kind: Pod
metadata:
name: m-alpine
spec:
containers:
- name: c1
image: nginx:1.20.1-alpine
[root@k8s231 pod]# kubectl get pods -o wide
2,模拟循环访问pod
while true ;
do
curl 10.100.2.30;
sleep 0.5
done
3,查看pod日志
[root@k8s231 ~]# kubectl logs -f m-alpine
4,面试题
如果pod中容器发生重启,如何查看重启前的容器的log日志信息?
· 模拟容器重启
[root@k8s233 ~]# docker kill bef68d03463f
· 验证是否重新拉起容器![](https://img-blog.csdnimg.cn/direct/667cd9084dd54e55bd3ff4faba9ef54c.png)
· 查看容器重启前,上一个容器的日志信息
-p
[root@k8s231 pod]# kubectl logs -p m-alpine
至此,pod的基础就完毕了;
九、【补充】进入pod容器exec与cp命令
#进入pod中容器
kubectl exec pod名称 -it -- sh
#拷贝容器中数据到宿主机(默认pod中第一个容器)
kubectl cp pod名称:/root/123.txt ./
#拷贝宿主机数据到容器
kubectl cp ./222.log pod名称:/mnt/
#指定容器拷贝
kubectl cp -c 容器名 pod名称:/root/123.txt ./
#pod外部执行命令
[root@k8s231 pod]# kubectl exec m-alpine -it -- ifconfig
eth0 Link encap:Ethernet HWaddr 36:46:92:5A:5C:11
inet addr:10.100.2.32 Bcast:10.100.2.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1450 Metric:1
RX packets:672 errors:0 dropped:0 overruns:0 frame:0
TX packets:478 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:52305 (51.0 KiB) TX bytes:112986 (110.3 KiB)lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)