kubernetes -pod 实践-CSDN博客

本文链接：https://blog.csdn.net/weixin_42816196/article/details/135029000

本文详细介绍了Kubernetes中的Pod，包括其作为最小部署单元的角色、使用场景、管理方式、运行阶段和状态，以及Pod的生命周期、初始化容器、钩子函数和探针的运用。重点探讨了Pod在日志收集、服务模块、不同IaaS平台环境适配等场景的应用，并解释了Pod如何通过初始化容器、控制器、探针等机制确保应用的稳定性和管理效率。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

一、资源与对象

1、pod

容器都是由镜像启动的，但在容器外面会包裹通过Pod将容器包裹起来这个是K8s的概念，在这个Pod里面可以有一个或多个容器，那这个Pod的有什么特征呢

Pod里的所有容器都会调度在同一个节点上运行0。
Pod中的所有容器会共享同一网络，它们有一个唯一的IP，就叫PodIP;
Pod中还有一个特殊的容器叫Pause，它会优先启动然后进行IP分e配，而后将其他容器都Link到该容器上，实现网络共享
pod 是kubernetes的最小资源

Pod是Kubernetes中的抽象概念，也是Kubernetes中的最小部署单元。在每个Pod中至少包含一个容器或多个容器，这些容器共享Network (网络) 、PID (进程) 、IPC (进程间通信)HostName (主机名称) 、Volume (卷) 。当我们需要部署应用时，其实就是在部署Pod，Kubernetes会将Pod中所有的容器作为一个整体，由Master调度到一个Node上运行。

2、Deployment

在Pod的上一层就是ReplicaSet控制器，它主要负责管理Pod的副本数，但通常我们并不直接使用ReplicaSet，而是使用比ReplicaSet更高一级的DepLoyment。由DepLoyment管理ReplicaSet，它会自动帮我们创建和销毁RS，有了Deployment就可以实现应用的滚动更新。
ReplicaSet是副本控制器

[root@master ~]# kubectl  create  deployment  nginx --image=nginx --replicas=3
deployment.apps/nginx created
[root@master ~]# kubectl  get pod
NAME                     READY   STATUS    RESTARTS   AGE
nginx-85b98978db-4475f   1/1     Running   0          22m
nginx-85b98978db-5r87f   1/1     Running   0          22m
nginx-85b98978db-85wtn   1/1     Running   0          22m
[root@master ~]# kubectl  get rs
NAME               DESIRED   CURRENT   READY   AGE
nginx-85b98978db   3         3         3       22m
[root@master ~]# kubectl  get deployments.apps 
NAME    READY   UP-TO-DATE   AVAILABLE   AGE
nginx   3/3     3            3           22m

3、Service

Service，是Kubernetes用来实现Pod负载均衡的一个服务;要想实现Pod的负载均衡，首先需要通过Labels为Pod打上特定的标签，而后创建Service时使用SeLector选择对应的标签，最终通过节点的kube-proxy来完成负载均衡的规则创建

4、Namespace

在 Kubernetes 中，名字空间’(Namespace) 提供一种机制，将同-集群中的资源划分为相互隔离的组。同一名字空间内的资源名称要唯，但跨名字空间时没有这个要求

对资源对象进行隔离: 比如: Pod、Deployment、Service、将其划分为相互隔离的组。
对资源配额进行隔离: CPU，Memory ，限制某个NS的可以使用的cpu和内存;

二、 kubernetes核心资源pod

1、为什么需要Pod
有些容器关系比较紧密，必须要再一起工作。Pod提供了比容器更高层次的抽象，将它们封装到一个部署单元中进行调度，从而达到一起部署、一起管理。

pod 使用场景

场景一：

比如：日志收集：
Tomcat filebeat 收集 access.log error.log 日志信息推送到 logging-server，一个pod有两个镜像

在这里插入图片描述

服务模块已经实现了一些核心的业务逻辑，并且稳定运行了一段时间，日志记录在了某个目录下，按照不同类别分别为 error.togaccess.Tog，现在希望收集这些日志并发送到统一的日志处理服务器上。
这时我们可以修改原来的服务模块，在其中添加日志收集、发送的服务但这样可能会影响原来服务的配置、部署方式，从而带来不必要的问题和成本，也会增加业务逻辑和基础服务的藕合度
如果使用Pod的方式，通过简单的编排，既可以保持原有服务逻辑、部署方式不变，又可以增加新的日志收集服务。而且如果我们对所有服务的日志生成有一个统一的标准，或者仅对日志收集服务稍加修改，就可以将日志收集服务和其他服务进行Pod编排，提供统一、标准的日志收集方式。

场景二：

提供ssh、ftp访问容器数据的能力
Docker Hub或者很多第三方的镜像并没有安装sshd的服务，不方便我们进入容器进行配置、代码的修改、调试，很多时候需要重新构建镜像或者在镜像基础上安装sshd的服务，这都需要时间和一定的学习成本
而通过Pod的方式，我们就可以将现有镜像和一个ssh、ftp镜像进行编排，获得操作容器内数据的能力。

在这里插入图片描述

场景三：

适配不同IaaS平台的环境

比如开发了一个节点管理agent程序，这个agent需要读取当前部署环境的一些信息，可以通过底层平台的API实现。但是，当部署到AWS、阿里云、青云等不同平台时，API就无法统一了。
但是我们可以运行一个适配各平台的服务用来获取不同平台的相关信息然后通过Pod编排部署，在不改变agent逻辑的情况下，通过服务组合来适配于不同平台。

在这里插入图片描述

场景四：

一个Nginx容器用来发布软件，另一个容器专门用来从源仓库做同步，这两个容器的镜像不太可能是一个团队开发的，但是他们一块儿工作才能提供一个微服务;所以需要将这些位于同一Pod内的容器形成单个服务对外提供，一个容器将共享卷获取的数据提供给用户，而另一个容器 (边车sidecar) 则不断更新文件到共享卷中来
通过这种方式，就可以将来自不同团队的容器镜像，在部署的时候组合成一个微服务对外提供服务。

在这里插入图片描述
但是在kubernetes新版本中，可以通过pod的编排进行解决，可以不通过修改代码进行解决

场景五：

pod 共享网络：

在Docker中，如果 tomcat 容器想与 mysgl容器进行共享，需要先启动mysql容器，然后tomcat容器通过 --net=db:mysgl选项即可和mysql共享网络，这也就意味着我们必须先运行mysql，后运行tomcat，才可以实现共享网络。
在Kubernetes中，Pod的网络共享和Docker的网络共享实现方式一致只不过在启动Pod时，会先启动一个 pause的容器，然后将后续的所有容器都 --Tink到这个 pause的容器，以实现网络共享。

在这里插入图片描述

通过上图我们可以得出如下结论

1、Pod中的Tomcat容器可以直接使用 Loca host 与MySQL容器进行通信;
2、Pod中的多个容器不允许绑定相同的端口，因为所有容器共享网络协议栈，看到的网络信息一致;

场景六：

默认情况下所有容器的文件系统是互相隔离的，要实现文件共享则需要在Pod 层面声明一个Volume 卷，然后在需要共享的容器中声明VolumeMounts 来挂载文件系统，从而达到多个容器共享一个存储卷。

在这里插入图片描述

cat pod-mount.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: pod-mutil
spec:
  volumes :
  - name: webpage
    emptyDir: {}
# 申明VoLumes共享卷
# 卷名称
# 卷类型
  containers:
  - name: random-app
  # 产生内容写入/apps/index.html 文件中

    image: busybox
    command: ['/bin/sh','-c','echo "web-$(date +%F)" >> /apps/index.html &&  sleep 30']
    volumeMounts:
    - name: webpage
      mountPath: /apps
       
  - name: nginx-app
   # 第二个容器读取第一个容器产生的内容，对外提供访问
    image: nginx
    volumeMounts:
    - name: webpage
      mountPath: /usr/share/nginx/html

在这里插入图片描述

三、pod管理方式

1、自主式管理pod

在Kubernetes中，我们部署pod的时候，基本上都是使用控制器管理那如果不使用控制器，也可以直接定义一个pod资源，那么就是pod自己去控制自己，这样的pod称为自主式pod。
如果Pod被删除，那就是真的被删除，不会重新在运行一个新的Pod;
如果Pod所在的节点需要维护，那么节点会先执行驱逐，如果是自助式Pod，驱逐后不会被重建。
如果Pod期望部署多个副本，这个也能实现，但如果想持续维持副本数量，则需要人为参与，过于繁琐。

查看pod的必备字段：
kubectl explain pod

这个是pod 最简单的pod编写

apiVersion: v1
kind: Pod
metadata:
  name: nginx 
  namespace: default
spec:
  containers: 
  - name: pod-nginx
    image: nginx:1.16
    ports:
    - containerPort: 80

测试pod删除：

[root@master yaml]# kubectl  get pod 
NAME                     READY   STATUS    RESTARTS      AGE
nginx                    1/1     Running   0             65s
nginx-85b98978db-4475f   1/1     Running   2 (98m ago)   27h
nginx-85b98978db-5r87f   1/1     Running   2 (98m ago)   27h
nginx-85b98978db-85wtn   1/1     Running   2 (98m ago)   27h
[root@master yaml]# kubectl delete pod nginx 
pod "nginx" deleted
[root@master yaml]# kubectl  get pod 
NAME                     READY   STATUS    RESTARTS       AGE
nginx-85b98978db-4475f   1/1     Running   2 (99m ago)    27h
nginx-85b98978db-5r87f   1/1     Running   2 (100m ago)   27h
nginx-85b98978db-85wtn   1/1     Ru