K8s中pod的管理和优化

一、k8s中的资源

1.1 资源管理介绍

• 在kubernetes中，所有的内容都抽象 资源，用户需要通过操作资源来管理kubernetes。
• kubernetes的本质上就是一个集群系统，用户可以在集群中部署各种服务
• 所谓的部署服务，其实就是在kubernetes集群中运行一个个的容器，并将指定的程序跑在容器中。
• kubernetes的最小管理单元是pod而不是容器，只能将容器放在 Pod中，
• kubernetes一般也不会直接管理Pod，而是通过 Pod控制器 来管理Pod的。
• Pod中服务服务的访问是由kubernetes提供的Service 资源来实现。
• Pod中程序的数据需要持久化是由kubernetes提供的各种 存储 系统来实现

 

1.2 资源管理方式

• 命令式对象管理：直接使用命令去操作kubernetes资源

kubectl run nginx-pod --image=nginx:latest --port=80

•  命令式对象配置：通过命令配置和配置文件去操作kubernetes资源

kubectl create/patch -f nginx-pod. yaml

• 声明式对象配置：通过apply命令和配置文件去操作kubernetes资源

kubectl apply -f nginx-pod. yaml

  

1.2.1 命令式对象管理

# 查看所有pod

kubectl get pod

＃查看某个pod
kubectl get pod pod_name

# 查看某个pod，以yam1格式展示结果
kubectl get pod pod_name -o yaml

1.2.2 资源类型

常用资源类型

k8s常见命令操作

 1.2.3 基本命令示例

# 显示集群版本

kubectl version

# 显示集群信息

kubectl cluster-info

# 创建一个webcluster控制器，控制器中pod数量为2

# 查看资源帮助

kubectl explain deployment

# 查看控制器参数帮助

kubectl explain deployment.spec

# 编辑控制器配置(利用补丁更改控制器配置)

kubectl patch deployments.apps webcluster -p '{"spec": {"replicas":4}}'

# 删除资源

kubectl delete deployments.apps webcluster

1.3 运行和调试命令

# 运行pod

kubectl run testpod --image nginx/nginx:latest

# 端口暴露

kubectl expose pod  testpod  --port 80 --target-port 80       

 # 查看资源详细信息

kubectl describe pods testpod

# 查看资源日志 

kubectl logs pods/testpod

# 运行交互pod

ctrl+pq退出不停止pod

kubectl run -it testpod --image busybox

 进入到已经运行的容器，且容器有交互环境

kubectl attach pods/testpod -it

# 在已经运行的pod中运行指定命令

kubectl exec -it pods/testpod1 /bin/bash

# 拷贝文件到pod中

kubectl cp testpod1.yml testpod1:/
kubectl exec -it pods/testpod1 /bin/bash

# 复制pod中的文件到本机

kubectl cp testpod1:/testpod1.yml testpod1.yml

# 运行非交互pod 

kubectl run nginx --image nginx/nginx:latest

二、什么是pod 

2.1 什么是pod?

• Pod是可以创建和管理Kubernetes计算的最小可部署单元
• 一个Pod代表着集群中运行的一个进程，每个pod都有一个唯一的ip。
• 一个pod类似一个豌豆英，包含一个或多个容器（通常是docker）
• 多个容器间共享IPC、Network和UTC namespace。

2.2 创建自主式pod(生产不推荐)

优点：
灵活性高：

• 可以精确控制 Pod 的各种配置参数，包括容器的镜像、资源限制、环境变量、命令和参数等，满足特定的应用需求。

学习和调试方便：

•  对于学习 Kubernetes 的原理和机制非常有帮助，通过手动创建 Pod 可以深入了解 Pod 的结构和配置方式。在调试问题时，可以更直接地观察和调整Pod的设置。

适用于特殊场景：

• 在一些特殊情况下，如进行一次性任务、快速验证概念或在资源受限的环境中进行特定配置时，手动创建 Pod 可能是一种有效的方式

缺点：
管理复杂：

• 如果需要管理大量的 Pod，手动创建和维护会变得非常繁琐和耗时。难以实现自动化的扩缩容、故障恢复等操作。

缺乏高级功能：

• 无法自动享受 Kubernetes 提供的高级功能，如自动部署、滚动更新、服务发现等。这可能导致应用的部署和管理效率低下。

可维护性差：

• 手动创建的 Pod 在更新应用版本或修改配置时需要手动干预，容易出现错误，并且难以保证一致性。相比之下，通过声明式配置或使用 Kubernetes 的部署工具可以更方便地进行应用的维护和更新。 

# 建立一个名为timinglee的pod 

kubectl run timinglee --image nginx/nginx:latest

# [root@k8s-master ~]# kubectl get pods

#显示pod的较为详细的信息
[root@k8s-master ~]# kubectl get pods -o wide

2.3 利用控制器管理pod (推荐) 

高可用性和可靠性：

•  自动故障恢复：如果一个Pod 失败或被删除，控制器会自动创建新的 Pod 来维持期望的副本数量。确保应用始终处于可用状态，减少因单个Pod故障导致的服务中断。
• 健康检查和自愈；可以配置控制器对 Pod 进行健康检查(如存活探针和就绪探针)。如果 Pod 不健康，控制器会采取适当的行动，如重启Pod 或删除并重新创建它，以保证应用的正常运行。

可扩展性：

• 轻松扩缩容：可以通过简单的命令或配置更改来增加或减少 Pod 的数量，以满足不同的工作负载需求。例如，在高流量期间可以快速扩展以处理更多请求，在低流量期间可以缩容以节省资源。
• 水平自动扩缩容(HPA)：可以基于自定义指标(如CPU利用率、内存使用情况或应用特定的指标)自动调整Pod的数量，实现动态的资源分配和成本优化，

版本管理和更新：

• 滚动更新：对于 Deployment 等控制器，可以执行滚动更新来逐步替换旧版本的 Pod 为新版本确保应用在更新过程中始终保持可用。可以控制更新的速率和策略，以减少对用户的影响。
• 回滚：如果更新出现问题，可以轻松回滚到上一个稳定版本，保证应用的稳定性和可靠性

声明式配置：

• 简洁的配置方式：使用YAML 或JSON格式的声明式配置文件来定义应用的部署需求。这种方式使得配置易于理解、维护和版本控制，同时也方便团队协作。
• 期望状态管理；只需要定义应用的期望状态(如副本数量、容器镜像等)，控制器会自动调整实际状态与期望状态保持一致。无需手动管理每个Pod的创建和删除，提高了管理效率。

服务发现和负载均衡：

• 自动注册和发现：Kubernetes中的服务(Service)可以自动发现由控制器管理的Pod，并将流量路由到它们。这使得应用的服务发现和负载均衡变得简单和可靠，无需手动配置负载均衡器
• 流量分发：可以根据不同的策略(如轮询、随机等)将请求分发到不同的Pod，提高应用的性能和可用性。

多环境一致性：

• 一致的部署方式：在不同的环境(如开发、测试、生产)中，可以使用相同的控制器和配置来部署应用，确保应用在不同环境中的行为一致。这有助于减少部署差异和错误，提高开发和运维效率。

 # 建立控制器并自动运行pod

kubectl create deployment timinglee --image nginx/nginx:latest

# 为timinglee扩容

kubectl scale deployment timinglee --replicas 6

# 为timinglee缩容

kubectl scale deployment timinglee --replicas 2

2.4 应用版本的更新

# 利用控制器建立pod

kubectl create deployment timinglee --image myapp: v1 --replicas 2

# 暴漏端口

kubectl expose deployment timinglee --port 80 --target-port 80

# 查看历史版本

kubectl rollout history deployment timinglee

# 更新控制器镜像版本

kubectl set image deployments/timinglee myapp=myapp:v2

# 版本回滚

kubectl rollout undo deployment timinglee --to-revision 1

2.5 利用yaml文件部署应用 

用yaml文件部署应用有以下优点
声明式配置：

• 清晰表达期望状态：以声明式的方式描述应用的部署需求，包括副本数量、容器配置、网络设置等。这使得配置易于理解和维护，并且可以方便地查看应用的预期状态
• 可重复性和版本控制：配置文件可以被版本控制，确保在不同环境中的部署一致性。可以轻松回滚到以前的版本或在不同环境中重复使用相同的配置，
• 团队协作：便于团队成员之间共要和协作，大家可以对配置文件进行审查和修改，提高部署的可靠性和稳定性。

灵活性和可扩展性：

• 丰富的配置选项：可以通过 YAML 文件详细地配置各种 Kubernetes 资源，如 Deployment、Service、ConfigMap、Secret等。可以根据应用的特定需求进行高度定制化。
• 组合和扩展：可以将多个资源的配置组合在一个或多个 YAML文件中，实现复杂的应用部署架构同时，可以轻松地添加新的资源或修改现有资源以满足不断变化的需求。

与工具集成：

• 与CI/CD 流程集成：可以将 YAML 配置文件与持续集成和持续部署(CIVCD)工具集成，实现自动化的应用部署。例如，可以在代码提交后自动触发部署流程，使用配置文件来部署应用到不同的环境。
• 命令行工具支持：Kubernetes 的命令行工具 kubect] 对 YAML 配置文件有很好的支持，可以方便地应用、更新和删除配置。同时，还可以使用其他工具来验证和分析 YAML 配置文件，确保其正确性和安全性。

# 获得资源帮助

kubectl explain pod.spec.containers

# 运行简单的单个容器pod

kubectl run timinglee --image myapp:v1 --dry-run=client -o yaml > pod.yml

vim pod.yml
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: timinglee   # pod 标签
  name: timingleel  # pod 名称
spec:
  containers:
  - image: myapp:v1  # pod 镜像
    name: web1  # 容器名称

三、pod的生命周期 

3.1 INIT容器

 

• Pod 可以包含多个容器，应用运行在这些容器里面，同时 Pod 也可以有一个或多个先于应用容器启动的 Init 容器。
• Init 容器与普通的容器非常像，除了如下两点:
•         1、它们总是运行到完成
•         2、 init 容器不支持 Readiness，因为它们必须在 Pod 就绪之前运行完成，每个Init 容器必须运            行成功，下一个才能够运行。
• 如果Pod的 Init 容器失败，Kubernetes 会不断地重启该 Pod，直到 Init 容器成功为止。但是，如果 Pod 对应的 restartPolicy 值为 Never，它不会重新启动。

3.2 INIT容器的功能

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

 3.3  INIT容器实例

kubectl run initpod --image myapp:v1 -o yaml > pod.yml
vim pod.yml
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: initpod
  name: initpod
spec:
  containers:
   - image: myapp:v1
     name: myapp
  initContainers:
   - name: init-myservice
     image: busybox
     command: ["sh","-c","until test -e /testfile;do echo wating for myservice;sleep 2;done"]

kubectl apply -f pod.yml

kubectl logs pods/initpod init-myservice

wating for myservice

wating for myservice

wating for myservice 

kubectl exec pods/initpod -c init-myservice -- /bin/sh -c "touch /testfile"