跳到主要内容

pod

组件

apiserver :

  1. 中央控制面板 与其他组件进行通信(调度器、控制器和 kubelet)

  2. RESTful API 接口

kube-scheduler :

  1. 负责将 Pod 调度到合适的节点上运行。(节点的资源可用性、Pod 的亲和性和反亲和性规则) 均匀分布 并获得 足够的资源
  2. 会不断监控集群状态，并根据 Pod 的状态变化进行调整，例如当 Pod 失败时，调度器会重新调度 Pod 到其他节点上运行

kube-controller-manager

  1. 节点控制器：负责维护节点状态，例如检测节点故障并标记节点为不可用。
  2. 端点控制器：负责更新 Service 的端点信息，反映 Pod 的实际状态。
  3. 复制控制器：负责确保运行指定数量的 Pod 副本。
  4. 垃圾回收控制器：负责清理不再需要的资源，例如已完成的 Pod 和无用的镜像。

kubelet

  1. 本地节点上管理 Pod 的生命周期(创建容器、配置网络、挂载卷)
  2. kubelet 监控容器的状态，并向 API 服务器报告 Pod 的状态变化。
  3. kubelet 还负责执行其他任务，例如拉取镜像、清理容器日志等。

kube-proxy

  1. 根据 Service 的配置，将(iptables 或 ipvs)流量转发(负载均衡)到 Service 后端的 Pod 上。

Ingress

  • Ingress 使用七层路由规则来匹配传入流量，并将其路由到正确的 Service。
  • Ingress 可以提供 SSL 终止、身份验证和授权等功能。

CNI

  • CNI 可以是 Flannel、Calico、CNI-Genie 等多种实现。
  • CNI 会为 Pod 创建虚拟网卡，并分配 IP 地址和路由信息。

CNI, CSI, CRI

etcd

  • 作为 Kubernetes 的数据存储，负责保存集群状态，包括 Pod、Service、Deployment 等资源的信息。
  • API 服务器、调度器、控制器等组件都依赖 etcd 来获取和更新集群状态。

pod 创建过程

kubectl -> apiserver ->etcd ->scheduler -> kubelet -> CRI(容器运行时接口) 容器网络接口 (CNI) 挂载卷 ->docker

创建pod 主要流程如下:

1、客户端提交Pod的配置信息(可以是yaml文件定义的信息)到kube-apiserver。

2、Apiserver收到指令后，通知给controller-manager创建一个资源对象。

3、Controller-manager通过api-server将pod的配置信息存储到ETCD数据中心中。

4、Kube-scheduler检测到pod信息会开始调度预选，会先过滤掉不符合Pod资源配置要求的节 点，然后开始调度调优，主要是挑选出更适合运行pod的节点，然后将pod的资源配置单发送到 node节点上的kubelet组件上。

5、Kubelet根据scheduler发来的资源配置单运行pod，运行成功后，将pod的运行信息返回给 scheduler，scheduler将返回的pod运行状况的信息存储到etcd数据中心

1）客户端提交创建请求，可以通过 api-server 提供的 restful 接口，或者是通过 kubectl 命令行工具，支持的数据类型包括 JSON 和 YAML；

2）api-server 处理用户请求，将 pod 信息存储至 etcd 中；

3）kube-scheduler 通过 api-server 提供的接口监控到未绑定的 pod，尝试为 pod 分配 node 节点，主要分为两个阶段，预选阶段和优选阶段，其中预选阶段是遍历所有的 node 节点，根据策略筛选出候选节点，而优选阶段是在第一步的基础上，为每一个候选节点进行打分，分数最高者胜出；

4）选择分数最高的节点，进行 pod binding 操作，并将结果存储至 etcd 中；

5）随后目标节点的 kubelet 进程通过 api-server 提供的接口监测到 kube-scheduler 产生的 pod 绑定事件，然后从 etcd 获取 pod 清单，下载镜像并启动容器。

详细过程及组件交互 Kubernetes创建一个Pod的详细流程涉及多个组件之间的通信和协作。下面是一个简化的创建Pod的流程：

用户使用kubectl或通过Kubernetes API发送创建Pod的请求。

Kubectl或API Server接收到创建Pod的请求，并验证请求的合法性。

如果请求合法，API Server将请求转发给调度器（Scheduler）。

调度器根据预定义的调度策略和资源约束，选择一个合适的节点来运行Pod。

调度器将Pod的调度决策发送给API Server。

API Server将调度决策保存在etcd中，作为集群状态的一部分。

调度器将Pod的绑定信息发送给Kubelet节点。

Kubelet收到调度器发送的绑定信息后，在相应节点上创建Pod的容器。

Kubelet通过容器运行时（如Docker、containerd）创建和管理Pod的容器。

容器创建完成后，Kubelet会向API Server报告Pod的状态和健康状况。

API Server更新Pod的状态，并将更新写入etcd中。

如果Pod定义中定义了服务（Service），API Server将创建相应的服务对象，并将其与Pod关联起来。

负载均衡器（如kube-proxy）根据服务的定义，将流量转发到Pod所在的节点上的容器。

在这个流程中，涉及到以下几个关键组件的通信：

用户与kubectl或API Server之间的通信：用户通过命令行工具kubectl或使用Kubernetes API与API Server进行通信，发送创建Pod的请求。

API Server与调度器之间的通信：API Server将创建Pod的请求转发给调度器，并接收调度器返回的调度决策。

API Server与etcd之间的通信：API Server将集群状态信息（如调度决策、Pod状态更新）写入etcd中，并从etcd中读取集群状态信息。

调度器与API Server、etcd之间的通信：调度器接收API Server发送的创建Pod请求，并向API Server报告调度决策，这些信息通过API Server与etcd进行通信。

调度器与Kubelet之间的通信：调度器将Pod的绑定信息发送给相应的Kubelet节点，以指示在哪个节点上创建Pod。

Kubelet与容器运行时之间的通信：Kubelet通过容器运行时（如Docker、containerd）创建和管理Pod的容器。

Kubelet与API Server之间的通信：Kubelet向API Server报告Pod的状态和健康状况，以及接收API Server发送的更新信息。

API Server与负载均衡器之间的通信：如果Pod定义中定义了服务，API Server将创建相应的服务对象，并与负载均衡器（如kube-proxy）进行通信，以将流量正确转发到Pod所在的节点。

K8S删除POD的流程 从集群中移除 yaml endpoint 终止容器 优雅停止 kill -15 (-14 发送警告) 等待终止超时 30s 清理资源 可能的重新调度

1）pod从service的endpoint列表中被移除；

2)如果该pod定义了一个停止前的钩子，其会在pod内部被调用，停止钩子一般定义了如何优雅的结束进程；

3)进程被发送TERM信号（kill -14）;

4)当超过优雅退出的时间后，Pod中的所有进程都会被发送SIGKILL信号（kill -9）

详述 当删除一个 Pod 时，以下事件将会发生：

从集群中移除：Kubernetes 控制平面接收到删除操作后，将从集群中移除该 Pod 的相关配置和定义。这意味着该 Pod 将不再被调度到任何节点，并且不再受到 Kubernetes 的管理。

终止容器：Kubernetes 会向 Pod 中的容器发送 SIGTERM 信号（15号信号），请求容器进行优雅关闭。容器收到该信号后，可以执行清理操作、释放资源、保存状态等，并尽量在一定时间内正常退出。

等待终止超时：在发送 SIGTERM 信号后，Kubernetes 会等待一段时间（默认为 30 秒）来等待容器正常退出。如果容器在超时时间内仍然没有终止，Kubernetes 将发送 SIGKILL 信号（9号信号）强制终止容器。

清理资源：一旦容器终止，Kubernetes 将清理与该 Pod 相关的资源。这可能包括释放节点上的网络、存储卷、临时文件等资源，以及更新集群中的状态信息。

可能的重新调度：如果删除的 Pod 属于由 ReplicaSet、Deployment 或其他控制器管理的副本集，Kubernetes 将尝试根据副本集的定义重新调度一个新的 Pod 来替代被删除的 Pod，以确保所需的副本数维持在正常状态。

静态pod

是由kubelet进行管理的仅存在于特定Node的Pod上，他们不能通过API Server进行管理，无法 与ReplicationController、Deployment或者DaemonSet进行关联，并且kubelet无法对他们进行健康检查。

静态Pod总是由kubelet进行创建，并且总是在kubelet所在的Node上运行。

K8S POD的共享资源 网络资源共享：Pod 中的容器可以共享同一个网络命名空间，它们可以通过 localhost 直接相互通信，而无需进行网络地址转换。此外，它们还可以共享同一个 IP 地址和端口空间。

存储资源共享：Pod 中的容器可以共享同一个存储卷（Volume）。这意味着它们可以访问和修改同一个存储卷中的数据。

进程间通信（IPC）资源共享：Pod 中的容器可以通过共享 IPC 命名空间进行进程间通信。它们可以使用共享的 System V IPC 对象（如共享内存、消息队列和信号量）进行通信。

命名空间（Namespace）资源共享：Pod 中的容器可以共享同一个命名空间，这意味着它们可以访问相同的系统资源和文件系统。

UTS 命名空间共享：UTS 命名空间用于隔离主机的主机名和域名。通过共享 UTS 命名空间，Pod 中的容器可以共享相同的主机名和域名。这意味着它们在网络上看起来像是同一台主机。 共享 UTS 命名空间对于某些应用场景很有用，比如需要在容器之间进行主机名解析或者依赖主机名的应用。共享 UTS 命名空间可以确保容器之间的主机名和域名保持一致，从而简化了应用的配置和管理。

pod 状态​

Pending:API Server已经创建该Pod，且Pod内还有一个或多个容器的镜像没有创建，包括正在下载镜

像的过程。

Running:Pod内所有容器均已创建，且至少有一个容器处于运行状态、正在启动状态或正在重启状 态。

Succeeded:Pod内所有容器均成功执行退出，且不会重启。

Failed:Pod内所有容器均已退出，但至少有一个容器退出为失败状态。

Unknown:由于某种原因无法获取该Pod状态，可能由于网络通信不畅导致。

pod 处于 Pending 状态的原因​

  • 调度器错误：如果调度器出现故障, 节点标签,亲和性,没有找到合适的节点
  • 资源不足：如果集群中没有足够的资源（limits/ CPU、内存等）来满足 pod 的要求，则 pod 将保持 Pending 状态。
  • pv/pvc ConfigMap 无法正常创建
  • 映像拉取错误(网络问题)：如果 pod 无法拉取其所需的映像，则它将保持 Pending 状态。
  • 节点污点（Taint）和容忍度（Toleration）不匹配：如果节点被“污染”，则它将被标记为排斥某些 pod。
  • 节点不可调度：如果节点不可调度，则 pod 将无法在其上调度。

以下是排查 Kubernetes pod 处于 Pending 状态的一些步骤：

  1. 检查 pod 的资源请求和限制。确保 pod 的资源请求和限制不超过集群中可用资源的总量。
  2. 检查 pod 的日志，看看是否有任何错误消息。错误消息可能提供有关为什么 pod 处于 Pending 状态的线索。
  3. 使用 kubectl describe pod 命令获取有关 pod 的更多详细信息。此命令将输出有关 pod 的状态、资源、映像和节点的信息。
  4. 使用 kubectl get nodes 命令获取有关集群中节点的详细信息。此命令将输出有关每个节点的名称、状态、资源和污点的详细信息。

pod一直是waiting​

容器的镜像名称正确否？ 容器镜像推送否？ 节点上docker pull / ctr -n k8s.io image pull 能拉取否？

pod处于running状态，但是不工作​

yaml语法、格式问题排查 kubectl apply xxx.yaml --validate pod是否达到预期？ kubectl get pod mypod -o yaml > mypod.yaml kubectl apply -f mp.yaml

Pod的重启策略包括​

Always、OnFailure和Never，默认值为Always。

Always:当容器失效时，由kubelet自动重启该容器; OnFailure:当容器终止运行且退出码不为0时，由kubelet自动重启该容器; Never:不论容器运行状态如何，kubelet都不会重启该容器。

同时Pod的重启策略与控制方式关联，当前可用于管理Pod的控制器包括ReplicationController、Job、 DaemonSet及直接管理kubelet管理(静态Pod)。

不同控制器的重启策略限制如下:

RC和DaemonSet:必须设置为Always，需要保证该容器持续运行; Job:OnFailure或Never，确保容器执行完成后不再重启; kubelet:在Pod失效时重启，不论将RestartPolicy设置为何值，也不会对Pod进行健康检查。

Pod的健康检查方式?

对Pod的健康检查可以通过两类探针来检查:LivenessProbe和ReadinessProbe。

LivenessProbe****探针:用于判断容器是否存活(running状态)，如果LivenessProbe探针探测到容器不 健康，则kubelet将杀掉该容器，并根据容器的重启策略做相应处理。若一个容器不包含LivenessProbe 探针，kubelet认为该容器的LivenessProbe探针返回值用于是“Success”。

ReadineeProbe****探针:用于判断容器是否启动完成(ready状态)。如果ReadinessProbe探针探测到 失败，则Pod的状态将被修改。Endpoint Controller将从Service的Endpoint中删除包含该容器所在Pod 的Eenpoint。

startupProbe****探针:启动检查机制，应用一些启动缓慢的业务，避免业务长时间启动而被上面两类探 针kill掉。

kubelet定期执行LivenessProbe探针来诊断容器的健康状态，通常有以下三种方式: ExecAction:在容器内执行一个命令，若返回码为0，则表明容器健康。 TCPSocketAction:通过容器的IP地址和端口号执行TCP检查，若能建立TCP连接，则表明容器健康。

HTTPGetAction:通过容器的IP地址、端口号及路径调用HTTP Get方法，若响应的状态码大于等于200 且小于400，则表明容器健康。

就绪探针的附加属性参数有以下几个：

initialDelaySeconds：延时秒数，即容器启动多少秒后才开始探测，不写默认容器启动就探测；

periodSeconds ：执行探测的频率（秒），默认为10秒，最低值为1；

timeoutSeconds ：超时时间，表示探测时在超时时间内必须得到响应，否则视为本次探测失败，默认为1秒，最小值为1；

failureThreshold ：连续探测失败的次数，视为本次探测失败，默认为3次，最小值为1次；

successThreshold ：连续探测成功的次数，视为本次探测成功，默认为1次，最小值为1次；

Pod****的常见调度方式? Kubernetes中，Pod通常是容器的载体，主要有如下常见调度方式:

Deployment或RC:该调度策略主要功能就是自动部署一个容器应用的多份副本，以及持续监控副 本的数量，在集群内始终维持用户指定的副本数量。 NodeSelector:定向调度，当需要手动指定将Pod调度到特定Node上，可以通过Node的标签 (Label)和Pod的nodeSelector属性相匹配。 NodeAffinity亲和性调度:亲和性调度机制极大的扩展了Pod的调度能力，目前有两种节点亲和力 表达: requiredDuringSchedulingIgnoredDuringExecution:硬规则，必须满足指定的规则，调度器才 可以调度Pod至Node上(类似nodeSelector，语法不同)。 preferredDuringSchedulingIgnoredDuringExecution:软规则，优先调度至满足的Node的节 点，但不强求，多个优先级规则还可以设置权重值。

Taints和Tolerations(污点和容忍): Taint:使Node拒绝特定Pod运行; Toleration:为Pod的属性，表示Pod能容忍(运行)标注了Taint的Node。

Kubernetes 提供了多种机制来确保 Pod 正常运行：

容器重启策略 Always deployment

节点健康检查

生命周期探测

日志记录和监控

资源配额

污点和容忍

Kubernetes 服务发现的工作原理如下：

  1. 客户端发送请求到 Kubernetes 集群中的任意一个 Pod。
  2. Pod 将请求转发到 Service 代理（kube-proxy）。
  3. kube-proxy 根据 Service 的配置规则，通过 iptables 或 IPVS 将请求转发到正确的 Pod。
  4. 请求被转发到与 Service 关联的 Pod，并由容器中的应用程序处理。
  5. Pod 将响应发送回 kube-proxy，然后 kube-proxy 将响应返回给客户端。

CoreDNS 提供以下优势，使其成为 Kubernetes 服务发现的理想选择：

  • 高性能：CoreDNS 是一个高性能的 DNS 服务器，可以快速处理 DNS 查询。
  • 可扩展性：CoreDNS 可以扩展到支持大型 Kubernetes 集群。
  • 可定制性：CoreDNS 可以使用插件进行定制以满足您的特定需求。

Kubernetes 服务发现具有以下优点：

  • 简单性：客户端无需知道 Pod 的 IP 地址或端口即可连接到它们。
  • 可扩展性：随着 Pod 的数量增加或减少，Service 将自动更新以反映这些更改。
  • 高可用性：如果 Pod 失败，Service 将继续将流量路由到其他 Pod。
  • 负载均衡：Service 可以将流量均匀地分布在 Service 后端的 Pod 之间。

Kubernetes 负载均衡是一种通过将流量分配给多个后端 Pod 来提高应用程序可用性和性能的技术。它通过使用称为 Service 的抽象和 Kube-proxy 守护进程来实现。

Service 充当一组 Pod 的前端，并提供稳定的网络端点。客户端可以使用 Service 名称和端口来连接到 Pod，而无需知道 Pod 的 IP 地址或端口。

Kube-proxy 运行在每个节点上，负责将请求转发到 Service 后端的 Pod。它使用各种负载均衡算法来选择要路由到哪个 Pod，例如随机、轮询和最少活跃最少使用 (LEAST_ACTIVE_POD_LAST_USED)。

Kubernetes 负载均衡具有以下优点：

  • 提高可用性：如果一个 Pod 失败，Kube-proxy 将继续将流量路由到其他 Pod。
  • 提高性能：通过将流量分布在多个 Pod 上，可以提高应用程序的性能。
  • 降低复杂性：客户端无需知道 Pod 的 IP 地址或端口即可连接到它们。

Ingress 是一种 Kubernetes 资源，用于将外部流量路由到集群内部的服务。它使用七层路由规则来匹配传入流量并将其路由到正确的服务。

Ingress 通常与 Ingress 控制器 一起使用，例如 Nginx 或 Traefik。Ingress 控制器将 Ingress 资源转换为负载均衡器配置，并负责将流量路由到正确的服务。

Ingress 具有以下优点：

  • 灵活性：Ingress 支持使用七层路由规则来匹配传入流量，这使您可以更灵活地控制流量路由。
  • SSL 终止：Ingress 可以终止 SSL/TLS 连接，这可以保护您的应用程序。
  • 身份验证和授权：Ingress 可以与身份验证和授权后端（如 Auth0 或 Keycloak）集成，以保护您的应用程序。
  • 外部名称：Ingress 可以为您的应用程序提供外部名称，这使您可以轻松地从外部访问它们。

何时使用服务

如果您需要一种简单的方法来暴露内部服务，则 服务 是一个不错的选择。服务易于使用且可扩展，并且它们提供高可用性和负载均衡。

何时使用 Ingress

如果您需要更灵活的路由功能，例如 SSL 终止、身份验证和授权或外部名称，则 Ingress 是一个不错的选择。Ingress 还可用于将外部流量路由到多个服务。

K8S中负载均衡的原理

service

endpoint

k8s service是如何与pod关联的​

Service 使用 Selector 来指定它要关联的 Pod。Selector 是一种基于标签的匹配机制，允许 Service 根据 Pod 的标签值来选择要关联的 Pod。

Endpoint 是 Service 的实际后端，它包含了 Service 所关联的 Pod 的 IP 地址和端口信息。Endpoint 由 kube-proxy 维护，并根据 Service 的 Selector 动态更新。

当客户端连接到 Service 时，kube-proxy 会根据 Service 的负载均衡算法将请求转发到 Endpoint 中的 Pod 之一。例如，kube-proxy 可以使用轮询、随机或最少活跃最少使用 (LEAST_ACTIVE_POD_LAST_USED) 等算法来选择转发请求的 Pod。

  1. 用户创建 Service 并定义 Selector。
  2. API Server 将 Service 信息存储到 etcd 中。
  3. kube-proxy 监视 etcd 中的 Service 信息。
  4. Pod 创建并运行后，kubelet 会将 Pod 的信息更新到 API Server。
  5. API Server 会将 Pod 的信息更新到 etcd 中。
  6. kube-proxy 监视 etcd 中的 Pod 信息，并根据 Selector 更新 Service 的 Endpoint 信息。
  7. 客户端连接到 Service 时，kube-proxy 会根据 Endpoint 信息将请求转发到 Pod 之一。

K8S的四种PORT nodePort 对外通过端口访问 port 对内 通过 server:port 访问 targetPort 经过kube-proxy转发到的端口 containerPort 转发后进入容器的端口

k8s 控制器 工作原理​

必须启动的控制器

  • EndpointController： 负责管理 Endpoints 对象，Endpoints 对象用于描述服务的端点信息。

默认启动的可选控制器

  • ReplicationController： 负责确保集群中的 Pod 数量与指定的数量相匹配。
  • NodeController： 负责管理集群中的节点，包括节点的加入、退出和更新。
  • DaemonSetController： 负责确保每个节点上都运行指定数量的 Pod。
  • JobController： 负责运行一次性作业。
  • HorizontalPodAutoscalerController： 负责根据 CPU 或内存使用率自动伸缩 Pod 的数量。
  • NamespaceController： 负责管理命名空间，包括命名空间的创建、删除和更新。
  • ServiceAccountController： 负责管理服务账号，服务账号用于为 Pod 提供身份验证和授权。
  • TokenController： 负责管理 Bootstrap Token，Bootstrap Token 用于简化集群的引导过程。

默认禁止的可选控制器

  • ReschedulerController： 负责将 Pod 重新调度到其他节点上，当 Pod 所在的节点出现故障时。
  • ValidatingAdmissionWebhookController： 负责验证 Pod、Service 等资源的有效性。

Pod 无法启动，如何查找原因？

  • 使用 kubectl describe pod [podname] -n [namespace_name] 命令意看该 Pod 的状态信息，检直容器的状态和事件信息，判断是否出现问题。

  • 使用 kubectl logs [pod_name] -n [namespace_name] 命令查看该 Pod 容器的日志信息，判断是否有错误或异常信息。

  • 使用 kubectl get events --field-selector involvedobject.name= [pod_name] -n [namespace_name] 命令查看该 Pod 相关的事件信息，判断是否 有异常事件发生，

Pod 无法连接到其他服务，如何排查？

使用 kubectl exec -it [pod_name] -n [namespace-name] -- /bin/bash 命令进入该 Pod 所在的容品，尝试使用 ping 或 telnet 等命令测试与其他 服务的网络连接情况。 使用 kubectl describe pod [podLname] -n [namespace_name] 命令检查 Pod 的 NetworkPolicy 配置，判新是否阻止了该 Pod 访问其他服务。 使用 kubectl describe service [service_name] -n [namespace-name]命令检查目标服务的配置和状态信息，判断是否存在故隨。

Pod 运行缓慢或异常，如何排查？

  • 使用 kubectl top pod [pod_name] -n [namespace_name] 命令查看该 Pod 的 CPU 和内存使用情况，判断是否存在性能瓶颈。

  • 使用 kubectl exec -it [pod_name] -n Inamespace_name] --/bin/bash 命令进入该 Pod 所在的容器，使用 top 或 htop 命令查看容器内部进程的CPU 和内存使用情况，找出可能存在的瓶颈。

  • 使用 kubectl logs [pod_name] -n [namespace_name]命令查看该 Pod 容器的日志信息，寻找可能的错误或异常信息。

Pod 无法被调度到节点上运行，如何排差

  • 使用 kubectl describe pod [pod_name] -n [namespace_name]命令童看 Pod 的调度情况，判断是否存在资源不足、调庭策略等问题。

  • 使用 kubectl get nodes 和 kubectl describe node [node-name]命令查看所有节点的资源使用情况，判断是否存在节点资源不足或故瞳的情况。

  • 使用 kubectl describe pod [podname] -n [namespace_name] 命令检查 Pod 所需的标签和注释，以及节点的标签和注释，判断是否匹配。

Pod 状态一直是 Pending， 怎么办？ 查看该 Pod 的事件信息：kubect1 describe pod [pod-name] 查看该节点资源利用率是否过高：kubectl top node 如果是调度问题，可以通过以下方式解决： 确保有足彩的节点资源满足该 Pod 调度需求

查看 Pod 中的应用程序日志：kubectl logs [pod-name] 查看该 Pod 的事件信息：kubectl describe pod [pod-name] 检查应用程序的配置文件是否正确 检查应用程序的依赖是否正常 尝试在本地使用相同的镇像运行该容强，查看是否有报谱信息，如执行 docker run ximage-names 确认该应用程序是否与 Pod 的资源限制相符

Kubernetes 集群中的 Service 不可访问，怎么办？ 检查 Service 的定义是否正确 检查 endpoint 是否正确生成 检直网络插件配置是否正确 确保防火埔配置允许 Service 对外开放

pod特点

每个pod就像一个独立的逻辑机器，k8s会为每个pod分配一个集群内部唯一的IP地址，所以每个pod都拥有自己的IP地址、主机名、进程等；

2、一个pod可以包含1个或多个容器，1个容器一般被设计成只运行1个进程，1个pod只可能运行在单个节点上，即不可能1个pod跨节点运行，pod的生命周期是短暂，也就是说pod可能随时被消亡（如节点异常，pod异常等情况）；

3、每一个pod都有一个特殊的被称为"根容器"的pause容器，也称info容器，pause容器对应的镜像属于k8s平台的一部分，除了pause容器，每个pod还包含一个或多个跑业务相关组件的应用容器；

4、一个pod中的容器共享network命名空间；

5、一个pod里的多个容器共享pod IP，这就意味着1个pod里面的多个容器的进程所占用的端口不能相同，否则在这个pod里面就会产生端口冲突；既然每个pod都有自己的IP和端口空间，那么对不同的两个pod来说就不可能存在端口冲突；

6、应该将应用程序组织到多个pod中，而每个pod只包含紧密相关的组件或进程；

7、pod是k8s中扩容、缩容的基本单位，也就是说k8s中扩容缩容是针对pod而言而非容器。

img