kubernete中的原子调度单位:pod

发布于 2022-5-1 10:48
浏览
0收藏

作者 |  jinjunzhu
来源 | 君哥聊技术(ID:gh_1f109b82d301)

在前面的文章中,我们介绍了容器技术,他的本质是操作系统上的一个进程,那么打包的容器镜像其实就是一个安装包,类似于windows操作系统中的exe文件,那容器所在的kubernete集群其实就是一个操作系统。

容器和操作系统中进程一样,并不是独立的运行,而是和其他容器之间有着关联的关系。假如我们有3个进程,因为相互之间的关系需要部署在同一台宿主机上,这3个进程每个需要分配1G内存,但是有2个宿主机,A机器有3G内存,B机器有2.5G内存,如果不能统一调度,其中2个进程调度到B机器后,因为内存不足,第3个进程启动失败。而如果我们使用kubernete中的pod,pod会对3个容器统一管理和调度,这样就会直接选择A宿主机。

调度在一个pod的中的容器,一般具有某些关联关系,比如共享Linux namespace,共享volume,通过localhost进行通信。像Tomcat和它所依赖的war包,就是这样的一个例子。在pod的,实现这个功能,依靠的是一个infra容器,这个容器使用的镜像是k8s.gcr.io/pause,只有不到200k,它的状态永远是pause,作用是启动后控制namespace,pod中的其他容器启动后就可以加入当前这个namespace中,这样pod中的容器共享一份namespace,就可以通过localhost进行通信了。如下图所示:kubernete中的原子调度单位:pod-开源基础软件社区

因此,infra容器是一个基础容器,它控制着namespace和整个pod的生命周期。

下面我们看一个yaml文件,Tomcat和war在同一个pod的不同容器中

apiVersion: v1
kind: Pod
metadata:
  name: javaweb-2
spec:
  initContainers:
  - image: zjj2006forever/spingboot-rabbitmq
    name: war
    command: ["cp", "/spingboot-rabbitmq.war", "/app"]
    volumeMounts:
    - mountPath: /app
      name: app-volume
  containers:
  - image: tomcat:jdk8-openjdk-slim
    name: tomcat
    command: ["sh","-c","/root/apache-tomcat-8.5.54-v2/bin/start.sh"]
    volumeMounts:
    - mountPath: /root/apache-tomcat-8.5.54-v2/webapps
      name: app-volume
    ports:
    - containerPort: 8080
      hostPort: 8001 
  volumes:
  - name: app-volume
    emptyDir: {}

上面的yaml文件中,定义了一个pod,这个pod中有2个容器,其中一个是运行标准Tomcat8镜像,一个是存放Tomcat下的war包,这儿使用的是我之前做的一个springboot-rabbitmq的镜像。同时我们也看到war包所在的容器类型是initContainer,这个镜像的特点是会比spec.containers中的容器先启动。而且,这2个容器都挂载了一个叫app-volume的volume,这个volume的路径是/app,war包容器启动时会把war包copy到/app目录下,这样Tomcat容器的/root/apache-tomcat-8.5.54-v2/webapps下就可以看到这个war包了。这就是kubernete容器编排的高明之处。

如果没有pod,那就是两种处理方式,要不就是在Tomcat容器下启动一个war包容器,这种方式不方便升级war包;要不就是把war包放在宿主机上,挂载在容器中,但这种情况不适合分布式场景。

上面这个配置所使用的设计模式,叫做sidecar,也就是在pod中启动一个辅助容器来配合主容器进程的工作,上面的war容器就是一个sidecar。sidecar有很多场景可以应用,比如pod中可以启动一个sidecar来收集日志。

收藏
回复
举报
回复
添加资源
添加资源将有机会获得更多曝光,你也可以直接关联已上传资源 去关联
    相关推荐