1.Kubernetes集群管理工具kubectl
概述
kubectl是Kubernetes集群的命令行工具，通过kubectl能够对集群本身进行管理，并能够在集群上进行容器化应用的安装和部署
命令格式
命令格式如下
kubectl [command] [type] [name] [flags]参数
- command：指定要对资源执行的操作，例如create、get、describe、delete
- type：指定资源类型，资源类型是大小写敏感的，开发者能够以单数 、复数 和 缩略的形式
例如：
kubectl get pod pod1
kubectl get pods pod1
kubectl get po pod1
- name：指定资源的名称，名称也是大小写敏感的，如果省略名称，则会显示所有的资源，例如
kubectl get pods- flags：指定可选的参数，例如，可用 -s 或者 -server参数指定Kubernetes API server的地址和端口
常见命令
kubectl help 获取更多信息
通过 help命令，能够获取帮助信息
# 获取kubectl的命令
kubectl --help
# 获取某个命令的介绍和使用
kubectl get --help基础命令
常见的基础命令
命令 | 介绍 |
create | 通过文件名或标准输入创建资源 |
expose | 将一个资源公开为一个新的Service |
run | 在集群中运行一个特定的镜像 |
set | 在对象上设置特定的功能 |
get | 显示一个或多个资源 |
explain | 文档参考资料 |
edit | 使用默认的编辑器编辑一个资源 |
delete | 通过文件名，标准输入，资源名称或标签来删除资源 |
部署命令
命令 | 介绍 |
rollout | 管理资源的发布 |
rolling-update | 对给定的复制控制器滚动更新 |
scale | 扩容或缩容Pod数量，Deployment、ReplicaSet、RC或Job |
autoscale | 创建一个自动选择扩容或缩容并设置Pod数量 |
集群管理命令
命令 | 介绍 |
certificate | 修改证书资源 |
cluster-info | 显示集群信息 |
top | 显示资源(CPU/M) |
cordon | 标记节点不可调度 |
uncordon | 标记节点可被调度 |
drain | 驱逐节点上的应用，准备下线维护 |
taint | 修改节点taint标记 |
故障和调试命令
命令 | 介绍 |
describe | 显示特定资源或资源组的详细信息 |
logs | 在一个Pod中打印一个容器日志，如果Pod只有一个容器，容器名称是可选的 |
attach | 附加到一个运行的容器 |
exec | 执行命令到容器 |
port-forward | 转发一个或多个 |
proxy | 运行一个proxy到Kubernetes API Server |
cp | 拷贝文件或目录到容器中 |
auth | 检查授权 |
其它命令
命令 | 介绍 |
apply | 通过文件名或标准输入对资源应用配置 |
patch | 使用补丁修改、更新资源的字段 |
replace | 通过文件名或标准输入替换一个资源 |
convert | 不同的API版本之间转换配置文件 |
label | 更新资源上的标签 |
annotate | 更新资源上的注释 |
completion | 用于实现kubectl工具自动补全 |
api-versions | 打印受支持的API版本 |
config | 修改kubeconfig文件（用于访问API，比如配置认证信息） |
help | 所有命令帮助 |
plugin | 运行一个命令行插件 |
version | 打印客户端和服务版本信息 |
目前使用的命令
# 创建一个nginx镜像
kubectl create deployment nginx --image=nginx
# 对外暴露端口
kubectl expose deployment nginx --port=80 --type=NodePort
# 查看资源
kubectl get pod, svc2.Kubernetes集群YAML文件详解
概述
k8s 集群中对资源管理和资源对象编排部署都可以通过声明样式（YAML）文件来解决，也就是可以把需要对资源对象操作编辑到YAML 格式文件中，我们把这种文件叫做资源清单文件，通过kubectl 命令直接使用资源清单文件就可以实现对大量的资源对象进行编排部署了。一般在我们开发的时候，都是通过配置YAML文件来部署集群的。
YAML文件：就是资源清单文件，用于资源编排
YAML文件介绍
YAML概述
YAML ：仍是一种标记语言。为了强调这种语言以数据做为中心，而不是以标记语言为重点。
YAML 是一个可读性高，用来表达数据序列的格式。
YAML 基本语法
- 使用空格做为缩进
- 缩进的空格数目不重要，只要相同层级的元素左侧对齐即可
- 低版本缩进时不允许使用Tab 键，只允许使用空格
- 使用#标识注释，从这个字符一直到行尾，都会被解释器忽略
- 使用 — 表示新的yaml文件开始
YAML 支持的数据结构
对象
键值对的集合，又称为映射(mapping) / 哈希（hashes） / 字典（dictionary）
# 对象类型：对象的一组键值对，使用冒号结构表示
name: Tom
age: 18
# yaml 也允许另一种写法，将所有键值对写成一个行内对象
hash: {name: Tom, age: 18}数组
# 数组类型：一组连词线开头的行，构成一个数组
People
- Tom
- Jack
# 数组也可以采用行内表示法
People: [Tom, Jack]YAML文件组成部分
主要分为了两部分，一个是控制器的定义 和 被控制的对象
控制器的定义
被控制的对象
包含一些 镜像，版本、端口等
属性说明
在一个YAML文件的控制器定义中，有很多属性名称
属性名称 | 介绍 |
apiVersion | API版本 |
kind | 资源类型 |
metadata | 资源元数据 |
spec | 资源规格 |
replicas | 副本数量 |
selector | 标签选择器 |
template | Pod模板 |
metadata | Pod元数据 |
spec | Pod规格 |
containers | 容器配置 |
如何快速编写YAML文件
一般来说，我们很少自己手写YAML文件，因为这里面涉及到了很多内容，我们一般都会借助工具来创建
使用kubectl create命令
这种方式一般用于资源没有部署的时候，我们可以直接创建一个YAML配置文件
# 尝试运行,并不会真正的创建镜像
kubectl create deployment web --image=nginx -o yaml --dry-run或者我们可以输出到一个文件中
kubectl create deployment web --image=nginx -o yaml --dry-run > hello.yaml然后我们就在文件中直接修改即可
使用kubectl get命令导出yaml文件
可以首先查看一个目前已经部署的镜像
kubectl get deploy
然后我们导出 nginx的配置
kubectl get deploy nginx -o=yaml --export > nginx.yaml然后会生成一个 nginx.yaml 的配置文件
3.Kubernetes核心技术Pod
Pod概述
Pod是K8S系统中可以创建和管理的最小单元，是资源对象模型中由用户创建或部署的最小资源对象模型，也是在K8S上运行容器化应用的资源对象，其它的资源对象都是用来支撑或者扩展Pod对象功能的，比如控制器对象是用来管控Pod对象的，Service或者Ingress资源对象是用来暴露Pod引用对象的，PersistentVolume资源对象是用来为Pod提供存储等等，K8S不会直接处理容器，而是Pod，Pod是由一个或多个container组成。
Pod是Kubernetes的最重要概念，每一个Pod都有一个特殊的被称为 “根容器”的Pause容器。Pause容器对应的镜像属于Kubernetes平台的一部分，除了Pause容器，每个Pod还包含一个或多个紧密相关的用户业务容器。
Pod基本概念
- 最小部署的单元
- Pod里面是由一个或多个容器组成【一组容器的集合】
- 一个pod中的容器是共享网络命名空间
- Pod是短暂的
- 每个Pod包含一个或多个紧密相关的用户业务容器
Pod存在的意义
- 创建容器使用docker，一个docker对应一个容器，一个容器运行一个应用进程
- Pod是多进程设计，运用多个应用程序，也就是一个Pod里面有多个容器，而一个容器里面运行一个应用程序
- Pod的存在是为了亲密性应用
- 两个应用之间进行交互
- 网络之间的调用【通过127.0.0.1 或 socket】
- 两个应用之间需要频繁调用
Pod是在K8S集群中运行部署应用或服务的最小单元，它是可以支持多容器的。Pod的设计理念是支持多个容器在一个Pod中共享网络地址和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。同时Pod对多容器的支持是K8S中最基础的设计理念。在生产环境中，通常是由不同的团队各自开发构建自己的容器镜像，在部署的时候组合成一个微服务对外提供服务。
Pod是K8S集群中所有业务类型的基础，可以把Pod看作运行在K8S集群上的小机器人，不同类型的业务就需要不同类型的小机器人去执行。目前K8S的业务主要可以分为以下几种
- 长期伺服型：long-running
- 批处理型：batch
- 节点后台支撑型：node-daemon
- 有状态应用型：stateful application
上述的几种类型，分别对应的小机器人控制器为：Deployment、Job、DaemonSet 和 StatefulSet (后面将介绍控制器)
Pod实现机制
主要有以下两大机制
- 共享网络
- 共享存储
共享网络
容器本身之间相互隔离的，一般是通过 namespace 和 group 进行隔离，那么Pod里面的容器如何实现通信？
- 首先需要满足前提条件，也就是容器都在同一个namespace之间
关于Pod实现原理，首先会在Pod会创建一个根容器： pause容器，然后我们在创建业务容器 【nginx，redis 等】，在我们创建业务容器的时候，会把它添加到 info容器 中
而在 info容器 中会独立出 ip地址，mac地址，port 等信息，然后实现网络的共享
完整步骤如下
- 通过 Pause 容器，把其它业务容器加入到Pause容器里，让所有业务容器在同一个名称空间中，可以实现网络共享
共享存储
Pod持久化数据，专门存储到某个地方中
使用 Volumn数据卷进行共享存储，案例如下所示
Pod镜像拉取策略
我们以具体实例来说，拉取策略就是 imagePullPolicy
拉取策略主要分为了以下几种
- IfNotPresent：默认值，镜像在宿主机上不存在才拉取
- Always：每次创建Pod都会重新拉取一次镜像
- Never：Pod永远不会主动拉取这个镜像
Pod资源限制
也就是我们Pod在进行调度的时候，可以对调度的资源进行限制，例如我们限制 Pod调度是使用的资源是 2C4G，那么在调度对应的node节点时，只会占用对应的资源，对于不满足资源的节点，将不会进行调度
示例
我们在下面的地方进行资源的限制
这里分了两个部分
- request：表示调度所需的资源
- limits：表示最大所占用的资源
Pod重启机制
因为Pod中包含了很多个容器，假设某个容器出现问题了，那么就会触发Pod重启机制
重启策略主要分为以下三种
- Always：当容器终止退出后，总是重启容器，默认策略 【nginx等，需要不断提供服务】
- OnFailure：当容器异常退出（退出状态码非0）时，才重启容器。
- Never：当容器终止退出，从不重启容器 【批量任务】
Pod健康检查
通过容器检查，原来我们使用下面的命令来检查
kubectl get pod但是有的时候，程序可能出现了 Java 堆内存溢出，程序还在运行，但是不能对外提供服务了，这个时候就不能通过 容器检查来判断服务是否可用了
这个时候就可以使用应用层面的检查
# 存活检查，如果检查失败，将杀死容器，根据Pod的restartPolicy【重启策略】来操作
livenessProbe
# 就绪检查，如果检查失败，Kubernetes会把Pod从Service endpoints中剔除
readinessProbe
Probe支持以下三种检查方式
- http Get：发送HTTP请求，返回200 - 400 范围状态码为成功
- exec：执行Shell命令返回状态码是0为成功
- tcpSocket：发起TCP Socket建立成功
Pod调度策略
创建Pod流程
- 首先创建一个pod，然后创建一个API Server 和 Etcd【把创建出来的信息存储在etcd中】
- 然后创建 Scheduler，监控API Server是否有新的Pod，如果有的话，会通过调度算法，把pod调度某个node上
- 在node节点，会通过
kubelet -- apiserver读取etcd 拿到分配在当前node节点上的pod，然后通过docker创建容器
影响Pod调度的属性
Pod资源限制对Pod的调度会有影响
根据request找到足够node节点进行调度
节点选择器标签影响Pod调度
关于节点选择器，其实就是有两个环境，然后环境之间所用的资源配置不同
我们可以通过以下命令，给我们的节点新增标签，然后节点选择器就会进行调度了
kubectl label node node1 env_role=prod节点亲和性
节点亲和性 nodeAffinity 和 之前nodeSelector 基本一样的，根据节点上标签约束来决定Pod调度到哪些节点上
- 硬亲和性：约束条件必须满足
- 软亲和性：尝试满足，不保证
支持常用操作符：in、NotIn、Exists、Gt、Lt、DoesNotExists
反亲和性：就是和亲和性刚刚相反，如 NotIn、DoesNotExists等
污点和污点容忍
概述
nodeSelector 和 NodeAffinity，都是Prod调度到某些节点上，属于Pod的属性，是在调度的时候实现的。
Taint 污点：节点不做普通分配调度，是节点属性
场景
- 专用节点【限制ip】
- 配置特定硬件的节点【固态硬盘】
- 基于Taint驱逐【在node1不放，在node2放】
查看污点情况
kubectl describe node k8smaster | grep Taint
污点值有三个
- NoSchedule：一定不被调度
- PreferNoSchedule：尽量不被调度【也有被调度的几率】
- NoExecute：不会调度，并且还会驱逐Node已有Pod
未节点添加污点
kubectl taint node [node] key=value:污点的三个值举例：
kubectl taint node k8snode1 env_role=yes:NoSchedule删除污点
kubectl taint node k8snode1 env_role:NoSchedule-
演示
我们现在创建多个Pod，查看最后分配到Node上的情况
首先我们创建一个 nginx 的pod
kubectl create deployment web --image=nginx然后使用命令查看
kubectl get pods -o wide
我们可以非常明显的看到，这个Pod已经被分配到 k8snode1 节点上了
下面我们把pod复制5份，在查看情况pod情况
kubectl scale deployment web --replicas=5我们可以发现，因为master节点存在污点的情况，所以节点都被分配到了 node1 和 node2节点上
我们可以使用下面命令，把刚刚我们创建的pod都删除
kubectl delete deployment web现在给了更好的演示污点的用法，我们现在给 node1节点打上污点
kubectl taint node k8snode1 env_role=yes:NoSchedule然后我们查看污点是否成功添加
kubectl describe node k8snode1 | grep Taint
然后我们在创建一个 pod
# 创建nginx pod
kubectl create deployment web --image=nginx
# 复制五次
kubectl scale deployment web --replicas=5然后我们在进行查看
kubectl get pods -o wide我们能够看到现在所有的pod都被分配到了 k8snode2上，因为刚刚我们给node1节点设置了污点
最后我们可以删除刚刚添加的污点
kubectl taint node k8snode1 env_role:NoSchedule-污点容忍
污点容忍就是某个节点可能被调度，也可能不被调度
4.Kubernetes核心技术-Controller
内容
- 什么是Controller
- Pod和Controller的关系
- Deployment控制器应用场景
- yaml文件字段说明
- Deployment控制器部署应用
- 升级回滚
- 弹性伸缩
什么是Controller
Controller是在集群上管理和运行容器的对象，Controller是实际存在的，Pod是虚拟机的
Pod和Controller的关系
Pod是通过Controller实现应用的运维，比如弹性伸缩，滚动升级等
Pod 和 Controller之间是通过label标签来建立关系，同时Controller又被称为控制器工作负载
Deployment控制器应用
- Deployment控制器可以部署无状态应用
- 管理Pod和ReplicaSet
- 部署，滚动升级等功能
- 应用场景：web服务，微服务
Deployment表示用户对K8S集群的一次更新操作。Deployment是一个比RS( Replica Set, RS) 应用模型更广的 API 对象，可以是创建一个新的服务，更新一个新的服务，也可以是滚动升级一个服务。滚动升级一个服务，实际是创建一个新的RS，然后逐渐将新 RS 中副本数增加到理想状态，将旧RS中的副本数减少到0的复合操作。
这样一个复合操作用一个RS是不好描述的，所以用一个更通用的Deployment来描述。以K8S的发展方向，未来对所有长期伺服型的业务的管理，都会通过Deployment来管理。
Deployment部署应用
之前我们也使用Deployment部署过应用，如下代码所示
kubectrl create deployment web --image=nginx但是上述代码不是很好的进行复用，因为每次我们都需要重新输入代码，所以我们都是通过YAML进行配置
但是我们可以尝试使用上面的代码创建一个镜像【只是尝试，不会创建】
kubectl create deployment web --image=nginx --dry-run -o yaml > nginx.yaml然后输出一个yaml配置文件 nginx.yml ，配置文件如下所示
apiVersion: apps/v1
kind: Deployment
metadata:
creationTimestamp: null
labels:
app: web
name: web
spec:
replicas: 1
selector:
matchLabels:
app: web
strategy: {}
template:
metadata:
creationTimestamp: null
labels:
app: web
spec:
containers:
- image: nginx
name: nginx
resources: {}
status: {}我们看到的 selector 和 label 就是我们Pod 和 Controller之间建立关系的桥梁
使用YAML创建Pod
通过刚刚的代码，我们已经生成了YAML文件，下面我们就可以使用该配置文件快速创建Pod镜像了
kubectl apply -f nginx.yaml
但是因为这个方式创建的，我们只能在集群内部进行访问，所以我们还需要对外暴露端口
kubectl expose deployment web --port=80 --type=NodePort --target-port=80 --name=web1关于上述命令，有几个参数
- –port：就是我们内部的端口号
- –target-port：就是暴露外面访问的端口号
- –name：名称
- –type：类型
同理，我们一样可以导出对应的配置文件
kubectl expose deployment web --port=80 --type=NodePort --target-port=80 --name=web1 -o yaml > web1.yaml得到的web1.yaml如下所示
apiVersion: v1
kind: Service
metadata:
creationTimestamp: "2020-11-16T02:26:53Z"
labels:
app: web
managedFields:
- apiVersion: v1
fieldsType: FieldsV1
fieldsV1:
f:metadata:
f:labels:
.: {}
f:app: {}
f:spec:
f:externalTrafficPolicy: {}
f:ports:
.: {}
k:{"port":80,"protocol":"TCP"}:
.: {}
f:port: {}
f:protocol: {}
f:targetPort: {}
f:selector:
.: {}
f:app: {}
f:sessionAffinity: {}
f:type: {}
manager: kubectl
operation: Update
time: "2020-11-16T02:26:53Z"
name: web2
namespace: default
resourceVersion: "113693"
selfLink: /api/v1/namespaces/default/services/web2
uid: d570437d-a6b4-4456-8dfb-950f09534516
spec:
clusterIP: 10.104.174.145
externalTrafficPolicy: Cluster
ports:
- nodePort: 32639
port: 80
protocol: TCP
targetPort: 80
selector:
app: web
sessionAffinity: None
type: NodePort
status:
loadBalancer: {}然后我们可以通过下面的命令来查看对外暴露的服务
kubectl get pods,svc
然后我们访问对应的url，即可看到 nginx了 http://192.168.177.130:32639/
升级回滚和弹性伸缩
- 升级： 假设从版本为1.14 升级到 1.15 ，这就叫应用的升级【升级可以保证服务不中断】
- 回滚：从版本1.15 变成 1.14，这就叫应用的回滚
- 弹性伸缩：我们根据不同的业务场景，来改变Pod的数量对外提供服务，这就是弹性伸缩
应用升级和回滚
首先我们先创建一个 1.14版本的Pod
apiVersion: apps/v1
kind: Deployment
metadata:
creationTimestamp: null
labels:
app: web
name: web
spec:
replicas: 1
selector:
matchLabels:
app: web
strategy: {}
template:
metadata:
creationTimestamp: null
labels:
app: web
spec:
containers:
- image: nginx:1.14
name: nginx
resources: {}
status: {}我们先指定版本为1.14，然后开始创建我们的Pod
kubectl apply -f nginx.yaml同时，我们使用docker images命令，就能看到我们成功拉取到了一个 1.14版本的镜像
我们使用下面的命令，可以将nginx从 1.14 升级到 1.15
kubectl set image deployment web nginx=nginx:1.15在我们执行完命令后，能看到升级的过程
- 首先是开始的nginx 1.14版本的Pod在运行，然后 1.15版本的在创建
- 然后在1.15版本创建完成后，就会暂停1.14版本
- 最后把1.14版本的Pod移除，完成我们的升级
我们在下载 1.15版本，容器就处于ContainerCreating状态，然后下载完成后，就用 1.15版本去替换1.14版本了，这么做的好处就是：升级可以保证服务不中断
我们到我们的node2节点上，查看我们的 docker images;
能够看到，我们已经成功拉取到了 1.15版本的nginx了
查看升级状态
下面可以，查看升级状态
kubectl rollout status deployment web
查看历史版本
我们还可以查看历史版本
kubectl rollout history deployment web应用回滚
我们可以使用下面命令，完成回滚操作，也就是回滚到上一个版本
kubectl rollout undo deployment web然后我们就可以查看状态
kubectl rollout status deployment web
同时我们还可以回滚到指定版本
kubectl rollout undo deployment web --to-revision=2弹性伸缩
弹性伸缩，也就是我们通过命令一下创建多个副本
kubectl scale deployment web --replicas=10能够清晰看到，我们一下创建了10个副本
5.Kubernetes核心技术Service
前言
前面我们了解到 Deployment 只是保证了支撑服务的微服务Pod的数量，但是没有解决如何访问这些服务的问题。一个Pod只是一个运行服务的实例，随时可能在一个节点上停止，在另一个节点以一个新的IP启动一个新的Pod，因此不能以确定的IP和端口号提供服务。
要稳定地提供服务需要服务发现和负载均衡能力。服务发现完成的工作，是针对客户端访问的服务，找到对应的后端服务实例。在K8S集群中，客户端需要访问的服务就是Service对象。每个Service会对应一个集群内部有效的虚拟IP，集群内部通过虚拟IP访问一个服务。
在K8S集群中，微服务的负载均衡是由kube-proxy实现的。kube-proxy是k8s集群内部的负载均衡器。它是一个分布式代理服务器，在K8S的每个节点上都有一个；这一设计体现了它的伸缩性优势，需要访问服务的节点越多，提供负载均衡能力的kube-proxy就越多，高可用节点也随之增多。与之相比，我们平时在服务器端使用反向代理作负载均衡，还要进一步解决反向代理的高可用问题。
Service存在的意义
防止Pod失联【服务发现】
因为Pod每次创建都对应一个IP地址，而这个IP地址是短暂的，每次随着Pod的更新都会变化，假设当我们的前端页面有多个Pod时候，同时后端也多个Pod，这个时候，他们之间的相互访问，就需要通过注册中心，拿到Pod的IP地址，然后去访问对应的Pod
定义Pod访问策略【负载均衡】
页面前端的Pod访问到后端的Pod，中间会通过Service一层，而Service在这里还能做负载均衡，负载均衡的策略有很多种实现策略，例如：
- 随机
- 轮询
- 响应比
Pod和Service的关系
这里Pod 和 Service 之间还是根据 label 和 selector 建立关联的 【和Controller一样】
我们在访问service的时候，其实也是需要有一个ip地址，这个ip肯定不是pod的ip地址，而是 虚拟IP vip
Service常用类型
Service常用类型有三种
- ClusterIp：集群内部访问
- NodePort：对外访问应用使用
- LoadBalancer：对外访问应用使用，公有云
举例
我们可以导出一个文件 包含service的配置信息
kubectl expose deployment web --port=80 --target-port=80 --dry-run -o yaml > service.yamlservice.yaml 如下所示
apiVersion: v1
kind: Service
metadata:
creationTimestamp: null
labels:
app: web
name: web
spec:
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
app: web
status:
loadBalancer: {}如果我们没有做设置的话，默认使用的是第一种方式 ClusterIp，也就是只能在集群内部使用，我们可以添加一个type字段，用来设置我们的service类型
apiVersion: v1
kind: Service
metadata:
creationTimestamp: null
labels:
app: web
name: web
spec:
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
app: web
type: NodePort
status:
loadBalancer: {}修改完命令后，我们使用创建一个pod
kubectl apply -f service.yaml然后能够看到，已经成功修改为 NodePort类型了，最后剩下的一种方式就是LoadBalanced：对外访问应用使用公有云
node一般是在内网进行部署，而外网一般是不能访问到的，那么如何访问的呢？
- 找到一台可以通过外网访问机器，安装nginx，反向代理
- 手动把可以访问的节点添加到nginx中
如果我们使用LoadBalancer，就会有负载均衡的控制器，类似于nginx的功能，就不需要自己添加到nginx上
6.Kubernetes控制器Controller详解
Statefulset
Statefulset主要是用来部署有状态应用
对于StatefulSet中的Pod，每个Pod挂载自己独立的存储，如果一个Pod出现故障，从其他节点启动一个同样名字的Pod，要挂载上原来Pod的存储继续以它的状态提供服务。
无状态应用
我们原来使用 deployment，部署的都是无状态的应用，那什么是无状态应用？
- 认为Pod都是一样的
- 没有顺序要求
- 不考虑应用在哪个node上运行
- 能够进行随意伸缩和扩展
有状态应用
上述的因素都需要考虑到
- 让每个Pod独立的
- 让每个Pod独立的，保持Pod启动顺序和唯一性
- 唯一的网络标识符，持久存储
- 有序，比如mysql中的主从
适合StatefulSet的业务包括数据库服务MySQL 和 PostgreSQL，集群化管理服务Zookeeper、etcd等有状态服务
StatefulSet的另一种典型应用场景是作为一种比普通容器更稳定可靠的模拟虚拟机的机制。传统的虚拟机正是一种有状态的宠物，运维人员需要不断地维护它，容器刚开始流行时，我们用容器来模拟虚拟机使用，所有状态都保存在容器里，而这已被证明是非常不安全、不可靠的。
使用StatefulSet，Pod仍然可以通过漂移到不同节点提供高可用，而存储也可以通过外挂的存储来提供 高可靠性，StatefulSet做的只是将确定的Pod与确定的存储关联起来保证状态的连续性。
部署有状态应用
无头service， ClusterIp：none
这里就需要使用 StatefulSet部署有状态应用
然后通过查看pod，能否发现每个pod都有唯一的名称
然后我们在查看service，发现是无头的service
这里有状态的约定，肯定不是简简单单通过名称来进行约定，而是更加复杂的操作
- deployment：是有身份的，有唯一标识
- statefulset：根据主机名 + 按照一定规则生成域名
每个pod有唯一的主机名，并且有唯一的域名
- 格式：主机名称.service名称.名称空间.svc.cluster.local
- 举例：nginx-statefulset-0.default.svc.cluster.local
DaemonSet
DaemonSet 即后台支撑型服务，主要是用来部署守护进程
长期伺服型和批处理型的核心在业务应用，可能有些节点运行多个同类业务的Pod，有些节点上又没有这类的Pod运行；而后台支撑型服务的核心关注点在K8S集群中的节点(物理机或虚拟机)，要保证每个节点上都有一个此类Pod运行。节点可能是所有集群节点，也可能是通过 nodeSelector选定的一些特定节点。典型的后台支撑型服务包括：存储、日志和监控等。在每个节点上支撑K8S集群运行的服务。
守护进程在我们每个节点上，运行的是同一个pod，新加入的节点也同样运行在同一个pod里面
- 例子：在每个node节点安装数据采集工具
这里是不是一个FileBeat镜像，主要是为了做日志采集工作
进入某个 Pod里面，进入
kubectl exec -it ds-test-cbk6v bash通过该命令后，我们就能看到我们内部收集的日志信息了
Job和CronJob
一次性任务 和 定时任务
- 一次性任务：一次性执行完就结束
- 定时任务：周期性执行
Job是K8S中用来控制批处理型任务的API对象。批处理业务与长期伺服业务的主要区别就是批处理业务的运行有头有尾，而长期伺服业务在用户不停止的情况下永远运行。Job管理的Pod根据用户的设置把任务成功完成就自动退出了。成功完成的标志根据不同的 spec.completions 策略而不同：单Pod型任务有一个Pod成功就标志完成；定数成功行任务保证有N个任务全部成功；工作队列性任务根据应用确定的全局成功而标志成功。
Job
Job也即一次性任务
使用下面命令，能够看到目前已经存在的Job
kubectl get jobs
在计算完成后，通过命令查看，能够发现该任务已经完成
我们可以通过查看日志，查看到一次性任务的结果
kubectl logs pi-qpqff
CronJob
定时任务，cronjob.yaml如下所示
这里面的命令就是每个一段时间，这里是通过 cron 表达式配置的，通过 schedule字段
然后下面命令就是每个一段时间输出
我们首先用上述的配置文件，创建一个定时任务
kubectl apply -f cronjob.yaml创建完成后，我们就可以通过下面命令查看定时任务
kubectl get cronjobs
我们可以通过日志进行查看
kubectl logs hello-1599100140-wkn79
然后每次执行，就会多出一个 pod
删除svc 和 statefulset
使用下面命令，可以删除我们添加的svc 和 statefulset
kubectl delete svc web
kubectl delete statefulset --allReplication Controller
Replication Controller 简称 RC，是K8S中的复制控制器。RC是K8S集群中最早的保证Pod高可用的API对象。通过监控运行中的Pod来保证集群中运行指定数目的Pod副本。指定的数目可以是多个也可以是1个；少于指定数目，RC就会启动新的Pod副本；多于指定数目，RC就会杀死多余的Pod副本。
即使在指定数目为1的情况下，通过RC运行Pod也比直接运行Pod更明智，因为RC也可以发挥它高可用的能力，保证永远有一个Pod在运行。RC是K8S中较早期的技术概念，只适用于长期伺服型的业务类型，比如控制Pod提供高可用的Web服务。
Replica Set
Replica Set 检查 RS，也就是副本集。RS是新一代的RC，提供同样高可用能力，区别主要在于RS后来居上，能够支持更多种类的匹配模式。副本集对象一般不单独使用，而是作为Deployment的理想状态参数来使用
任务的结果
kubectl logs pi-qpqff
