Kubernetes
k8s环境设置-pod下载及重启策略
k8s环境设置
在我们开始使用k8s之前，我们可以先做一些环境配置，使k8s更加的方便使用
- 第一个要做的就是kubectl命令的补全
在使用kubectl的时候你会发现参数你是Tab不出来的，这时候我们可以操作一下，让他可以补全
# 在/etc/bashrc里面写入 [root@master ~]# echo "source <(kubectl completion bash)" >> /etc/bashrc # 然后重新登录一下或者bash一下,souce 这个文件也行，习惯用什么你就用什么 [root@master ~]# source /etc/bashrc
现在你去敲kubectl 你就可以发现他的命令是可以补全的了
- 第二个要做的就是安装metrics-server
这个是用来监控k8s的资源使用率的，也能监控pod，你默认去使用kubectl top node他是会报错的
[root@master ~]# kubectl top node error: Metrics API not available
我们可以安装一个工具，让他可以监控到node和pod
# 我们先下载yaml文件，github上可以找到 [root@master ~]# wget https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.6.4/components.yaml
下载好之后我们vim修改这个文件的内容，在第135行的地方我们给他加上一行
134 - args:
135 - --kubelet-insecure-tls # 加上这一行就行
136 - --cert-dir=/tmp
137 - --secure-port=4443
138 - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
139 - --kubelet-use-node-status-port
140 - --metric-resolution=15s
然后在141行修改
141 image: registry.aliyuncs.com/google_containers/metrics-server:v0.6.4 # 改成这样就好了
# 修改好之后apply这个文件 [root@master ~]# kubectl apply -f components.yaml
稍等片刻之后我们执行kubectl top node
[root@master ~]# kubectl top node NAME CPU(cores) CPU% MEMORY(bytes) MEMORY% master 94m 4% 1314Mi 34% node1 44m 2% 701Mi 18% node2 38m 1% 784Mi 20%
k8s操作
我们默认使用kubectl去操作的时候，他都是在default命名空间里面，如果我们想要修改的话，可以这样操作
[root@master ~]# kubectl config set-context --current --namespace kube-system
这样修改完之后，我们后续的操作他就会默认在kube-system下进行操作，比如查询pod
[root@master ~]# kubectl get pod NAME READY STATUS RESTARTS AGE coredns-5bbd96d687-4vmbt 1/1 Running 3 (19m ago) 4h58m coredns-5bbd96d687-9r9bt 1/1 Running 3 (19m ago) 4h58m etcd-master 1/1 Running 3 (19m ago) 4h59m kube-apiserver-master 1/1 Running 3 (17m ago) 4h59m kube-controller-manager-master 1/1 Running 4 (19m ago) 4h59m kube-proxy-mp98s 1/1 Running 1 (39m ago) 4h55m kube-proxy-snk8k 1/1 Running 3 (19m ago) 4h59m kube-proxy-xmxpj 1/1 Running 1 (39m ago) 4h55m kube-scheduler-master 1/1 Running 4 (19m ago) 4h59m metrics-server-7bf8c67888-qjqvw 1/1 Running 0 13m
每个命令空间内的资源都是隔离的，linux也是使用namespace来进行隔离的
我们现在切换回default命令空间
[root@master ~]# kubectl config set-context --current --namespace default Context "kubernetes-admin@kubernetes" modified.
Pod的操作
在k8s里面，k8s调度的最小单位是pod，pod里面跑容器，一般一个pod跑一个容器，如果有特殊需求，也可以跑多个容器
创建pod的2种方式
- 通过命令行创建
- 通过yaml文件创建
通过命令行创建
# kubectl run 这个应该很容易看懂 [root@master ~]# kubectl run pod01 --image=nginx pod/pod01 created # 现在他的状态时正在创建，因为他需要拉取镜像，如果已经存在这个镜像，那么他就会很快变成running [root@master ~]# kubectl get pod NAME READY STATUS RESTARTS AGE pod01 0/1 ContainerCreating 0 5s # 等他一会之后他就会变成running了 [root@master ~]# kubectl get pod NAME READY STATUS RESTARTS AGE pod01 1/1 Running 0 33s
通过命令行去操作pod其实跟docker的命令时差不多的
我们同样也可以使用exec去进入pod
我们可以通过describe命令去查看这个pod产生的日志啊，事件
[root@master ~]# kubectl describe pods pod01 # 这里面会显示很多信息 Normal Scheduled 4m30s default-scheduler Successfully assigned default/pod01 to node2 Normal Pulling 4m29s kubelet Pulling image "nginx" Normal Pulled 4m11s kubelet Successfully pulled image "nginx" in 18.539149997s (18.539154065s including waiting) Normal Created 4m11s kubelet Created container pod01 Normal Started 4m10s kubelet Started container pod01
他这里面会记录从拉取镜像到启动容器的过程
我们刚刚已经启动过一个nginx了，镜像他也拉取到了，那我们现在去创建pod是不是非常的快呢？？？不一定
# 我们再来创建一个pod [root@master ~]# kubectl run pod02 --image=nginx pod/pod02 created [root@master ~]# kubectl get pod NAME READY STATUS RESTARTS AGE pod01 1/1 Running 0 8m56s pod02 0/1 ContainerCreating 0 13s [root@master ~]# kubectl get pod NAME READY STATUS RESTARTS AGE pod01 1/1 Running 0 9m3s pod02 1/1 Running 0 20s
你会发现他过了20秒才running，我们不是已经拉取过镜像了吗，为什么还是这么慢呢
这其实是因为调度的原因
[root@master ~]# kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod01 1/1 Running 0 10m 10.244.104.5 node2 <none> <none> pod02 1/1 Running 0 79s 10.244.166.135 node1 <none> <none>
通过这个命令我们可以看见，pod01是被调度到了node2上面，那么他拉取的镜像也应该是存在node2上面，然而pod02是被调度到了node1上面，他也需要重新拉取镜像，所以会很慢
我们同样可以到node1上面去看看是不是真的存在这样镜像了
# 注意，k8s在1.24之后就剔除了dockershim，所以他的镜像并不是存在docker里 [root@node1 ~]# crictl img |grep nginx docker.io/library/nginx latest d453dd892d935 70.5MB
我们可以看到 node1上确实是有这个镜像的
通过describe也是可以看到他的调度过程的
[root@master ~]# kubectl describe pods pod02 Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 4m58s default-scheduler Successfully assigned default/pod02 to node1 Normal Pulling 4m58s kubelet Pulling image "nginx" Normal Pulled 4m39s kubelet Successfully pulled image "nginx" in 18.445251423s (18.445254681s including waiting) Normal Created 4m39s kubelet Created container pod02 Normal Started 4m39s kubelet Started container pod02
现在2个节点上都有镜像了，我们不妨再来创建一个pod，看看他是不是要快很多
[root@master ~]# kubectl run pod03 --image=nginx pod/pod03 created [root@master ~]# kubectl get pod NAME READY STATUS RESTARTS AGE pod01 1/1 Running 0 15m pod02 1/1 Running 0 6m57s pod03 1/1 Running 0 4s
可以看到pod03只用了4秒就已经running了
4秒就是极限了吗？不，还可以更快，想要更快就需要了解镜像拉取策略了
pod的镜像拉取策略
总共有3种策略，分别是
- Always
这个就是默认的策略，不管你当前的节点上是否存在你指定的那个镜像，他都会有一个联网的动作，如果你的节点上存在这个镜像，那么他会联网检查这个动作，如果不存在则会联网拉取镜像
- Never
这个是从不拉取，只会使用本地镜像
- IfNotPresent
这个策略会检测本地是否存在，存在的话就直接使用了，不存在的话就会联网拉取
那么我们现在创建pod并指定一下策略，看看他是不是会比默认的策略要快
[root@master ~]# kubectl run pod04 --image=nginx --image-pull-policy=IfNotPresent pod/pod04 created [root@master ~]# kubectl get pod NAME READY STATUS RESTARTS AGE pod01 1/1 Running 0 48m pod02 1/1 Running 0 39m pod03 1/1 Running 0 32m pod04 1/1 Running 0 2s
我们可以看到，他只花了2秒就已经启动了这个pod，更快的原因是因为他没有了联网联查的这个动作
这个就是镜像的拉取策略
通过yaml文件创建
通过命令行去创建我们会觉得不太方便，因为我们创建一个pod他就需要敲一次命令，我能不能写个文件，让他按照这个文件去创建pod呢？可以
通过这种方式我们的这个文件是可以复用的
像这种文件里面的参数是很多的，减少记忆负担，我们是可以通过命令让他生成一个模板的，我们只需要改这个模板就好了
# 这个模板就是使用nginx镜像，拉取策略是IfNotPresent --dry-run 是测试运行的意思，然后将内容以yaml的格式进行输出， [root@master ~]# kubectl run pod01 --image=nginx --image-pull-policy=IfNotPresent --dry-run=client -o yaml
# 那么他输出的就是这样的一些信息，我们可以通过重定向将他保存到文件内
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: pod01
name: pod01
spec:
containers:
- image: nginx
imagePullPolicy: IfNotPresent
name: pod01
resources: {}
dnsPolicy: ClusterFirst
restartPolicy: Always
status: {}
我们来完整生成并使用一次这个文件
[root@master ~]# kubectl run pod01 --image=nginx --image-pull-policy=IfNotPresent --dry-run=client -o yaml > pod01.yml [root@master k8s]# kubectl apply -f nginx.yml pod/pod01 created
这样pod01就被创建出来了，我们可以改动这个模板，比如我想要用centos镜像，那么改动image后面的nginx，改成centos就好了，然后执行kubectl apply，那么一个新的pod就会被创建了
如果我现在需要在一个pod里跑2个容器或者多个容器，应该怎么去写yaml文件呢
直接看示例
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: pod01
name: pod01
spec:
containers:
- image: nginx
imagePullPolicy: IfNotPresent
name: pod04
resources: {}
- image: centos
args:
- sleep
- "3600"
imagePullPolicy: IfNotPresent
name: pod05
resources: {}
dnsPolicy: ClusterFirst
restartPolicy: Always
status: {}
我们首先来看一下，他跟之前的区别就是，在spec下的containers里边，多写了一个- image，我们得知道。在yaml语法种，- 代表的是列表，那么现在他的意思就是第一个零七用nginx的镜像，第二个容器使用centos的镜像
但是dnsPolicy和restartPolicy这两个为什么只用写一次呢，因为他们所属的层级不一样，这两个策略看他们的缩进，是和containers属于同一层级，所以只用写一个，并不是一个容器就得给他一个策略，不是这样的
[root@master k8s]# kubectl apply -f nginx.yml pod/pod01 created [root@master k8s]# kubectl get pods NAME READY STATUS RESTARTS AGE pod01 2/2 Running 0 3s # 我们现在一个pod里面有2个容器，那我执行exec进入容器的时候他会进入哪个呢？随机进入吗？我们试试 [root@master k8s]# kubectl exec -it pod01 -- /bin/bash Defaulted container "pod04" out of: pod04, pod05 root@pod01:/# # 我们一个是nginx，另一个是centos，想要检验进入的是哪个的话非常容易，centos容器里面是有yum命令的，执行一下就知道了，如果报错，那么进入的就是nginx root@pod01:/# yum bash: yum: command not found # 看出来了，我们进入的是nginx # 我们退出再进一次，看看他是不是随机进入的 [root@master k8s]# kubectl exec -it pod01 -- /bin/bash Defaulted container "pod04" out of: pod04, pod05 root@pod01:/# yum bash: yum: command not found # 其实我们看提示信息就知道了。它默认进入的是pod04，也就是nginx # 那我我想进入pod05怎么办呢？我们可以加上-c参数 [root@master k8s]# kubectl exec -it pod01 -c pod05 -- /bin/bash [root@pod01 /]# yum version Failed to set locale, defaulting to C.UTF-8 No such command: version. Please use /usr/bin/yum --help It could be a YUM plugin command, try: "yum install 'dnf-command(version)'" # 可以看到我们确实进入了centos，yum命令可以是用了
pod的生命周期及重启策略
容器运行的是进程，而进程是由镜像定义好的
在上面的yaml文件中，我们可以看得到有一个restartPolicy，这个就是重启策略
重启策略总共有3种，分别是
- Always：当容器终止退出后，总是重启容器，默认策略。
- OnFailure：当容器终止异常退出（退出码非0）时，才重启容器。
- Never：当容器终止退出时，不管是正常还是非正常退出，都不重启
Always
我们直接来看一个示例
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: pod01
name: pod01
spec:
containers:
- image: nginx
imagePullPolicy: IfNotPresent
name: pod04
resources: {}
args:
- sleeeeeeep
- "3600"
dnsPolicy: ClusterFirst
restartPolicy: Always
status: {}
这里容器执行的命令我们故意将他写错，来看效果
[root@master k8s]# kubectl apply -f nginx.yml pod/pod01 created [root@master k8s]# kubectl get pods NAME READY STATUS RESTARTS AGE pod01 0/1 Error 1 (2s ago) 2s [root@master k8s]# kubectl get pods NAME READY STATUS RESTARTS AGE pod01 0/1 Error 4 (59s ago) 101s
会发现他一直都在重启，这个就是Always
Never
这个策略我们依旧使用上面那个yaml文件，但是策略我们改成Never，我们来看看效果
[root@master k8s]# kubectl apply -f nginx.yml pod/pod01 created [root@master k8s]# kubectl get pods NAME READY STATUS RESTARTS AGE pod01 0/1 Error 0 3s [root@master k8s]# kubectl get pods NAME READY STATUS RESTARTS AGE pod01 0/1 Error 0 30s
我们可以看见，过了30秒他的restarts依旧是0，说明没有重启过
OnFailure
这个策略我们用到2个yaml文件，一个是上面的那个命令错误的yaml文件，另一个是让他执行命令echo，他执行完之后是正常退出的，我们来看效果
# 这个依旧是使用之前的yaml文件，策略改成OnFailure，其他不变 [root@master k8s]# kubectl apply -f nginx.yml pod/pod01 created [root@master k8s]# kubectl get pods NAME READY STATUS RESTARTS AGE pod01 0/1 Error 1 (3s ago) 4s [root@master k8s]# kubectl get pods NAME READY STATUS RESTARTS AGE pod01 0/1 Error 2 (15s ago) 17s
我们可以看到，他是一直在重启的，符合他的重启策略
现在我们来让他执行一个瞬时任务，echo 他执行完这个命令之后容器的生命周期就结束了，所以是属于正常退出，我们来看看他会不会重启
# 修改yaml文件
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: pod01
name: pod01
spec:
containers:
- image: nginx
imagePullPolicy: IfNotPresent
name: pod04
resources: {}
args:
- echo
- hello
dnsPolicy: ClusterFirst
restartPolicy: OnFailure
status: {}
使用这个yaml文件去创建pod
[root@master k8s]# kubectl apply -f nginx.yml pod/pod01 created [root@master k8s]# kubectl get pods NAME READY STATUS RESTARTS AGE pod01 0/1 Completed 0 3s [root@master k8s]# kubectl get pods NAME READY STATUS RESTARTS AGE pod01 0/1 Completed 0 52s
我们可以看见，容器是正常退出的，状态时完成，不是Error，所以他并没有重启
-
云原生周刊：利用 eBPF 增强 K8s12-23
-
/kubernetes 1.32版本更新解读：新特性和变化一目了然12-20
-
拒绝 Helm？ 如何在 K8s 上部署 KRaft 模式 Kafka 集群？12-19
-
云原生周刊：Kubernetes v1.32 正式发布12-16
-
Kubernetes上运行Minecraft：打造开发者平台的例子12-13
-
深入 Kubernetes 的健康奥秘：探针（Probe）究竟有多强？12-12
-
运维实战：K8s 上的 Doris 高可用集群最佳实践12-10
-
2024年最好用的十大Kubernetes工具12-02
-
OPA守门人：Kubernetes集群策略编写指南12-02
-
云原生周刊：K8s 严重漏洞11-26
-
在Kubernetes (k8s) 中搭建三台 Nginx 服务器怎么实现？-icode9专业技术文章分享11-15
-
基于Kubernetes的自定义AWS云平台搭建指南11-05
-
基于Kubernetes Gateway API的现代流量管理方案11-05
-
在Kubernetes上部署你的第一个应用：Nginx服务器11-05
-
利用拓扑感知路由控制Kubernetes中的流量11-05
