Kubernetes 几大概念的作用

已于 2024-03-11 08:47:28 修改
阅读量1k 收藏 20
点赞数 20
分类专栏： k8s 文章标签： kubernetes 容器 云原生
于 2024-03-08 20:30:08 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_52943021/article/details/136571318
版权

更详细的组件通信流程

Kubernetes 主要由以下几个核心组件组成：

1. etcd 保存了整个集群的状态；
2. API Server 提供了资源操作的唯一入口，并提供认证，授权，访问控制，API 注册和发现等机制；
3. Controller Manager 负责维护集群的状态，比如故障检查，自动扩展，滚动更新等；
4. Scheduler 负责资源的调度，按照预定的调度策略将 Pod 调度到相应的机器上；
5. Kubelet 负责维护容器的生命周期，同时也负责 Volume(CVI) 和网络(CNI)的管理；
6. Container Runtime 负责镜像管理以及 Pod 和容器的真正运行(CRI);
7. Kube-proxy 负责为 Service 提供 cluster 内部的服务发现和负载均衡；

理解 k8s 核心几块资源

k8s 默认的组件很多，每一个 Pod 控制器(工作负载)，以及网络插件组件，没法一个个的去读，前期也都被封装在了底层，也关心不到。

因此，只聊我们能用到的几个组件，如 Pod 创建，需要用到几个组件，需要背一背，以及查看对应的资源，在机器上的容器进程信息。

后续不断的加入新知识，再去理解对应的组件，即可循序渐进的理解 k8s 的复杂知识。

当然，建议也是，平日里看 k8s 官网文档，以及如 k8s 权威指南 v5版本书籍，去阅读理论知识，扩充自己的理论知识，更合适。v1-v5

上课，为了更快速的，理解，操作，k8s 组件该如何玩。

1) .快速学会玩法
2).再去看资料理解本质原理

4.node 节点组成

1. CRI
容器运行时 | Kubernetes
容器运行时，这是 k8s 组件之一，负责容器运行。
默认情况 k8s 使用 CRI 容器运行时接口，和你部署的容器交互。
如果同时检测你部署了 docker engine,containerd 两款容器，优先会选用 docker
2. docker engine
https://kubernetes.io/zh-cn/docs/setup/production-environment/container-runtime/#docker
负责 Node 上容器的管理工作，创建 docker 容器实例。
3. kubelet
安装在 Node 节点上的代理程序，用来管理 Pod, 容器，镜像，Volume等。
4. kube-proxy
安装在 Node 上的网络代理程序，提供网络代理，负载均衡，和 Service 通讯

5. k8s 重要资源(学会用 k8s 就靠这个)

不属于k8s的资源，属于重要概念

一. Node

(不属于k8s的资源，属于重要概念)-ECS机器 k8s 运行的一个环境

Pod等资源，属于 k8s 安装好后的，集群内的一个资源信息。

Node 是 Pod 真正运行的主机，可以是物理机，也可以是虚拟机。

为了管理 Pod,每个 Node 节点上至少要运行 container runtime(比如 docker 或 rkt), kuberlet 和 kube-proxy 服务。

1. k8s 工作节点,node,运行环境可以是：：：vmware 创建的一个虚拟机，k8s-node-11 k8s-node-12

2. node 上具体运行啥呢？运行容器，k8s 部署的应用，都是跑在容器里，node 上还得安装 docker,

3.初始化，运行工作节点，或者主节点，背后的逻辑：

a. 下载 k8s 自身的一些组件的镜像。
b. 运行镜像，创建对应的容器，到对应的目标机器上(k8s-master,k8s-node-11,k8s-node-12)

这就是我们主要部署的架构逻辑

k8s-node 的部署逻辑

# POD(10.10.10.3)	根容器	创建一个隔绝的名称空间	Pause/Infra
Volume   容器1	容器2   容器3
k8s-node-12(阿里云ECS)  先安装好 docker,kubelet组件

# POD(10.10.10.2)	根容器	创建一个隔绝的名称空间 Pause/Infra
Volume	 容器1	容器2
k8s-node-11(阿里云ECS)  先安装好 docker,kubelet组件

# POD(10.10.10.4)	根容器	创建一个隔绝的名称空间 Pause/Infra
Volume	 容器1	
k8s-node-13(阿里云ECS)  先安装好 docker,kubelet组件

# 共享资源  kubelet  Docker  kube-proxy
kubelet 和 master 的 api-server 通信  决定容器创建的信息获取，信息更新。
kube-proxy 在 k8s 里，容器要对外提供网络访问，以及 ip 地址设置等。底层基于 iptables 的规则转发数据包，修改数据包。

二 container

Container(容器) 是一种便携式，轻量级的操作系统级虚拟化技术。

它使用 namespace 隔离不同的软件运行环境，并通过镜像自包含软件的运行环境，从而使得容器可以很方便的在任何地方运行。

由于容器体积小且启动快，因此可以在每个容器镜像中打包一个应用程序，这种一对一的应用镜像关系拥有很多好处，使用容器，不需要与外部的基础架构环境绑定，因为每一个应用程序都不需要外部依赖，更不需要与外部的基础架构环境依赖，完美解决了从开发到生产环境的一致性问题。

容器同样比虚拟机更加透明，这有助于监测和管理。尤其是容器进程的生命周期由基础设施管理，而不是被进程管理隐藏在容器内部，最后，每个应用程序用容器封装，管理容器部署就等同于管理应用程序部署。

其他容器的优点还包括：

  • 敏捷的应用程序创建和部署：与虚拟机镜像相比，容器镜像更易用，更高效。
  • 持续开发，集成和部署：提供可靠与频繁的容器镜像构建，部署和快速简便的回滚(镜像是不可变的)。
  • 开发与运维的关注分离：在构建/发布时及创建容器镜像，从而将应用与基础架构分离。
  • 开发，测试与生产环境的一致性：在笔记本电脑上运行和云中一样。
  • 可观测：不仅显示操作系统的信息和度量，还显示应用自身的信息和度量。
  • 云和操作系统的分发可移植性：可运行在 Ubuntu,RHEL,CoreOS,物理机，GKE以及其他任何地方。
  • 以应用为中心的管理：从传统的硬件上部署操作系统提升到操作系统中部署应用程序。
  • 松耦合，分布式，弹性伸缩，微服务：应用程序被分成更小，更独立的模块，并可以动态管理和部署-而不是运行在专用设备上的大型单体程序。
  • 资源隔离：可预测的应用程序性能。
  • 资源利用：高效率和高密度。
1. Pod
  • Kubernetes 使用 Pod 来管理容器，每个 Pod 可以包含一个或多个紧密关联的容器。
  • Pod 是一组紧密关联的容器集合，它们共享 进程间通信 和 Network namespace, 是 Kubernetes 调度的基本单位。
  • Pod 内的多个容器共享网络和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。
  • Pod 的设计理念是支持多个容器在一个 Pod 中共享网络地址和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。
  • Pod 是 k8s 集群中所有业务类型的基础，可以看作运行在 k8s 集群中的小机器人，不同类型的业务就需要不同类型的小机器人去执行。
  • 目前 k8s 中的业务主要可以分为长期伺服型(long-running), 批处理型 (batch), 节点后台支撑型(node-daemon) 和有状态应用型(stateful application)。
  • 分别对应的小机器人控制器为 Deployment, Job, DaemonSet 和 StatefulSet.
1. Pod 是在 k8s 集群中运行部署应用或服务的最小单元，它是可以支持多容器的，
2. Pod 的 IP 是随机变化的，删除 Pod ，IP 变化
3. Pod 内部有一个根容器
4. 一个 Pod 内可以有一个，多个容器 比如 nginx pod 容器组，mysql pod 容器组 等
5. 一个 Pod 内的所有容器，共享根容器的网络名称空间，文件系统，进程资源
6. 一个 Pod 内的容器网络地址，由根容器提供。

比如：pod 部署的多种形态
Pod1 	10.10.10.1   Pod1 这个容器组可以包含一个容器 或者多个容器 根据你的需求而定

Pod2	10.10.10.2	 无状态	无需数据卷
可以跑一个 nginx-pod  nginx1.14  nginx-pod 容器也会有自己的 pod id  这是						一个无状态的 nginx-pod 容器

Pod3	10.10.10.3	持久化容器内的数据，以卷的形式，放在宿主机上(k8s-node节点了)
可以涉及存储  把它的数据以卷的形式 映射 到宿主机上 
nginx-pod   /var/log/nginx/ 涉及存储卷 卷的数据依然映射到宿主机上 /linux0224/nginx/logs

Pod4 	10.10.10.4	一个 Pod4 容器组中 运行多个容器共享一个数据卷

Pod4 	10.10.10.5	IP address	volume	containerized app

# Pod 可以是虚拟机 k8s-node-12 也可以是物理机，或者阿里云服务器
1.下载安装(yum install/rpm -ivh) docker 容器引擎
2. 初始化时，自动生成 kubelet 与 kube-proxy 组件
3.Pod 你部署的一个业务容器组，一个，多个容器，都被 pod 管理了


# Pod 部署的多种形态,区分，有无数据要持久化，以及容器有无数据共享
1. 无状态	无需数据卷
2. 持久化容器内的数据，以卷的形式，放在宿主机上(k8s-node节点了)
3. 形态3，一个 Pod 下的多个容器共享一个数据卷 比如 一个 pod 下，运行2个 wordpress 容器，的静态数据，读取 NFS 

# Pod 就想豌豆一样，里面的豆子就像是一个个容器，共享网络，存储  一个个豆子容器被一个豌豆荚的 pod 管理
即碗豆子容器被管理豌豆荚容器管理着  都来自于豌豆荚设置的一个隔离环境

创建 Pod 请求走向

  • API Server 负责 etcd 存储的所有操作，且只有 API Server 才直接操作 etcd 集群
  • API Server 对内 (集群中的其他组件) 和对外 (用户) 提供统一的 REST API,其他组件均通过 API Server 进行通信
    • Controller Manager, Scheduler, Kube-proxy 和 Kubelet 等均通过 API Server watch API 监测资源变化情况，并对资源作相应的操作。
    • 所有需要更新资源状态的操作均通过 API Server 的 REST API 进行
  • API Server 也会直接调用 Kubelet API (如 logs,exec,attach等)，默认不校验 Kubelet 证书，但可以通过 --kubelet-certificate-authority 开启(而 GKE 通过 SSH 隧道保护他们之间的通信)

Pod 是如何被创建的

1.运维执行创建 Pod 请求(一个 yaml 文件，记录了业务应用的名字，镜像，如何部署等信息)，提交给 api-server
2.api-server 接收请求后将资源清单的信息写入 etcd
3.etcd 存储好信息后反馈 api-server
4.api-server 告知 scheduler 事件信息，scheduler 发现有一个新 pod ,但是没有绑定 node,通过资源清单信息以及算法选择合适的 node
5.将要 pod 和 node 绑定的信息告诉 api-server
6.api-server 将调度结果写入 etcd
7.etcd 更新好 pod 的信息后继续反馈 api-server 
8.此时 kubelet 组件(目标 node) watch 到有一个新 pod 被分配过来了，获取 pod 信息，根据 pod 描述内容创建对应容器
9.kubelet 反馈 pod 创建结果(docker 信息) 给 api-server,且写入 etcd
10. 最终结束一个 pod 的完整创建流程

架构组件的认识

1.系统各个组件分工明确(APIServer 是所有请求入口，CM 是控制中枢，Scheduler 主管调度，而 Kubelet负责运行)，配合流畅，整个运行机制一气呵成。
2. 除了配置管理和持久化组件 ETCD,其他组件并不保存数据，意味 除ETCD外 其他组件都是无状态的。
3. 因此，从架构设计上对 kubernetes 系统高可用部署提供了支撑。
4. 同时因为组件无 状态，组件的升级，重启，故障等并不影响集群最终状态，只要组件恢复后就可以从中所处继续运行。
5. 各个组件和 kube-apiserver 之间的数据推送都是通过 list-watch 机制来实现。

容器的运行状态

创建 pod 是为了运行容器，容器有运行状态，表现为创建的成功，失败，问题。
https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/

kubenetes 会跟踪 Pod 中每个容器的状态，就像它跟踪 Pod 总体上的阶段一样，你可以使用容器生命周期回调 来在容器

一旦调度器将 pod 分配给某个节点，kubelet 就通过 容器运行时 开始为 pod 创建容器，容器的状态有三种，waiting

要检查 Pod 中容器的状态，你可以使用 kubectl describle pod <pod 名称> 其输出中包含 Pod 中每个容器的状态。

每种状态都有特定的意义：

Waiting (等待)
如果容器并不在 Running 或者 Terminated 状态之一，他就处在 Waiting 状态，处于 Waiting 状态的容器仍在运行它。。。

Running (运行中)
Running 状态表明容器正在执行状态并且没有问题发生，如果配置了 postStart 回调，那么该回调已经执行且已完成，如果。。。

Terminated(已终止)
处于 Terminated 状态的容器已经开始执行并且或者正常结束或者或者因为某些原因失败，如果你使用 kubectl 来查询包含 Termnated 

如果容器配置了 preStop 回调，则该回调会在容器进入 Terminated 状态之前执行

2. Label

Label 也是面试发问的点
Label 是识别 Kubenetes 对象的标签，以 key/value 的方式附加到对象上 (key最长不能超过63字节，value可以为空，也可以是不超过253字节的字符串)。
Label 不提供唯一性，并且实际上经常是很多对象 (Pods) 都使用相同的 label 来标志具体的应用。
label 定义好后其他对象可以使用 Label Selector 来选择一组相同 label 对象（比如 ReplicaSet 和 用 label 来选择一组 Pod)，Label Selector 支持以下几种方式：
  • 等式，如 app=nginx 和 env!=production
  • 集合，如 env in (production, qa)
  • 多个 label (它们之间是 AND 关系)，如 app=nginx,env=test
1. label 就像身份证标签一样，用于标识 k8s 的对象
2. 我们传统的机器上应用查找，那是基于 ip:port,但是在 k8s 里，更多匹配关系，都是通过 label 来查找

3. Namespace

k8s 里可以基于 namespace,管理不同环境下的资源，也是一个重要资源，形成逻辑上的不同的项目组。
Namespace 是对一组资源和对象的抽象集合，比如可以用来将系统内部的对象划分为不同的项目组成用户组。

常见的 pods, services,replication controllers 和 deployment 等都是属于某一个 namespace 的 (默认是 default)

而 node , persistentVolumes 等 不属于任何 namespace.

4.Controller

k8s 控制器种类有很多，用来在不同的场景，如何更好的管理 Pod
1. 上面于超老师也说了，POD可以理解为 k8s 里面的干活的小机器人，不同的类型都要用不同的机器人去执行，
2. 控制这些小机器人的控制器，就主要分为
​

Replication Controller        简称         RC

  • 也叫 RC 控制器，副本控制器，控制 pod 的副本数；
  • RC 是 k8s 集群中最早的保证 Pod 高可用的 API 对象；
  • 通过监控运行中的 Pod 来保证集群中运行指定数目的 Pod 副本；
  • 指定的数目可以是多个也可以是1个；
    • 当少于指定数目， RC 就会启动运行新的 Pod 副本；
    • 多于指定数目，RC 就会杀死多余的 Pod 副本；
    • 严格根据你定义的数量，确保POD数量
即使在指定数目为1的情况下，通过 RC 运行 Pod 也比直接运行 Pod 更明智，因为 RC 也可以发挥它高可用的能力，保证永远有1个 Pod 在运行，(pod 挂了，容器就挂了，机器人也就挂了，有控制在，就不怕应用挂了)
RC 是 k8s 较早期的技术概念，比如控制小机器人提供高可用的 Web 服务，启动如3个 pod 副本，也就是3套应用后端。

Replica Set        简称    RS

RS 是 RC 控制器的下一代，也提供副本数，确保 pod (容器的高可用) ，
RS 控制器一般不会直接用，而是结合另一种控制器 (Deployment) 以及更多参数使用。

Deployment

部署控制器，主要用 k8s 部署应用就是靠这个。
Deployment 表示用户对 k8s 集群的一次更新操作。
部署是一个比 RS 应用模式更广泛的 API 对象，可以是创建一个新的服务，更新一个新的服务，也可以是滚动升级一个服务。
滚动升级一个服务，实际是创建一个新的 RS,然后逐渐将新 RS 中副本数增加到理想状态，将旧 RS 中的副本数减小到0的复合操作；
这样一个复合操作用一个 RS 是不太好描述的，所以用一个更通用的 Deployment 来描述。
以 k8s 的 发展方向，未来对所有长期服务型的业务的管理，都会通过 Deployment 来管理。
(LNMP就是典型代表，需要高可用，负载均衡的应用集群，积极更新多个后端，这些所有的)
长期服务型的应用特点在于业务应用提供访问，有的 Node 上 可能有改 pod ,有的 Node 可以没有

DaemonSet

  • 后台支撑服务集控制器的功能在于关注 k8s 中的 Node (物理机，虚拟机)
  • 能保证每个节点上都有一个此类的 Pod 在运行
    • 这种特性，就很实用用于部署如监控软件的 agenl,采集每一个目标 Node 的资源数据，
  • 节点可以所有集群中的机器，也可能是基于 NodeSelector选定的部分节点。
  • DaemonSet 主要用于
    • 日志采集
    • 监控采集
    • 存储
    • 这几类服务的运行

StatefulSet

有状态服务集在 k8s 1.3 版本后发布，之前于超老师说过，nginx 此类应用一般是无状态的，可以随意创建，删除；
还有一种就是有状态(stateful)的应用。
RC,RS,deployment 主要提供无状态服务的部署， pod 的名字也都是随机生成的，一个 pod 挂了 ，重建一个就好，pod 的。。。

而 stateful 用来控制有状态的，每一个 pod 的名字是预先定义好的，不能更改；
无状态的 pod 一般不会挂载存储，保证 pod 共享状态即可，可以随意创建，删除;
有状态的 pod ,pod 都会单独挂载一个存储，如果 pod 出了问题，其他节点要重新创建 pod,并且获取原有 pod 的存储信息，继续。。。

这个特性明显就是提供给数据库使用。

5. Service

上述讲的 pod 控制器，是实现了 Pod,容器被创建在目标 Node 机器，以及确保了数量，副本数；
但是目前还没说，这些 Pod 该如何访问？ 分散在不同的机器，通过什么 ip 去访问？

Node 节点主要就是 kubelet 和 api-server 通信，Pod 管理，也就是 docker 管理以及 kube-proxy 实现网络代理功能。
pause-amd64 是 kubernetes 基础设施的一部分，kubernetes 管理的所有 Pod 里，pause-amd64容器是第一个启动的，用于实现 pause container 作为 Pod 里其他所在 container 的 parent container,主要 有两个职责：
1. 是 Pod 里其他容器共享 linux namespace 的基础。
2. 扮演 PID 1 的角色，负责处理僵尸进程。

Kubernetes 的官网解释:

https://github.com/kubernetes/kubernetes/tree/master/build/pause

参考资料

https://jimmysong.io/kubernetes-handbook/concepts/pause-container.html
https://lib.jimmysong.io/

Pause 容器

Pause 容器，又叫 Infra (基础网)容器，本文将探究该容器的作用与原理。
我们知道在 kubelet 的配置中有这样一个参数：
KUBELET_POD_INFRA_CONTAINER=--pod-infra-container-image=registry.access.redhat.com/rhel7/pod-infrastructure:latest
上面是 openshift 中的配置参数，kubernetes 中默认的配置参数是：
KUBELET_POD_INFRA_CONTAINER=--pod-infra-container-image=gcr.io/google_containers/pause-amd64:3.0

Pause 容器，是可以自己来定义，官方使用的 gcr.io/google_containers/pause-amd64:3.0 容器的代码见 Github，使用 C 语言编写。

Pause 容器特点

  • 镜像非常小，目前在 700KB 左右
  • 永远处于 Pause (暂停) 状态

Pause 容器背景

像 Pod 这样一个东西，本身是一个逻辑概念。那在机器上，它究竟是怎么实现的呢？这就是我们要解释的一个问题。
既然说 Pod 要解决这个问题，核心就在于如何让一个 Pod 里的多个容器之间最高效的共享某些资源和数据。
因为容器之间原本是被 Linux Namespace 和 cgroups 隔开的，所以现在实际要解决的是怎么去打破这个隔离，然后共享某些事情和某些信息。这就是 Pod 的设计要解决的核心问题所在。
所以说具体的解法分为两个部分：网络和存储。
Pause 容器就是为解决 Pod 中的网络问题而生的。

Pause 容器实现

Pod 里的多个容器怎么去共享网络？下面是个例子：
比如说现在有一个 Pod，其中包含了一个容器 A 和一个容器 B，它们两个就要共享 Network Namespace。在 Kubernetes 里的解法是这样的：它会在每个 Pod 里，额外起一个 Infra container 小容器来共享整个 Pod 的 Network Namespace。
Infra container 是一个非常小的镜像，大概 700KB 左右，是一个 C 语言写的、永远处于 “暂停” 状态的容器。由于有了这样一个 Infra container 之后，其他所有容器都会通过 Join Namespace 的方式加入到 Infra container 的 Network Namespace 中。
所以说一个 Pod 里面的所有容器，它们看到的网络视图是完全一样的。即：它们看到的网络设备、IP 地址、Mac 地址等等，跟网络相关的信息，其实全是一份，这一份都来自于 Pod 第一次创建的这个 Infra container。这就是 Pod 解决网络共享的一个解法。
在 Pod 里面，一定有一个 IP 地址，是这个 Pod 的 Network Namespace 对应的地址，也是这个 Infra container 的 IP 地址。所以大家看到的都是一份，而其他所有网络资源，都是一个 Pod 一份，并且被 Pod 中的所有容器共享。这就是 Pod 的网络实现方式。
由于需要有一个相当于说中间的容器存在，所以整个 Pod 里面，必然是 Infra container 第一个启动。并且整个 Pod 的生命周期是等同于 Infra container 的生命周期的，与容器 A 和 B 是无关的。这也是为什么在 Kubernetes 里面，它是允许去单独更新 Pod 里的某一个镜像的，即：做这个操作，整个 Pod 不会重建，也不会重启，这是非常重要的一个设计。

Pause 容器的作用

我们检查 node 节点的时候会发现每个 node 上都运行了很多的 pause 容器，例如如下。
$ docker ps
CONTAINER ID        IMAGE                                                                                                                    COMMAND                  CREATED             STATUS              PORTS               NAMES
2c7d50f1a7be        docker.io/jimmysong/heapster-grafana-amd64@sha256:d663759b3de86cf62e64a43b021f133c383e8f7b0dc2bdd78115bc95db371c9a       "/run.sh"                3 hours ago         Up 3 hours                              k8s_grafana_monitoring-influxdb-grafana-v4-5697c6b59-76zqs_kube-system_5788a3c5-29c0-11e8-9e88-525400005732_0
5df93dea877a        docker.io/jimmysong/heapster-influxdb-amd64@sha256:a217008b68cb49e8f038c4eeb6029261f02adca81d8eae8c5c01d030361274b8      "influxd --config ..."   3 hours ago         Up 3 hours                              k8s_influxdb_monitoring-influxdb-grafana-v4-5697c6b59-76zqs_kube-system_5788a3c5-29c0-11e8-9e88-525400005732_0
9cec6c0ef583        jimmysong/pause-amd64:3.0                                                                                                "/pause"                 3 hours ago         Up 3 hours                              k8s_POD_monitoring-influxdb-grafana-v4-5697c6b59-76zqs_kube-system_5788a3c5-29c0-11e8-9e88-525400005732_0
54d06e30a4c7        docker.io/jimmysong/kubernetes-dashboard-amd64@sha256:668710d034c4209f8fa9a342db6d8be72b6cb5f1f3f696cee2379b8512330be4   "/dashboard --inse..."   3 hours ago         Up 3 hours                              k8s_kubernetes-dashboard_kubernetes-dashboard-65486f5fdf-lshl7_kube-system_27c414a1-29c0-11e8-9e88-525400005732_0
5a5ef33b0d58        jimmysong/pause-amd64:3.0
kubernetes 中的 pause 容器主要为每个业务容器提供以下功能：
  • 在 pod 中担任 Linux 命名空间共享的基础；
  • 启用 pid 命名空间，开启 init 进程。

我们首先在节点上运行一个 pause 容器

docker run -d --name pause -p 8880:80 --ipc=shareable jimmysong/pause-amd64:3.0
然后再运行一个 nginx 容器，nginx 将为 localhost:2368 创建一个代理。
$ cat <<EOF >> nginx.conf
error_log stderr;
events { worker_connections  1024; }
http {
    access_log /dev/stdout combined;
    server {
        listen 80 default_server;
        server_name example.com www.example.com;
        location / {
            proxy_pass http://127.0.0.1:2368;
        }
    }
}
EOF
$ docker run -d --name nginx -v `pwd`/nginx.conf:/etc/nginx/nginx.conf --net=container:pause --ipc=container:pause --pid=container:pause nginx
然后再为 ghost 创建一个应用容器，这是一款博客软件。
$ docker run -d --name ghost --net=container:pause --ipc=container:pause --pid=container:pause ghost
现在访问 http://localhost:8880/ 就可以看到 ghost 博客的界面了。
解析
pause 容器将内部的 80 端口映射到宿主机的 8880 端口，pause 容器在宿主机上设置好了网络 namespace 后，nginx 容器加入到该网络 namespace 中，我们看到 nginx 容器启动的时候指定了 --net=container:pause，ghost 容器同样加入到了该网络 namespace 中，这样三个容器就共享了网络，互相之间就可以使用 localhost 直接通信，--ipc=container:pause --pid=container:pause 就是三个容器处于同一个 namespace 中，init 进程为 pause，这时我们进入到 ghost 容器中查看进程情况。
# ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0   1024     4 ?        Ss   13:49   0:00 /pause
root         5  0.0  0.1  32432  5736 ?        Ss   13:51   0:00 nginx: master p
systemd+     9  0.0  0.0  32980  3304 ?        S    13:51   0:00 nginx: worker p
node        10  0.3  2.0 1254200 83788 ?       Ssl  13:53   0:03 node current/in
root        79  0.1  0.0   4336   812 pts/0    Ss   14:09   0:00 sh
root        87  0.0  0.0  17500  2080 pts/0    R+   14:10   0:00 ps aux
在 ghost 容器中同时可以看到 pause 和 nginx 容器的进程，并且 pause 容器的 PID 是 1。而在 Kubernetes 中容器的 PID=1 的进程即为容器本身的业务进程。

哆啦A梦1588
关注
  • 20
    点赞
  • 踩
  • 20
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
专栏目录
kubernetes网络分析
11-07
在深入探讨 Kubernetes 网络模型之前，先要理解 Kubernetes（K8S...Kubernetes 网络模型的复杂性和灵活性使其成为大规模容器化应用的理想选择。理解并掌握这些网络概念对于有效地管理和优化 Kubernetes 集群至关重要。
Kubernetes集群实战——Kubernetes集群部署、故障模拟及处理、pod管理
weixin_45792518的博客
06-20 848
0.Borg概述 Borg是谷歌内部的大规模集群管理系统，负责对谷歌内部很多核心服务的调度和管理，Borg的目的是让用户能够不必操心资源管理问题，让他们专注于自己的核心业务，并且做到跨多个数据中心的资源利用率最大化 borg主要由borgmaster 1.Kubernetes简介 在Docker 作为高级容器引擎快速发展的同时,在Google内部,容器技术已经应 用了很多年,Borg系统运行管理着成千上万的容器应用。 Kubernetes项目来源于Borg,可以说是集结了Borg设计思想的精华,并且吸收了
Kubernetes第一天之架构及概念理解篇
企业实战系列集 ●●● https://ximenjianxue.blog.csdn.net
08-18 1568
Kubernetes介绍 Kubernetes（k8s）最初源于谷歌内部的Borg（Borg是谷歌内部的大规模集群管理系统，负责对谷歌内部很多核心服务的调度和管理），是一个轻便的和可扩展的开源平台，提供了面向应用的容器集群部署和管理系统，用于管理容器化应用和服务，进行应用的自动化部署和扩缩容，Kubernetes(k8s)是一个自动化容器操作的开源平台。Kubernetes 的目标旨在：消除编排物理/虚拟计算，网络和存储基础设施的负担，并使应用程序运营商和开发人员完全将重点放在以容器为中心的原语上进行自助运
好文推荐 | etcd 问题、调优、监控
朱小厮的博客
05-27 4207
点击上方“朱小厮的博客”，选择“设为星标”后台回复"加群"，加入新技术来源：www.xuyasong.com/?p=1983etcd 原理解析：读《etcd 技术内幕》这...
ETCD：从应用场景到实现原理的全方位解读
热门推荐
s1070的专栏
07-11 1万+
随着CoreOS和Kubernetes等项目在开源社区日益火热，它们项目中都用到的etcd组件作为一个高可用、强一致性的服务发现存储仓库，渐渐为开发人员所关注。在云计算时代，如何让服务快速透明地接入到计算集群中，如何让共享配置信息快速被集群中的所有机器发现，更为重要的是，如何构建这样一套高可用、安全、易于部署以及响应快速的服务集群，已经成为了迫切需要解决的问题。etcd为解决这类问题带来了福音，本
《k8s权威指南》读书笔记
guoshaoliang789的专栏
05-13 267
抽空读完了《k8s权威指南》一书，对k8s的总算有了较为系统的认知。 好记忆不如多写字，以下是读书笔记 第一章 k8s入门 k8s是什么： 一个开源的容器集群管理平台，可提供容器集群的自动部署，扩缩容，维护等功能。分为管理节点Master和工作节点Node 核心组件： etcd保存了整个集群的状态； apiserver提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制； controller manager负责维护集群的状态，比如故障检测、自动扩展、滚动更新等； s
Kubernetes 1.20.0 image 离线安装包
06-02
Kubernetes的核心概念包括节点(Node)、工作负载(Workloads)、服务(Services)、存储(Storage)和网络(Networking)等。在1.20.0版本中，我们关注以下几个关键知识点： 1. **新特性与改进**：每个新版本都带来了一些新...
Kubernetes学习笔记
11-05
在Kubernetes（简称k8s）的学习过程中，控制器是理解整个集群运作机制的关键概念。控制器在Kubernetes生态系统中扮演着协调者和管理者的重要角色，它们确保集群中的各种对象，如Pods、Deployments、Services等，始终...
kubernetes笔记.rar
05-30
Kubernetes，又被称为K8s，是Google开源的一款容器编排系统，现已成为云原生计算基金会...2018年11月的更新意味着它可能包含了当时最新的特性和最佳实践，对于理解Kubernetes在云计算领域的地位和作用具有重要价值。
kubernetes实战指南源码.zip
02-10
Kubernetes是一个开源容器编排系统，它允许用户在大规模集群中管理和运行容器化应用。 在深入探讨yaml源码之前，我们先理解Kubernetes的核心概念。Kubernetes由多个组件构成，如etcd（持久化数据存储）、apiserver...
K8s-控制器
l6xy6的博客
07-23 513
2.编辑RS控制器：kubectl -n lxy edit rs nginx-rs (有些是无法修改)获取当前rs资源的Yaml: kubectl -n lxy get rs nginx-rs -oyaml。1.对yaml修改副本数，修改资源配置：kubectl apply -f rs-nginx.yml。2.控制器可以帮助用户监控，并保证节点上运行定义好的pod副本数。3.pod超过或低于用户期望，控制器会创建、删除pod副本数量。作用：1.pod类型资源删除，不会重建。
[k8s源码]9.workqueue
最新发布
weixin_45396500的博客
07-24 588
client-go 是一个库，提供了与 Kubernetes API 服务器交互的基础设施。它提供了诸如 Informer、Lister、ClientSet 等工具，用于监听、缓存和操作 Kubernetes 资源。而自定义控制器则利用这些工具来实现特定的业务逻辑和自动化任务。业务逻辑实现：client-go 不包含特定的业务逻辑。自定义控制器允许实现特定于您的应用程序或需求的逻辑。扩展 Kubernetes：通过自定义控制器，可以扩展 Kubernetes 的功能，处理自定义资源或实现特定的自动化任务。
k8s v1.30 完整安装过程及CNI安装过程总结
从善若水的博客
07-21 621
k8s v1.30 完整安装过程及CNI安装过程总结
k8s+containerd（kvm版）
weixin_62799021的博客
07-22 699
k8s（Kubernetes）是由Gogle开源的容器编排引擎，可以用来管理容器化的应用程序和服务，kk8s提供了自动重启、自动重建、自动修复提高集群的可用性,以下概念稍微了解即可,看一看直接实操，
[k8s源码]8.deltaFIFO
weixin_45396500的博客
07-24 317
DeltaFIFO: 这是一个特殊类型的队列，它结合了FIFO（先进先出）队列的特性和增量（Delta）处理的能力。这种设计提供了处理的灵活性和优化的机会，允许控制器根据实际需求选择最有效的处理策略。Resync机制会将Indexer本地存储中的资源对象同步到DeltaFIFO中，并将这些资源对象设置为Sync的操作类型。Resync函数在Reflector中定时执行，它的执行周期由NewReflector函数传入的resyncPeriod参数设定。获取资源对象（如 Pod）的变化。
k8s基本单位Pod
misakivv的博客
07-21 974
k8s基本单位Pod
k8s中部署Jenkins、SonarQube、StorageClass部署流程
虫虫的博客
07-23 841
k8s中部署Jenkins、SonarQube、StorageClass部署流程
k8s 公共服务
怨行客
07-23 191
修改named.conf。修改第13行和第21行下面是 named.rfc1912 修改位置，在最后所以用cp -p 复制文件，保留权限nslookup 回车，server是看哪个dns 在起作用dns服务器要配置给所有公共服务节点和 k8s 节点就在网络文件加个DNS2就行了，网络还要重启。
k8s集群 安装配置 Prometheus+grafana
weixin_43258559的博客
07-17 1074
k8s集群 安装配置 Prometheus+grafana+alertmanager
Kubernetes深度解析：从概念到实践
它将探讨 Kubernetes 的核心价值和在现代分布式系统中的作用。 2. 概念原理 2.1 设计理念 这里将深入讲解 Kubernetes 的设计理念，包括可移植性、弹性、自我修复能力和可扩展性等关键原则。 2.2 Objects ...
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值