Kubernetes核心概念

Kubernetes相关组件

服务的分类（有状态和无状态）

资源和对象

资源和对象可以简单理解为：对应Java的类和对象

对象的规约和状态

规约（Spec）

"spec"是"规约"、"规格"的意思，spec 是 必需的 ，它描述了对象的期望状态（Desired state）------希望对象所具有的特征。当创建 Kubernetes 对象时，必须提供对象的规约，用来描述该对象的期望状态，以及关于对象的一些基本信息(例如名称)。

状态

表示 对象的实际状态，该属性由 k8s 自己维护，k8s 会通过一系列的控制器对对应对象进行管理，让对象尽可能的让实际状态与期望状态重合。

资源的分类

元数据、集群、命名空间

元数据（了解）

Horizontal Pod Autoscaler(HPA)

Pod 自动扩容：可以根据 CPU使用率 或 自定义指标(metrics) 自动对 Pod 进行扩/缩容。

控制管理器每隔 30s （可以通过 -horizontal-pod-autoscaler-sync-period 修改）查询 metrics 的资源使用情况
支持三种 metrics类型
- 预定义metrics（比如Pod的CPU）以利用率的方式计算
- 自定义的Pod metrics，以原始值（raw value）的方式计算
- 自定义的object metrics
支持两种metrics查询方式：Heapster和自定义的REST API
支持多metrics

PodTemplate

Pod Template 是关于 Pod 的定义 ，但是被包含在其他的Kubernetes对象中（例如 Deployment 、Statefulset Daemonset 等控制器）。控制器通过 Pod Template 信息来创建Pod。

LimitRange

可以对集群内 Request 和 Limits 的配置做一个全局的统一的限制，相当于批量设置了某一个范围内(某个命名空间)的 Pod 的资源使用限制。

集群级（了解）

Namespace
Node

不像其他的资源(如 Pod和 Namespace)，Node 本质上不是Kubernetes 来创建的，Kubernetes 只是管理 Node上的资源。虽然可以通过 Manifest 创建一个Node对象(如下json 所示)，但 Kubernetes 也只是去检查是否真的是有这么一个 Node，如果检查失败，也不会往上调度 Pod。

ClusterRole
ClusterRoleBinding

命名空间级（重点，下面重点介绍）

命名空间级（重点）

Pod

Pod解决的难题

Pod结构

Pod（容器组 ）是 Kubernetes 中 最小的可部署单元 。一个 Pod 包含了 一个应用程序容器（某些情况下是多个容器）、存储资源、一个唯一的网络IP 地址、以及一些确定容器该如何运行的选项。Pod 容器组代表了Kubernetes 中一个独立的应用程序运行实例，该实例可能由单个容器或者几个紧耦合在一起的容器组成。

Docker 是 Kubernetes Pod 中使用最广泛的容器引擎；

Kubernetes Pod 同时也支持其他类型的容器引擎。

Kubernetes 集群中的 Pod 存在如下两种使用途径:

一个 Pod 中只运行一个容器 。"one-container-per-pod" 是Kubernetes中最常见的使用方式。此时，您可以认为Pod容器组是该容器的 wrapper，Kubernetes 通过 Pod 管理容器，而不是直接管理容器。
一个 Pod 中运行多个需要互相协作的容器。您可以将多个紧密耦合、共享资源且始终在一起运行的容器编排在同一个Pod 中。

副本（replicas）

一个 Pod 可以被复制成多份，每一份可被称之为一个"副本"，这些"副本"除了一些描述性的信息(Pod的名字、uid 等)不一样以外，其它信息都是一样的，譬如Pod内部的容器、容器数量、容器里面运行的应用等的这些信息都是一样的，这些副本提供同样的功能。

Pod 的 "控制器" 通常包含一个名为 "replicas"的属性。"replicas"属性则指定了特定 Pod 的副本的数量，当当前集群中该 Pod 的数量与该属性指定的值不一致时，k8s会采取一些策略去使得当前状态满足配置的要求。

探针

类型

StartupProbe（启动探针）

k8s 1.16 版本新增的探针，用于判断应用程序是否已经启动了。

当配置了 startupProbe 后，会先禁用其他探针，直到startupProbe 成功后，其他探针才会继续。

作用:由于有时候不能准确预估应用一定是多长时间启动成功，因此配置另外两种方式不方便配置初始化时长来检测，而配置了statupProbe 后，只有在应用启动成功了，才会执行另外两种探针，可以更加方便的结合使用另外两种探针使用。

LivenessProbe（保活探针）

用于探测容器中的应用是否运行，如果探测失败，kubelet 会根据配置的重启策略进行重启，若没有配置，默认就认为容器启动成功，不会执行重启策略。

ReadinessProbe（就绪探针）

用于探测容器内的程序是否健康，它的返回值如果返回success，那么就认为该客器已经完全启动，并且该容器是可以接收外部流量的。

探测方式

ExecAction

在容器内部执行一个命令，如果返回值为0，则任务容器时健康的。

yaml 复制代码

livenessProbe:
	exec:
		command:
			- cat
			-/health

TCPSocketAction

通过 tcp 连接监测容器内端口是否开放，如果开放则证明该容器健康。

yaml 复制代码

livenessProbe:
	tcpSocket:
		port: 80

HTTPGetAction

生产环境用的较多的方式 ，发送 HTTP 请求到容器内的应用程序，如果接口返回的状态码在 200~400 之间，则认为容器健康。

yaml 复制代码

livenessProbe:
	failureThreshold: 5
		httpGet:
			path: /health
			port: 8080
			scheme: HTTP
			httpHeaders:
				- name:xx
				  value: xxx

参数配置

生命周期

Pod退出流程------删除操作

Endpoint删除pod的ip地址
Pod变成 Terminating状态
变为删除中的状态后，会给 pod 一个宽限期，让pod 去执行一些清理或销毁操作 。
配置参数:
yaml 复制代码
```
#作用与 pod 中的所有容器
terminationGracePeriodseconds: 30
containers:
	- xxx
```
执行 preStop 的指令

PreStop的应用

注册中心下线
数据清理
数据销毁

资源清单

控制器

适用无状态服务

ReplicationController(RC)（已废弃）

帮助我们动态更新 Pod 的副本数

ReplicaSet(RS)

Label 和 Selector

在RC的基础上，可以通过 selector 来选择对哪些 Pod 生效

Deployment（工作实际使用）

针对RS更高层次的封装，提供了更丰富的部署相关功能：

创建 ReplicaSet / Pod
滚动升级/回滚
平滑扩容和缩容
暂停和恢复 Deployment

适用有状态服务

StatefulSet

Statefulset 中每个Pod的 DNS 格式为 statefulSetName-{0..N-1}.serviceName.namespace.svc.cluster.local

serviceName为Headless Service的名字
0..N-1为 Pod 所在的序号，从0开始到 N-1
statefulsetName 为Statefulset的名字
namespace 为服务所在的namespace，Headless Servic 和 Statefulset 必须在相同的 namespace
.cluster.local 为Cluster Domain

主要特点

稳定的持久化存储
稳定的网络标志
有序部署，有序扩展
有序收缩，有序删除

组成

Headless Service

用于定义网络标志（DNS domain）

volumeClaim Template

用于创建持久化卷的模板。

注意事项

kubernetes v1.5 版本以上才支持
所有Pod的Volume必须使用 PersistentVolume 或者是管理员事先创建好
为了保证数据安全，删除StatefulSet时不会删除Volume
StatefulSet需要 Headless Service 来定义 DNS domain，需要在 StatefulSet 之前创建好

守护进程

DaemonSet

Daemonset保让在每Node都运行一个容器副本，常用来部署一些集群的日志、监控或者其他系统管理应用。典型的应用包括：

日志收集，比如 fuentd，logstash 等
系统监控，比如 Prometheus Node Exporter, collectd, New Relic agent, Ganglia gmond 等
系统程序，比如 kube-proxy, kube-dns, glusterd, ceph 等

任务/定时任务

Job

一次性任务，运行完成后Pod销毁，不再重新启动新容器。

CronJob

CronJob是在Job基础上加上了定时功能。

服务发现

Service

内部服务访问

Ingress

外部服务访问

配置与存储

Volume

数据卷，共享Pod 中容器使用的数据。用来放持久化的数据，比如数据库数据。

CSI

Container Storage Interface 是由来自 Kubernetes、Mesos、Docker 等社区成员联合制定的一个行业标准接口规范，旨在将任意存储系统暴露给容器化应用程序。

CSI规范定义了存储提供商实现 CSI 兼容的 Volme Plugin 的最小操作集和部署建议。CSI规范的主要焦点是声明 Volume Plugin 必须实现的接口。

特殊类型配置

ConfigMap

Secret

Secret解决了密码、token、密钥等敏感数据的配置问题，而不需要把这些敏感数据暴露到镜像或者 Pod spec 中。secret 可以以 Volume 或者环境变量的防式使用。

Secret 有三种类型:

Service Account：用来访问 Kubernetes APl，由Kubernetes 自动创建，并且会自动挂载到 Pod 的 /run/secrets/kubernetes,io/serviceaccount 目录中；
Opaque：base64 编码格式的 Secret，用来存储密码、秘钥等；
kubernetes.io/dockerconfigjson：用来存储私有 docker registry 的认证信息。

DownwardAPI

downwardAPI这个模式和其他模式不一样的地方在于它不是为了存放容器的数据也不是用来进行容器和宿主机的数据交换的，而是让 pod 里的容器能够直接获取到这个 pod 对象本身的一些信息。

downwardAPI提供了两种方式用于将 pod 的信息注入到容器内

部:

环境变量：用于单个变量，可以将 pod 信息和容器信息直接注入容器内部
volume 挂载：将 pod 信息生成为文件，直接挂载到容器内部中去

其他

Role

Role 是一组权限的集合，例如 Role可以包含列出 Pod 权限及列出 Deployment 权限，Role 用于给某个 Namespace 中的资源进行鉴权。

RoleBinding

Label 和 Selector

资源之间的关联都是通过Label + Selector方式，例如 Deployment、RS、Pod之间的关联关系。

标签（Label）

配置文件配置

在各类资源的 spec.metadata.labels 中进行配置

kubectl配置

临时创建label
修改已经存在的标签
查看label

选择器（Selector）

配置文件配置

在各对象的配置 spec.selector 或其他可以写 selector 的属性中编写

kubectl配置