k8s中pod的管理和优化

资源管理介绍

在kubernetes中，所有的内容都抽象为资源，用户需要通过操作资源来管理kubernetes。

kubernetes的本质上就是一个集群系统，用户可以在集群中部署各种服务

所谓的部署服务，其实就是在kubernetes集群中运行一个个的容器，并将指定的程序跑在容器中。

kubernetes的最小管理单元是pod而不是容器，只能将容器放在Pod中，

kubernetes一般也不会直接管理Pod，而是通过Pod控制器来管理Pod的。

Pod中服务服务的访问是由kubernetes提供的Service资源来实现。

Pod中程序的数据需要持久化是由kubernetes提供的各种存储系统来实现

常见的命令操作

建立一个webcluster控制器，控制器中pod的数量为3

[root@k8s-master ~]# kubectl create deployment web --image nginx/nginx --replicas 3

查看控制器

[root@k8s-master ~]# kubectl get deployments.apps

NAME READY UP-TO-DATE AVAILABLE AGE

web 3/3 3 3 5s

运行pod

[root@k8s-master ~]# kubectl run testpod --image nginx
pod/testpod created

查看pod

[root@k8s-master ~]# kubectl get pods
NAME      READY   STATUS    RESTARTS   AGE
testpod   1/1     Running   0          5s

端口暴露

查看日志，并指定pod的名称

删除微服务

[root@k8s-master ~]# kubectl delete service web

运行交互的pod

root@k8s-master ~]# kubectl run -it test --image busybox/busybox

If you don't see a command prompt, try pressing enter.

/ #

/ #

重新进入

[root@k8s-master ~]# kubectl attach pods/test -it

将文件复制到pod

[root@k8s-master ~]# mkdir mqw

[root@k8s-master ~]# kubectl cp mqw web:/

将pod文件复制到本机中

[root@k8s-master mnt]# kubectl cp web:/home home
 

高级命令演示

生成yaml模板文件

[root@k8s-master ~]# kubectl create deployment --image nginx/nginx web --dry-run=client -o yaml > web.yml

利用yaml文件生成资源

vim webcluster.yml

使用该文件

[root@k8s-master ~]# kubectl apply -f web.yml

查看

[root@k8s-master ~]# kubectl get deployments.apps

 回收资源

[root@k8s-master ~]# kubectl delete -f web.yml

命令修改

[root@k8s-master ~]# kubectl set image deployments/test myapp=myapp:v2

命令修改

[root@k8s-master ~]# kubectl rollout undo deployment test --to-revision 1
 

获取yaml模板

[root@k8s-master ~]# cd mqw/
[root@k8s-master mqw]# ls
[root@k8s-master mqw]# kubectl run test --image myapp:v1 --dry-run=client -o yaml > pod.yml

查看文件

[root@k8s-master mqw]# vim pod.yml

运行

资源回收

[root@k8s-master mqw]# kubectl delete -f pod.yml 

在一个pod中开启多个容器时一定要确保容器彼此不能互相干扰

[root@k8s-master mqw]# vim pod1.yml 
  
apiVersion: v1
kind: Pod 
metadata:
  labels:
    run: timing
  name: timinglee
spec:
  containers:
    - image: nginx/nginx:latest
      name: web1
 
    - image: busybox/busybox:latest
      name: busybox
      command: ["/bin/sh","-c","sleep 1000000"]
~                  

                              

在一个pod中的容器共用一个网络

[root@k8s-master mqw]# vim pod2.yml 

端口映射

[root@k8s-master mqw]# vim pod3.yml 

设定环境变量

[root@k8s-master mqw]# vim pod4.yml

资源限制

[root@k8s-master mqw]# vim pod5.yml

容器启动管理

[root@k8s-master mqw]# vim pod6.yml

选择节点管理

[root@k8s-master mqw]# vim pod7.yml
 

apiVersion: v1
kind: Pod
metadata:
  labels:
    run: timinglee
  name: test
spec:
  nodeSelector:
    kubernetes.io/hostname: k8s-2  #选择在节点2上运行
  restartPolicy: Always
  containers:
    - image: myapp:v1
      name: myapp
~                         

共享主机网络

[root@k8s-master mqw]# vim pod8.yml
 
 apiVersion: v1
kind: Pod
metadata:
  labels:
    run: timinglee
  name: test
spec:
  hostNetwork: true      #打开
  restartPolicy: Always
  containers:
    - image: busybox/busybox:latest
      name: busybox
      command: ["/bin/sh","-c","sleep 100000"]
~                              

测试

 [root@k8s-master mqw]# kubectl apply -f pod8.yml 
 [root@k8s-master mqw]#  kubectl exec -it pods/test -c busybox -- /bin/s     

pod的生命周期和INIT容器的功能

NIT容器的功能

Init容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。
Init容器可以安全地运行这些工具，避免这些工具导致应用镜像的安全性降低。
应用镜像的创建者和部署者可以各自独立工作，而没有必要联合构建一个单独的应用镜像。
Init 容器能以不同于Pod内应用容器的文件系统视图运行。因此，Init容器可具有访问 Secrets 的权限，而应用容器不能够访问。
由于 Init 容器必须在应用容器启动之前运行完成，因此 Init 容器提供了一种机制来阻塞或延迟应用容器的启动，直到满足了一组先决条件。一旦前置条件满足，Pod内的所有的应用容器会并行启动。

 [root@k8s-master mqw]# vim pod9.yml

 探针

探针是由kubelet对容器执行的定期诊断

ExecAction：在容器内执行指定命令。如果命令退出时返回码为0则认为诊断成功
TCPSocketAction：对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开，则诊断被认为是成功的。
HTTPGetAction：对指定的端口和路径上的容器的 IP 地址执行 HTTP Get 请求。如果响应的状态码大于等于200 且小于 400，则诊断被认为是成功的。

每次探测都将获得以下三种结果之一

• 成功：容器通过了诊断，
• 失败：容器未通过诊断。
• 未知：一断失败， 因此不会采取任何行动

Kubelet 可以选择是否执行在容器上运行的三种探针执行和做出反应

livenessProbe：指示容器是否正在运行，如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其 重启策略 的影响。如果容器不提供存活探针，则默认状态为 Success,
readinessProbe：指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与 Pod 匹配的所有 Service 的端点中删除该 Pod 的IP 地址。初始延迟之前的就绪状态默认为 Failure。如果容器不提供就绪探针，则默认状态为 Success.
startupProbe:指示容器中的应用是否已经启动。如果提供了启动探测(startup probe)，则禁用所有其他探测，直到它成功为止。如果启动探测失败，kubelet 将杀死容器，容器服从其重启策略进行重启。如果容器没有提供启动探测，则默认状态为成功Success
 

ReadinessProbe 与 LivenessProbe 的区别

ReadinessProbe当检测失败后，将Pod的IP:Port从对应的EndPoint列表中删除。

如果三个探针同时存在，先执行 StartupProbe 探针，其他两个探针将会被暂时禁用，直到 pod 满足 StartupProbe 探针配置的条件，其他2个探针启动，如果不满足按照规则重启容器。

另外两种探针在容器启动后，会按照配置，直到容器消亡才停止探测，而 StartupProbe 探针只是在容器启动后按照配置满足一次后，不在进行后续的探测。

root@k8s-master pod]# ls
lee.yml  timinglee.yml
[root@k8s-master pod]# vim timinglee.yml

[root@k8s-master pod]# kubectl apply -f timinglee.yml
pod/timinglee created
[root@k8s-master pod]# kubectl get pods
NAME                        READY   STATUS    RESTARTS     AGE
timinglee                   1/1     Running   2 (2s ago)   12s
timinglee-c56f584cf-6jxb7   1/1     Running   0            13h
timinglee-c56f584cf-mwrx8   1/1     Running   0            13h

[root@k8s-master pod]# kubectl get pods
NAME                        READY   STATUS             RESTARTS     AGE
timinglee                   0/1     CrashLoopBackOff   4 (3s ago)   44s
timinglee-c56f584cf-6jxb7   1/1     Running            0            13h
timinglee-c56f584cf-mwrx8   1/1     Running            0            13h

就绪探针

[root@k8s-master mqw]# vim pod11.yml

端口启动微服务

[root@k8s-master mqw]# kubectl expose pod readiness --port 80 --target-port 80

添加

[root@k8s-master mqw]# kubectl exec pods/readiness -c myapp -- /bin/sh -c "echo test > /usr/share/nginx/html/test.html"