k8s-learning-why we need pod

应用场景

应用从虚拟机迁移到容器中

为什么虚拟机中的应用不能无缝迁移到容器中

虚拟机中应用：一组进程，被管理在systemd或者supervisord中

容器的本质：一个容器一个进程

所以将运行在虚拟机中的应用无缝迁移到容器中，与容器的本质是相悖的。

容器无法像虚拟机那样，完全模拟本地物理机环境中的部署方式。

swarm 项目无法成长起来的原因：单容器的工作方式，难以描述真实世界里的复杂的应用架构。

Pod的本质：一种编排思想

扮演传统基础设施里“虚拟机”的角色；而容器则是这个虚拟机中的用户程序

虚拟机应用迁移到docker

方法：松耦合的容器编排技巧，超亲密关系容器的设计思想，

分析那些进程（组件）运行在这个虚拟机里
把虚机想象成为一个pod，把进程分别做成镜像
把有顺序关系的定义为 Init Container。

从传统应用架构，到微服务架构最自然的过渡方式。

Pod 实现原理

pod 是一组共享了某些资源的容器。如network，声明 volume

docker run -net--volumes-from

Pod里的容器是拓扑关系

中间容器来解决容器启动顺序问题

第一个：Infra容器 k8s.io/pause 100-200KB
第二个：容器 A Join Infra Network namespace
第三个：容器 B Join Infra Network namespace

共享volume

apiVersion: v1
kind: Pod
metadata:name: two-containers
spec:restartPolicy: Nevervolumes:- name: shared-datahostPath:path: /datacontainers:- name: nginx-containerimage: nginxvolumeMounts:- name: shared-datamountPath: /usr/share/nginx- name: debian-containerimage: debianvolumeMounts:- name: shared-datamountPath: /pod-datacommand: ["/bin/sh"]args: ["-c", "echo Hello from the debian container > /pod-data/index.html"]

宿主机目录 /data 被同时绑定到上述两个容器中，

例子一：war包与web服务器

一个java Web 应用的WAR包，需要被放在Tomcat的webapps目录下运行起来

docker解决方式：

方法一：把war包直接放在Tomcat 镜像的webapps目录下，做成一个新的镜像运行起来。

缺点：更新升级时，需要重新制作镜像

方法二：只发布一个tomcat 镜像，声明一个hostPath 的volume , 从而把宿主机上的WAR包挂载进Tomcat容器中巡行。

缺点：每一个宿主机都要存储WAR包目录。或者独立维护一套分布式存储系统。

pod 解决方式：

sidecar 设计模式

作用：在一个pod 中启动一个辅助容器，完成一些独立于主进程之外的工作

如下面启动一个InitContainer 的方式优先运行一个WAR包容器，扮演一个sidecar的角色。

apiVersion: v1
kind: Pod
metadata:name: javaweb-2
spec:initContainers:- image: geektime/sample:v2name: warconmmand: ["cp", "/sample.war", "/app"]volumeMounts:- mountPath: /appname: app-volumecontainers:- image: geektime/tomcat:7.0name: tomcatcammand: ["sh", "-c", "/root/apache-tomcat-7.0.42-v2/bin/start.sh"]volumeMounts:- mountPath: /root/apache-*/webappsname: app-volumeports:- containerPort: 8080hostPort: 8001volumes:- name: app-volumeemptyDir: {}