K8S（一）--概述

1. 编排的概述
2. K8S功能、框架
3. K8S架构、组件
4. K8S核心概念
5. K8S流行流程

1.编排的概述

        1.1  编排背景、含义

Docker平台以及周边生态系统包含很多工具来管理容器的生命周期。例如，Docker Command Line Interface(CLI)满足在单个主机上管理容器的需求，但是面对部署在多个主机上的容器时就无所适从了。为了超越单个容器管理，我们必须转向编排工具。容器编排工具将生命周期管理能力扩展到部署在大量机器集群上部署的复杂的、多容器工作负载。

容器编排关键能力概括 ：

集群管理、部署、可伸缩性、健康、基础结构抽象化、资源优化、资源分配、服务可用性、敏捷性、隔离

        1.2   其他的编排工具

mesos                 swarm

2.K8S功能、框架

        2.1  K8S功能

服务发现和负载均衡 ：

  Kubernetes 可以使用 DNS 名称或自己的 IP 地址公开容器, 如果进入容器的流量很大, Kubernetes 可以负载均衡并分配网络流量, 从而使部署稳定. 常用的DNS插件为coreDNS, 用作服务发现和集群中容器通讯; 负载均衡器常使用集群内的service资源进行对外暴露服务, 同时也提供ingress插件接口对外暴露服务

存储编排 ：

 Kubernetes 允许你自动挂载你选择的存储系统, 例如本地存储、公共云提供商等. 对于集群内部的应用有时会需要持久化数据, 这时容器如果被删除数据也会随之消失, 所以一个稳定的外部存储集群就显得很重要了; 常见的对k8s提供存储能力的集群有: heketi + gluesterfs 、Rook + Ceph、阿里云OSS等, 配合集群内的storageclass可直接向存储集群申请存储空间

自动部署和回滚 ：

 你可以使用 Kubernetes 描述已部署容器的所需状态, 它可以以受控的速率将实际状态 更改为期望状态. 例如, 你可以自动化 Kubernetes 来为你的部署创建新容器, 删除现有容器并将它们的所有资源用于新容器. 控制k8s集群中容器的状态大多数时候都会采用 yaml 资源配置清单的形式, 方便记忆也易于识别

自动完成装箱计算 ：

 Kubernetes 允许你指定每个容器所需 CPU 和内存（RAM）. 当容器指定了资源请求时, Kubernetes 可以做出更好的决策来管理容器的资源. 这就与Linux操作系统中的资源限额有关系了, 有些容器在接收高并发访问的时候, 往往会无限制的占用宿主机资源, 从而导致其他服务容器争抢不到应有的资源进行运行和服务, 从而导致大面积瘫痪

自我修复 ：

 Kubernetes 重新启动失败的容器、替换容器、杀死不响应用户定义的 运行状况检查的容器, 并且在准备好服务之前不将其通告给客户端. 在创建pod的时候, 只有当设置在pod中的探针全部探测正常后才会将pod连接到集群内网络中对外进行服务, 否则将通过监控告警给运维人员; 同样的对于k8s中的容器会受到kubelet和kube-apiserver的双重管理, kubelet上报容器运行状态, api-server向etcd中请求期望状态, 比较后让其达到期望的状态, 从而保证其功能/服务容器永久保持在线

密钥与配置管理 ：

 Kubernetes 允许你存储和管理敏感信息, 例如密码、OAuth 令牌和 ssh 密钥. 你可以在不重建容器镜像的情况下部署和更新密钥和应用程序配置, 也无需在堆栈配置中暴露密钥. 对于无状态应用(exam: nginx)的配置文件, 可以使用k8s中的configmap资源进行存储, 但对于密码和某些私密信息而言就可以使用secret资源进行存储, 从而避免频繁更改和私密信息泄漏的风险

        2.2  框架 

3.K8S架构、组件

        3.1   K8S架构

 一个 Kubernetes 集群由一组被称作节点的机器组成. 这些节点上运行 Kubernetes 所管理的容器化应用. 集群具有至少一个工作节点. 工作节点托管作为应用负载的组件的 Pod . 控制平面管理集群中的工作节点和 Pod . 为集群提供故障转移和高可用性, 这些控制平面一般跨多主机运行, 集群跨多个节点运行.

        3.2  组件

        （一）Kubernetes Master

集群控制节点，负责整个集群的管理和控制，基本上Kubernetes所有的控制命令都是发给它，它来负责具体的执行过程，我们后面所有执行的命令基本都是在Master节点上运行的；

1.Kubernetes API Server：

    作为Kubernetes系统的入口，其封装了核心对象的增删改查操作，以RESTful API接口方式提供给外部客户和内部组件调用。维护的REST对象持久化到Etcd中存储。

      API 服务器是 Kubernetes 控制面的组件, 该组件公开了 Kubernetes API. API 服务器是 Kubernetes 控制面的前端. Kubernetes API 服务器的主要实现是 kube-apiserver. kube-apiserver 设计上考虑了水平伸缩, 也就是说, 它可通过部署多个实例进行伸缩. 你可以运行 kube-apiserver 的多个实例, 并在这些实例之间平衡流量.

2.Kubernetes Scheduler：

     为新建立的Pod进行节点(node)选择(即分配机器)，负责集群的资源调度。组件抽离，可以方便替换成其他调度器。

      控制平面组件, 负责监视新创建的、未指定运行节点（node）的 Pods, 选择节点让 Pod 在上面运行. 调度决策考虑的因素包括单个 Pod 和 Pod 集合的资源需求、硬件/软件/策略约束、亲和性和反亲和性规范、数据位置、工作负载间的干扰和最后时限.

3.Kubernetes Controller：

    负责执行各种控制器，目前已经提供了很多控制器来保证Kubernetes的正常运行。

    运行控制器进程的控制平面组件. 从逻辑上讲, 每个控制器都是一个单独的进程, 但是为了降低复杂性, 它们都被编译到同一个可执行文件, 并在一个进程中运行. 这些控制器包括:

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

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

• 端点控制器（Endpoints Controller）: 填充端点（Endpoints）对象（即加入 Service 与 Pod）

• 服务帐户和令牌控制器（Service Account & Token Controllers）: 为新的命名空间创建默认帐户和 API 访问令牌

4.cloud-controller-manager ：

    云控制器管理器是指嵌入特定云的控制逻辑的 控制平面组件. 云控制器管理器使得你可以将你的集群连接到云提供商的 API 之上, 并将与该云平台交互的组件同与你的集群交互的组件分离开来. cloud-controller-manager 仅运行特定于云平台的控制回路. 如果你在自己的环境中运行 Kubernetes, 或者在本地计算机中运行学习环境, 所部署的环境中不需要云控制器管理器. 与 kube-controller-manager 类似, cloud-controller-manager 将若干逻辑上独立的 控制回路组合到同一个可执行文件中, 供你以同一进程的方式运行. 你可以对其执行水平扩容（运行不止一个副本）以提升性能或者增强容错能力. 下面的控制器都包含对云平台驱动的依赖:

• 节点控制器（Node Controller）: 用于在节点终止响应后检查云提供商以确定节点是否已被删除

• 路由控制器（Route Controller）: 用于在底层云基础架构中设置路由

• 服务控制器（Service Controller）: 用于创建、更新和删除云提供商负载均衡器

        （二）Kubernetes Node   

节点组件在每个节点上运行, 维护运行的 Pod 并提供 Kubernetes 运行环境.

除了Master，Kubernetes集群中的其他机器被称为Node节点，Node节点才是Kubernetes集群中的工作负载节点，每个Node都会被Master分配一些工作负载（Docker容器），当某个Node宕机，其上的工作负载会被Master自动转移到其他节点上去；

包含如下组件:

1.Kubelet：

    负责管控容器，Kubelet会从Kubernetes API Server接收Pod的创建请求，启动和停止容器，监控容器运行状态并汇报给Kubernetes API Server。

    一个在集群中每个节点（node）上运行的代理. 它保证容器（containers）都 运行在 Pod 中. kubelet 接收一组通过各类机制提供给它的 PodSpecs, 确保这些 PodSpecs 中描述的容器处于运行状态且健康. kubelet 不会管理不是由 Kubernetes 创建的容器.

2.Kubernetes Proxy：

     负责为Pod创建代理服务，Kubernetes Proxy会从Kubernetes API Server获取所有的Service信息，并根据Service的信息创建代理服务，实现Service到Pod的请求路由和转发，从而实现Kubernetes层级的虚拟转发网络。

     kube-proxy 是集群中每个节点上运行的网络代理, 实现 Kubernetes 服务（Service） 概念的一部分. kube-proxy 维护节点上的网络规则. 这些网络规则允许从集群内部或外部的网络会话与 Pod 进行网络通信. 如果操作系统提供了数据包过滤层并可用的话, kube-proxy 会通过它来实现网络规则. 否则, kube-proxy 仅转发流量本身.

3.Docker Engine（docker）：

     Docker引擎，负责本机的容器创建和管理工作；

     容器运行环境是负责运行容器的软件. Kubernetes 支持容器运行时, 例如 Docker、 containerd、CRI-O 以及 Kubernetes CRI (容器运行环境接口) 的其他任何实现.

        （三）数据库组件

     etcd数据库，可以部署到master上，也可以独立部署是分布式键值存储系统。用于保存集群状态数据，比如Pod、Service等对象信息。

     etcd 是兼具一致性和高可用性的键值数据库, 可以作为保存 Kubernetes 所有集群数据的后台数据库. 你的 Kubernetes 集群的 etcd 数据库通常需要有个备份计划. 要了解 etcd 更深层次的信息, 请参考 etcd 文档.

        （四）插件

插件使用 Kubernetes 资源实现集群功能. 因为这些插件提供集群级别的功能, 插件中命名空间域的资源属于 kube-system 命名空间. 下面描述众多插件中的几种. 有关可用插件的完整列表, 请参见 插件（Addons）.

DNS ：

尽管其他插件都并非严格意义上的必需组件, 但几乎所有 Kubernetes 集群都应该 有集群 DNS, 因为很多示例都需要 DNS 服务. 集群 DNS 是一个 DNS 服务器, 和环境中的其他 DNS 服务器一起工作, 它为 Kubernetes 服务提供 DNS 记录. Kubernetes 启动的容器自动将此 DNS 服务器包含在其 DNS 搜索列表中.

Web 界面（仪表盘） ：

Dashboard 是 Kubernetes 集群的通用的、基于 Web 的用户界面. 它使用户可以管理集群中运行的应用程序以及集群本身并进行故障排除.

容器资源监控 ：

容器资源监控 将关于容器的一些常见的时间序列度量值保存到一个集中的数据库中, 并提供用于浏览这些数据的界面.

集群层面日志 ：

集群层面日志 机制负责将容器的日志数据 保存到一个集中的日志存储中, 该存储能够提供搜索和浏览接口 ELK/Loki+grafana

4.K8S核心概念

        4.1   Master

Master主要负责 资源调度（scheduler （组件 ））；控制副本（controller ）；和提供统一访问集群的入口（apiserver） 。

        4.2   Node (5000)个节点

真正运行应用的节点；

Node是Kubernetes集群架构中运行Pod的服务节点（亦叫agent或minion）。

Node是Kubernetes集群操作的单元，用来承载被分配Pod的运行，是Pod运行的宿主机，由Master管理，并汇报容器状态给Master，同时根据Master要求管理容器生命周期。

master  与  node节点的关系：

        4.3   Node IP

Node节点的IP地址，是Kubernetes集群中每个节点的物理网卡的IP地址，是真是存在的物理网络，所有属于这个网络的服务器之间都能通过这个网络直接通信；

        4.4    Pod

Pod (超亲密关系的容器才能放)；超亲密关系的容器放到一个pod

master节点通过---pause 容器---（联系控制）运行真实服务的容器

设计pod初衷：

服务由一组进程完成，多个子进程，由主进程，对外提供服务

主进程、子进程有亲和力；同一个进程组，包在一起，运行在一个节点上。

Pod直译是豆荚，可以把容器想像成豆荚里的豆子，把一个或多个关系紧密的豆子包在一起就是豆荚（一个Pod）。在k8s中我们不会直接操作容器，而是把容器包装成Pod再进行管理

运行于Node节点上， 若干相关容器的组合。Pod内包含的容器运行在同一宿主机上，使用相同的网络命名空间、IP地址和端口，能够通过localhost进行通信。Pod是k8s进行创建、调度和管理的最小单位，它提供了比容器更高层次的抽象，使得部署和管理更加灵活。一个Pod可以包含一个容器或者多个相关容器。

Pod 就是 k8s 世界里的"应用"；而一个应用，可以由多个容器组成。

        4.5    pause容器

每个Pod中都有一个pause容器，pause容器做为Pod的网络接入点，Pod中其他的容器会使用容器映射模式启动并接入到这个pause容器。

属于同一个Pod的所有容器共享网络的namespace。

如果Pod所在的Node宕机，会将这个Node上的所有Pod重新调度到其他节点上；

pause容器  属于基础设施（infrastructure）

        4.6    Pod Volume

Docker Volume对应Kubernetes中的Pod Volume；

数据卷，挂载宿主机文件、目录或者外部存储到Pod中，为应用服务提供存储，也可以Pod中容器之间共享数据。

用法：

volunme -v 容器卷

        4.7    资源限制

每个Pod可以设置限额的计算机资源有CPU和Memory

        4.8     Event

是一个事件记录，记录了事件最早产生的时间、最后重复时间、重复次数、发起者、类型，以及导致此事件的原因等信息。Event通常关联到具体资源对象上，是排查故障的重要参考信息

        4.9    Pod IP

Pod的IP地址，是Docker Engine根据docker0网桥的IP地址段进行分配的，通常是一个虚拟的二层网络，位于不同Node上的Pod能够彼此通信，需要通过Pod IP所在的虚拟二层网络进行通信，而真实的TCP流量则是通过Node IP所在的物理网卡流出的；

        4.10   Endpoint

IP+Port   

标识服务进程的访问点；

端口：

pod 的ip      +        容器端口       =       端口

        4.11   Namespace

default (默认)；

命名空间将资源对象逻辑上分配到不同Namespace，可以是不同的项目、用户等区分管理，并设定控制策略，从而实现多租户。命名空间也称为虚拟集群。

        4.12    Replica Set

确保任何给定时间指定的Pod副本数量，并提供声明式更新等功能。可以通过Replica   Set   的版本号来进行回滚

        4.13    Deployment （副本控制器）

Deployment是一个更高层次的API对象，它管理ReplicaSets和Pod，并提供声明式更新等功能。官方建议使用Deployment管理ReplicaSets，而不是直接使用ReplicaSets，这就意味着可能永远不需要直接操作ReplicaSet对象，因此Deployment将会是使用最频繁的资源对象。

RC 和  Deployment  是同一个概念 ，随着RC升级出现 Deployment   

        4.14    Replication Controller   （RC--副本控制器）

Replication Controller用来管理Pod的副本，保证集群中存在指定数量的Pod副本。集群中副本的数量大于指定数量，则会停止指定数量之外的多余pod数量，反之，则会启动少于指定数量个数的容器，保证数量不变。Replication Controller是实现弹性伸缩、动态扩容和滚动升级的核心。

部署和升级Pod，声明某种Pod的副本数量在任意时刻都符合某个预期值；

Pod期待的副本数；

用于筛选目标Pod的Label Selector；

当Pod副本数量小于预期数量的时候，用于创建新Pod的Pod模板（template）；

        4.15    Service

Service定义了Pod的逻辑集合和访问该集合的策略，是真实服务的抽象。Service提供了一个统一的服务访问入口以及服务代理和发现机制，用户不需要了解后台Pod是如何运行。

一个service定义了访问pod的方式，就像单个固定的IP地址和与其相对应的DNS名之间的关系。

Service其实就是我们经常提起的微服务架构中的一个"微服务"，通过分析、识别并建模系统中的所有服务为微服务——Kubernetes Service，最终我们的系统由多个提供不同业务能力而又彼此独立的微服务单元所组成，服务之间通过TCP/IP进行通信，从而形成了我们强大而又灵活的弹性网络，拥有了强大的分布式能力、弹性扩展能力、容错能力；

每个Pod都提供了一个独立的Endpoint（Pod IP+ContainerPort）以被客户端访问，多个Pod副本组成了一个集群来提供服务，一般的做法是部署一个负载均衡器来访问它们，为这组Pod开启一个对外的服务端口如8000，并且将这些Pod的Endpoint列表加入8000端口的转发列表中，客户端可以通过负载均衡器的对外IP地址+服务端口来访问此服务。运行在Node上的kube-proxy其实就是一个智能的软件负载均衡器，它负责把对Service的请求转发到后端的某个Pod实例上，并且在内部实现服务的负载均衡与会话保持机制。Service不是共用一个负载均衡器的IP地址，而是每个Servcie分配一个全局唯一的虚拟IP地址，这个虚拟IP被称为Cluster IP。

        4.16     Cluster IP

Service的IP地址,特性：

• 仅仅作用于Kubernetes Servcie这个对象，并由Kubernetes管理和分配IP地址；

• 无法被Ping，因为没有一个"实体网络对象"来响应；

• 只能结合Service Port组成一个具体的通信端口；

• Node IP网、Pod IP网域Cluster IP网之间的通信，采用的是Kubernetes自己设计的一种编程方式的特殊的路由规则，与IP路由有很大的不同

        4.17    Label

Kubernetes中的任意API对象都是通过Label进行标识，Label的实质是一系列的K/V键值对。Label是Replication Controller和Service运行的基础，二者通过Label来进行关联Node上运行的Pod。

一个label是一个被附加到资源上的键/值对，譬如附加到一个Pod上，为它传递一个用户自定的并且可识别的属性.Label还可以被应用来组织和选择子网中的资源。

selector是一个通过匹配labels来定义资源之间关系得表达式，例如为一个负载均衡的service指定所目标Pod。

Label可以附加到各种资源对象上，一个资源对象可以定义任意数量的Label。给某个资源定义一个Label，相当于给他打一个标签，随后可以通过Label Selector（标签选择器）查询和筛选拥有某些Label的资源对象。我们可以通过给指定的资源对象捆绑一个或多个Label来实现多维度的资源分组管理功能，以便于灵活、方便的进行资源分配、调度、配置、部署等管理工作；

注：Node、Pod、Replication Controller和Service等都可以看作是一种"资源对象"，几乎所有的资源对象都可以通过Kubernetes提供的kubectl工具执行增、删、改、查等操作并将其保存在etcd中持久化存储。

5.K8S流行流程