docker&kubernets篇（二十二）

yitian_hm

已于 2022-08-25 12:09:22 修改

阅读量174

点赞数

分类专栏： docker&kubernet 文章标签： docker kubernetes 容器

于 2022-08-23 08:18:32 首次发布

本文链接：https://blog.csdn.net/yitian_881112/article/details/126473536

版权

docker&kubernet 专栏收录该内容

28 篇文章 2 订阅

订阅专栏

Kubernetes的设计解读

Kubernetes为我们提供工具来构建自己的云服务，使应用程序开发者能够从繁杂的运维中极大地解放出来。作为一个备受瞩目的主流容器应用部署框架，Kubernetes无疑融合了很多先进的设计理念和广泛的实践经验。它不仅提供了APIServer、scheduler、kubelet等底层核心组件，从而使得用户能够放心管理成千上万个容器实例，更提供了pod、service、replication controller等设计理念和服务，帮助用户更加方便快捷地基于容器构建应用系统。为了帮助读者快速上手Kubernetes，本节将全面梳理pod、replication controller、service等设计理念，而这一切都将从一个官方提供的常用示例Guestbook开始。

kubernet 安装

安装docker，之前有介绍过docker安装；
安装组建 kubelet kubeadm kubectl (3台机器都安装)

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

第二种方式

cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-\$basearch
enabled=1
gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
exclude=kubelet kubeadm kubectl
EOF

# Set SELinux in permissive mode (effectively disabling it)
sudo setenforce 0
sudo sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config

sudo yum install -y kubelet kubeadm kubectl --disable excludes=kubernetes

sudo systemctl enable --now kubelet

通过运行将 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。

zoom=40%
用户在创建容器时，会给每个容器指定一个用来分组的标签（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的概念将在后面讨论。