K8S知识点脑图

Kubernates

Why Kubernates

Kubernetes 太热门了

核心功能

部署应用

分支主题

访问应用

要访问应用只能直接访问容器的 8080 端口。为了能够从外部访问应用，我们需要将容器的 8080 端口映射到节点的端口

Scale 应用

默认情况下应用只会运行一个副本，可以通过 kubectl get deployments查看副本数

kubectl scale deployments/kubernetes-bootcamp --replicas=3

滚动更新

v1 的 Pod 被逐个删除，同时启动了新的 v2 Pod

核心组件

etcd保存了整个集群的状态；

apiserver提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制；

controller manager负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；

scheduler负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上；

kubelet负责维护容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的管理；

Container runtime负责镜像管理以及Pod和容器的真正运行（CRI）；

kube-proxy负责为Service提供cluster内部的服务发现和负载均衡；

核心层：Kubernetes最核心的功能，对外提供API构建高层的应用，对内提供插件式应用执行环境

应用层：部署（无状态应用、有状态应用、批处理任务、集群应用等）和路由（服务发现、DNS解析等）

管理层：系统度量（如基础设施、容器和网络的度量），自动化（如自动扩展、动态Provision等）以及策略管理（RBAC、Quota、PSP、NetworkPolicy等）

接口层：kubectl命令行工具、客户端SDK以及集群联邦

生态系统：在接口层之上的庞大容器集群管理调度的生态系统，可以划分为两个范畴

Kubernetes外部：日志、监控、配置管理、CI、CD、Workflow、FaaS、OTS应用、ChatOps等

Kubernetes内部：CRI、CNI、CVI、镜像仓库、Cloud Provider、集群自身的配置和管理等

重要概念

Cluster

Cluster 是计算、存储和网络资源的集合，Kubernetes 利用这些资源运行各种基于容器的应用。

Master

Master 是 Cluster 的大脑，它的主要职责是调度，即决定将应用放在哪里运行。Master 运行 Linux 操作系统，可以是物理机或者虚拟机。为了实现高可用，可以运行多个 Master

Node

Node 的职责是运行容器应用。Node 由 Master 管理，Node 负责监控并汇报容器的状态，并根据 Master 的要求管理容器的生命周期。Node 运行在 Linux 操作系统，可以是物理机或者是虚拟机。

Pod

Pod 是 Kubernetes 的最小工作单元。每个 Pod 包含一个或多个容器。Pod 中的容器会作为一个整体被 Master 调度到一个 Node 上运行。

优点

可管理性

有些容器天生就是需要紧密联系，一起工作。Pod 提供了比容器更高层次的抽象，将它们封装到一个部署单元中。Kubernetes 以 Pod 为最小单位进行调度、扩展、共享资源、管理生命周期

通信和资源共享

Pod 中的所有容器使用同一个网络 namespace，即相同的 IP 地址和 Port 空间。它们可以直接用 localhost 通信。同样的，这些容器可以共享存储，当 Kubernetes 挂载 volume 到 Pod，本质上是将 volume 挂载到 Pod 中的每一个容器

两种使用方式

运行单一容器

运行多个容器

这些容器联系必须 非常紧密，而且需要 直接共享资源

Controller

Kubernetes 通常不会直接创建 Pod，而是通过 Controller 来管理 Pod 的。Controller 中定义了 Pod 的部署特性，比如有几个副本，在什么样的 Node 上运行等。为了满足不同的业务场景，Kubernetes 提供了多种 Controller，包括 Deployment、ReplicaSet、DaemonSet、StatefuleSet、Job 等

Replication Controller

副本控制器. 通过监控运行中的Pod来保证集群中运行指定数目的Pod副本。指定的数目可以是多个也可以是1个；少于指定数目，RC就会启动运行新的Pod副本；多于指定数目，RC就会杀死多余的Pod副本

ReplicaSet

副本集ReplicaSet RS是新一代RC，提供同样的高可用能力，区别主要在于RS后来居上，能支持更多种类的匹配模式。实现了 Pod 的多副本管理。使用 Deployment 时会自动创建 ReplicaSet，也就是说 Deployment 是通过 ReplicaSet 来管理 Pod 的多个副本

Deployment

部署表示用户对Kubernetes集群的一次更新操作.部署是一个比RS应用模式更广的API对象，可以是创建一个新的服务，更新一个新的服务，也可以是滚动升级一个服务。滚动升级一个服务，实际是创建一个新的RS，然后逐渐将新RS中副本数增加到理想状态

Service

不能以确定的IP和端口号提供服务。要稳定地提供服务需要服务发现和负载均衡能力。服务发现完成的工作，是针对客户端访问的服务，找到对应的的后端服务实例。Service会对应一个集群内部有效的虚拟IP，集群内部通过虚拟IP访问一个服务

Job

Job是Kubernetes用来控制批处理型任务的API对象。批处理业务与长期伺服业务的主要区别是批处理业务的运行有头有尾，而长期伺服业务在用户不停止的情况下永远运行。

DaemonSet

DaemonSet 确保全部（或者一些）Node 上运行一个 Pod 的副本。当有 Node 加入集群时，也会为他们新增一个 Pod

运行集群存储 daemon，例如在每个 Node 上运行 glusterd、ceph。

在每个 Node 上运行日志收集 daemon，例如fluentd、logstash。

在每个 Node 上运行监控 daemon，例如 Prometheus Node Exporter、collectd、Datadog 代理、New Relic 代理，或 Ganglia gmond。

PetSet

云原生应用的体系里，有下面两组近义词；第一组是无状态（stateless）、牲畜（cattle）、无名（nameless）、可丢弃（disposable）；第二组是有状态（stateful）、宠物（pet）、有名（having name）、不可丢弃（non-disposable）

RC和RS主要是控制提供无状态服务的，其所控制的Pod的名字是随机设置的，一个Pod出故障了就被丢弃掉，在另一个地方重启一个新的Pod，名字变了、名字和启动在哪儿都不重要，重要的只是Pod总数

PetSet是用来控制有状态服务，PetSet中的每个Pod的名字都是事先确定的，不能更改

适合于PetSet的业务包括数据库服务MySQL和PostgreSQL，集群化管理服务Zookeeper、etcd等有状态服务

StatefulSet

StatefulSet是为了解决有状态服务的问题

稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现

稳定的网络标志，即Pod重新调度后其PodName和HostName不变，基于Headless Service（即没有Cluster IP的Service）来实现

有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依次进行（即从0到N-1，在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态），基于init containers来实现

有序收缩，有序删除（即从N-1到0）

Kubernetes Service 定义了外界访问一组特定 Pod 的方式。Service 有自己的 IP 和端口，Service 为 Pod 提供了负载均衡。

Kubernetes 运行容器（Pod）与访问容器（Pod）这两项任务分别由 Controller 和 Service 执行。

Namespace

Namespace 可以将一个物理的 Cluster 逻辑上划分成多个虚拟 Cluster，每个 Cluster 就是一个 Namespace。不同 Namespace 里的资源是完全隔离的。

Kubernetes 默认创建了两个 Namespace。

Volume

Kubernetes集群中的存储卷跟Docker的存储卷有些类似，只不过Docker的存储卷作用范围为一个容器，而Kubernetes的存储卷的生命周期和作用范围是一个Pod。每个Pod中声明的存储卷由Pod中的所有容器共享。

Kubernetes支持非常多的存储卷类型，特别的，支持多种公有云平台的存储，包括AWS，Google和Azure云；支持多种分布式存储包括GlusterFS和Ceph；也支持较容易使用的主机本地目录hostPath和NFS。

持久存储卷（Persistent Volume，PV）

持久存储卷声明（Persistent Volume Claim，PVC）

PV和PVC使得Kubernetes集群具备了存储的逻辑抽象能力，使得在配置Pod的逻辑里可以忽略对实际后台存储技术的配置，而把这项配置的工作交给PV的配置者，即集群的管理者。存储的PV和PVC的这种关系，跟计算的Node和Pod的关系是非常类似的；PV和Node是资源的提供者，根据集群的基础设施变化而变化，由Kubernetes集群管理员配置；而PVC和Pod是资源的使用者，根据业务服务的需求变化而变化，有Kubernetes集群的使用者即服务的管理员来配置。

Secret

Label

Label是附着到object上（例如Pod）的键值对

Label能够将组织架构映射到系统架构上（就像是康威定律），这样能够更便于微服务的管理

ETCD

kubernetes系统中一共有两个服务需要用到etcd用来协同和存储配置

网络插件flannel、对于其它网络插件也需要用到etcd存储网络的配置信息

kubernetes本身，包括各种对象的状态和元信息配置

原理

是raft一致性算法来实现的，是一款分布式的一致性KV存储，只要用于共享配置和服务发现

使用Etcd存储Kubernetes对象信息

开放接口

CRI（Container Runtime Interface）：容器运行时接口，提供计算资源

RuntimeService

ImageService

CNI（Container Network Interface）：容器网络接口，提供网络资源

添加网络、删除网络、添加网络列表、删除网络列表

CNI设计的时候考虑了以下问题

容器运行时必须在调用任何插件之前为容器创建一个新的网络命名空间。

然后，运行时必须确定这个容器应属于哪个网络，并为每个网络确定哪些插件必须被执行。

网络配置采用JSON格式，可以很容易地存储在文件中。网络配置包括必填字段，如name和type以及插件（类型）。网络配置允许字段在调用之间改变值。为此，有一个可选的字段args，必须包含不同的信息。

容器运行时必须按顺序为每个网络执行相应的插件，将容器添加到每个网络中。

在完成容器生命周期后，运行时必须以相反的顺序执行插件（相对于执行添加容器的顺序）以将容器与网络断开连接。

容器运行时不能为同一容器调用并行操作，但可以为不同的容器调用并行操作。

容器运行时必须为容器订阅ADD和DEL操作，这样ADD后面总是跟着相应的DEL。 DEL可能跟着额外的DEL，但是，插件应该允许处理多个DEL（即插件DEL应该是幂等的）。

容器必须由ContainerID唯一标识。存储状态的插件应该使用（网络名称，容器ID）的主键来完成。

运行时不能调用同一个网络名称或容器ID执行两次ADD（没有相应的DEL）。换句话说，给定的容器ID必须只能添加到特定的网络一次。

CSI（Container Storage Interface）：容器存储接口，提供存储资源

部署 k8s Cluster

安装 Docker

安装 kubelet、kubeadm 和 kubectl

用 kubeadm 创建 Cluster

初始化 Master

① kubeadm 执行初始化前的检查。

② 生成 token 和证书。

③ 生成 KubeConfig 文件，kubelet 需要这个文件与 Master 通信。

④ 安装 Master 组件，会从 goolge 的 Registry 下载组件的 Docker 镜像，这一步可能会花一些时间，主要取决于网络质量。

⑤ 安装附加组件 kube-proxy 和 kube-dns。

⑥ Kubernetes Master 初始化成功。

⑦ 提示如何配置 kubectl，后面会实践。

⑧ 提示如何安装 Pod 网络，后面会实践。

⑨ 提示如何注册其他节点到 Cluster，后面会实践。

配置 kubectl

安装 Pod 网络

Kubernetes 支持多种网络方案

添加 k8s-node1 和 k8s-node2

k8s 架构

Master 节点

Master 是 Kubernetes Cluster 的大脑

运行着如下 Daemon 服务

kube-apiserver

API Server 提供 HTTP/HTTPS RESTful API，即 Kubernetes API。API Server 是 Kubernetes Cluster 的前端接口，各种客户端工具（CLI 或 UI）以及 Kubernetes 其他组件可以通过它管理 Cluster 的各种资源。

kube-scheduler

Scheduler 负责决定将 Pod 放在哪个 Node 上运行。Scheduler 在调度时会充分考虑 Cluster 的拓扑结构，当前各个节点的负载，以及应用对高可用、性能、数据亲和性的需求。

Controller Manager 负责管理 Cluster 各种资源，保证资源处于预期的状态。Controller Manager 由多种 controller 组成，包括 replication controller、endpoints controller、namespace controller、serviceaccounts controller 等。不同的 controller 管理不同的资源。例如 replication controller 管理 Deployment、StatefulSet、DaemonSet 的生命周期，namespace controller 管理 Namespace 资源。

etcd

etcd 负责保存 Kubernetes Cluster 的配置信息和各种资源的状态信息。当数据发生变化时，etcd 会快速地通知 Kubernetes 相关组件。

Pod 网络（例如 flannel）

Node

Node是 Pod 运行的地方

Kubernetes 支持 Docker、rkt 等容器 Runtime

Node上运行的 Kubernetes 组件有 kubelet、kube-proxy 和 Pod 网络

kubelet

kubelet 是 Node 的 agent，当 Scheduler 确定在某个 Node 上运行 Pod 后，会将 Pod 的具体配置信息（image、volume 等）发送给该节点的 kubelet，kubelet 根据这些信息创建和运行容器，并向 Master 报告运行状态。

kube-proxy

每个 Node 都会运行 kube-proxy 服务，它负责将访问 service 的 TCP/UPD 数据流转发到后端的容器。如果有多个副本，kube-proxy 会实现负载均衡。

① kubectl 发送部署请求到 API Server。

② API Server 通知 Controller Manager 创建一个 deployment 资源。

③ Scheduler 执行调度任务，将两个副本 Pod 分发到 k8s-node1 和 k8s-node2。

④ k8s-node1 和 k8s-node2 上的 kubelet 在各自的节点上创建并运行 Pod。

重点问题

了解Pod的构成

Pod的生命周期

Pod中容器的启动顺序模板定义

什么是Pod

Pod就像是豌豆荚一样，是一个服务的多个进程的聚合单位，它由一个或者多个容器组成（例如Docker容器），它们共享容器存储、网络和容器运行配置项。Pod是kubernetes中你可以创建和部署的最小也是最简单位。一个Pod代表着集群中运行的一个进程。

Pod中封装着应用的容器（有的情况下是好几个容器），存储、独立的网络IP，管理容器如何运行的策略选项。Pod代表着部署的一个单位：kubernetes中应用的一个实例，可能由一个或者多个容器组合在一起共享资源。Pod中共享的环境包括Linux的namespace，cgroup和其他可能的隔绝环境，这一点跟Docker容器一致

Pod中的容器总是被同时调度，有共同的运行环境

你可以把单个Pod想象成是运行独立应用的“逻辑主机”——其中运行着一个或者多个紧密耦合的应用容器

每个Pod都是应用的一个实例。如果你想平行扩展应用的话（运行多个实例），你应该运行多个Pod

Pod中可以共享两种资源

网络

每个Pod都会被分配一个唯一的IP地址。Pod中的所有容器共享网络空间，包括IP地址和端口。Pod内部的容器可以使用localhost互相通信。Pod中的容器与外界通信时，必须分配共享网络资源（例如使用宿主机的端口映射）。

存储

可以Pod指定多个共享的Volume。Pod中的所有容器都可以访问共享的volume。Volume也可以用来持久化Pod中的存储资源，以防容器重启后文件丢失。

Init 容器

Init 容器总是运行到成功完成为止。

每个 Init 容器都必须在下一个 Init 容器启动之前成功完成

Pod 安全策略

基于布尔值控制：这种类型的字段默认为最严格限制的值。

基于被允许的值集合控制：这种类型的字段会与这组值进行对比，以确认值被允许。

基于策略控制：设置项通过一种策略提供的机制来生成该值，这种机制能够确保指定的值落在被允许的这组值中。

Pod 的生命周期

生命周期

挂起（Pending）：Pod 已被 Kubernetes 系统接受，但有一个或者多个容器镜像尚未创建。等待时间包括调度 Pod 的时间和通过网络下载镜像的时间，这可能需要花点时间。

运行中（Running）：该 Pod 已经绑定到了一个节点上，Pod 中所有的容器都已被创建。至少有一个容器正在运行，或者正处于启动或重启状态。

成功（Successed）：Pod 中的所有容器都被成功终止，并且不会再重启。

失败（Failed）：Pod 中的所有容器都已终止了，并且至少有一个容器是因为失败终止。也就是说，容器以非0状态退出或者被系统终止。

未知（Unkonwn）：因为某些原因无法取得 Pod 的状态，通常是因为与 Pod 所在主机通信失败。

容器探针

探针 是由 kubelet 对容器执行的定期诊断

成功：容器通过了诊断。

失败：容器未通过诊断。

未知：诊断失败，因此不会采取任何行动。

Service 定义了这样一种抽象：一个 Pod 的逻辑分组，一种可以访问它们的策略 —— 通常称为微服务。 这一组 Pod 能够被 Service 访问到

在 Kubernetes 集群中，每个 Node 运行一个 kube-proxy 进程。kube-proxy 负责为 Service 实现了一种 VIP（虚拟 IP）的形式

userspace 代理模式

通过 round-robin 算法来选择 backend Pod

iptables 代理模式

网络解析flannel

内部存在三类IP

Node IP：宿主机的IP地址

Pod IP：使用网络插件创建的IP（如flannel），使跨主机的Pod可以互通

Cluster IP：虚拟IP，通过iptables规则访问服务

Flannel

Flannel是作为一个二进制文件的方式部署在每个node上，主要实现两个功能

为每个node分配subnet，容器将自动从该子网中获取IP地址

当有node加入到网络中时，为每个node增加路由配置

calico

概念

Calico 创建和管理一个扁平的三层网络(不需要overlay)，每个容器会分配一个可路由的ip。由于通信时不需要解包和封包，网络性能损耗小，易于排查，且易于水平扩展。

Calico架构

Etcd：负责存储网络信息

BGP client：负责将Felix配置的路由信息分发到其他节点

Felix：Calico Agent，每个节点都需要运行，主要负责配置路由、配置ACLs、报告状态

BGP Route Reflector：大规模部署时需要用到，作为BGP client的中心连接点，可以避免每个节点互联

Deployment为Pod和Replica Set（下一代Replication Controller）提供声明式更新。

使用场景

定义Deployment来创建Pod和ReplicaSet

滚动升级和回滚应用

扩容和缩容

暂停和继续Deployment

典型的用例

使用Deployment来创建ReplicaSet。ReplicaSet在后台创建pod。检查启动状态，看它是成功还是失败。

然后，通过更新Deployment的PodTemplateSpec字段来声明Pod的新状态。这会创建一个新的ReplicaSet，Deployment会按照控制的速率将pod从旧的ReplicaSet移动到新的ReplicaSet中。

如果当前状态不稳定，回滚到之前的Deployment revision。每次回滚都会更新Deployment的revision。

扩容Deployment以满足更高的负载。

暂停Deployment来应用PodTemplateSpec的多个修复，然后恢复上线。

根据Deployment 的状态判断上线是否hang住了。

清除旧的不必要的 ReplicaSet

失败的 Deployment

无效的引用

不可读的 probe failure

镜像拉取错误

权限不够

范围限制

程序运行时配置错误

过程

用户通过 kubectl 创建 Deployment。

Deployment 创建 ReplicaSet。

ReplicaSet 创建 Pod。

方式

用 kubectl 命令直接创建

通过配置文件和 kubectl apply 创建

用 YAML 配置文件部署应用

① apiVersion 是当前配置格式的版本。

② kind 是要创建的资源类型，这里是 Deployment。

③ metadata 是该资源的元数据，name 是必需的元数据项。

④ spec 部分是该 Deployment 的规格说明。

⑤ replicas 指明副本数量，默认为 1。

⑥ template 定义 Pod 的模板，这是配置文件的重要部分。

⑦ metadata 定义 Pod 的元数据，至少要定义一个 label。label 的 key 和 value 可以任意指定。

⑧ spec 描述 Pod 的规格，此部分定义 Pod 中每一个容器的属性，name 和 image 是必需的。

Scale Up/Down

再次执行 kubectl apply

K8S新特性

1.9

全面提供了App Workload应用编程接口

App Workloads API对开发者来说是一个重要工具，聚合了包括DaemonSet、Deployment、RepliaSet和StatefulSet等工具，用于为Kubernetes中的状态工作负载提供支持

首次包含Windows支持

存储方面

新增了一项名为Container Storage Interface（CSI）的功能

旨在让用户更轻松地增加卷插件作为Kubernetes的新存储系统。这个想法是通过创建单一接口进行配置、附加和安装不同的存储卷为Kubernetes使用，从而让数据跨Kubernetes工作负载的可移动性更高。

1.8

安全性发面

基于角色的访问控制（RBAC）

允许集群的管理者动态地定义角色并通过Kubernetes API来施加访问的策略

稳定性方面

Pod的横向自动伸缩自定义特性处于beta状态

Kubernetes允许基于CPU利用率来进行向上或者向下伸缩，但是开发者也想能够根据其他类型的指标来伸缩应用

新打造的度量服务器拥有更高可读性更加易懂的错误输出，能帮助在问题发生时指示出错原因和位置

现在能对临时存储设置限定条件，可以指定挂载选项，同时也覆盖了更多与存储使用相关的指标。

引入了flex驱动的部署

能允许源码树外（out-of-tree）的卷驱动

简洁性方面

只需两行命令就能架设好一个Kuebernetes集群。现在kubeadm命令加入了集群升级的支持

1.7

API聚合

容器运行时接口（CRI）

可扩展外部访问控制

加密etcd中的secret

网络策略API