kubernetes概述

1.Kubernetes简介

官网链接：https://kubernetes.io/zh-cn/

• kubernetes是可移植、可扩展、开源的容器管理平台，是谷歌Borg的开源版本，简称k8s，它可以创建应用、更新应用、回滚应用，也可实现应用的扩容缩容，做到故障自恢复。

  • 可移植：基于镜像可从一个环境迁移到另一个环境
  • 可扩展：k8s集群可以横向扩展、根据流量实现自动扩缩容
  • 开源的：源代码已经公开了，可以被用户免费使用，可以二次开发

  可以对容器自动化部署、自动化扩缩容、跨主机管理等；

  可以对代码进行灰度发布、金丝雀发布、蓝绿发布、滚动更新等；

  具有完整的监控系统和日志收集平台，具有故障自恢复的能力。

1.1Kubernetes起源

Kubernetes单词起源于希腊语, 是“舵手”或者“领航员、飞行员”的意思。

Google公司看到的docker的流行，2014年2月开始研发容器编排系统kubernetes(简称"k8s")。

k8s集成了Google商业化编排系统"Omega"(第一代),“Borg”(第二代)两代编排系统的优点于一身，在Google公司内部经了15年的测试，每周数十亿容器运行。

K8S是在Borg的基础上开发出来的轻量级容器编排工具。K8S的根基非常牢固，得益于Borg过去十数年间积累的经验和教训，是站在巨人的肩膀上发展起来的项目。开源之后，迅速称霸容器编排技术领域。

k8s在2014年6月6日首次发布。

2.CNI，OCI，CRI技术词汇

2.1 CNI（Container Networker Interface）

CNI全称为"Container Networker Interface"。主要是用于容器跨主机互联提供基础网络服务。

k8s本身并不提供容器跨主机互联，而是声明了CNI规范，凡事遵循了CNI规范都可以被k8s集群用作网络基础组件。

目前市面上比较流行且符合CNI标准的代表有: Flannel，Calico。

推荐阅读：https://kubernetes.io/zh-cn/docs/concepts/cluster-administration/addons

2.2 OCI（Open Container Initative）

​ 业内最早的容器运行时环境(Runtime)是LXC，起初Docker就是利用LXC做容器管理引擎，但是在创建容器用户空间时不在用LXC的模板现场安装生成容器，而是先通过一种镜像技术，把一个操作系统用户空间所要用到的所有组件事先准备编排好打包成一个文件，这个文件Docker称之为镜像文件。

​ 但后来觉得隔离性差，后来采用libcontainer组件，不过此时Docker已被CNCF挟持了，当然容器的话语权依旧归Docker公司，这并不是说CNCF组织没有能力定制Docker的标准，只不过他们真那样做就太欺负Docker公司了。

​ 后来Docker又转型到runC，所以说到目前为止，runC是Docker的独生子。

随着LXC，LXD，Docker，Rkt等容器运行时环境各有不同，这时候容器运行时的确是有点多了，开放容器倡议(Open Container Initiative，简称"OCI")由多家公司共同成立的项目，并由linux基金会进行管理。

​ OCI（全称为"Open Container Initative"）是建立围绕容器格式和运行时的开放式行业标准的明确目的的开放式的治理结构。OCI由Docker和其他容器行业的领导者于2015年6月建立，但在2015年12月18日才在GitHub上发布的"v0.1.1"。

所谓container runtime，主要负责的是容器的生命周期的管理。OCI目前包含两个规范：运行时规范(runtime-spec)和映像规范(image-spec)。

(1)OCI的runtime spec标准中对于容器的状态描述，创建，删除，查看等操作进行了定义，以及容器运行时如何运行指定文件系统上的包;

(2)OCI的image-spec标准在定义了如何创建一个OCI运行时可运行的文件系统上的包;

Docker公司将容器镜像格式和runtime(也就是runc)都捐献给了Open Container Initiative组织。runc是对于OCI标准的一个参考实现，是一个可以用于创建和运行容器的CLI(command-line interface)工具。

runc直接与容器所依赖的cgroup/linux kernel等进行交互，负责为容器配置cgroup/namespace等启动容器所需的环境，创建启动容器的相关进程。

为了兼容OCI标准，docker也做了架构调整。2016年12月14日，Docker公司宣布将将容器运行时相关的程序从docker daemon剥离出来，形成了containerd。而早在同年的2月份，Docker 1.11的Docker Engine里就包含了containerd。

Containerd向docker提供运行容器的API，二者通过grpc进行交互。containerd最后会通过runc来实际运行容器。其架构如下图所示。

2.3 CRI（全称为"Container Runtime Interface")

​ kubernetes在初期版本里，就对多个容器引擎做了兼容，因此可以使用docker、rkt对容器进行管理。以docker为例，kubelet中会启动一个docker manager，通过直接调用docker的api进行容器的创建等操作。

在kubernetes中，pod是由一组进行了资源限制的，在隔离环境中的容器组成。而这个隔离环境，称之为PodSandbox。

据说是Google(对K8S源码贡献第一)和RedHat(对K8S源码贡献第二)这两家公司有意将Docker边缘化，因此大力扶持由CoreOS公司2014年开源的轻量级rkt容器工具引擎。

在Kubernetes早期版本，主要是支持docker和rkt两种容器引擎，这需要Kubernetes官方做大量的工作来兼容这两种容器，而兼容会带来很多维护性工作。

于是在OCI提出一年后，大概在2016年12月19日，即在k8s 1.5版本之后，kubernetes推出了自己的运行时接口Container Runtime Interface(下面简称"CRI")。

凡是支持CRI皆可作为K8S的底层运行时，CRI接口的推出，隔离了各个容器引擎之间的差异，而通过统一的接口与各个容器引擎之间进行互动。

与OCI不同，CRI与kubernetes的概念更加贴合，并紧密绑定。CRI不仅定义了容器的生命周期的管理，还引入了k8s中pod的概念，并定义了管理pod的生命周期。

但Docker本身并未实现CRI，因此使用临时解决方案: 其中kubelet是通过CRI接口，调用docker-shim，并进一步调用docker api实现的。但这增大了K8S官方的工作负担，于是在2020年12月宣布将来会弃用docker-shim。

如上文所述，docker独立出来了containerd。kubernetes也顺应潮流，孵化了cri-containerd项目，用以将containerd接入到cri的标准中。

为了进一步与oci进行兼容，kubernetes还孵化了cri-o，成为了架设在cri和oci之间的一座桥梁。通过这种方式，可以方便更多符合oci标准的容器运行时，接入kubernetes进行集成使用。

可以预见到，通过cri-o，kubernetes在使用的兼容性和广泛性上将会得到进一步加强。

大概在2017年左右，Docker将自身的容器运行时(即"containerd")捐给了CNCF组织(该组织维护的是Kubernetes开源产品)。同年，Docker的网络组建(libnetwork)增加了CNI的支持，同时实现基于IPVS的SERVICE负载均衡。

来自谷歌、Docker、IBM、中兴通讯和ZJU的工程师们致力于为containerd实现CRI。该项目名为cri containerd，其特性在2017年9月25日发布了完整的v1.0.0-alpha.0版本。

在2018年5月24日，Kubernetes GA版本正式集成了cri containerd架构。使用cri containerd，用户可以运行Kubernetes集群，使用containerd作为底层运行时，而无需安装Docker。

2019年8月16日，CNCF组织正式将rkt归档，结束了rkt容器的在Kubernetes的生命周期，在此之前，2018年4月16日是发布的最新rkt容器工具。

3.图解K8S集群架构组件

• k8s的物理架构是master/node模式，master节点负责管理集群，node节点是容器应用真正运行的地方

  • K8S集群至少需要一个主节点(Master)和多个工作节点(Worker)，Master节点是集群的控制节点，负责整个集群的管理和控制，主要用于暴露API、调度部署和对节点进行管理。工作节点主要是运行容器的。
  • master节点包含的组件有：kube-api-server、kube-controller-manager、kube-scheduler、etcd。node节点包含的组件有：kubelet、kube-proxy、container-runtime。

• 单master节点架构图如下：

master 组件

• API Server:

kube-apiserver，提供k8s api，是整个系统的对外接口，提供资源操作的唯一入口，供客户端和其它组件调用，提供了k8s各类资源对象（pod,deployment,Service等）的增删改查，是整个系统的数据总线和数据中心，并提供认证、授权、访问控制、API注册和发现等机制，并将操作对象持久化到etcd中。

• Etcd:

分布式键值存储系统，用于保存集群状态元数据信息，比如Pod，Service等对象信息。这个数据库是可以单独拿出来部署，只需要API server可以连接到该分布式数据库集群即可。

• Scheduler:

  负责k8s集群中pod的调度的 ， scheduler通过与apiserver交互监听到创建Pod副本的信息后，它会检索所有符合该Pod要求的工作节点列表，开始执行Pod调度逻辑。调度成功后将Pod绑定到目标节点上，相当于“调度室”

• Controller Manager:

Kube-controller-manager，处理集群中常规后台任务，一个资源对应一个控制器，而ControllerManager就是负责管理这些控制器的。作为集群内部的管理控制中心，负责集群内的Node、Pod副本、服务端点（Endpoint）、命名空间（Namespace）、服务账号（ServiceAccount）、资源定额（ResourceQuota）的管理，当某个Node意外宕机时，Controller Manager会及时发现并执行自动化修复流程，确保集群始终处于预期的工作状态。

有许多不同类型的控制器。以下是一些例子：

• 节点控制器（Node Controller）：负责在节点出现故障时进行通知和响应

• 任务控制器（Job Controller）：监测代表一次性任务的 Job 对象，然后创建 Pod 来运行这些任务直至完成

• 端点分片控制器（EndpointSlice controller）：填充端点分片（EndpointSlice）对象（以提供 Service 和 Pod 之间的链接）。

• 服务账号控制器（ServiceAccount controller）：为新的命名空间创建默认的服务账号（ServiceAccount）。

• Cloud Controller Manager:

用在云平台上的Kube-controller-manager组件。如果我们直接在物理机上部署的话，可以不使用该组件。

云控制器管理器（Cloud Controller Manager）允许将你的集群连接到云提供商的 API 之上， 并将与该云平台交互的组件同与你的集群交互的组件分离开来。

cloud-controller-manager 仅运行特定于云平台的控制器。 因此如果你在自己的环境中运行 Kubernetes，或者在本地计算机中运行学习环境， 所部署的集群不需要有云控制器管理器。

与 kube-controller-manager 类似，cloud-controller-manager 将若干逻辑上独立的控制回路组合到同一个可执行文件中， 供你以同一进程的方式运行。 你可以对其执行水平扩容（运行不止一个副本）以提升性能或者增强容错能力。

​ 下面的控制器都包含对云平台驱动的依赖：

• 节点控制器（Node Controller）：用于在节点终止响应后检查云提供商以确定节点是否已被删除
• 路由控制器（Route Controller）：用于在底层云基础架构中设置路由
• 服务控制器（Service Controller）：用于创建、更新和删除云提供商负载均衡器

Node 组件

• kubelet:

可以理解为Master在工作节点上的Agent，管理本机运行容器的生命周期，比如创建容器，Pod挂载数据卷，下载secret，获取容器的节点状态等工作。kubelet将每一个Pod转换成一组容器。

kubelet 会在集群中每个[节点（node）上运行。 它保证[容器（containers）都运行在 Pod中。

kubelet 接收一组通过各类机制提供给它的 PodSpec，确保这些 PodSpec 中描述的容器处于运行状态且健康。 kubelet 不会管理不是由 Kubernetes 创建的容器。

​

• kube-proxy:

在工作节点上实现Pod网络代理，维护网络规则和四层负载均衡工作。换句话说，就是用于负责Pod网络路由，用于对外提供访问的实现。可以找到你关心的项目所在的pod节点。

提供网络代理和负载均衡，是实现service的通信与负载均衡机制的重要组件，kube-proxy负责为Pod创建代理服务，从apiserver获取所有service信息，并根据service信息创建代理服务，实现service到Pod的请求路由和转发，从而实现K8s层级的虚拟转发网络，将到service的请求转发到后端的pod上。

• Cordns：

CoreDNS 其实就是一个 DNS 服务，而 DNS 作为一种常见的服务发现手段，很多开源项目以及工程师都会使用 CoreDNS 为集群提供服务发现的功能，Kubernetes 就在集群中使用 CoreDNS 解决服务发现的问题。

• Calico：

是一套开源的网络和网络安全方案，用于容器、虚拟机、宿主机之前的网络连接，可以用在kubernetes、OpenShift、DockerEE、OpenStrack等PaaS或IaaS平台上

• Pod:

用户划分容器的最小单位，一个Pod存在多个容器。

• 容器运行时（Container Runtime）

这个基础组件使 Kubernetes 能够有效运行容器。 它负责管理 Kubernetes 环境中容器的执行和生命周期。

Kubernetes 支持许多容器运行环境，例如 containerd、 CRI-O 以及 Kubernetes CRI (容器运行环境接口) 的其他任何实现

参考链接：https://kubernetes.io/zh/docs/concepts/overview/components//

Kubeadm安装k8s集群

参看上一篇博客：http://t.csdnimg.cn/Lzilr