wordpress 中文语言/seo包年优化

Pod名字的解释

在英语中，会将a groupof whales（一群鲸鱼）称作a Pod of whales，Pod就是来源于此。因为Docker的Logo是鲸鱼，所以在Kubernetes中会将包含了一组容器的事物称作Pod。

Pod中的容器

在前面已经提到了，pod是k8s调度的原子单位，一个pod可以有一个或多个容器在其中运行，他们拥有同一个IPC命名空间，共享的内存，共享的磁盘、网络以及其他资源，相同的ip（通过端口区分服务）等。

在多个容器的pod中，会有主容器，副容器的说法，其实在 Kubernetes 的设计理念中，Pod 中的容器地位是平等的，没有“主容器”这个正式概念。不过在实际使用中，尤其是在有多个容器共处一个 Pod 的时候，我们通常会从“业务功能”或“系统设计”角度，人为划分出所谓的 “主容器” 和 “副容器（Sidecar 容器）”。

示例 ：Tomcat + Nginx

• 主容器：Tomcat（跑 Java Web 项目）
• 副容器：Nginx（代理请求）

🔍 举个具体例子：

假设一个 Pod 有两个容器：

• 容器 A：运行 Tomcat，监听 8080 端口（Java 应用）
• 容器 B：运行 Nginx，监听 80 端口（反向代理）

Pod 的 IP 是 10.0.0.100

此时：

• 外部访问 http://10.0.0.100:80，就访问到了 Nginx 容器
• 外部访问 http://10.0.0.100:8080，就访问到了 Tomcat 容器

容器之间通信时也一样，比如：

• 容器 B 内部可以通过 localhost:8080 访问容器 A 提供的服务

Pod中的容器怎么通信？

内部通信（网络命名空间）

如果在同一个Pod中运行的两个容器之间需要通信（在Pod内部的容器间），那么就可以使用Pod提供的（其实是 Pod 的网络命名空间提供的）localhost接口来完成，具体如下图所示。

外部通信（集群网络 CNI）

运行在相同Pod中的所有容器都有相同的IP地址（Pod的IP地址），这时候可能大家会有疑问，既然共用一个ip，如何区分服务呢？实际上是通过端口来区分的（上面已经举过例子了），非常完美，我们服务器本来就是用端口来区分服务的，在这里也不例外。

Pod的原子性

Pod的部署是一个原子操作。长话短说，这意味着，只有当Pod中的所有容器都启动成功且处于运行状态时，Pod提供的服务才会被认为是可用的。对于Pod中可能有部分容器或服务未成功启动(实际上k8s是有探针来检测Pod状态的，这个以后再说)，那么这个Pod绝对不会响应服务请求，最终Pod也会被定性为启动失败。

所以整个Pod要么全部启动成功，并加入服务；要么被认为启动失败。

但请注意，实际上，如果只是部分容器失败，Pod 不一定直接被标记为“启动失败/未就绪”。状态可能会是 Running、CrashLoopBackOff、Pending （状态的详解请继续向下学习，此处不做解释）等，K8s 会根据重启策略尝试恢复，但只要不是真正启动成功，服务一般都不可达，也就是不响应你的请求。

Pod 安全策略

Pod 安全策略 由设置和策略组成，它们能够控制 Pod 访问的安全特征（控制pod的权限啊，端口，selinux等，可以理解为权限控制）。这些设置分为如下三类：

• 基于布尔值控制：这种类型的字段默认为最严格限制的值。
• 基于被允许的值集合控制：这种类型的字段会与这组值进行对比，以确认值被允许。
• 基于策略控制：设置项通过一种策略提供的机制来生成该值，这种机制能够确保指定的值落在被允许的这组值中

下面的表格是 Pod Security Policy（psp），但 psp 在 Kubernetes v1.21 中被弃用， 在 Kubernetes v1.25 中被移除。Pod Security Admission（psa）是目前新的策略，实际应用可以参考官网，此处仅用于让读者理解pod的安全策略。

控制面	字段名称	基于什么类型	类型选项 / 说明
特权容器控制	privileged	容器	true / false：是否允许以特权模式运行容器
默认添加能力	defaultAddCapabilities	容器	字符串数组：自动为容器添加的 Linux Capabilities，例如 ["NET_ADMIN", "SYS_TIME"]
强制去掉的能力	requiredDropCapabilities	容器	字符串数组：必须移除的 Capabilities
容器请求能力的白名单	allowedCapabilities	容器	字符串数组：允许容器请求的 Capabilities 列表
卷类型控制	volumes	Pod	字符串数组：允许使用的 Volume 类型，如 ["configMap", "emptyDir", "secret"]
主机网络	hostNetwork	Pod	true / false：是否允许使用宿主机网络
主机端口	hostPorts	容器	指定允许的宿主机端口范围，例如：min: 80, max: 80
主机 PID 命名空间	hostPID	Pod	true / false：是否允许访问主机 PID 命名空间
主机 IPC 命名空间	hostIPC	Pod	true / false：是否允许访问主机 IPC 命名空间
主机路径挂载	allowedHostPaths	容器卷挂载	字符串数组：允许挂载的主机路径前缀（prefix）
SELinux 安全上下文	seLinux	PodSecurityContext	定义策略和类型，如 rule: MustRunAs, seLinuxOptions: level: s0:c123,c456
用户 ID 控制	runAsUser	PodSecurityContext	MustRunAs, RunAsAny，并可指定 UID 范围
补充用户组	supplementalGroups	PodSecurityContext	允许分配的补充 GID，例如范围 1000-2000
数据卷组权限控制	fsGroup	PodSecurityContext	允许指定的 GID 范围：用于赋予数据卷共享访问权限
只读根文件系统	readOnlyRootFilesystem	容器	true / false：是否强制使用只读根文件系统

小知识-命名空间

注意，首先我要强调一点，Kubernetes命名空间（K8s Namespace）与Pod内的共享命名空间是两个东西，下面请让我我来解释。（官方参考：Kubernetes 1.30：对 Pod 使用用户命名空间的支持进阶至 Beta | Kubernetes）

Pod内的共享命名空间：是 Linux 内核提供的一种隔离机制，这个命名空间是指 Pod内容器共享的网络、存储、IPC等资源命名空间。在同一个Pod内，多个容器共享网络命名空间、存储卷、PID命名空间等。这个概念更多的是与容器的协作和资源共享相关，而非集群范围的资源隔离（再次强调！意思就是和Kubernetes命名空间不是一个东西）。（官方文档：用户命名空间 | Kubernetes）
Kubernetes中的Namespace是一种用于在集群内部组织和隔离资源的机制。一个Namespace可以看作是一个虚拟的集群，它将物理集群划分为多个逻辑部分，每个部分都有自己的一组资源（如Pod、Service、ConfigMap等）。

！！！非常重要！！！： 实际上一些容器运行时的默认配置（如 Docker Engine、containerd、CRI-O）就使用 Linux 命名空间进行隔离，这样我们就可以理解pod为什么有用户命名空间这个东西了（既Pod 网络命名空间的设置由实现容器运行时接口（CRI）的系统层面软件处理。）。

常见的 7 种 Linux 命名空(namespaces(7) - Linux manual page)间如下：

命名空间	简称	作用
Mount Namespace	mnt	隔离挂载点（如文件系统结构），不同容器看不到彼此的挂载点。
UTS Namespace	uts	隔离主机名和域名（hostname 和 domainname）。
IPC Namespace	ipc	隔离进程间通信资源，如信号量、消息队列、共享内存。
PID Namespace	pid	隔离进程编号（每个容器都认为自己从 PID 1 开始）。
Network Namespace	net	隔离网络接口、IP 地址、路由表、端口等。
User Namespace	user	隔离用户和组 ID（UID、GID），可实现非特权容器。
Cgroup Namespace	cgroup	隔离 cgroup 层级，控制资源分配和限制的视图。

Pod内部共享情况

命名空间类型	是否 Pod 内容器默认共享	是否可配置为共享	说明
Network (net)	✅ 是	❌ 否	所有容器共享 Pod 的网络栈：同一个 IP、端口需避免冲突。
PID (pid)	❌ 否	✅ 可以共享	可通过 shareProcessNamespace: true 启用容器之间共享进程视图。
IPC (ipc)	✅ 是	❌ 否	所有容器共享信号量、消息队列、共享内存。
Mount (mnt)	❌ 否	✅ 通过 Volume 实现	不直接共享，但可通过挂载同一个 Volume 实现数据共享。
UTS (uts)	❌ 否	✅ 某些场景下可共享	可通过配置让多个容器看到同样的 hostname（不常用）。
User (user)	❌ 否	✅ 支持（1.25+ 默认开启）	Linux 支持，K8s 中需要额外配置或启用。
Cgroup(cgroup)	❌ 否	⚠️ 受限支持	Kubernetes 不直接暴露配置，但可通过容器运行时影响。

下面着重介绍一下刚刚提到的内部命名空间

IPC Namespace

IPC （Inter-Process Communication）命名空间 是 Linux 容器中非常核心的一个隔离机制，它的作用是让同一个 Pod 中的多个容器能够共享进程间通信资源（IPC），而不同 Pod 的容器之间则无法互相访问这些资源（当然，这样也保证了不同pod的隔离性从而保证安全与互不干扰）。

那么这些资源包括如下种类：

• 共享内存（Shared Memory）
• 信号量（Semaphores）
• 消息队列（Message Queues）

所以，在一个pod中的容器由于拥有同一个IPC命名空间，这导致这些容器之间能够共享内存，使用同一个key获取同一个信号量，通过消息队列进行通信。

Network Namespace

Pod 有自己的私有网络命名空间，Pod 内的所有容器共享这个命名空间。 运行在同一个 Pod 中的不同容器的进程彼此之间可以通过 localhost 进行通信。但是在外部通信时由于网络命名空间之间彼此独立（不同pod实际上是被命名空间隔离了），但它们之间的通信可以通过宿主机上的虚拟网络桥或者网络插件（容器网络接口CNI）实现连接。（官方文档：网络插件 | Kubernetes）