【k8s核心概念与专业术语】

k8s架构

在这里插入图片描述

1、服务的分类

服务分类按如下图根据数据服务支撑，分为无状态和有状态

无状态引用如下所示，如果一个nginx服务，删除后重新部署有可以访问，这个属于无状态，不涉及到数据存储。

在这里插入图片描述

有状态服务，如redis，如果用户访问应用生成的token存储在redis中，如果把这个redis删除，重新部署redis后，这个用户还能正常访问么？（肯定是不是可以正常访问，用户的token都会没。）

在这里插入图片描述

2、资源和对象

Kubernetes中的所有内容部被抽象为资源"，如Pod、Service、Node等都是资源。对象"就是"资源的实例。是持久化的实体如某个具体的Pod、某个具体的Node。Kubernetes使用这些实体去表示整个集群和的状态。
对象的创建、删除、修改都是通过"Kubernetes APl"，也就是"Api Server"组件提供的API接口，这些是RESTful风格的Api，与k8s的"万物皆对象理念相符。命令行工具“kubectl,实际上也是调用kubernetes api。
K8s中的资源类别有很多种，kubectl可以通过配置文件来创建这些“对象”，配置文件更像是描述对象属性“的文件，配置文件格式可以是“JSON或YAML",常用"YAML"。

2.1 资源的分类

2.1.1 元数据型

对于资源的元数据描述是每一个资源都可以使用元空间的数据

1 自动扩缩容 Horizontal Pod Autoscaler (HPA)

场景eg：假设某个抢购场景，早上10点抢购，假设正常是有2个服务使用， 10点抢购时高并发场景，可以自定义在10点前自动扩容成10个服务使用，服务期流量降低后，自动缩减成2个服务正常使用。

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

2 Pod模板定义： PodTemplate

场景eg：原本有5个应用，现在要把5个应用扩容成10个应用，创建的新的应用应该是要和之前的5个应用一致，会基于这5个应用有一个配置文件，这个文件中会有（spec.template.描述）模版，那么新的应用会根据这个模版来创建应用。

Pod Template是关于Pod的转义，但是被包含在其他的Kubernetes对象中（例攸如Deployment、.StatefulSet、DaemonSet等控制器)。控制器通过Pod Template信息来创建Pod。

3 资源限制：LimitRange

场景eg：假设一个java应用，初始内存是2G，最大内存5G，假设整个应用有16G，超过5G的时候就进行限制，这个就是一个内存限制的策略。

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

2.1.2 集群级

集群级别的资源作用于集群之上，集群下的所有资源都可以共享使用

1 命名空间：Namespace

命名空间的资源本身就属于K8s的资源，只不过多了一个逻辑意义上独立的概念。

2 Node资源

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

3 ClusterRole

这个角色是属于集群的角色，他是用在集群之上，用于对集群的权限管理。

4 ClusterRoleBinding

上面的ClusterRole只是应用于一个权限组，但是还没真正用到那个用户身上。用来把权限和那个资源进行绑定。只能绑定到集群级别的资源对象上，不能给namespace的资源对象上绑定。

2.1.3 命名空间级资源

作用在命名空间之上，通常只能作用于命名空间范围内使用，命名空间A不可以访问命名空间B的资源，可以理解为逻辑意义上的集群，一个k8s集群可以有多个命名空间。

1 工作负载

1.1 什么是POD？

Pod(容器组)是Kubemetes中最小的可部署单元，一个Pod(容器组)包含了一个应用程序容器（某些情况下是多个容器)、存储资源、一个维一的网烙IP地址、以及一些确定容器该如何运行的选项。Pod容器组代表了Kubernetes中一个独立的应用程序运行实例，该实例可能由单个容器或者几个紧耦合在一起的容器组成。
Docker是Kubernetes Pod中使用最广泛的容器引擎；Kubernetes Pod同时也支持其他类型的容器引擎。
Kubernetes集群中Pod存在如下两种使用途径：
- 一个Pod中只运行一个容器.，"one-container-per-pod"是Kubemetes中最常见的使用式。此时，您可以认为Pod容器组是该容器的wrapper，Kubernetes通过Pod管理容器。而不是直接管理容器。
- 一个Pod中运行多个需要互相协作的容器。您可以将多个紧耦合、共享资源目始终在一起运行的容器编排在同一个Pod中。

1.2 Pod 副本（replicas）

先引入副本的概念一一个Pod可以被复制成多份，每一份可被称之为一个“副本"，这些副本除了一些描述性的信息(Pod的名字、uuid等)不一样以外，其它信息都是一样的。如Pod内部的容器、容器数量、容器里面运行的应用等的这些信总都是一样的。这些副本提供问样的功能。
Pod的"控制器"逼常包含一个名为"replicas’的属性，“replicas"属性则指定了特定Pod的副本的数量，当当前集群中该Pod的数量与该属性指定的值不一致时。k85会采取一些策路去使得当前状态满足配置的要求。

1.3 Pod 的控制器的类型

1.3.1 适用于无状态的服务

在这里插入图片描述

（1）【了解】ReplicationController（RC）帮助我们动态更新pod的副本数

Replication Controller简称RC,RC是Kubernetes系统中的接心概念之一，简单来说。RC可以保证在任意时间运行Pod的副本款量，能够保证Pod总是可用的。如果实际Pod数量比指定的多那就结束掉多余的。如果实示数量比指定的数量少，则新启动一些Pod，当Pod失败、被删除或者挂掉后，RC都会去自动创建新的Pod来保证利本数量，所以即使只有一个Pod,我们也应该用RC来管理我们的Pod,可以说，通过ReplicationController控制器，Kubernetes实现了Pod的高可用性。

在这里插入图片描述

（2）【了解】ReplicaSet（RS）帮助我们动态更新pod的副本数，可以通过selector来选择对那些pod生效

RC(ReplicationController)主要的作用就是用来确保容器应用的副本数始终保特在用户定义的副本数，。即如果有容器异常退出，会自动创建新的Pod来替代：而如果异常多出来的容器也会自动回收（已经成为过去时），在v1.11版本废弃。
-
Kubernetes官方建议使用RS(ReplicaSet)替代RC(ReplicationController)进行部署，RS跟RC没有本质的不同，只是名字不一样，并且RS支持集合式的selector。

在这里插入图片描述

（3）【重点】Deployment：增对RS的更高层次封装，提供了更丰富的部署相关的功能

自动创建ReplicaSet，自动创建Pod。
可以滚动升级和回滚，eg：代码更新后，回自动升级创建新的pod，新的pod可以用，在把旧的pod删除。
可以平滑扩容和缩容
暂停和恢复Deployment

1.3.2 适用有状态的服务 StatefulSet

在这里插入图片描述

StatefulSet：专门对有状态服务进行部署的一个控制器

StatefulSet中每个Pod的DNS格式为 statefulSetName-{O…N-1).serviceName.namespace.svc.cluster.local
serviceName为Headless Service的名字
0…N-1为Pod所在的序号，从0开始到N-1
"statefulSetName为StatefulSet的名字
namespace为服务所在的namespace,Headless Service和StatefulSet必须在相同的namespace
.cluster.local为Cluster Domain

场景：假设我们的集群是一个redis集群，redis集群（主从结构）官方推荐的方案是大于等于3个数量，并且一定是一个单数（涉及到redis的选举机制），如果更新redis这个pod的时候，会出现以下问题：
1、容器的网络还在不在？（原来的网络会没有，导致我们的后端服务去找这个redis的时候就不知道一什么ip地址去找了，我们不可以把这个redis的服务ip写到后端服务上，网络变更，那后端服务找不到这个redis了）
2、数据问题如何解决？（Pod删除掉后，数据也同样会被删除，就算新建的pod可以访问，但是数据不共享。）
3、顺序性问题（master节点一般都是可读可写，slave节点是可读的，那我们在创建pod的时候就会涉及到一个顺序性问题）
如上3个问题就需要用到StatefulSet，可以保证网络、数据、顺序性问题都可以解决。通过Headless service和volumeClaimTemplate实现。

在这里插入图片描述

1.3.3 守护进程 DaemonSet

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

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

场景：每个node可以添加一个type的标签，如果ds的pod匹配到这个标签，就会在这个node上创建这样一个pod

在这里插入图片描述

1.3.4 任务/定时任务 Job/CronJob

Job：一次性任务，运行完成后直接销毁
CronJob：在Job的基础上增加了定时的功能

2 服务发现

服务发现分为service和ingress两个服务。

原先的访问模式
1、用户访问域名，可以通过F5、LVS、阿里云slb负载均衡访问到后端服务，后端服务通过网关可以发现每个微服务，这种流量称为”南北流量“。
2、后端的微服务直线的相互访问称之为”东西流量“。

在这里插入图片描述

使用k8s集群后，用户访问域名访问k8s集群，通过域名访问集群内的ingress服务，通过service访问到后端服务。
后端服务之间的访问是是通过service服务来进行访问。

在这里插入图片描述

3 配置与存储

Volume：数据卷，共享Pod中容器使用的数据。用来放持久化的数据，比如数据库库数据。（可以和docker中的数据卷进行比对学习）
CSI：Container Storage Interface是由来自Kubernetes、Mesos、Docker等社区成员联合制定的一个行业标准接口规范，旨在将任意存储系统暴露给容器化应用程序。CSI规范定义了存储提供商实现CSI兼容的Volume Plugin的最小操作集和部署建议。CSl规范的主要焦点是声明Volume Plugin必须实现的接口。

4 特殊类型配置

ConfigMap：可以通过key-value这样的信息构建一个ConfigMap，让容器或者pod里面可以读取到这个ConfigMap的数据。可以把容器内的数据暴露出来，或者可以这么说原先容器内的运行的后端服务有些数据，比如数据库信息，如果更新需要重新打包jar包然后更新pod，现在可以通过把这个信息放置到ConfigMap，如果要修改信息直接修改ConfigMap，这个就是ConfigMap的作用。
Secret：Secret解决了密码、token、密钥等敏感数据的配置问题，而不需要把这些敢感数据暴露到镜像或者Pod Spec中。Secret可以以Volume或者环境变量的方式使用，Secret有三种类型：
- Service Account:用来访问Kubemetes API，由Kubernetes自动创建，并目会自动挂载到Pod的/run/secrets/kubernetes.io/serviceaccount目录中
- Opaquet base64编码格式的Secret，用来存储密码、密钥等
- kubernetes.io/dockerconfigjson：用来存储私有docker registry的认证信息。
DownwardAPI：DownwardAPI这个模式和其他模式不一样的地方在于它不是为了存放容器的数据也不是用来进行容器和宿主机的数据交换的，而是让pod里的容器能够直接获取到这个pod对象本身的一些信息。
DownwardAPI提供了两种方式用于将pod的信息注入到容器内部：
- 环境变量：用于单个变量，可以将p0d信息和容器信息直接注入容器内部
- volume挂载：将pod信息生成为文件，直接挂载到容器内部中去

5 其他

Role：是去定义一组权限，定义我们命名空间级别的权限，和上文的（ClusterRole）不是一个级别的权限。Role是一组权限的集合，例如Role可以包含列出Pod权限及列出Deployment权限，Role用于给某个Namespace中的资源进行鉴权。
RoleBinding：可以作用于Role和ClusterRole，用RoleBinding就只能绑定到命名空间内。

2.2资源清单

必须存在的属性

参数名	字段类型	说明
apiVersion	String	这里指的是K8s API的版本，目前基本上是v1，可以用kubectl api-version命令查询
kind	String	这里指的是yaml文件定义的资源类型和角色，比如：pod
metadata	Object	元数据对象，固定值就写 metadata
metadata.name	String	元数据对象的名字，这里由我们编写，比如命令Pod的名字
metadata.namespace	String	元数据对象的命名空间，由我们自身定义
spec	Object	详细定义对象，固定值就写 Spec
spec.containers[]	list	这里是Spec对象的容器列表定义，是个列表
spec.containers[].name	String	这里定义容器的名字
spec.containers[].image	String	这里定义要用到的镜像名称

主要对象

参数名	字段类型	说明
spec.containers[].name	String	定义容器的名字
spec.containers[].image	String	定义要用到的镜像名称
spec.containers[].imagePullRolicy	String	定义镜像拉取策略，有Always、Never、IfNotPresent三个选项； Always：每次都尝试重新拉取镜像，默认Always ；Never：仅使用本地镜像；IfNotPresent：如果本地有镜像就使用本地就像，如果没有就拉取在线镜像；
spec.containers[].command[]	List	指定容器启动命令，因为是数组可以指定多个，不指定则使用镜像打包时使用的启动命令。
spec.containers[].args[]	List	指定容器启动命令参数，因为是数组可以指定多个。
spec.containers[].workingDir	String	指定容器的工作目录。
spec.containers[].volumeMounts[]	List	指定容器内部的存储卷配置
spec.containers[].volumeMounts[].name	String	指定可以被容器挂载的存储卷的名称
spec.containers[].volumeMounts[].mountPath	String	指定可以被容器挂载的存储卷的路径
spec.containers[].volumeMounts[].readOnly	String	设置存储卷路径的读写模式，true或者false，默认为读写模式
spec.containers[].ports[]	List	指定容器需要用到的端口列表
spec.containers[].ports[].name	String	指定端口名称
spec.containers[].containerPort	String	指定容器需要监听的端口号
spec.containers[].ports[].hostPort	String	指定容器所在主机需要监听的端口号，默认跟上面containerPort相同；注意设置了hostPort同一台主机无法启动该容器的相同副本（因为主机的端口号不能相同，这样会冲突）
spec.containers[].ports[].protocol	String	指定端口协议，支持TCP和UDP，默认为TCP
spec.containers[].env[]	List	指定容器运行前需设置的环境变量列表

额外的参数项

参数名	字段类型	说明
spec.restartPolicy	String	定义Pod的重启策略，可选值为Always、OnFailure，默认值为Always；1.Always：pod一旦终止运行，则无论容器是如何终止的，kubelet服务都将重启它。2.OnFailure：只有pod以非零退出码终止时，kubelet才会重启该容器；如果容器正常退出(退出码为0)，则kubelet将不会重启它；3.Never：pod终止后，kubelet将退出码报告给master，不会重启pod。
spec.nodeSelector	Object	定义Node的Label过滤标签，以key: value格式指定
spec.imagePullSecrets	Object	定义pull镜像时使用sercet名称，以name: secretkey格式指定
spec.hostNetwork	Boolean	定义是否使用主机网络模式，默认值false；设置true表示使用宿主机网络，不使用docker网桥，同时设置了true将无法再同一台宿主机上启动第二个副本。