Kubernetes理论基础
有勇气的牛排
1567
云原生
2021-08-26 21:57:34
文章目录
1 介绍
高可用集群副本数据最好是 >= 3 奇数个
2 组件介绍
k8s架构

2.1 核心组件
2.1.1 api server
所有服务访问统一入口
2.1.2 ControllerManager
维护副本的期望数
2.1.3 Scheduler
负责介绍任务,选择合适的节点进行分配任务
2.1.4 etcd
键值对数据库,存储K8S集群的所有重要信息(持久化)
- ETCD
etcd 的官方将它定位程一个可信赖的分布式键值存储服务,它能够为整个分布式集群存储一些关键服务数据,协助分布式集群的正藏运转。
架构图

AWL:日志
Store:持久化写入本地磁盘
2.1.5 Kubelet
直接跟容器交互实现容器的生命周期管理
2.1.6 Kube-proxy
负责写入规则至IPTABELS、IPVS,实现服务映射访问的
2.2. 其他插件
2.2.1 CoreDNS
可以为集群中的SVC创建一个域名、IP对应关系解析
2.2.2 dashboard
给K8S集群提供一个B/S结构的访问体系
2.2.3 Ingress Controller
官方只能实现四层代理,Ingress可以实现7层
2.2.4 fedetation
提供一个可以跨集群中心多K8S统一管理功能
2.2.5 prometheus
提供一个K8S集群监控能力
2.2.6 ELK
提供K8S集群日志统一分析介入平台
3 Pod
3.1 Pod概念
注:官方不是安上面的分类的
3.1.1 Pod服务类型
HPA
Horizontal Pod Autoscaling仅适用于Deployment和ReplicaSet,在V1版本中仅支持根据Pod的CPU利用率扩缩容,在vlalpha版本中,支持根据内存和用户自定义的metric扩缩容。
StatefulSet
是为了解决有状态服务的问题(对应Deployments和ReplicaSets是为了无状态服务而假设),其场景包括:
- 稳定的持久化存储:即Pod重新调度后还是能访问到相同的持久化数据,基于PVC来实现。
- 稳定的网络标志,即Pod重新调度后其PodName和HostName不变,基于Headless Service(即没有Cluster Ip的Service)来实现。
- 有序部署,有序扩展,即Pod是有顺序的,在部署或者扩展的时候要依据定义的顺序依次进行(即从0到N-1,在下一个运行之前所有的Pod必须都是Running和Read状态),基于init containers来实现
- 有序收缩,有序删除(即从N-1到0)
DaemonSet
确保全部(或者一些)Node上运行一个Pod的副本。当有Node加入集群时,也会为他们新增一个Pod。当有Node从集群移除时,这些Pod也会被回收。删除DaemonSet将会删除它创建的所有Pod
使用DaemonSet的一些典型用法
- 运行集群存储daemon,例如在每个Node上运行glusterd、ceph
- 在每个Node上运行日志手机daemon,例如fluentd、logstash
- 在每个Node上运行监控daemon,例如Prometheus Node Exporter
Job
负责批处理任务,即执行一次任务,它保证批处理任务的一个或多个Pod成功结束
Cron Job
管理基于时间的Jod,即
- 在给定的时间点只运行一次
- 周期性地在给定的时间点运行
3.1.2 Pod 服务发现

4 网络通讯方式
Kubernetes的网络模型假定了所有的Pod都在一个可以直接连通的扁平的网络空间中,这在GCE(Google Comute Engine)里面是现成的网络模型,Kubernetes假定这个网络已经存在。而在私有云里面搭建Kubernetes集群,就不能假定这个网络已经存在了。我们需要自己实现这个网络假设,将不同节点上的Docker容器之间的互相访问先打通,然后运行Kubernetes。
- 同一个Pod内的多个容器之间:lo
- 各Pod之间的通讯:Overlay Network
- Pod与Service之间通讯:各节点的Iptables规则
Flannel是CoreOS团队针对Kubernetes设计的一个网络规划服务,简单来说,它的功能是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址。而且它还能在这些IP地址之间建立一个覆盖网络(Overlay Network),通过这个覆盖网络,将数据包原封不动地传递到目标容器内。
etcd之Flannel提供说明
- 存储管理Flannel可分配的IP地址段资源
- 监控etcd中每个Pod的实际地址,并在内存中建立维护Pod节点路由表
学习地址:
https://www.bilibili.com/video/BV1w4411y7Go
<p><h3>文章目录</h3><ul><ul><li><a href="#1__2">1 介绍</a></li><li><a href="#2__6">2 组件介绍</a></li><ul><li><a href="#21__12">2.1 核心组件</a></li><ul><li><a href="#211_api_server_14">2.1.1 api server</a></li><li><a href="#212_ControllerManager_18">2.1.2 ControllerManager</a></li><li><a href="#213_Scheduler_22">2.1.3 Scheduler</a></li><li><a href="#214_etcd_26">2.1.4 etcd</a></li><li><a href="#215_Kubelet_40">2.1.5 Kubelet</a></li><li><a href="#216_Kubeproxy_44">2.1.6 Kube-proxy</a></li></ul><li><a href="#22__48">2.2. 其他插件</a></li><ul><li><a href="#221_CoreDNS_50">2.2.1 CoreDNS</a></li><li><a href="#222_dashboard_54">2.2.2 dashboard</a></li><li><a href="#223_Ingress_Controller_58">2.2.3 Ingress Controller</a></li><li><a href="#224_fedetation_62">2.2.4 fedetation</a></li><li><a href="#225_prometheus_66">2.2.5 prometheus</a></li><li><a href="#226_ELK_70">2.2.6 ELK</a></li></ul></ul><li><a href="#3_Pod_74">3 Pod</a></li><ul><li><a href="#31_Pod_76">3.1 Pod概念</a></li><ul><li><a href="#311_Pod_83">3.1.1 Pod服务类型</a></li><li><a href="#312_Pod__114">3.1.2 Pod 服务发现</a></li></ul></ul><li><a href="#4__119">4 网络通讯方式</a></li></ul></ul></p>
<h2><a id="1__2"></a>1 介绍</h2>
<p>高可用集群副本数据最好是 >= 3 奇数个</p>
<h2><a id="2__6"></a>2 组件介绍</h2>
<p>k8s架构</p>
<p><img src="https://static.couragesteak.com/article/d9fc8f435df7ad203ae855216f4c0552.png" alt="" /></p>
<h3><a id="21__12"></a>2.1 核心组件</h3>
<h4><a id="211_api_server_14"></a>2.1.1 api server</h4>
<p>所有服务访问统一入口</p>
<h4><a id="212_ControllerManager_18"></a>2.1.2 ControllerManager</h4>
<p>维护副本的期望数</p>
<h4><a id="213_Scheduler_22"></a>2.1.3 Scheduler</h4>
<p>负责介绍任务,选择合适的节点进行分配任务</p>
<h4><a id="214_etcd_26"></a>2.1.4 etcd</h4>
<p>键值对数据库,存储K8S集群的所有重要信息(持久化)</p>
<ul>
<li>ETCD<br />
etcd 的官方将它定位程一个可信赖的分布式键值存储服务,它能够为整个分布式集群存储一些关键服务数据,协助分布式集群的正藏运转。</li>
</ul>
<p><strong>架构图</strong></p>
<p><img src="https://static.couragesteak.com/article/ff85fc2bfd09f575809b66eddfd5c15b.png" alt="" /></p>
<p>AWL:日志<br />
Store:持久化写入本地磁盘</p>
<h4><a id="215_Kubelet_40"></a>2.1.5 Kubelet</h4>
<p>直接跟容器交互实现容器的生命周期管理</p>
<h4><a id="216_Kubeproxy_44"></a>2.1.6 Kube-proxy</h4>
<p>负责写入规则至IPTABELS、IPVS,实现服务映射访问的</p>
<h3><a id="22__48"></a>2.2. 其他插件</h3>
<h4><a id="221_CoreDNS_50"></a>2.2.1 CoreDNS</h4>
<p>可以为集群中的SVC创建一个域名、IP对应关系解析</p>
<h4><a id="222_dashboard_54"></a>2.2.2 dashboard</h4>
<p>给K8S集群提供一个B/S结构的访问体系</p>
<h4><a id="223_Ingress_Controller_58"></a>2.2.3 Ingress Controller</h4>
<p>官方只能实现四层代理,Ingress可以实现7层</p>
<h4><a id="224_fedetation_62"></a>2.2.4 fedetation</h4>
<p>提供一个可以跨集群中心多K8S统一管理功能</p>
<h4><a id="225_prometheus_66"></a>2.2.5 prometheus</h4>
<p>提供一个K8S集群监控能力</p>
<h4><a id="226_ELK_70"></a>2.2.6 ELK</h4>
<p>提供K8S集群日志统一分析介入平台</p>
<h2><a id="3_Pod_74"></a>3 Pod</h2>
<h3><a id="31_Pod_76"></a>3.1 Pod概念</h3>
<ul>
<li>自主式Pod</li>
<li>控制器管理的Pod</li>
</ul>
<p>注:官方不是安上面的分类的</p>
<h4><a id="311_Pod_83"></a>3.1.1 Pod服务类型</h4>
<p><strong>HPA</strong><br />
Horizontal Pod Autoscaling仅适用于Deployment和ReplicaSet,在V1版本中仅支持根据Pod的CPU利用率扩缩容,在vlalpha版本中,支持根据内存和用户自定义的metric扩缩容。</p>
<p><strong>StatefulSet</strong><br />
是为了解决有状态服务的问题(对应Deployments和ReplicaSets是为了无状态服务而假设),其场景包括:</p>
<ul>
<li>稳定的持久化存储:即Pod重新调度后还是能访问到相同的持久化数据,基于PVC来实现。</li>
<li>稳定的网络标志,即Pod重新调度后其PodName和HostName不变,基于Headless Service(即没有Cluster Ip的Service)来实现。</li>
<li>有序部署,有序扩展,即Pod是有顺序的,在部署或者扩展的时候要依据定义的顺序依次进行(即从0到N-1,在下一个运行之前所有的Pod必须都是Running和Read状态),基于init containers来实现</li>
<li>有序收缩,有序删除(即从N-1到0)</li>
</ul>
<p><strong>DaemonSet</strong><br />
确保全部(或者一些)Node上运行一个Pod的副本。当有Node加入集群时,也会为他们新增一个Pod。当有Node从集群移除时,这些Pod也会被回收。删除DaemonSet将会删除它创建的所有Pod</p>
<p>使用DaemonSet的一些典型用法</p>
<ul>
<li>运行集群存储daemon,例如在每个Node上运行glusterd、ceph</li>
<li>在每个Node上运行日志手机daemon,例如fluentd、logstash</li>
<li>在每个Node上运行监控daemon,例如Prometheus Node Exporter</li>
</ul>
<p><strong>Job</strong><br />
负责批处理任务,即执行一次任务,它保证批处理任务的一个或多个Pod成功结束</p>
<p><strong>Cron Job</strong><br />
管理基于时间的Jod,即</p>
<ul>
<li>在给定的时间点只运行一次</li>
<li>周期性地在给定的时间点运行</li>
</ul>
<h4><a id="312_Pod__114"></a>3.1.2 Pod 服务发现</h4>
<p><img src="https://static.couragesteak.com/article/04638ff4b251cd95f66b5a34f4c86f57.png" alt="Pod 服务发现" /></p>
<h2><a id="4__119"></a>4 网络通讯方式</h2>
<p>Kubernetes的网络模型假定了所有的Pod都在一个可以直接连通的扁平的网络空间中,这在GCE(Google Comute Engine)里面是现成的网络模型,Kubernetes假定这个网络已经存在。而在私有云里面搭建Kubernetes集群,就不能假定这个网络已经存在了。我们需要自己实现这个网络假设,将不同节点上的Docker容器之间的互相访问先打通,然后运行Kubernetes。</p>
<ul>
<li>同一个Pod内的多个容器之间:lo</li>
<li>各Pod之间的通讯:Overlay Network</li>
<li>Pod与Service之间通讯:各节点的Iptables规则</li>
</ul>
<p>Flannel是CoreOS团队针对Kubernetes设计的一个网络规划服务,简单来说,它的功能是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址。而且它还能在这些IP地址之间建立一个覆盖网络(Overlay Network),通过这个覆盖网络,将数据包原封不动地传递到目标容器内。</p>
<p><strong>etcd之Flannel提供说明</strong></p>
<ul>
<li>存储管理Flannel可分配的IP地址段资源</li>
<li>监控etcd中每个Pod的实际地址,并在内存中建立维护Pod节点路由表</li>
</ul>
<p>学习地址:<br />
https://www.bilibili.com/video/BV1w4411y7Go</p>
留言