既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上大数据知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
app: hello-world
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
创建一个Pod
kubectl create -f pod1.yaml
查看Pod信息:
$ kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx 1/1 Running 0 69s 10.244.1.3 node01 <none> <none>
对该node01节点进行docker ps命令操作得到:
通过上图我们可以看到,该pod的组成是:一个pause的容器和n个自定义的容器。
大致如下图所示:
2、通过label组成一个Pod
Pod使用label把上述的container组成一个的,接下来查看看container的label信息:
pause的label信息
nginx的label信息
通过上面的对比分析,会发现: pod.name:“nginx”, namespace: “default”,"pod.uid"都是一样的。
而K8s就是通过这些label来组织Pod的。
3、到底为什么需要Pod?
首先需要回顾一下容器的概念,容器的本质是一个视图被隔离、资源受限的进程。
而容器里PID=1的进程就是应用本身(如下图与下文所示),所以,管理虚拟机 = 管理基础设施;管理容器=直接管理应用本身。
而这一点也正是不可变基础设施的最佳表现,这个时候应用就是基础设施,一定是不可变的。
Docker中,进程管理的基础就是Linux的PID名空间技术。在不同PID名空间中,进程ID是独立的:即在两个不同名空间下的进程可以有相同的PID。
当创建一个Docker容器的时候,就会新建一个PID名空间。容器启动进程在该名空间内PID为1。当PID1进程结束之后,Docker会销毁对应的PID名空间,并向容器内所有其它的子进程发送SIGKILL。
需要注意的是:PID=1的进程对于操作系统而言具有特殊意义。操作系统的PID1进程是init进程,以守护进程方式运行,是所有其他进程的祖先,具有完整的进程生命周期管理能力。在Docker容器中,PID1进程是启动进程,它也会负责容器内部进程管理的工作。而这也将导致进程管理在Docker容器内部和完整操作系统上的不同。
而介于上面的场景之下,K8s的作用又是什么呢?这里需要引用一个特殊的经典话语,那就是容器本身没有价值,有价值的是“容器编排”。而K8s就是用来容器编排的,也有很多人说K8s是云原生时代的操作系统。那么如果按照这个比较关系下去,那么容器镜像就是操作系统里的软件安装包,容器、容器镜像、K8s就是这样一个相互之间的关系。
可以大致的认为:K8s=操作系统linux、容器=进程(linux线程),Pod=进程组(线程组)
真实的操作系统案例:进程组
引入一个Helloworld程序,而该程序由4个进程组构成,这些进程之间共享某些系统的资源文件。
如下图所示,程序中有4个进程。(这里的进程就是linux系统中的线程),分别是api、main、log、compute,这四个线程共同协作helloworld程序的系统资源,进行运行程序的工作。这就是进程组的概念。
假设现在需要用容器跑起来上面的程序,那么该怎么进行处理?
最直接的方法,就是通过启动一个docker容器,里面运行四个进程,那么就会存在一个问题,即该容器中PID=1的进程是应用本身的话,如mian进程,那么谁来负责管理剩余的3个进程成了需要解决的难题。
那么对于这个方法,最需要注意的问题是,容器本身是“单进程”模型。(这并不是意味着容器只能跑一个进程。)
而是说因为容器=应用=进程,所以只能管理PID=1的进程,而其他再跑起来的进程,只能认为是托管状态。所以说除非应用进程具备“进程管理”能力,即helloworld程序需要具备systemd的能力。或者将容器的Pid=1的进程改成systemd,而这样会导致管理容器=管理systemd!=直接管理应用本身。
而如果不具备systemd的能力,那么一旦PID=1的进程kill或者死掉了,那么剩下3个进程的资源没有进行回收,那么这是一个很严重的问题。
总结的来说,一旦容器启动了多个进程,那么只能有一个PID=1的进程,而如果PID=1的进程挂了,那么就会没人回收剩下3个应用的回收,而如果run一个systemd进程来管理其他进程,那么这个时候没有办法直接管理其他的应用,这个时候应用状态的生命周期就不等于容器的生命周期,这样的情况就十分复杂了。
引申:Linux 容器的“单进程”模型,指的是容器的生命周期等同于 PID=1 的进程(容器应用进程)的生命周期,而不是说容器里不能创建多进程。当然,一般情况下,容器应用进程并不具备进程管理能力,所以你通过 exec 或者 ssh 在容器里创建的其他进程,一旦异常退出(比如 ssh 终止)是很容易变成孤儿进程的。
Pod的真正作用
而Pod就是用来K8s抽象出来的类比为进程组的概念,而上面提到的情况,就可以认为是一个拥有4个容器的pod,即现在不会塞进一个容器中,而是用4个分别独立的容器启动起来,包含在一个pod里面,而4个容器共享了一部分资源,所以说,Pod在K8s里面是一个逻辑单位(没有真实的去对应某些东西)。
总的来说,Pod 是 Kubernetes 分配资源的一个单位,因为里面的容器要共享某些资源,所以 Pod 也是 Kubernetes 的原子调度单位。
而Pod的设计问题早在 Google 研发 Borg 的时候,就已经发现了这样一个情况:这些应用之前往往有着密切的协作关系,使得它们必须部署在同一台机器上并共享某些资源。
4、Pod的具体业务案例
现在通过一个例子来帮助我们更好的理解为什么Pod是原子调度单位。
假设现在两个容器,是需要协作完成业务的,所以应该在一个Pod里面。第一个容器为业务容器A,完成写日志文件的功能,第二个容器为转发容器B,顾名思义,即将日志文件转发到后端进行对应处理。
A和B的资源需求如下:A 需要 1G 内存,B需要 0.5G 内存。
而当前集群环境的可用内存情况如下:Node01:1.25G 内存,Node02:2G 内存。
如果没有Pod,那么A和B需要运行在一台机子上,调度器先把A调到了Node01上,那么这就会使得B不能调度到01上了,因为资源不够,也就是内存不够B用了,这个时候调度失败,需要重新调度。
这类问题在以前没有K8s的Pod的帮助下,很多企业解决这类问题都比较复杂,并且需要额外的开销。
而现在只需要一个Pod就解决了。这样的一个 A 容器和 B 容器一定是属于一个 Pod 的,在调度时是以一个 Pod 为单位进行调度,问题是不存在的。
5、Pod的深入理解:超亲密关系
通过上述讲解,已经有了一定的了解。那么继续深入研究一下Pod的“超亲密关系”。
对于普通的亲密关系,就是通过调度来解决的。例如两个应用需要在同一台主机上运行。
而对于Pod的超亲密关系则会存在这样几类关系:
1、两个进程之间会发生文件交换,一个写日志,一个读日志
2、两个进程之间需要通过 localhost 或者说是本地的 Socket 去进行通信,这种本地通信也属于超亲密关系
3、两个容器是微服务,需要发生非常频繁的 RPC 调用,考虑性能方面将之认为是超亲密关系
4、两个容器是应用,需要共享某些 Linux Namespace。举个简单例子:有一个容器需要加入另一个容器的 Network Namespace。这样就能看到另一个容器的网络设备,和它的网络信息。
总结
所以通过上述的讲解,理解了Pod的概念设计来由,以及为什么需要Pod。
通过Pod,可以知道怎么去描述超亲密关系,怎么去进行统一的业务调度。
这就是Pod最主要的来由与作用。
Pod的实现机制
1、刨根究底:Pod到底怎么实现的?
在机器上,Pod是怎么实现的,对于这个问题,核心就在于如何让一个 Pod 里的多个容器之间最高效的共享某些资源和数据。
容器之间原本是被 Linux Namespace 和 cgroups 隔开的,现在要解决的是怎么去打破这个隔离,然后共享某些资源等。这就是 Pod 的设计要解决的核心问题所在。
解法1:通过共享网络
假设现在有一个 Pod,其中包含了两个容器A 和 B,它们要共享 Network Namespace。
在 Kubernetes 里的解法是这样的:它会在每个 Pod 里,额外起一个 Infra container 小容器来共享整个 Pod 的 Network Namespace。
Infra container 是一个十分小的镜像,大概 100-200KB ,是一个汇编语言写的、永远处于“暂停”状态的容器。
这就可以使得其他所有容器都会通过 Join Namespace 的方式加入到 Infra container 的 Network Namespace 中。
所以 Pod 里面的所有容器,它们看到的网络视图是一致的,如它们看到的网络设备、IP地址、Mac地址等等,跟网络相关的信息等。上述这些信息都来自于Pod 第一次创建的这个 Infra container。这就是 Pod 解决网络共享的一个方法。
在 Pod 里面,有一个 IP 地址,是这个 Pod 的 Network Namespace 对应的地址,也是这个 Infra container 的 IP 地址。所以Pod里面的容器看到的都是这个。而对于宿主机上的其他网络资源,都是一个 Pod为 一组来分的,并且被该 Pod 中的所有容器共享网络视图。
该Infra容器相当于总dialing,所以整个 Pod 中是 Infra container 第一个启动。并且整个 Pod 的生命周期是等同于 Infra container 的生命周期的,与容器 A 和 B 是无关的。这也是为什么 K8s中,允许去单独更新 Pod 里的某一个镜像的,即做这个操作,整个 Pod 并不会进行重建或者重启。
解法2:通过共享存储
有两个容器,一个是 A,一个是B,在A放一些文件,使之能通过 Nginx 访问到。所以A需要去 share 这个目录。 share 文件或者是 share 目录在 Pod 里面是容易实现的,就是把 volume 变成了 Pod level。对于同一个Pod下的容器来说共享所有的 volume即可。
在下图的案例中,这个 volume 叫做 shared-data,是属于 Pod level 的,在每一个容器里可以直接声明:挂载 shared-data 这个 volume。只要声明挂载这个 volume,在容器里去看这个目录,实际上每个容器看到的就是同一份。
在之前的例子中,A写了日志,只要这个日志是写在一个 volume 中,只要声明挂载了同样的 volume,这个 volume 就可以立刻被另外一个 B容器给看到。以上就是 Pod 实现存储的方式。
附录:Pod的详细定义
apiVersion: v1 # 必选,API的版本号
kind: Pod # 必选,类型Pod
metadata: # 必选,元数据
name: nginx # 必选,符合RFC 1035规范的Pod名称
# namespace: default # 可选,Pod所在的命名空间,不指定默认为default,可以使用-n 指定namespace
labels: # 可选,标签选择器,一般用于过滤和区分Pod
app: nginx
role: frontend # 可以写多个
annotations: # 可选,注释列表,可以写多个
![img](https://img-blog.csdnimg.cn/img_convert/1c822d8452d32d1125eda8bbc202cf57.png)
![img](https://img-blog.csdnimg.cn/img_convert/45911fd31d90b06affc53103acfb7d76.png)
![img](https://img-blog.csdnimg.cn/img_convert/67ef2a8b28fb413e7d6eccd7b893f126.png)
**既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上大数据知识点,真正体系化!**
**由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新**
**[需要这份系统化资料的朋友,可以戳这里获取](https://bbs.csdn.net/topics/618545628)**
g-MJ0hXGAm-1715754720575)]
[外链图片转存中...(img-xIUbkW4S-1715754720575)]
**既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上大数据知识点,真正体系化!**
**由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新**
**[需要这份系统化资料的朋友,可以戳这里获取](https://bbs.csdn.net/topics/618545628)**