没有前言

简介

k8s架构图

核心模块和用途如下：

• Cluster：Cluster是一个抽象的集合概念，包括计算、存储和网络资源。具体来说Kubernetes Cluster由Master和Worker组成，各个worker节点上运行着若干Kubernetes服务

• Master：master相当于整个kubernetes集群的大脑，依靠一些运行的服务进行kubernetes的任务调度工作：

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

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

• Scheduler：负责资源的调度，按照调度策略（预定和择优）将Pod调度到相应的机器上；

• etcd：用于保存整个集群的状态信息；

• Worker：除了Master，Kubernetes集群中的其它机器被称为worker节点。Node职责是运行容器应用，worker由Master管理，并负责监控并汇报容器的状态，同时根据Master的要求管理容器的生命周期。

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

• Proxy：负责为Service提供cluster内部的服务发现和负载均衡；

资源

k8s中所有的内容都抽象为资源， 资源实例化之后，叫做对象。

对象类型介绍：

• 工作负载型资源对象（workload）：POD，ReplicaSet，Deployment， StatefulSet，DaemonSet，Job，Cronjob …
• 服务发现及均衡资源对象：Service，Ingress …
• 配置与存储资源对象：Volume(存储卷)，CSI(容器存储接口,可以扩展各种各样的第三方存储卷)，ConfigMap，Secret，DownwardAPI
• 集群级资源：Namespace，Node，Role，ClusterRole，RoleBinding，ClusterRoleBinding
• 元数据型资源：HPA，PodTemplate，LimitRange

rc rs deployment

ReplicationController (RC)用来确保容器应用的副本数始终保持在用户定义的副本数，即如果有容器异常退出，会自动创建新的pod来替代；而异常多出来的容器也会自动回收。

在新版的Kubernetes中建议使用ReplicaSet (RS)来取代ReplicationController。ReplicaSet跟ReplicationController没有本质的不同，只是名字不一样，但ReplicaSet支持集合式selector。

虽然 ReplicaSets 可以独立使用，但如今它主要被Deployments 用作协调 Pod 的创建、删除和更新的机制。当使用 Deployment 时，你不必担心还要管理它们创建的 ReplicaSet，Deployment 会拥有并管理它们的 ReplicaSet。

ReplicaSet 是下一代的 Replication Controller。 ReplicaSet 和 Replication Controller 的唯一区别是选择器的支持。ReplicaSet 支持新的基于集合的选择器需求，这在标签用户指南中有描述。而 Replication Controller 仅支持基于相等选择器的需求。

Deployment 控制器为 Pods和 ReplicaSets提供描述性的更新方式。用来替代以前的ReplicationController以方便管理应用。

daementSet

它也是一种Pod控制器。
特点:它会在每一个Node节点上都会生成并且只能生成一个Pod资源。
使用场景:如果必须将Pod运行在固定的某个或某几个节点，且要优先于其他Pod的启动。通常情况下，默认每一个节点都会运行，并且只能运行一个Pod。这种情况推荐使用DaemonSet资源对象。
监控程序;
日志收集程序；
运行一个web服务，在每一个节点都运行一个Pod。

pod

Pod是所有业务类型的基础，也是K8S管理的最小单位级，它是一个或多个容器的组合。这些容器共享存储、网络和命名空间，以及如何运行的规范。在Pod中，所有容器都被同一安排和调度，并运行在共享的上下文中。对于具体应用而言，Pod是它们的逻辑主机，Pod包含业务相关的多个应用容器。

• 网络:每一个Pod都会被指派一个唯一的Ip地址，在Pod中的每一个容器共享网络命名空间，包括Ip地址和网络端口。在同一个Pod中的容器可以同locahost进行互相通信。当Pod中的容器需要与Pod外的实体进行通信时，则需要通过端口等共享的网络资源。

• 存储:Pod能够被指定共享存储卷的集合，在Pod中所有的容器能够访问共享存储卷，允许这些容器共享数据。存储卷也允许在一个Pod持久化数据，以防止其中的容器需要被重启。

statefulSet

StatefulSet本质上是Deployment的一种变体，在v1.9版本中已成为GA版本，它为了解决有状态服务的问题，它所管理的Pod拥有固定的Pod名称，启停顺序，在StatefulSet中，Pod名字称为网络标识(hostname)，还必须要用到共享存储。
在Deployment中，与之对应的服务是service，而在StatefulSet中与之对应的headless service，headless service，即无头服务，与service的区别就是它没有Cluster IP，解析它的名称时将返回该Headless Service对应的全部Pod的Endpoint列表。
除此之外，StatefulSet在Headless Service的基础上又为StatefulSet控制的每个Pod副本创建了一个DNS域名，这个域名的格式为：
$(podname).(headlessservername)FQDN：$(podname).(headless server name).namespace.svc.cluster.local

特点
Pod一致性：包含次序（启动、停止次序）、网络一致性。此一致性与Pod相关，与被调度到哪个node节点无关；
稳定的次序：对于N个副本的StatefulSet，每个Pod都在[0，N)的范围内分配一个数字序号，且是唯一的；
稳定的网络：Pod的hostname模式为( s t a t e f u l s e t 名 称 ) − (statefulset名称)-(statefulset名称)−(序号)；
稳定的存储：通过VolumeClaimTemplate为每个Pod创建一个PV。删除、减少副本，不会删除相关的卷。

组成

• Headless Service：用来定义Pod网络标识( DNS domain)；
• volumeClaimTemplates ：存储卷申请模板，创建PVC，指定pvc名称大小，将自动创建pvc，且pvc必须由存储类供应；
• StatefulSet ：定义具体应用，名为Nginx，有三个Pod副本，并为每个Pod定义了一个域名部署statefulset。

service

Kubernetes Service定义了这样一种抽象： Service是一种可以访问 Pod逻辑分组的策略， Service通常是通过 Label Selector访问 Pod组。

Service能够提供负载均衡的能力，但是在使用上有以下限制：只提供 4 层负载均衡能力，而没有 7 层功能，但有时我们可能需要更多的匹配规则来转发请求，这点上 4 层负载均衡是不支持的

service 类型

• ClusterIp：默认类型，自动分配一个仅Cluster内部可以访问的虚拟IP
• NodePort：在ClusterIP基础上为Service在每台机器上绑定一个端口，这样就可以通过: NodePort来访问该服务。
• LoadBalancer：在NodePort的基础上，借助Cloud Provider创建一个外部负载均衡器，并将请求转发到NodePort
• ExternalName：把集群外部的服务引入到集群内部来，在集群内部直接使用。没有任何类型代理被创建，这只有 Kubernetes 1.7或更高版本的kube-dns才支持。

job cronJob

Job
负责批处理任务

Job创建一个或多个Pod，并确保指定数量的Pod成功终止。Pod成功完成后，Job将跟踪成功完成的情况。当达到指定的成功完成次数时，任务（即Job）就完成了。删除Job将清除其创建的Pod。

一个简单的情况是创建一个Job对象，以便可靠地运行一个Pod来完成。如果第一个Pod发生故障或被删除（例如，由于节点硬件故障或节点重启），则Job对象将启动一个新的Pod。

当然还可以使用Job并行运行多个Pod。

Job终止和清理
Job完成后，不会再创建其他Pod，但是Pod也不会被删除。这样使我们仍然可以查看已完成容器的日志，以检查是否有错误、警告或其他诊断输出。Job对象在完成后也将保留下来，以便您查看其状态。

当我们删除Job对象时，对应的pod也会被删除。

特殊说明
单个Pod时，默认Pod成功运行后Job即结束
restartPolicy 仅支持Never和OnFailure
.spec.completions 标识Job结束所需要成功运行的Pod个数，默认为1
.spec.parallelism 标识并行运行的Pod个数，默认为1
.spec.activeDeadlineSeconds 为Job的持续时间，不管有多少Pod创建。一旦工作到指定时间，所有的运行pod都会终止且工作状态将成为type: Failed与reason: DeadlineExceeded。

CronJob
Cron Job 创建是基于时间调度的 Jobs

一个 CronJob 对象就像 crontab (cron table) 文件中的一行。它用 Cron 格式进行编写，并周期性地在给定的调度时间执行 Job。

CronJob 限制
CronJob 创建 Job 对象，每个 Job 的执行次数大约为一次。 之所以说 “大约” ，是因为在某些情况下，可能会创建两个 Job，或者不会创建任何 Job。虽然试图使这些情况尽量少发生，但不能完全杜绝。因此，Job 应该是幂等的。

CronJob 仅负责创建与其调度时间相匹配的 Job，而 Job 又负责管理其代表的 Pod。

未完待续。。。