文章目录
1.Kubernetes是啥？
-
Kubernetes是一个管理跨主机容器化应用的系统，实现了包括应用部署、高可用和弹性伸缩哎内的一系列基础功能并封装称为一整套完整、简单易用的restful api对外提供服务。
-
K8S建立了一套健壮的集群自恢复机制，包括：容器的自动重启、自动重调度及自动备份
-
K8S的服务对象是：由多个容器组合而成的复杂应用，如：弹性、分布式的服务架构。
K8S引入了专门对容器进行分组管理的pod，K8S对外提供容器服务的模式是：用户提交容器集群运行所需要的资源的申请(就是个配置文件)，然后由K8S负责完成这些容器的调度任务(就是自动地为这些容器选择运行的宿主机)
2.K8S集群部署Guestbook应用例子
- eg：应用部署说明如下：
（1）它是一个PHP网站，同时运行3个副本来保证高可用
（2）该PHP网站在Redis里存储了一个数据，不定期进行读写
（3）该Redis服务由1个Master节点和2个slave节点组成的高可用集群，读请求由Slave处理，写请求则交给Master
（4）使用负载均衡组件来完成多个Redis Slave之间以及PHP实例之间的请求分配
在K8S中部署如下：
php的副本数量为3，Redis Slave的数量为2，Redis Master的副本数量为1
（1）用户在创建容器时，会给每个容器指定一个用来分组的标签label：比如所有的php网站容器都属于name=frontend
（2）这些容器可以使用IP：PORT的方式进行通信，但是K8S内置了service代理组件，可以使用固定的IP，以防止容器重启
（3）replication controller，label和service，真正操作的对象都是一个称之为pod的逻辑对象。并通过APIServer组件提供了
一套对它们按照RESTful格式的增删改查和监听接口。
3.pod
-
在K8S中，能够被创建、调度和管理的最小单元是pod
-
pod可以想象成一个篮子，而容器则是篮子里的鸡蛋，
当K9S需要调度容器时，它直接把一个篮子(连同里面的鸡蛋)从一个宿主机调度到另一个宿主机。
其关系包括：
（1）一个pod里的容器能有多少资源取决于这个篮子的大小；
（2）label也是贴在篮子上的；
（3）IP分配给篮子而不是容器，篮子里面的所有容器共享这个IP；
（4）哪怕只有一个鸡蛋(容器)，K8S仍然会给他分配一个篮子； -
pod容器共享的内容，包括：
（1）IP及对应的network namespace是由pod里的容器所共享的
（2）pod内的所有容器共享volume
（3）同一个pod内的应用容器能够使用System VIPC或者POSIX消息队列进行通信
（4）同一个pod内的应用容器共享主机名 -
label和label selector与pod协作
（1）labels属性是一组绑定到K8S对象(eg:pod)上的键值对，同一个对象labels属性的key必须独一无二。
一个label的key：代表一个资源管理维度(eg:release，environment)
（2）label selector作为发送给APIServer的RESTful查询请求的条件参数，用于检索一个与label selector匹配的K8S对象列表
查询方法：
（1）基于值相等的查询条件
environment=production,tier!=frontend
表示的意思：过滤出为域production环境，但是非前端的资源对象
（2）基于子集的查询条件
key值=enviroment，且value值=production或qa的资源对象
enviroment in (production, qa)
选择key值=tire，value值!=frontend且backend的资源对象
选择所有labels属性中包含key值=partition的资源对象，不需要检查value值
partion
-
pod的现状和未来走向
（1）目前pod内的容器共享同一个network namespace，IP资源和端口区间，能够通过localhost进行相互间的通信
（2）pod对于K8S来说，最有用的价值就是原子化调度，即：在为一个pod选择目的宿主机时，K8S会考量这个机器是够能放下整个pod，而避免出现本应该部署在一起的容器因为资源不足，无法满足“超亲密”关系 -
pod的使用场景
尽量不要在单个pod中运行同一个应用的多个实例 -
pod使用实例
（1）创建K8S对象
kubectl creat -f obj.json
obj.json可以是定义pod，replication controller，service等K8S对象的json格式的资源配置文件
（2）将配置内容写入testpod.json文件
kubectl creat -f testpod.json
注意：同一个pod内的容器端口不能重复；同一个pod的不同容器的端口不要映射到宿主机的同一个端口；
（3）查看pod信息
kubectl get pod
（4）查看pod中master1容器输出的log信息
kubectl log podtest master1
- pod内的容器网络与通信
假设pod内一共有3个容器
上面两个是用户容器，第三个是K8S的网络容器
（1）容器master1将6379端口映射到宿主机的6388端口；
将master2容器的22端口映射到宿主机上的8888端口；
（2）先通过ssh的方式进入master2容器
ssh root@127.0.0.1 -p 8888
在master2容器内通过localhost访问master1容器
telnet 127.0.0.1 6379
4.replication controller设计
- K8S决定了一个pod有多少同时运行的副本，并保证这些副本的期望状态与当前状态一致。
- 任何时候一个pod中的容器退出或者整个pod变成Failed，replication controller都会固执地重启这个容器或者pod
- replication controller的描述文件，包括：
创建pod的pod模板（pod template），一个期望副本数和一个用于选择被控制的pod集合的label selector；
（1）从下面的描述文件可以看出：replication controller通过使用于定义的pod模板来创建pod，一旦pod创建成功，对模板的任何更改都不会对已经在运行的pod有任何直接的影响。
（2）删除一个replication controller不会影响它所创建的pos，若想删除一个replication controller所控制的pod，需要将其replicas字段设置为0
（3）通过修改pod的labels，可以将一个pod从replication controller的控制集中移除
（4）如下所示：该replication controller实例化了2个运行nginx的pod，replication controller通过使用预定义的pod模板来创建pod， 一旦pod创建成功，对模板的任何更改都不会对已经在运行的pod有任何直接的影响。
调整这些已经在运行的pod的CPU，MEM参数等操作应该直接更新pod本身而不是更新replication controller。
（4）可以通过修改podlabels将一个pod从replicatin controller的控制集中移除，然后针对这个pod进行debug、数据恢复等操作。此外，replication controller则会自动重启一个新的pod来替换被移除的pod
（5）若想要删除一个replication controller所控制的pod，需要将该replication controller的副本数(replicas)字段置为0，这样所有的pod都会被自动删除。
5.replication controller的典型场景
- （1）重调度。
