k8s集群多容器Pod和资源共享

k8s集群多容器Pod和资源共享

k8s的最小可调度单元

如果选择容器作为k8s的最小可调度单元，那么容器的健康检测，多个耦合性强的容器的调度，多容器之间的资源共享就比较麻烦了。而使用Pod这个虚拟的最小可调度单元，可以完美解决如上问题。具体对比如下：

Pod 多container共享网络、存储 一个Pod可以运行耦合性强的多个container，而不必把多应用全塞到一个container中 方便监控，我们可以对Pod中的多个容器单独设置不同的健康检查，记录日志及分析 不用担心单个容器内多进程，其某个进程崩溃导致整个容器挂掉的情况 Container： 容器设计理念是一个容器只运行一个主进程（其产生的子进程不算） 单个容器，与其它container是”完全隔离”的 常规情况下，无法与其它容器共享网络、存储。只能通过expose的端口进行相互访问

Pod中容器的类型

临时容器ephemeralcontainers

临时容器处于早期的 alpha 阶段，不适用于生产环境集群。一种特殊的容器，该容器在现有 Pod 中临时运行，以便完成用户发起的操作，例如故障排查。 你会使用临时容器来检查服务，而不是用它来构建应用程序。

目前，本人在k8s 1.18环境上根据官方文档没有成功运行起来此容器。具体参考文档见：容器是一种特殊容器，在 Pod 内的应用容器启动之前运行。Init 容器可以包括一些应用镜像中不存在的实用工具和安装脚本。每个 Pod 中可以包含多个容器， 应用运行在这些容器里面，同时 Pod 也可以有一个或多个先于应用容器启动的 Init 容器。Init 容器不支持 lifecycle、livenessProbe、readinessProbe 和 startupProbe， 因为它们必须在 Pod 就绪之前运行完成。如果为一个 Pod 指定了多个 Init 容器，这些容器会按顺序逐个运行。 每个 Init 容器必须运行成功，下一个才能够运行。当所有的 Init 容器运行完成时， Kubernetes 才会为 Pod 初始化应用容器并像平常一样运行。

使用场景

Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。 例如，没有必要仅为了在安装过程中使用类似 sed、awk、python 或 dig 这样的工具而去 FROM 一个镜像来生成一个新的镜像。Init 容器可以安全地运行这些工具，避免这些工具导致应用镜像的安全性降低。 应用镜像的创建者和部署者可以各自独立工作，而没有必要联合构建一个单独的应用镜像。 Init 容器能以不同于 Pod 内应用容器的文件系统视图运行。因此，Init 容器可以访问 应用容器不能访问的 Secret 的权限。 由于 Init 容器必须在应用容器启动之前运行完成，因此 Init 容器 提供了一种机制来阻塞或延迟应用容器的启动，直到满足了一组先决条件。 一旦前置条件满足，Pod 内的所有的应用容器会并行启动。

sidecar

在一个Pod中，某个Container运行主要业务的同时，需要另一个Container协同 ——这是一个常见的业务场景，这个协同Container通常称为Sidecar。 主要的Container在运行时，Sidecar需要已经就绪；而当主要的Container停止后，Sidecar也需要停止。

一般有紧密联系的容器会在同一个Pod中运行。目前，最新k8s官方的最新稳定版本还没有原生支持sidecar功能。

使用场景

日志代理/转发，例如fluentd 代理，比如 Docker Ambassador 探活：检查某些组件是不是正常工作 其他辅助性的工作，比如拷贝文件，下载文件等；

应用容器

Pod中的主容器，主要来运行服务的主要业务逻辑

Pod中的容器特点

启动顺序

Pod 内容器的启动顺序按照：初始化容器->Sidecar 容器->业务容器

资源共享

默认共享网络，MNT卷存储，IPC，UTS 通过配置ShareProcessNamespace实现共享进程namespacehttps://v1-18.docs.kubernetes.io/zh/docs/tasks/configure-pod-container/share-process-namespace/

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。