前言

对于云计算来说我们都知道它会有这样的一些交互标准。例如
IaaS （Infrastructure as a Service 基础设施即服务）
PaaS（Platform as a Service 平台设施即服务)
SaaS (Software as a Service 软件设施即服务）
等等…

我们最早可以接触到的资源管理平台有两个：MESOS 和 dockerSwarm

MESOS

Mesos 是 Apache 下的开源分布式资源管理框架，它被称为是分布式系统的内核。 Mesos 最初是由加州大学伯克利分校的AMPLab开发的，后来被 Twitter 选中作为它的基础平台，进而被广泛应用。
但是呢，好景不长，在 2019-5 旧金山的Twitter发布会上 Twitter 的技术人员宣布以后将停止使用 Mesos ，转为我们现在所熟知的 Kubernetes 。

dockerSwarm

Swarm是Docker公司在2014年12月初新发布的容器管理工具。和Swarm一起发布的Docker管理工具还有Machine以及Compose，号称Docker三剑客。Swarm项目是Docker公司发布三剑客（Swarm，Compose，Machine）中的一员，用来提供容器集群服务，目的是更好的帮助用户管理多个Docker Engine，方便用户使用，像使用Docker Engine一样使用容器集群服务。
但是现在呢已经销声匿迹很久了，随之而来的也是我们的Kubernetes 。

主角 ：Kubernetes

Kubernetes 是用于自动部署，扩展和管理容器化应用程序的开源系统。它将组成应用程序的容器组合成逻辑单元，以便于管理和服务发现。Kubernetes 源自Google 15 年生产环境的运维经验，同时凝聚了社区的最佳创意和实践。
Kubernetes里边有个非常著名的组件叫 Borg 它呢是Google内部的管理这些所谓的容器的这样一个框架。叫“资源管理器”。这个是归Google公司独有的这么一个技术，但是随着docker 的大规模运行，Google发现大家这个时候都开始研究这个资源管理器了，这个时候我就要站出来说点话了。万一以后这个趋势不是我领导的岂不是很尴尬。在日后的一段时间里，Google派了几名工程师用 GO语言 对 borg 的系统进行翻写。也就开发了新的组件，也就是我们现在所熟知的 Kubernetes

特点：

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

适合人群：

软件工程师 测试工程师 运维工程师 软件架构师 项目经理

Kubernetes结构详解

因为这个思维导图确实比较大不方便展开所以我就放在了文档里
点击链接下载详细查看吧（免费的哦！！！！！）
https://download.csdn.net/download/m0_51277041/84544881

虽然很大很详细看起来会很迷茫，但是我们只要捋清思路。搞清楚几个基础概念一样可以很快熟悉Kubernetes 。我从Kubernetes结构详解中抽取了一些我自己总结出来的几点，分享给大家。

什么是 Pod 、控制器类型 、 K8S 网络通讯模式 。
Kubernetes： 构建 K8S 集群。
资源清单： 资源、掌握资源清单的语法、编写 Pod、掌握 Pod 的生命周期。
Pod 控制器： 掌握各种控制器的特点以及使用定义方式。
服务发现： 掌握 SVC 原理及其构建方式。
存储： 掌握多种存储类型的特点 并且能够在不同环境中选择合适的存储方案。
调度器： 掌握调度器原理 能够根据要求把Pod 定义到想要的节点运行。
安全： 集群的认证 鉴权 访问控制 原理及其流程 。
HELM： 类似于Linux yum。掌握 HELM 原理 、HELM 模板自定义、HELM 部署一些常用插件。
运维： 修改Kubeadm 达到证书可用期限为 10年。 能够构建高可用Kubernetes 集群。
服务分类：
有状态服务：DBMS
无状态服务：LVS 、APACHE

Kubernetes组件说明

Borg架构

我们都知道Kubernetes其实是我们的Borg系统通过GO语言重新编译或者说重构来的，那我们先去了解一下Borg架构，可能对后续理解Kubernetes是更有帮助的。

可以看出Borg架构是由很多的 BorgMaster 和 Borglet 组成的。
BorgMaster 就是去负责这些请求的分发的。你可以理解它为整个集群的大脑。真正去工作的就是我们的 Borglet。
我们可以看到不管是BorgMaster 还是 Borglet 都是有很多副本的。
那为什么需要这么多的副本呢？而且副本的数量为什么是5个呢？是1个不行吗？怎么都是奇数个，偶数个不行吗？我知道小伙伴们的心理肯定会有这样的疑问，我们下面来一一解答。
首先我们知道BorgMaster 是我们整个集群的大脑，那如果只有1个节点，是不是会造成单节点故障呢。如果是2个节点
，你一票我一票，我们两个听谁的呢，这就牵扯到一个指挥权的问题。所以我们的节点个数最好是3、5、7、9这样的奇数个。
我们有三种方式：web broesers 、command-linetools、borgcfg 来对BorgMaster进行调度管理.我们分发任务的时候需要根据不同的任务分发给不同Borglet 。如何精确的区别这些任务呢？就是我们的 scheduler (调度器)。而 scheduler 并不直接与我们的Borglet 进行交互。而是把任务写进Google的一个键值对的额这样一个数据库 Paxos。当有请求发送的时候它会自动去匹配Borglet 进行工作。

Kubernetes架构

我们可以看到图片仍是有两大部分组成的 Master 节点和 node 节点组成

Master 节点

我们可以看到Master节点中所指箭头几乎都与 api server 有关联和交互。那我们的scheduler依然是我们的调度器。
kubectl 是我们kubernetes的命令行。web UI 就是网页。replication controller (简称rc)是我们的控制器，用来维护我们期望的副本数量。etcd呢其实是来存放我们的Kubernetes的一些组件信息的。那可以看到我们的 api server 其实是非常繁忙的，那为了减轻我们 api server 的压力，其他的组件是可以在本地生成缓存，并不需要每件事情都到 api server 去进行请求。

node 节点

如图所示需要在我们的node节点安装3个软件 kubelet 、kube proxy、docker。
1、kubelet 会跟我们的 CRI(Container Runtime Interface) 也就是我们docker在这里的表现形式。kubelet 会与我们的docker进行交互，操作docker去创建对应的容器，kubelet会维持我们的一个pod的生命周期。
【扩展】
Kubernetes节点的底层由一个叫做“容器运行时”的软件进行支撑，它负责比如启停容器这样的事情。最广为人知的容器运行时当属Docker，但它不是唯一的。事实上，容器运行时这个领域发展迅速。为了使Kubernetes的扩展变得更容易，一款支持容器运行时的K8s插件API：容器运行时接口(Container Runtime Interface, CRI)诞生了。

Kubelet与容器运行时通信（或者是CRI插件填充了容器运行时）时，Kubelet就像是客户端，而CRI插件就像对应的服务器。它们之间可以通过Unix 套接字或者gRPC框架进行通信。

2、kube proxy 是实现我们pod 与 pod 之间的访问，包括负载均衡。它的默认操作对象是操作防火墙（firewall）去实现pod 的映射，当然我们的新版本中还支持 IPVS。

同时高可用集群副本数据最好是 >= 3 奇数个

同时还把一些参数对应的服务整理出来供大家参考：

APISERVER：所有服务访问统一入口。
CrontrollerManager： 维持副本期望数目。
Scheduler： 负责介绍任务，选择合适的节点进行分配任务。
ETCD： 键值对数据库 储存K8S集群所有重要信息（持久化）。
Kubelet： 直接跟容器引擎交互实现容器的生命周期管理。
Kube-proxy： 负责写入规则至 IPTABLES、IPVS 实现服务映射访问的。
COREDNS： 可以为集群中的SVC创建一个域名IP的对应关系解析。
DASHBOARD： 给 K8S 集群提供一个 B/S 结构访问体系。
INGRESS CONTROLLER： 官方只能实现四层代理，INGRESS 可以实现七层代理。
FEDERATION： 提供一个可以跨集群中心多K8S统一管理功能。
PROMETHEUS： 提供K8S集群的监控能力。
ELK： 提供 K8S 集群日志统一分析介入平台。

Pod概念

自主式 Pod
控制器管理的 Pod

控制器类型

1、Replication Controller & ReplicaSet & Deployment

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

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

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

2、HPA （HorizontalPodAutoScale)
Horizontal Pod Autoscaling仅适用于Deployment和 ReplicaSet，在V1版本中仅支持根据Pod的CPU利用率扩所容，在 vlalpha 版本中，支持根据内存和用户自定义的 metric扩缩容

3、StatefullSet
StatefulSet 是为了解决有状态服务的问题(对应Deployments和 ReplicaSets是为无状态服务而设计），其应用场景包括：
稳定的持久化存储，即 Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现。
稳定的网络标志，即 Pod 重新调度后其 PodName和 HostName不变，基于Headless Service(即没有iuster IP的Service )来实现。
有序部署，有序扩展，即 Pod 是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依次进行(即从О到N-1，在下一个 Pod运行之前所有之前的 Pod必须都是Running 和 Ready状态），基于init containers 来实现。
有序收缩，有序删除（即从N-1到0)。
4、DaemonSet
DaemonSet确保全部(或者一些)Node 上运行一个 Pod 的副本。当有 Node 加入集群时，也会为他们新增一个Pod。当有 Node从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有Pod
使用DaemonSet的一些典型用法：
运行集群存储daemon，例如在每个Node 上运行glusterd、ceph。
在每个Node上运行日志收集daemon，例如fluentd、logstash。
在每个Node上运行监控 daemon，例如 Prometheus Node Exporter。
5、Job，Cron job
Job 负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个Pod成功结束

Cron Job 管理基于时间的 Job，即：
在给定时间点只运行一次。
周期性地在给定时间点运行。

服务发现

网络通讯方式

模式1：

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

模式2：

同一个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
〉Pod1 与Pod2不在同一台主机，Pod的地址是与docker0在同一个网段的，但dockerO网段与宿主机网卡是两个完全不同的IP网段，并且不同Node之间的通信只能通过宿主机的物理网卡进行。将Pod的IP和所在Node的IP关联起来，通过这个关联让Pod可以互相访问。
〉Pod1 与Pod2在同一台主机，由 Docker0网桥直接转发请求至Pod2，不需要经过Flannel 。

Pod 至Service 的网络:目前基于性能考虑，全部为iptables 维护和转发。

Pod到外网: Pod向外网发送请求，查找路由表，转发数据包到宿主机的网卡，宿主网卡完成路由选择后，iptables执行Masquerade，把源IP更改为宿主网卡的IP，然后向外网服务器发送请求。

外网访问Pod: Service

组件通讯示意图