k8s入门介绍

向右看齐 2023-01-06 13:00 339阅读 0赞

#### 一、k8s特点 ####

*  轻量级：消耗资源小
 *  开源
 *  弹性伸缩
 *  负载均衡：IPVS

#### 二、架构设计 ####

高可用集群副本数量最好是 >= 3的奇数

##### 2.1 Borg架构（k8s前身） #####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzM0MjQxODYx_size_16_color_FFFFFF_t_70]

##### 2.2 k8s架构 #####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6suLy9ibG9nLmNzZG4ubmV0L3NpbmF0XzM0MjQxODYx_size_16_color_FFFFFF_t_70]

*  etcd：官方将它定位成一个可信赖的**分布式键值存储服务**，它能够为整个分布式集群存储一些关键数据，协助分布式集群的正常运转。**etcd是键值对数据库，储存k8s集群所有重要信息（持久化）**。推荐在k8s集群中使用Etcd v3版本，v2版本已经在k8s v1.11中弃用啦
 *  api server：所有服务访问的统一入口
 *  ControllerManager：维持副本期望数目
 *  Scheduler：负责介绍任务，选择合适的节点进行分配任务
 *  kubelet：直接跟容器引擎交互实现容器的生命周期管理
 *  kube-proxy：负责写入规则至 IPTABLES、IPVS 实现服务映射访问
 *  coredns：可以为集群中的SVC创建一个域名和IP的对应关系解析
 *  dashboard：给 k8s 集群提供一个 B/S 结构访问体系
 *  ingress controller：官方只能实现四层代理、ingress可以实现七层代理
 *  federaction：提供一个可以跨集群中心多k8s统一管理功能
 *  prometheus：提供k8s集群的监控能力
 *  ELK：提供 k8s 集群日志统一分析介入平台

##### 2.3 服务分类 #####

*  有状态服务：DBMS
 *  无状态服务：LVS APACHE

##### 2.4 控制器 #####

###### 2.4.1 ReplicationController&ReplicaSet&Deployment ######

ReplicationController用来确保容器应用的副本数始终保持在用户定义的副本数。即如果有容器异常退出，会自动创建新的Pod代替；而如果异常多出来的容器也会自动回收。在新版本的 Kubernetes中建议使用ReplicaSet来取代ReplicationController。

ReplicaSet和ReplicationController没有本质的不同，只是名字不一样，并且ReplicaSet支持集合式的selector。

虽然ReplicaSet可以独立使用，但一般还是建议使用Deployment来自动管理ReplicaSet。这样就无需担心跟其他机制的不兼容问题（ 比如 ReplicaSet 不支持rolling-update，但 Deployment支持）

###### 2.4.2 HPA（Horizontal Pod Autoscaling） ######

Horizontal Pod Autoscaling仅适用于 Deployment 和 ReplicaSet，在v1版本中仅支持根据Pod的CPU利用率扩缩容，在vlalpha版本中，支持根据内存和用户自定义的metric扩缩容。

###### 2.4.3 StatefulSet ######

StatefulSet是为了解决有状态服务的问题（对应 Deployment 和 ReplicaSet是为无状态服务而设计），其应用场景包括：

*  稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据。基于PVC来实现
 *  稳定的网络标志，即Pod重新调度后其podname和hostname不变。基于Headless Service（即没有Cluster IP的Service）来实现
 *  有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次进行（即从0到N-1，在下一个Pod运行之前所有的Pod必须都是Running和Ready状态），基于init containers来实现
 *  有序收缩，有序删除（即从N-1 到 0）

###### 2.4.4 DaemonSet ######

DaemonSet确保全部（或者一些）Node上运行一个Pod副本。当有Node加入集群时，也会为他们新增一个Pod。当有Node从集群移除时，这些Pod也会被回收。删除DaemonSet将会删除它创建的所有Pod

使用DaemonSet的一些典型用法：

*  运行集群存储 daemon，例如在每一个Node上运行 glustered、ceph。
 *  在每一个Node上运行日志收集daemon，例如fluentd、logstash
 *  在每一个Node上运行监控daemon，例如Prometheus NodeExporter

#### 三、K8S网络通讯模式 ####

Kubernetes的网络模型假定了所有Pod都在一个可以直接连通的扁平的网络空间中，这在GCE（Google Compute Engine）里面是现成的网络模型，Kubernetes假定这个网络已经存在。而在私有云里搭建Kubernetes集群，就不能假定这个网络已经存在了。我们需要自己实现这个网络假设，将不同节点上的Docker容器之间的互相访问先打通，然后运行Kubernetes

**通讯模式：**

*  同一个Pod内的多个容器之间：lo
 *  各Pod之间的通讯：Overlay Network
 *  Pod与Service之间的通讯：各节点的Iptables规则

**网络解决方案：Kubernetes + Flannel**

Flannel是CoreOS团队针对Kubernetes设计的一个网络规划服务。简单来说，它的功能是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址。而且它还能在这些IP地址之间建立一个覆盖网络（Overlay Network），通过这个覆盖网络，将数据包原封不动的传递到目标容器内

**ETCD与Flannel之间的关联：**

*  存储管理Flannel可分配的IP地址段资源
 *  监控ETCD中每个Pod的实际地址，并在内存中建立维护Pod节点路由表

**不同情况下网络通信方式**

*  同一个Pod内部通讯：同一个Pod共享同一个网络命名空间，共享同一个Linux协议栈
 *  Pod1访问Pod2：  
    （1）Pod1与Pod2不在同一台主机，Pod的地址是与docker0在同一个网段的，但docker0网段与宿主机网卡是两个完全不同的IP网段，并且不同Node之间的通信只能通过宿主机的物理网卡进行。将Pod的IP和所在Node的IP关联起来，通过这个关联让Pod可以互相访问  
    （2）Pod1与Pod2在同一台主机，由docker0网桥直接转发请求至Pod2，不需要经过Flannel
 *  Pod访问Service的网络：目前基于性能考虑，全部为 iptables维护和转发
 *  Pod访问外网：Pod向外网发送请求，查找路由表，转发数据包到宿主机的网卡，宿主机网卡完成路由选择后，iptables执行Masquerade，把源IP更改为宿主机网卡的IP，然后向外网服务器发送请求
 *  外网访问Pod：Service

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzM0MjQxODYx_size_16_color_FFFFFF_t_70]: /images/20221119/633986d0148a4727a79f67caf2a92c92.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6suLy9ibG9nLmNzZG4ubmV0L3NpbmF0XzM0MjQxODYx_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20210114191555495.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6suLy9ibG9nLmNzZG4ubmV0L3NpbmF0XzM0MjQxODYx,size_16,color_FFFFFF,t_70