K8S系统（三）——K8S介绍及相关名词简述

【前言】

  按照系列的前两篇文章操作，不出意外的话，K8S集群已经部署好。在正式开始后面的实操前，我们需要熟悉下K8S及其相关名词，先对其有概念，接下来的操作才更加丝滑。

【K8S的起源】

  谈到 Kubernetes，就绕不开 Docker。
  2010 年几个搞 IT 的年轻人在旧金山使用谷歌 go 语言开发了一个创建和管理容器的工具供公司内部使用，命名为 Docker。其寓意是用 Docker 这艘船承载 container（集装箱）以封装和支撑各类应用服务。
  这一阶段 Docker 是一个闭源工具，其技术仅限于企业内部使用，没有引起 IT 行业的任何关注。当时 Docker 所在的公司在激烈的市场竞争下步履维艰。  
  2013 年 3 月公司就要坚持不下去了，以 Solomon Hykes 为首的技术团队沮丧之余，不忍让 Docker 这样的前沿容器技术付之东流，抱着破罐子破摔试一试的心态，将 Docker 在 GitHub 社区上彻底开源。开源之时使用的一句宣传标语是“Build Once, Run Everywhere”，即“一次构建，随处运行”。
  万万没想到，不开则已，一开惊人。这就像打开了容器领域的潘多拉魔盒，越来越多的 IT 工程师发现了 Docker 的优点，大家蜂拥而至加入 Docker 开源社区学习并作出贡献。Docker 人气迅速攀升，所在公司迅速起死回生，这项技术的传播速度之快，令早就在使用和推广容器等 IT 基础设施技术的 Google 等互联网国际大厂瞠目结舌。
  随着 Docker 在容器技术开源社区站稳脚跟，并在多个场合和商业应用场景挑战了 Google 的切身利益。Google 管理层深感不妙，在 Docker 项目刚兴起的同一年就迅速祭出一剑：将内部生产验证的容器栈管理工具 MCTFY （Let Me Container That For You） 开源。另一方面，Google 还有意支持 Docker 的多个竞争对手和项目发展，但事与愿违，面对 Docker 的强势崛起和渗透，Google 的这些举措表现得毫无招架之力。
  战局节节败退，Google 作为财力雄厚的互联网财阀，直接开出高价有意买断 Docker。但 Docker 的技术总监兼联合创始人 Solomon Hykes 估计是一位理想主义者，雄心万丈的他对抛来的这枚橄榄枝不屑一顾。技术牛人就是这么率真、耿直！
  容器战场的连番失利和收购意图被漠视，促使 Google 高层改变策略，2014 年6 月在开源社区放出了内部雪藏近十年的底层核心技术，即大规模集群管理系统 Borg，这就是 Kubernetes 的前身。
  IT 江湖，技术为先。如同当年 Docker 横空出世一样，Kubernetes 再一次改写了容器市场的格局。2015 年 7 月 Kubernetes 1.0 正式发布。同年 Google 宣布成立 CNCF，全称 Cloud Native Computing Foundation（云原生计算基金会），建立以 Kubernetes 为中心的云原生解决方案开放生态体系。
  2017 年 Docker 将容器运行时部分 Containerd 捐献给 CNCF 社区，同年 10 月又宣布将 Docker 企业版内置到 Kubernetes 项目，持续了几年的容器编排之争终于落下帷幕。

【K8S简介】

  Kubernetes是一个开源容器编排引擎，kubernetes是希腊语『舵手』的意思，简称K8s，是用8代替名字中间的8个字符“ubernete”而成的缩写，它是Google大规模集群管理系统Borg的开源版本，深受公司内部Borg和Omega项目的影响。Kubernetes 已然成为事实上的容器编排标准，是运维、开发人员使用最流行的微服务、DevOps、CI/CD 云原生底座，其将超过15年的Google在大规模生产工作负载方面的经验与社区中最好的想法和实践相结合，其于2014年9月发布第一个版本，2015年7月发布第一个正式版本。
  K8S的目标是让部署容器化的应用简单并且高效（powerful）,提供了应用部署，规划，更新，维护的一种机制。在Kubernetes中，我们可以创建多个容器，每个容器里面运行一个应用实例，然后通过内置的负载均衡策略，实现对这一组应用实例的管理、发现、访问，而这些细节都不需要运维人员去进行复杂的手工配置和处理。
  K8S的出现不仅主宰了容器编排的市场，更改变了过去的运维方式，不仅将开发与运维之间边界变得更加模糊，而且让DevOps这一角色变得更加清晰，每一个软件工程师都可以通过Kubernetes来定义服务之间的拓扑关系、线上的节点个数、资源使用量并且能够快速实现水平扩容、蓝绿部署等在过去复杂的运维操作。

【K8S特点】

自我修复：一旦某个容器出现异常，能够迅速启动新的容器
弹性伸缩：按需自动对集群中正在运行的容器数量进行调整
服务发现：通过自动发现的形式找到当前 Service 所依赖的新生服务
负载均衡：如果 Service 启动了多个容器，能够自动实现请求的负载均衡
版本回退：若发现新发布的程序版本有问题，可以立即回退到原来的版本
存储编排：可以根据容器自身的需求自动创建存储卷，支持本地存储、公共云提供商等

【K8S名词解释】
Cluster
Cluster 是计算、存储和网络资源的集合，Kubernetes 利用这些资源运行各种基于容器的应用

Master
集群控制节点，每个集群需要至少一个master节点负责集群的管控。Master 是 Cluster 的大脑，它的主要职责是调度，即决定将应用放在哪里运行。Master运行Linux操作系统，可以是物理机或者虚拟机。为了实现高可用，可以运行多个 Master

Node
Node 的职责是运行容器应用。Node 由 Master 管理，Node 负责监控并汇报容器的状态，并根据 Master 的要求管理容器的生命周期。Node 运行在 Linux 操作系统，可以是物理机或者是虚拟机。工作负载节点，由master分配容器到这些node工作节点上，然后node节点上的docker负责容器的运行

Pod
Pod是kubernetes的最小控制单元，容器都是运行在pod中的，一个pod中可以有1个或者多个容器。Pod 中的容器会作为一个整体被 Master 调度到一个 Node 上运行
Kubernetes 引入 Pod 主要基于下面两个目的：
可管理性
有些容器天生就是需要紧密联系，一起工作。Pod 提供了比容器更高层次的抽象，将它们封装到一个部署单元中。Kubernetes 以 Pod 为最小单位进行调度、扩展、共享资源、管理生命周期
通信和资源共享
Pod 中的所有容器使用同一个网络 namespace，即相同的 IP 地址和 Port 空间。它们可以直接用 localhost 通信。同样的，这些容器可以共享存储，当 Kubernetes 挂载 volume 到 Pod，本质上是将 volume 挂载到 Pod 中的每一个容器

Controller
控制器，通过它来实现对pod的管理，比如启动pod、停止pod、伸缩pod的数量等等

Service
pod对外服务的统一入口，下面可以维护者同一类的多个pod

Label
标签，用于对pod进行分类，同一类pod会拥有相同的标签

NameSpace
命名空间，用来隔离pod的运行环境

【K8S组件】

Master主要组件
Master组件提供集群的管理控制中心，可以在集群中任何节点上运行。但是为了简单起见，通常在一台VM/机器上启动所有Master组件，并且不会在此VM/机器上运行用户容器
1. kube-apiserver    所有服务访问的统一入口
kube-apiserver用于暴露Kubernetes API，使用的是RESTAPI接口，也是唯一一个与 etcd集群通信的组件。kube-apiserver是所有服务访问的唯一入口，任何的资源请求/调用操作都是通过kube-apiserver提供的接口进行，提供了认证、授权、访问控制、API注册和发现等机制，其他所有组件都必须通过它提供的API来操作资源数据，通过对相关的资源数据“全量查询”+“变化监听”，这些组件可以很“实时”地完成相关的业务功能

2. etcd            负责存储K8S集群的所有信息（可持久化）
etcd是Kubernetes提供默认的存储系统，保存所有集群数据，使用时需要为etcd数据提供备份计划。

3. kube-controller-manager   运行管理控制器，维持副本期望数量
负责维护集群的状态，比如副本期望数量、故障检测、自动扩展、滚动更新等。集群中处理常规任务的后台线程。逻辑上，每个控制器是一个单独的进程，但为了降低复杂性，它们都被编译成单个二进制文件，并在单个进程中运行。生命周期管理。相比之下，APIServer负责接收用户的请求，并完成集群内资源的“增删改”，而controller manager系统中扮演的角色是在一旁默默地管控这些资源，确保它们永远保持在用户所预期的状态
这些控制器包括：
Service控制器
节点（Node）控制器
路由（Route）控制器
卷（Volume）控制器
副本（Replication）控制器：负责维护系统中每个副本中的pod
端点（Endpoints）控制器：填充Endpoints对象（即连接Services&Pods）
Service Account和Token控制器：为新的Namespace创建默认帐户访问API Token

4. cloud-controller-manager  云控制器管理器
云控制器管理器负责与底层云提供商的平台交互。云控制器管理器是Kubernetes版本1.6中引入的，还是Alpha的功能。云控制器管理器仅运行云提供商特定的（controller loops）控制器循环。可以通过将--cloud-providerflag设置为external启动kube-controller-manager ，来禁用控制器循环

5. kube-scheduler    负责选择合适的节点进行任务分配
它的作用是根据特定的调度算法将pod调度到指定的工作节点Node上，这一过程通常被称为绑定(bind)

6. kubectl      直接和容器引擎交互实现容器的生命周期管理

Node主要组件
节点组件运行在Node，提供Kubernetes运行时环境，以及维护Pod。Worker 节点实现就相对比较简单了，它主要由 kubelet 和 kube-proxy 两部分组成
1. kubelet
kubelet是工作节点执行操作的 agent，负责具体的容器生命周期管理，根据从数据库中获取的信息来管理容器，并上报 pod 运行状态等。负责维护本节点上 Pod 任务的生命周期，通过控制 Docker 引擎来创建、启动、停止和删除，同事定时上报节点状态信息到 API Server

2. kube-proxy    负责写入规则到IPVS来实现服务映射访问
kube-proxy在每个工作节点上都有一个，是一个简单的网络访问代理，同时也是一个 Load Balancer。它负责将访问到某个服务的请求具体分配给工作节点上同一类标签的 Pod。kube-proxy 实质就是通过操作防火墙规则(iptables或者ipvs)来实现 Pod 的映射。负责为 Service 提供 cluster 内部的服务发现和负载均衡

3. cni      容器运行时
容器运行环境是负责运行容器的软件，Kubernetes 支持多个容器运行环境: Docker、 containerd、cri-o、 rktlet 以及任何实现 Kubernetes CRI(容器运行环境接口)

推荐组件
dashboard     用户界面，给K8S集群提供一个B/S结构的访问界面
CoreDNS     为集群中的SVC创建一个域名到IP的对应关系解析
IngressController 官方只能够实现四层的网络代理，而 Ingress 可以实现七层的代理
Federation     提供可以跨集群中心多K8S统一管理功能
Prometheus   提供K8S集群的服务即系统监控
ELK              提供K8S集群日志统一分析介入平台
Fluentd        负责保存容器日志，搜索/查看日志
Flannel      容器网络通信方案

K8S组件调用调用关系例子

以部署一个nginx服务来说明kubernetes系统各个组件调用关系：

首先要明确，一旦kubernetes环境启动之后，master和node都会将自身的信息存储到etcd数据库中

一个nginx服务的安装请求会首先被发送到master节点的apiServer组件

apiServer组件会调用scheduler组件来决定到底应该把这个服务安装到哪个node节点上

在此时，它会从etcd中读取各个node节点的信息，然后按照一定的算法进行选择，并将结果告知apiServer

apiServer调用controller-manager去调度Node节点安装nginx服务

kubelet接收到指令后，会通知docker，然后由docker来启动一个nginx的pod

pod是kubernetes的最小操作单元，容器必须跑在pod中至此，

一个nginx服务就运行了，如果需要访问nginx，就需要通过kube-proxy来对pod产生访问的代理

K8S技术生态全景图
https://landscape.cncf.io/

参考链接：
https://baike.baidu.com/item/kubernetes/22864162?fr=aladdin
https://blog.csdn.net/qq_25854057/article/details/122223620   
https://zhuanlan.zhihu.com/p/403308354  这个链接还包括一些控制器、Service等的解释，写的比较简明易懂，建议看下。后续有时间我看下是补充在这篇文章，还是另写