k8s中pod管理

一、Pod的基本概念

定义:Pod是Kubernetes中可以创建和管理的最小单元,是资源对象模型中由用户创建或部署的最小资源对象模型。

组成:Pod由一个或多个容器组成,这些容器共享网络、存储等资源,并作为一个整体被调度和管理。

功能:Pod是Kubernetes中运行容器化应用的基本单位,其他大多数组件都是围绕着Pod来进行支撑和扩展功能的。

二、Pod的特点

共享资源:Pod中的容器共享Network、UTS及IPC命令空间,因此具有相同的域名、主机名和网络接口,并可通过IPC直接通信。

生命周期:Pod从创建到销毁的整个过程称为生命周期。Pod的状态包括Pending(等待调度)、Running(运行中)、Succeeded(成功完成)、Failed(失败)和Unknown(未知状态)等。

自动恢复:当Pod中的容器因为某些原因停止运行时,Kubernetes会自动尝试重新启动这些容器,以保证Pod的可用性。

三、Pod的组成结构

Pause容器:每个Pod在创建时都会自动创建一个Pause容器(也称为基础容器或父容器)。Pause容器为Pod提供Linux命名空间的基础,并启用PID命名空间。它在每个Pod中都作为PID为1的进程(init进程),并回收僵尸进程。Pause容器还负责管理Pod容器间的共享操作,如网络命令空间、共享存储等。

初始化容器(Init Containers):初始化容器在Pod的主容器启动之前运行,用于完成一些预处理工作,如配置环境变量、下载文件等。初始化容器按顺序串行启动,每个初始化容器都必须在下一个初始化容器启动前完成启动和退出。

应用容器(Main Containers):应用容器是Pod中实际运行业务逻辑的容器。在所有初始化容器启动和退出后,应用容器才会启动,并且是并行启动的。

四、Pod的使用方式

单个容器Pod:这是最常见的使用方式,每个Pod中只运行一个容器。在这种情况下,可以把Pod想象成是单个容器的封装,Kubernetes管理的是Pod而不是直接管理容器。

多个容器Pod:一个Pod中也可以同时封装几个需要紧密耦合、互相协作的容器。这些容器共享资源,并作为一个service单位来运行。例如,一个容器负责共享文件,另一个“sidecar”容器负责更新这些文件。

资源管理介绍

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

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

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

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

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

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

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

0e73cb22440843ab9aee463b1e817ef2.png

 

资源管理方式

 

 

命令对象式管理:直接使用命令去操作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.1命令式对象管理

3cdbaef7baf945fa9c958af168ac8e1a.png

66224216328b45d3a58594841956e738.png 

高级命令事例演示

利用命令生成yaml模板文件

959dbd58a4ac48d3b6f25a3eb82099bd.png

388bcddd59434e1bb99d2c5844c6e39f.png 

 什么是pod

Pod的组成

容器: Pod中可以包含一个或多个容器,这些容器共享Pod的网络和存储卷。通常,一个Pod只运行一个主容器,但也可以运行多个辅助容器 (例如,用于日志收集或数据备份的容器)。

存储:Pod可以定义存储卷(Volumes),用于存储数据。这些存储卷可以是空的目录、持久化存储(如NFS、Ceph等)、或者从已有的数据卷中挂载。Pod中的容器可以共享这些存储卷。

网络:每个Pod在Kubernetes集群中都有一个唯一的IP地址。Pod中的容器共享这个网络命名空间,包括IP地址和端口空间。这意味着 Pod内的容器可以通过localhost相互通信,并且可以通过Pod的IP地址从集群外部访问Pod内的服务。

生命周期: Pod有一个生命周期,包括创建、运行、更新和删除等阶段。Kubernetes通过Controller(如Deployment、ReplicaSet等) 来管理Pod的生命周期,确保Pod按照预期的数量和状态运行。

Pod的用途

Pod是Kubernetes中运行应用的基本单位。通过将应用封装在Pod中,Kubernetes可以轻松地管理应用的部署、扩展、升级和故障恢复。此外,Pod还提供了以下功能:

资源隔离:通过限制Pod的资源使用(如CPU和内存),可以防止单个应用占用过多的集群资源。

服务发现:Kubernetes中的Service可以通过标签选择器来选择并暴露一组Pod。这使得服务能够自动发现和连接到具有特定标签的Pod。负载均衡:Service还可以为Pod提供负载均衡功能,将流量分发到多个Pod实例上。

滚动更新和回滚:通过Controller,Kubernetes可以实现对Pod的滚动更新和回滚操作,确保应用升级过程中的稳定性和可用性。

查看所有pods

8ebae3f4589d4f54b6e0f8a20518f585.png

 创建一个pod

93296621fd1242e0a3fcf965638925cc.png

 显示更为详细的信息

7af6ff1d570c4b258e526c4024e7da43.png

 控制器的作用

1.高可用性和可靠性:
·自动故障恢复:如果一个Pod失败或被删除,控制器会自动创建新的Pod来维持期望的副本数量。确保应用始终处于可用状态,减少因单个Pod 故障导致的服务中断。
●健康检查和自愈:可以配置控制器对Pod进行健康检查(如存活探针和就绪探针)。如果Pod不健康,控制器会采取适当的行动,如重启Pod或删除并重新创建它,以保证应用的正常运行。可扩展性:
●轻松扩缩容:可以通过简单的命令或配置更改来增加或减少Pod的数量,以满足不同的工作负载需求。例如,在高流量期间可以快速扩展以处理更多请求,在低流量期间可以缩容以节省资源。·水平自动扩缩容(HPA):可以基于自定义指标(如CPU利用率、内存使用情况或应用特定的指标)自动调整Pod的数量,实现动态的资源分配和成本优化。版本管理和更新:
·滚动更新:对于Deployment等控制器,可以执行滚动更新来逐步替换旧版本的Pod为新版本,确保应用在更新过程中始终保持可用。可以控制更新的速率和策略,以减少对用户的影响。·回滚:如果更新出现问题,可以轻松回滚到上一个稳定版本,保证应用的稳定性和可靠性。声明式配置:
·简洁的配置方式:使用YAML或JSON 格式的声明式配置文件来定义应用的部署需求。这种方式使得配置易于理解、维护和版本控制,同时也方便团队协作。
●期望状态管理:只需要定义应用的期望状态(如副本数量、容器镜像等),控制器会自动调整实际状态与期望状态保持一致。无需手动管理每个Pod的创建和删除,提高了管理效率。服务发现和负载均衡:
·自动注册和发现:Kubernetes中的服务(Service)可以自动发现由控制器管理的Pod,并将流量路由到它们。这使得应用的服务发现和负载均衡变得简单和可靠,无需手动配置负载均衡器。
●流量分发:可以根据不同的策略(如轮询、随机等)将请求分发到不同的Pod,提高应用的性能和可用性。

2.如何使用控制器管理Pod

创建控制器:使用YAML文件或kubectl命令创建控制器。

指定Pod模板、副本数、标签选择器等参数。

监控和管理:使用kubectl命令查看控制器的状态和Pod的状态。

根据需要调整控制器的配置,例如修改副本数、更新Pod模板等。

弹性伸缩:通过Horizontal Pod Autoscaler(HPA)根据资源利用率自动调整Pod副本数。

控制器会根据HPA的配置自动进行扩容或缩容操作。

滚动更新:对于Deployment控制器,可以使用kubectl命令或YAML文件更新Pod模板。

控制器会按照滚动更新的策略逐步替换旧的Pod,确保服务的连续性。

故障恢复:当Pod出现故障时,控制器会根据重启策略尝试重启Pod。

利用控制器建立pod

5dc1cb324846447098565c2aeb7c70ad.png

暴露端口

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

service/timinglee exposed

应用版本的更新

kubectl set image deployments/timinglee myapp=myapp:v2

利用yaml文件部署应用

活得资源帮助

kubectl explain pod.spec.containers

进行简单的单个容器pod

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

运行多个容器pod

vim pod.yml

apiVersion: v1

kind: Pod

metadata:

  labels:

    run: timinglee

  name: timinglee

spec:

  containers:

  - image: myapp:v1

    name: web1

  - image: myapp:v2

    name: web2

开启多个互不干扰

vim pod.yml
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: timinglee
  name: timinglee
spec:
  containers:
  - image: myapp:v1
    name: web1
  - image: busybox:latest
    name: web2
    command: ["/bin/sh","-c","sleep 1000000"]

30d2a128313044d898860de6047aec2b.png

pod的生命周期 

init容器

f7c10c156bdf4e569863d296877f0b32.png

 Pod 可以包含多个容器,应用运行在这些容器里面,同时Pod也可以有一个或多个先于应用容器启动的Init容器。·Init 容器与普通的容器非常像,除了如下两点:

它们总是运行到完成

init 容器不支持Readiness,因为它们必须在Pod 就绪之前运行完成,每个Init容器必须运行成功,下一个才能够运行。

如果Pod的 Init容器失败,Kubernetes会不断地重启该Pod,直到Init容器成功为止。但是,如果Pod 对应的restartPolicy值为 Never,它不会重新启动。

容器的功能

Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。·Init 容器可以安全地运行这些工具,避免这些工具导致应用镜像的安全性降低。

应用镜像的创建者和部署者可以各自独立工作,而没有必要联合构建一个单独的应用镜像。

Init 容器能以不同于Pod内应用容器的文件系统视图运行。因此,Init容器可具有访问Secrets的权限,而应用容器不能够访问。

由于 Init 容器必须在应用容器启动之前运行完成,因此Init容器提供了一种机制来阻塞或延迟应用容器的启动,直到满足了一组先决条件。一旦前置条件满足,Pod内的所有的应用容器会并行启动。 

init容器事例

d01583e6e4bf4ba8b2eeb2c9dd607eb0.png

3fd008a8146d4f3d8f218af43b2e956d.png

85eafcae1bcb4697ae75f63e91ef3168.png  

探针事例 

e5469ed02dd74022a267b93b3cb1d6c4.png

 

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值