docker&kubernets篇（二十二）

curl -s https://mirrors.aliyun.com/kubernetes/apt/doc/apt-key.gpg | apt-key add -
cat << EOF >/etc/apt/sources.list.d/kubernetes.list
deb http://mirrors.ustc.edu.cn/kubernetes/apt kubernetes-xenial mainx`
EOF
apt update && apt install -y kubelet kubeadm kubectl
1
2
3
4
5

cat <

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17

通过运行将 SELinux 设置为许可模式setenforce 0并sed …有效地禁用它。这是允许容器访问主机文件系统所必需的，例如 pod 网络需要的。在 kubelet 中改进 SELinux 支持之前，您必须这样做。
如果您知道如何配置 SELinux，则可以启用它，但它可能需要 kubeadm 不支持的设置。
如果baseurl由于您的基于 Red Hat 的发行版无法解释而失败basearch，请替换$basearch为您计算机的体系结构。键入uname -m以查看该值。例如，baseurlURLx86_64可能是：https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64。

kubelet 现在每隔几秒重新启动一次，因为它在 crashloop 中等待 kubeadm 告诉它该做什么。

一个典型案例：Guestbook

❏ 它是一个PHP网站，并同时运行3个副本来保证高可用；
❏ 这个PHP网站在Redis里存储了一个数据，不定期进行读写；
❏ 这个Redis服务由1个Master节点和2个Slave节点组成高可用集群，读请求由Slave处理，写请求则交给Master。

这类应用是非常常见的，在不借助其他工具的前提下，仅使用Docker容器也能把这个集群运行起来，然后使用负载均衡组件来完成多个Redis Slave之间以及多个PHP实例之间的请求分配。当然其中也少不了自己搭一些服务发现的组件，来保证自动化管理的过程。

那么，这样的集群在Kubernetes的管理下又是怎样的呢？如图所示，在Kubernetes的管理下，所有容器（包括PHP网站和Redis节点）都会被分配一个“副本控制器”（replication controller），并且指定PHP的副本数量为3, Redis Slave的副本数量为2, Redis Master的副本数量为1。

用户在创建容器时，会给每个容器指定一个用来分组的标签（label）：比如所有PHP网站容器都属于name=frontend这个组。在调度的时候，Kubernetes就可以根据这些标签来进行一些决策。比如，从高可用角度出发，用户可以指定所有name=frontend标签的容器不会被调度在同一台node上。

这些容器可以直接使用IP:Port的方式进行通信，但是由于重新调度或者重启之后Docker容器的IP会发生变化，所以Kubernetes内置了一个名为service的代理组件。当为某些容器（同样可以使用label来指定）分配了一个service代理后，这些容器就可以统一使用一个固定IP（cluster IP）被访问到，这就为用户省去了自己搭建负载均衡的麻烦，当然，如有需要，也可以使用自己的负载均衡组件来代替这些service。

最后也是最重要的，上述replication controller、label和service，真正操作的对象都是一个称为pod的逻辑对象，而非容器，这是Kubernetes与其他编排调度平台最大的区别。

pod可以想象成一个篮子，而容器则是篮子里的鸡蛋，当Kubernetes需要调度容器时，它直接把一个篮子（连同里面的鸡蛋）从一个宿主机调度到另一个宿主机，而不是一个一个地搬运里面的鸡蛋。篮子和鸡蛋的关系主要表现为以下几点。
❏ 一个pod里的容器能有多少资源也取决于这个篮子的大小。
❏ label也是贴在篮子上的。
❏ IP分配给篮子而不是容器，篮子里面的所有容器共享这个IP。
❏ 哪怕只有一个鸡蛋（容器）, Kubernetes仍然会给它分配一个篮子。
在Kubernetes中，pod、replication controller和service统称为“对象”或者“资源”，并通过APIServer组件提供了一套对它们按照RESTful格式的增、删、改、查和监听接口。Kubernetes支持多个API版本，如/api/v1和/apis/extensions/v1beta1，对应的资源对象分别定义在/pkg/api/{apiversion}/types.go和/pkg/apis/extensions/{apiversion}/types.go中。

不同的API版本中Kubernetes对象的定义和操作略有不同，同时它们在系统中的稳定程度也略有差异。如alpha级别的API通常是处于开发的不成熟阶段，而beta级别和稳定级别的API在测试完备度和支持程度上是逐渐递增的。

注意 上述所有的资源对于不同的租户来说在逻辑上是隔离的，租户隔离使用的概念叫namespace（注意不是Linux 的namaspace），大家可以理解为工作空间。如非特殊说明，下文出现的namespace均指Kubernetes的namespace。更多关于Kubernetes namespace的概念将在后面讨论。