两个镜像怎么放到一个pod里？ 两个镜像文件合并？

kubernetes-Pod基本概念(六)

POD是Kubernetes的最小管理单位，它由一个或多个容器组成，构成集群中的基本运行单位。Kubernetes中的pod控制器管理着Pod的创建、更新和删除，确保其在集群中的稳定运行。控制器类型多样，适合不同场景，如ReplicaSet、deployment、Horizontal Pod Autoscaler（HPA）等，下面将对这些控制器进行详细解析。

Kubernetes中同主机pod连接的几种方式及性能对比如下：Veth方式：性能表现：使用podIP或通过clusterIP访问pod的性能差异不大，除非iptables规则过多导致性能下降。特点：直接利用veth接口连接pod，实现简单。Bridge方式：性能表现：与veth性能相差不大，考虑到bridge的额外功能，实际性能表现可能优于veth。

Pod 是 Kubernetes 中的核心概念，用于承载和协调容器的执行，而容器是一种轻量级的虚拟化技术。以下是关于容器和 Pod 的详细解释： Pod 的概念： Pod 是一个逻辑概念，并非实体。 它可以看作是云平台中的虚拟机，用于承载和协调容器的执行。

Pod是Kubernetes的基本计算单元，它将一个或多个容器封装在一起，并共享相同的名称空间和本地网络。Pod中的容器可以互相通信，仿佛它们在同一台机器上，同时保持一定程度的隔离。Pod被用作Kubernetes的复制单元，确保负载均衡和故障恢复。Pod应保持较小的规模，通常只包含一个主进程和紧密耦合的辅助容器。

Kubernetes——Pod控制器详解

Pod控制器是管理pod的中间层，使用Pod控制器之后，只需要告诉Pod控制器，想要多少个什么样的Pod就可以了，它会创建出满足条件的Pod并确保每一个Pod资源处于用户期望的目标状态。如果Pod资源在运行中出现故障，它会基于指定策略重新编排Pod。

Endpoints控制器负责将外部服务接入集群，使得服务能在集群内部被发现与访问。通过创建一个Service，外部服务能够被映射到集群内部的Pod上，从而实现跨网络的通信。ingress控制器是集群中对外暴露应用服务的关键组件。它将外部网络流量路由到集群内部的Pod上，提供负载均衡、SSL终止等功能。

Deployment是Kubernetes中的一种Pod控制器，它通过控制ReplicaSet间接管理Pod，提供了更高级的自动化操作和功能。以下是关于Deployment的详细解功能整合与优化：Deployment整合了ReplicaSet的所有功能，并优化了Pod的更新升级流程。它提供了更自动化的升级方式，如滚动升级和灰度发布，以满足灵活的服务编排需求。

pod里面没有bash怎么进容器

1、如果你需要在没有bash的容器中进入容器，可以考虑使用其他可用的shell，如ash、sh等。你可以通过在docker命令中使用`exec`或`run`命令来进入容器，并指定要使用的shell。此外，进入容器需要具备足够的权限。

2、使用kubectl logs命令查看Pod内容器的日志，有助于快速定位应用程序的运行问题。也可以通过kubectl get pod命令获取日志文件路径，进一步分析日志内容。直接在Pod中运行命令：如果日志信息不足以定位问题，可以尝试在Pod内部执行“sh”、“bash”或“ash”命令。进入容器内部进行详细检查，使用exit命令退出容器。

3、技巧3：检查日志。容器启动后，通过检查日志来监控应用程序运行状态。例如，通过kubectl logs命令查看日志，或者使用Get pod命令获取日志文件，有助于快速定位问题。技巧4：直接在Pod中运行命令。如果日志信息不足以定位问题，可以尝试在Pod内部执行“sh”、“bash”或“ash”命令，进入容器内部进行详细检查。

4、解决方法之一是通过设置环境变量 `TZ` 来指定时区。许多编程语言支持这一功能，部署工作负载时，为容器指定 `TZ` 环境变量，可实现实时调整程序输出时间。

5、在Pod容器上启动bash会话，查看环境变量和执行命令。关闭容器连接，输入exit。通过上述步骤，可以成功在Kubernetes集群中公开外部IP地址，并访问集群内部应用程序。了解Kubernetes组件和命令行工具，对Kubernetes集群的管理和故障排查至关重要。通过实践和理解这些概念，可以更有效地利用Kubernetes平台。

6、bash kubectl create -f pod.yaml 此外，kubectl还提供了大量的子命令和选项，以满足用户在不同场景下的需求。例如，kubectl get命令可以用于获取集群中资源的状态信息，kubectl describe命令可以用于查看资源的详细信息，kubectl logs命令可以用于查看Pod中的容器日志等。

k8s中Pod状态及问题排查方法

1、含义：调度器未能将 Pod 调度到可用节点。可能原因：节点资源不足或 Pod 依赖的资源未准备好。排查方法：检查节点资源使用情况及资源预留情况，确保集群有足够的 CPU 和其他资源。CrashLoopBackoff 状态：含义：容器在启动后立即崩溃或退出。可能原因：容器配置错误、应用程序错误、内存不足或权限问题。

2、要排查镜像拉取问题，可使用kubectl describe pod命令检查pod事件，寻找“Failed to pull image”或“ImagePullBackOff”事件，表明镜像拉取存在问题。资源不足时，使用kubectl describe node命令检查节点资源状态。检查持久卷（PVC）状态，确保其STATUS为“Bound”，表明存储供应无问题。

3、Pod驱逐 节点资源不足时，K8s驱逐内存敏感型Pod。优化资源配额和限制值，避免资源被耗尽。Pod失联 Pod处于Unknown状态，无法获取信息。检查Kubelet状态，修复节点问题。无法被删除 Pod执行删除操作后长时间处于Terminating状态。排查删除操作和集群状态，确保删除流程顺利。

4、首先，要从容器输出和状态详情入手。通过运行`docker logs $container_id`，您可以直接查看容器内的应用程序输出，以获取实时运行信息。接着，`docker inspect $container_id`可提供容器的详细状态信息，其中特别要注意“OOMKilled”信息，该信息表示容器因内存不足而被Docker自动终止。

5、Kubernetes触发OOMKilled故障的排除方法如下：检查宿主节点行为：确认资源限制：检查Pod是否有适当的资源限制设置，避免未设置资源限制导致Pod无限制地使用内存。查看宿主机日志：分析宿主机日志，确认是否由Cgroup限制触发的OOMKilled。可以使用如dMESg或journalctl等工具查看相关日志。

Pod镜像拉取策略imagePullPolicy

Pod镜像拉取策略有三种：Always、IfNotPresent、Never，其默认值为IfNotPresent。Always策略总是拉取远程仓库中的镜像。首先获取远程仓库的镜像信息，若远程镜像与本地镜像不同，则拉取远程镜像覆盖本地；若相同，则不进行拉取操作。如果远程仓库无法访问，pod运行将会失败。

创建pod-base.yaml，定义一个包含两个容器的简单Pod配置。2 镜像拉取 通过pod-imagepullpolicy.yaml文件，设置镜像拉取策略。默认值为Always，强制拉取；IfNotPresent，只当本地无镜像时拉取；Never，从本地直接使用。

默认的镜像拉取策略是IfNotPresent：在镜像已经存在的情况下，kubelet将不再去拉取镜像。如果希望强制总是拉取镜像，你可以执行以下操作之一： 设置容器的imagePullPolicy为Always。 省略imagePullPolicy，并使用：latest作为要使用的镜像的标签。 省略imagePullPolicy和要使用的镜像标签。

K8S部署Kafka界面管理工具(kafkamanager)

在K8S中部署Kafka界面管理工具的步骤如下：准备kafkamanager镜像：下载kafkamanager的压缩包。

接下来，进行kafka-manager的Pod创建。通过Kubernetes的命令行工具或配置文件，创建并确认Pod的运行状态。最后，要访问kafka-manager，可以利用K8S的NodePort功能。通过Kubernetes集群中的某个节点的指定端口，输入用户名admin和默认密码AdMin@123，即可登录并开始管理你的Kafka集群。

首先，请确保K8S、Helm、NFS、StorageClass准备就绪。进入配置阶段，找到`configurationOverrides`，移除注释并确认网络访问设置，以便Kafka能从外部访问。接着，配置数据卷，调整`persistence`大小，指明已准备的`storageclass`名称，用于存储Kafka数据。设置zookeeper数据卷，确保Kafka启动依赖于zookeeper。

在构建DevOps CI/CD流程时，遵循以下关键点： **标准pipelien script**：确保编写符合行业标准的pipelien script。 **k8s配置**：正确配置Service以实现应用间通信，使用NodePort类型。 **微服务部署**：确保k8s ingress配置支持HTTPS，自动将HTTP跳转至https。

Kafka则手动在Node-01上通过docker-comPOSe启动，以补救集群外的部署问题。整个故障处理过程持续了约6个小时，尽管是在测试集群中，但这也足以反映出线上环境下的问题处理难度。