网站底部备案网站如何发布
目录
一、pod
1、什么是pod
2、pod的上下文环境怎么理解？
二、Namespace & ResourceQuota
1、命名空间
2、ResourceQuota
三、Replication controller/ReplicaSet
1、replication controller是什么？
四、Service
1、service是什么？
2、service的代理
五、Endpoint
六、Ingress / Ingress Controller
七、Label / Selector
八、Configmap / Secret
九、Deployment
十、DaemonSet
十一、PV / PVC
1、PV
2、PVC
十二、StorageClass
十三、StatefulSet
开始本章内容之前，先讲解一下k8s对资源的定义：k8s将所有的内容都抽象为资源(例如：pod、service等)，在k8s中运行的是对已经定义的资源的实例化实体(例如一个提供后端java服务的pod)，所有内容均通过YAML/JSON文件描述。下面对k8s中的常用资源做一个简单的简介。
一、pod
1、什么是pod
K8s最基本的管理调度单元，逻辑上相当于一组共享上下文环境的托管应用。Pod模型在容器环境里表示为指定应用的逻辑主机。Pod可以包含一个或多个紧耦合的应用容器。
2、pod的上下文环境怎么理解？
pod的上下文环境可以理解为多个Linux namespace的连接体，包括：
1) PID namespace(pod里的应用可以感知彼此的进程)
2) Network namespace(pod里的应用可以同一IP和端口空间)
3) IPC namespace(pod里的应用可以用SystemV IPC 信号量、消息队列和共享内存，POSIX信息队列)
4) UTS namespace(pod里的应用可以共享主机名)
pod的生命周期是相对短暂的，pod在node上被部署管理，直到被终止删除。当node节点无响应时，node上的pod将被删除，在node上的pod不会被迁移到其他node上，而是通过replicationSet被其它node上的pod所取代。
但是在生产环境中，一般一个pod只部署一个服务，方便管理。
二、Namespace & ResourceQuota
1、命名空间
1）namespace是k8s集群中的虚拟化集群。在一个k8s集群中可以拥有多个命名空间，他们在逻辑上彼此隔离。
2）大多数的k8s集群会有一个叫default的默认namespace，实际上k8s会有三个：
default：用户的service和app会默认创建在这个空间；
kube-system：k8s系统组件使用；
kube-public：公共资源使用，但实际上现在并不常用。
2、ResourceQuota
1) 按类型限制命名空间下所创建对象的数量
2) 限制所消耗计算资源的总量
三、Replication controller/ReplicaSet
1、replication controller是什么？
1) replication controller是pod的复制抽象，用于解决pod的扩容缩容问题。通常，分布式应用为了性能或高可用性的考虑，需要复制多分资源，并且根据负载情况动态伸缩。
2) 通过replicaitonController，我们可以指定一个应用需要几份复制，k8s将为每份复制创建一个pod，并且保证实际运行pod数量总是跟复制数量相等，当某一个pod宕机时，自动创建新的pod来替换。
注：最新版本的k8s已经用replicaSet来代替replicationController，使用方式没有改变，只是增加了支持集合式的selector。
Selector:
matchLabels：
Tier：frontend
matchExpresions：
-{key: tier, operator:In, values:[frontend]}
四、Service
1、service是什么？
Service：是pod的路由代理抽象，用于解决pod之间的服务发现问题。因为pod的运行状态可动态变化(比如切换机器了、缩容过程中被终止了等)，所以访问端不能以写死IP的方式去访问该pod提供的服务。service的引入旨在保证pod的动态变化对访问端保持透明，访问端只需要知道service的地址，由service来提供代理。
2、service的代理
Kube-proxy从API Server获取服务及端点的对象状态。每个服务都会在本地节点打开一个端口。任何访问该端口的连接都会被代理到后端pod的相应端口上。
五、Endpoint
K8s会根据service关联到pod的PodIP信息，组合成endpoint(PODIP + PODPort),若service定义中没有selector字段，service被创建时，也不会自动创建endpoint。
六、Ingress / Ingress Controller
1、Ingress
Service是后端真实服务的抽象，一个Service可以代表多个相同的后端服务。
Ingress是反向代理规则，用来规定HTTP/S请求应该被转发到哪个Service上，比如根据请求中不同的Host和url路径让请求落到不同的Sevice上。
2、Ingress Controller
Ingress Controller就是一个反向代理程序，它负责解析Ingress的反向代理规则，如果Ingress有增删改的变动，所有的Ingress Controller都会及时更新自己相应的转发规则，当Ingress Controller收到请求后就会根据这些规则将请求转发到对应的Service。
七、Label / Selector
service和replicationController是建立在pod之上的抽象，那么它们如何跟pod联系起来呢？
这里使用了label的概念，label很好理解，就是为pod加上可用于搜索关联的一组key/value标签，而service和replicationController正是通过label selector机制来和pod关联的。
比如：现在有三个的pod的label为“app = backend”，创建service和replicationController时可以指定同样的label：“app = backend”，这样就将他们就与这三个pod关联起来了。当有其他frontend pod访问该service时，自动会转发到其中一个backend pod中。
八、Configmap / Secret
K8s集群中的应用使用configmap资源或者Secret资源管理配置文件。Configmap资源主要管理通用配置文件，Secret资源解决了密码、token、密钥等敏感数据的配置问题。
Configmap使用方式：
1）设置环境变量的值
2）在容器里设置命令行参数
3）在数据卷里面创建config文件(volume)
Secret使用方式：
1）以Volume方式
2）以环境变量方式
九、Deployment
deployment是构建于ReplicaSet资源之上，主要管理无状态应用。
1）deployment借助ReplicaSet管理pod资源，其大部分管理操作于ReplicaSet相同。
2）相比ReplicaSet具有的高级功能，主要为自动滚动更新以及回滚的功能。
十、DaemonSet
在每个Worker Node上都创建相同的POD
与deployment的不同之处：daemonSet每个node上最多只能运行一个副本；deployment部署的pod分布在各个node上，每个node都可能运行好几个副本。
十一、PV / PVC
1、PV
PV是集群中已由管理员配置的存储(网络、本地)。集群中的资源就像一个节点是一个集群资源。PV是诸如卷之类的卷插件，但是具有独立于使用PV的任何单个pod的生命周期。
2、PVC
PVC是用户存储的请求。它类似于pod。Pod消耗节点资源，PVC消耗存储资源。pod可以请求特定级别的资源(CPU和内存)。权限要求可以请求特定的大小和访问模式。
十二、StorageClass
K8s集群管理员通过提供不同的存储类，可以满足用户不同的服务质量级别、备份策略和任意策略要求的存储需求。动态存储卷供应使用StorageClass进行实现，其允许存储卷按需被创建。如果没有动态存储供应，k8s集群的管理员将不得不通过手工的方式创建新的存储卷。K8s将能够按照用户的需要，自动创建其需要的存储。
十三、StatefulSet
statefulSet是为了解决有状态服务的问题(对应Deployments和ReplicaSets是为无状态服务而设计)，适用场景：
1、稳定的持久化存储，即pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现
2、稳定的网络标志，即pod重新调度后其PodName和HostName不变，基于Headless Service(即没有Cluster IP的Service)来实现
3、有序部署，有序扩展，即pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次进行(即从0到N-1，在下一个od运行之前所有之前的pod必须都是Runnin和Ready状态)，基于init containers来实现
4、有序收缩，有序删除(即从N-1到0)
5、有序的滚动更新
