ToB企服应用市场:ToB评测及商务社交产业平台

标题: K8s中pod的管理和优化 [打印本页]

---

作者: 张裕    时间: 2024-10-15 01:49
标题: 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"

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

---

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)

Powered by Discuz! X3.4