Kubernetes的pod控制器及ReplicaSet控制器类型的pod的定义

为什么需要Pod

Kubernetes项目之所以这么做的原因；
因为Kubernetes是谷歌公司基于Borg项目做出来的，谷歌工程师发现，他们部署的应用往往存在这进程与进程组的关系。具体说呢，就是这些应用之间有着密切的协作关系，使得他们必须部署在同一台机器上
而如果事先没有组的概念，像这样的运维关系很难处理；举个例子
rsyslogd是由3个进程组成的：一个imklog模块，一个imuxsock模块，一个rsyslogd自己的9函数主进程。这三个进程一定要运行在同一台机器上否则，他们之间基于 Socket的通信和文件交换，都会出现问题；现在，我要把rsyslogd这个应用给容器化，由于受限于的单进程模型，这三个模块必须被分别制作成三个不同容器运行，他们设置的内存配额都是1GB
注意：强调一下容器的“单进程模型”，并不是指容器里只能运行一个进程，而是容器没有管理多个进程的能力。这是因为容器里PID=1的进程就是应用本身，其他进程都是这个PID=1进程的子进程。可是，用户编写的应用，并不能够像正常操作系统里的init进程或者systemd那样拥有进程管理功能。比如，你的应用是一个java Web程序（PID=1），然后你执行docker exec在后台启动了一个nginx进程（PID=3）。可是，当nginx进程异常退出的时候，你怎么知道呢？这个进程退出后的垃圾收集工作，由谁做
假设我们Kubernetes集群上有两个节点：node-1上有3GB可用内存，node-2上有2.5GB可用内存
这时，假设我要用Docker Swarm来运行这个rsyslogd程序。为了能够让着三个容器都运行在同一台机器上，就必须在两个容器上设置一个affinity=main（与main容器有亲密性）的约束，即：它俩必须和main容器运行在同一台机器上
然后，我依次执行：“docker run main” “docker run imklog” 和“docker run imuxsock”,创建这三个容器；这样，这三个容器都进入Swarm的代调度队列。然后，main容器和imklog容器都先后出队列并被调度到node-2节点上（这个情况完全有可能的）
可是，当imuxsock容器出队列调度时，Swarm就有的懵了：node-2上的可用资源只有0.5GB了，并不足运行imuxsock容器；可是，根据affinity=main的约束，imuxsock容器有只能运行在node-2上；这就是一个典型的成组调度没有被妥善处理的例子
工业界与学术界，关于这个问题的讨论可谓旷日持久，也产生很多可选方案
比如，Mesos中就有一个资源囤积的机制，会在所有设置了Affinity约束的任务都到达时，才开始对它们统一进行调度。而谷歌在Omege论文中提出使用乐观调度处理冲突方法，即：先不管这些冲突，而是通过精心设计的回滚机制在出现冲突之后解决
以上的方法都谈不上完美。资源囤积带来了不可避免的调度效率失所与死锁的可能性；而乐观调度的复杂程度，不是常规技术团结队所能驾驭的。
但是，到了Kubernetes项目里，这样的问题迎刃而解：Pod是Kubernetes的最小调度单位，这就意味着，Kubernetes项目在调度时，自然就会去选择可用内存等于3GB的node-1节点进行绑定，而根本就不会考虑nod-2
像这样的容器间紧密协作，我们称为“超亲密关系”。这些具有“超亲密关系”容器的典型特征包括但不限于：互相之间发生直接的文件交换，使用localhost或者Socket文件进行本地通信、会发生非常频繁的远程调用、需要共享这些Linux Namespace（比如，一个容器要加入另一个容器的Linux Namespace）等等
这也就意味着，并不是所有有关系的容器都属于同一个Pod。比如，PHP容器和Mysql虽然会发生访问关系，但并不需要、也不应该部署同一个Pod里，更适合做成两个pod

如果只是处理这种超亲密关系这样的调度问题，有Borg和Omega论文珠玉在前，Kubernetes项目肯定可以在调度器层面把它解决掉
不过，pod在Kubernetes项目里还有更重要的意义，那就是容器设计模式
为理解这一层含义，就必须介绍一下Pod的实现原理
首先关于Pod最重要的一个事实是：它就是一个逻辑概念；也就是说Kubernetes真正处理的，还是宿主机操作系统是上的Linux容器的Namespace与Cgroups，而并不存在所谓的Pod边界或者隔离排环境；pod其实就是一组共享某些资源的容器
具体说：pod里所有容器都是共享同一个Network Namespace，并且可以声明挂载同一个Volume
那这么来看的话，一个有A、B两个容器的pod,不就等同一个容器（容器A)共享另一个容器（容器B）的网络和Volume的玩法了；这个好像通过 Docker run --net --volumes-from这样的命令就可以实现
docker run --net=B --volumes-from=B --name=A image-A ...
但是，你没有考虑过，如果真的这样的话，容器B就必须比容器A先启动，这样一个Pod里的多个容器就不是对等关系，而是拓扑关系；
所以在Kubernetes项目里，pod的实现需要一个中间容器，这个容器叫Infra容器。在这个pod中，infra容器永远都是第一个被创建出来的容器，而其他用户定义的容器，则通过join Network Namespace 的方式，与Infra容器关联在一起的

 

这个pod 里有两个用户容器A和B，还有一个Infra容器，很容易理解，在Kubernetes项目里，Infra容器一定占有少量的资源，所有它使用的是一个非常特殊的镜像叫做：k8s.gcr.io/pause。这个镜像时一个汇编语言编写的、永远处于暂停装态的容器，解压后的大小也只有100~200kb左右
而Infra容器Hold住network Namespace后，用户容器

pod 控制器

  ReplicaSet：代用户创建指定数量的副本，并控制副本数量一直处于用户期望的数量状态；多退少补，支持滚动更新；自动扩缩容机制；不建议直接使用

 顶级帮助

[root@master manifests]# kubectl explain rs
KIND:     ReplicaSet
VERSION:  extensions/v1beta1

DESCRIPTION:
     DEPRECATED - This group version of ReplicaSet is deprecated by
     apps/v1beta2/ReplicaSet. See the release notes for more information.
     ReplicaSet ensures that a specified number of pod replicas are running at
     any given time.

FIELDS:
   apiVersion	
     APIVersion defines the versioned schema of this representation of an
     object. Servers should convert recognized schemas to the latest internal
     value, and may reject unrecognized values. More info:
     https://git.k8s.io/community/contributors/devel/api-conventions.md#resources

   kind	
     Kind is a string value representing the REST resource this object
     represents. Servers may infer this from the endpoint the client submits
     requests to. Cannot be updated. In CamelCase. More info:
     https://git.k8s.io/community/contributors/devel/api-conventions.md#types-kinds

   metadata