1.资源控制器
- 什么是控制器？
Kubernetes中内建了很多controller (控制器) ,这些相当于一个状态机,用来控制Pod的具体状态和行为。
Pod 的分类如下：
1）自主式 Pod：Pod 退出了，此类型的 Pod 不会被创建
2）控制器管理的 Pod：在控制器的生命周期里，始终要维持 Pod 的副本数目- 常用控制器
1）ReplicationController（副本控制器旧版本，目前基本不用了）
2）ReplicaSet（新的副本控制器，我们现在都用这个）
3）Deployment （是新一代用于Pod和ReplicaSet管理的对象）
4）DaemonSet （DaemonSet 确保全部（或者某些）节点上运行一个 Pod 的副本，删除 DaemonSet 将会删除它创建的所有 Pod）
5）StatefulSet （是用来管理有状态应用的工作负载 API 对象）
6）Job/Cronjob （定时任务）- 自主式Pod(单独定义一个pod,这个没有没有副本控制器管理，也没有对应deployment)
# 自主式的pod: 单独定义一个pod,这个没有没有副本控制器管理，也没有对应deployment #init-pod.yaml apiVersion: v1 kind: Pod metadata: name: init-pod labels: app: myapp spec: containers: - name: myapp image: myapp:v1 initContainers: - name: init-mydb image: myapp:v1
- RC&RS
ReplicationController (RC)用来确保容器应用的副本数始终保持在用户定义的副本数,即如果有容器 异常退出,会自动创建新的Pod来替代;而如果异常多出来的容器也会自动回收.
在新版本的Kubernetes中建议使用Replicaset来取代ReplicationController. ReplicaSet跟 ReplicationController没有本质的不同,只是名字不一样,并且ReplicaSet支持集合式的selector。使用yaml脚本单独创建如下：apiVersion: extensions/v1beta1 kind: ReplicaSet metadata: name: frontend spec: replicas: 3 selector: matchLabels: tier: frontend template: metadata: labels: tier: frontend spec: containers: - name: Java-nginx image: myapp:v1 env: - name: GET_HOSTS_FROM value: dns ports: - containerPort: 80注意：使用上面的yaml脚本创建RS之后，会存在3个pod,一个RS,但是没有deployment,那么没有deployment就没有办法做滚动更新，但是副本的数量是可以控制的。
- Deployment
Deployment为Pod和ReplicaSet提供了一个声明式定义(declarative)方法,用来替代以前的 ReplicationController来方便的管理应用。
典型的应用场景包括如下;
1）定义Deployment来创建Pod和ReplicaSet
2）滚动升级和回滚应用
3）扩容和缩容
4）暂停和继续Deploymen
案例部署一个简单的Nginx应用：
首选我们创建一个my-deployment.yaml文件：
内容如下：apiVersion: extensions/v1beta1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 3 template: metadata: labels: app: nginx spec: containers: - name: nginx image: hub.harbor.com/library/myapp:v1 env: - name: GET_HOSTS_FROM value: dns ports: - containerPort: 80执行脚本：kubectl create -f my-deployment.yaml
下面我们来看看deployment的滚动更新，由上面的脚本可知我们现在运行的容器对应的镜像版本是hub.harbor.com/library/myapp:v1，
那么我们如何使用命令切换为hub.harbor.com/library/myapp:v2版本呢？
命令：kubectl set image deployment 指定的deployment名称 容器名称=指定的image版本
kubectl set image deployment nginx-deployment nginx=hub.harbor.com/library/myapp:v2- 将上面的v2版本回滚到历史版本
命令：kubectl rollout undo deployment deployment名称- Deployment更新策略
Deployment可以保证在升级时只有一定数量的Pod是down的。默认的,它会确保至少有比期望的 Pod数量少一个是up状态(最多一个不可用)。
Deployment同时也可以确保只创建出超过期望数量的一定数量的Pod,默认的,它会确保最多比期望 的Pod数量多一个的Pod是up的(最多1个surge )- DaemonSet
创建一个my-daemonset.yaml文件：
内容如下：apiVersion: apps/v1 kind: DaemonSet metadata: name: my-deamon namespace: default labels: app: daemonset spec: selector: matchLabels: app: my-daemonset template: metadata: labels: app: my-daemonset spec: containers: - name: daemon-app image: hub.harbor.com/library/myapp:v1执行脚本：kubectl create -f my-daemonset.yaml
2.pod简介
Pod是kubernetes中你可以创建和部署的最⼩也是最简的单位。 ⼀个Pod代表着集群中运⾏的⼀个 进程。 Pod中封装着应⽤的容器（有的情况下是好⼏个容器） ， 存储、 独⽴的⽹络IP， 管理容器如何 运⾏的策略选项。 Pod代 表着部署的⼀个单位： kubernetes中应⽤的⼀个实例， 可能由⼀个或者多个 容器组合在⼀起共享资源。 在Kubrenetes集群中Pod有如下两种使⽤⽅式：
- ⼀个Pod中运⾏⼀个容器。 “每个Pod中⼀个容器”的模式是最常⻅的⽤法； 在这种使⽤⽅式 中， 你可以把Pod想象成是单个容器的封装， kuberentes管理的是Pod⽽不是直接管理容 器。
- 在⼀个Pod中同时运⾏多个容器。 ⼀个Pod中也可以同时封装⼏个需要紧密耦合互相协作的容 器， 它们之间共享资源。 这些在同⼀个Pod中的容器可以互相协作成为⼀个service单位—— ⼀个容器共享⽂件， 另⼀个“sidecar”容器来更新这些⽂件。 Pod将这些容器的存储资源作为 ⼀个实体来管理
每个Pod都是应⽤的⼀个实例。 如果你想平⾏扩展应⽤的话（运⾏多个实例） ， 你应该运⾏多个 Pod， 每个Pod都是⼀个应⽤实例。 在Kubernetes中， 这通常被称为replication。
服务如何部署：
- 建议一个pod中部署一个容器（通常情况下都是这样的）
- 有一些业务上紧密耦合的服务，可以部署在一个容器，通信效率比较高。
3.Pod Phase
Pod 的 status 属性是一个 PodStatus 对象，拥有一个 phase 字段。它简单描述了 Pod 在其生 命周期的阶段。
- Pending
Pod 已被 Kubernetes 接受，但尚未创建一个或多个容器镜像。这包括被调度之 前的时间以及通过网络下载镜像所花费的时间，执行需要一段时间。- Running
Pod 已经被绑定到了一个节点，所有容器已被创建。至少一个容器正在运行，或 者正在启动或重新启动。- Succeeded
所有容器成功终止，也不会重启。- Failed
所有容器终止，至少有一个容器以失败方式终止。也就是说，这个容器要么已非 0 状态退出，要么被系统终止。- Unknown
由于一些原因，Pod 的状态无法获取，通常是与 Pod 通信时出错导致的。
4.pod的重启策略
Pod 的重启策略有 3 种，默认值为 Always。
- Always
容器失效时，kubelet 自动重启该容器；- OnFailure
容器终止运行且退出码不为0时重启；- Never
不论状态为何， kubelet 都不重启该容器。失败的容器由 kubelet 以五分钟为上限的指数退避延迟（10秒，20秒，40秒…）重新启动，并在成功执行 十分钟后重置
5.pod生命周期详解
说明：
- 初始化容器阶段初始化pod中每一个容器,他们是串行执行的，执行完成后就退出了
- 启动主容器main container
- 在main container刚刚启动之后可以执行post start命令
- 在整个main container执行的过程中可以做两类探测：liveness probe(存活 探测)和readiness probe(就绪探测)
- 在main container结束前可以执行pre stop命令
配置启动后钩子(post start)和终止前钩子(pre stop)
- post start：容器创建之后立即执行，如果失败了就会按照重启策略重启容器
- pre stop：容器终止前立即执行，执行完成之后容器将成功终止
可以使用以下命令查看post start和pre stop的设置格式：
- kubectl explain pod.spec.containers.lifecycle.preStop
- kubectl explain pod.spec.containers.lifecycle.postStar
pod init：
- init容器
Pod能够持有多个容器，应用运行在容器里面，但是它也可能有一个或多个先于应用容器启动的 Init容器。
Init容器与普通的容器非常像，除了如下两点：
1）Init容器总是运行到成功完成为止
2）每个Init容器都必须在下一个Init容器启动之前成功完成
如果Pod的Init容器失败，Kubernetes会不断地重启该Pod，直到Init容器成功为止。然而，如果 Pod对应的restartPolicy为Never，它不会重新启动- init作用
因为Init容器具有与应用程序容器分离的单独镜像，所以它们的启动相关代码具有如下优势：
1）它们可以包含并运行实用工具，但是出于安全考虑，是不建议在应用程序容器镜像中包含 这些实用工具的
2）它们可以包含使用工具和定制化代码来安装，但是不能出现在应用程序镜像中。例如，创 建镜像没必要FROM另一个镜像，只需要在安装过程中使用类似sed、awk、python或dig这 样的工具
3）应用程序镜像可以分离出创建和部署的角色，而没有必要联合它们构建一个单独的镜像。
4）Init容器使用LinuxNamespace，所以相对应用程序容器来说具有不同的文件系统视图。 因此，它们能够具有访问Secret的权限，而应用程序容器则不能。
5）它们必须在应用程序容器启动之前运行完成，而应用程序容器是并行运行的，所以Init容 器能够提供了一种简单的阻塞或延迟应用容器的启动的方法，直到满足了一组先决条件。- 特殊说明
1）在Pod启动过程中，Init容器会按顺序在网络和数据卷初始化之后启动。每个容器必须在 下一个容器启动之前成功退出(网络和数据卷初始化是在pause)
2）如果由于运行时或失败退出，将导致容器启动失败，它会根据Pod的restartPolicy指定的 策略进行重试。然而，如果Pod的restartPolicy设置为Always，Init容器失败时会使用 RestartPolicy策略
3）在所有的Init容器没有成功之前，Pod将不会变成Ready状态。Init容器的端口将不会在 Service中进行聚集。正在初始化中的Pod处于Pending状态，但应该会将Initializing状态设置 为true
4）如果Pod重启，所有Init容器必须重新执行
5）对Init容器spec的修改被限制在容器image字段，修改其他字段都不会生效。更改Init容器 的image字段，等价于重启该Pod
6）Init容器具有应用容器的所有字段。除了readinessProbe（就绪检测），因为Init容器无 法定义不同于完成（completion）的就绪（readiness）之外的其他状态。这会在验证过程中 强制执行
7）在Pod中的每个app和Init容器的名称必须唯一；与任何其它容器共享同一个名称，会在 验证时抛出错误- 案例：
1）首先我们创建一个init-pod.yaml内容如下：
apiVersion: v1 kind: Pod metadata: name: init-pod labels: app: myapp spec: containers: - name: myapp image: hub.harbor.com/library/busybox:v1 command: ['sh', '-c', 'echo -n "running at " && date +%T && sleep 600'] initContainers: #这里有一个初始化容器 - name: init-mydb image: hub.harbor.com/library/busybox:v1 #下面的命令表示会一直反复的查询init-db容器服务，如果查询不到那么该init-pod就会一直启动不成功 command: ['sh', '-c', 'until nslookup init-db; do echo waiting for init-db;date +%T; sleep 2;echo; done;']
2）在创建一个init-db.yaml文件，内容如下：
kind: Service apiVersion: v1 metadata: name: init-db spec: ports: - protocol: TCP port: 80 targetPort: 3366
3）通过命令对两个脚本进行执行
3.1）先执行init-pod.yaml
命令：kubectl create -f init-pod.yaml
#查看pod状态 init没成功
kubectl get pod
#查看log
kubectl logs init-pod -c init-mydb
可以发现一只在查找init-db容器服务。
3.2）下面我们执行init-db.yaml文件
命令：kubectl create -f init-db.yaml
#查看
kubectl get svc
再次通过kubectl get pod查看init-pod服务容器（等的时间可能会长点）
6.容器探针
探针是由kubelet对容器执行的定期诊断。要执行诊断，kubelet调用由容器实现的Handler。有三 种类型的处理程序：
- ExecAction：在容器内执行指定命令。如果命令退出时返回码为0则认为诊断成功。
- TCPSocketAction：对指定端口上的容器的IP地址进行TCP检查。如果端口打开，则诊断被认 为是成功的。
- HTTPGetAction：对指定的端口和路径上的容器的IP地址执行HTTPGet请求。如果响应的状 态码大于等于200且小于400，则诊断被认为是成功的
每次探测都将获得以下三种结果之一：
- 成功：容器通过了诊断。
- 失败：容器未通过诊断。
- 未知：诊断失败，因此不会采取任何行动
探测方式：
- livenessProbe：指示容器是否正在运行。如果存活探测失败，则kubelet会杀死容器， 并且容器将受到其重启策略的影响。如果容器不提供存活探针，则默认状态为Success（会随 着容器的生命周期一直存在）
- readinessProbe：指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从 与Pod匹配的所有Service的端点中删除该Pod的IP地址。初始延迟之前的就绪状态默认为 Failure。如果容器不提供就绪探针，则默认状态为Success
6.1）案例之检测探针之就绪检测
在/opt目录下创建readiness-probe.yaml文件并且内容如下：
#这个是我们的版本信息 apiVersion: v1 #这个表示资源类型我们创建的是Pod kind: Pod metadata: #这个里面定义的是deployment中我们创建的对象信息 #对象名称 name: readiness-httpget-pod #元数据名称空间 namespace: default spec: #这个是对Pod的详细定义 # 定义Pod下面的容器 containers: #定义容器的名称 - name: readiness-httpget-container image: hub.harbor.com/library/myapp:v1 #定义镜像的拉取策略 imagePullPolicy: IfNotPresent #下面定义就绪检查策略 readinessProbe: #使用httpGet的方式 httpGet: port: 80 path: /index1.html #初始化时间为1秒 initialDelaySeconds: 1 #每隔3秒重试检测一遍 periodSeconds: 3使用命令执行：kubectl create -f readiness-probe.yaml
查看pod状态：
由上面我们可以发现一个问题，这个pod的状态是Running但是pod里面的容器却还没有Ready,还没有启动起来。下面我们通过命令查看这个pod的详细信息。命令：kubectl describe pod readiness-httpget-pod
那么我们就需要看一下上面我们定义的httpget请求的index1.html是否存在了
下面我们通过命令进入容器内部：kubectl exec -it readiness-httpget-pod -- /bin/sh
那么我们在里面创建一个index1.html退出容器我们再次查看pod状态，发现已经成功了，说明readiness一直在检测容器，我们刚一修改后它就检测到了
6.2）案例之检测探针之存活检测
在/opt目录下创建liveness-exec.yaml文件并且内容如下:
#这个是我们的版本信息 apiVersion: v1 #这个表示资源类型我们创建的是Pod kind: Pod metadata: #这个里面定义的是deployment中我们创建的对象信息 #对象名称 name: liveness-exec-pod #元数据名称空间 namespace: default spec: #这个是对Pod的详细定义 # 定义Pod下面的容器 containers: #定义容器的名称 - name: liveness-exec-container image: hub.harbor.com/library/busybox:v1 #定义镜像的拉取策略 imagePullPolicy: IfNotPresent #下面的命令表示启动容器的时候会创建/tmp/live目录，并且睡眠60秒后会删除这个文件 command: ["/bin/sh","-c","touch /tmp/live;sleep 60;rm -rf /tmp/live;sleep 3600"] #下面定义就绪检查策略 livenessProbe: #使用httpGet的方式 exec: #表示容器会一直检测/tmp/live文件是否存在，不存在则会重新创建容器 command: ["test","-e","/tmp/live"] #初始化时间为1秒 initialDelaySeconds: 1 #每隔3秒重试检测一遍 periodSeconds: 3执行文件：
过一会会发现重启次数会不断增加，这就是存活检测：
当然我们也可以使用http方式进行存活检测：
#这个是我们的版本信息 apiVersion: v1 #这个表示资源类型我们创建的是Pod kind: Pod metadata: #对象名称 name: liveness-httpget-pod #元数据名称空间 namespace: default spec: #这个是对Pod的详细定义 # 定义Pod下面的容器 containers: #定义容器的名称 - name: liveness-httpget-container image: hub.harbor.com/library/myapp:v1 #定义镜像的拉取策略 imagePullPolicy: IfNotPresent ports: #定义容器的名称和端口 - name: http containerPort: 80 #下面定义就绪检查策略 livenessProbe: #使用httpGet的方式 httpGet: port: 80 path: /index.html #初始化时间为1秒 initialDelaySeconds: 1 #每隔3秒重试检测一遍 periodSeconds: 3 #超时时间10s timeoutSeconds: 10我们可以执行上面的文件，然后进入容器内部，删除index.html,看看容器是否就无法正常运行了
6.3）案例检测探针之livenessProbe-Tcp方式存活检测配置文件可以类似下面：
apiVersion: v1 kind: Pod metadata: name: probe-tcp spec: containers: - name: myapp image: hub.harbor.com/library/myapp:v1 #下面定义就绪检查策略 livenessProbe: #使用tcpSocket的方式 tcpSocket: #下面就一直监听80端口，80端口不通就会一直重启容器 port: 80 #初始化时间为1秒 initialDelaySeconds: 1 #每隔3秒重试检测一遍 periodSeconds: 3 #超时时间10s timeoutSeconds: 106.4）也可以同时定义存活检测和就绪检测
#这个是我们的版本信息 apiVersion: v1 #这个表示资源类型我们创建的是Pod kind: Pod metadata: #对象名称 name: liveness-httpget-pod #元数据名称空间 namespace: default spec: #这个是对Pod的详细定义 # 定义Pod下面的容器 containers: #定义容器的名称 - name: liveness-httpget-container image: hub.harbor.com/library/myapp:v1 #定义镜像的拉取策略 imagePullPolicy: IfNotPresent ports: #定义容器的名称和端口 - name: http containerPort: 80 #下面定义就绪检查策略 readinessProbe: #使用httpGet的方式 httpGet: port: 80 path: /index1.html #初始化时间为1秒 initialDelaySeconds: 1 #每隔3秒重试检测一遍 periodSeconds: 3 #超时时间10s timeoutSeconds: 10 #下面定义就绪检查策略 livenessProbe: #使用httpGet的方式 httpGet: port: 80 path: /index.html #初始化时间为1秒 initialDelaySeconds: 1 #每隔3秒重试检测一遍 periodSeconds: 3 #超时时间10s timeoutSeconds: 106.5）启动及退出动作
apiVersion: v1 kind: Pod metadata: name: lifecycle-demo spec: containers: - name: lifecycle-container image: hub.harbor.com/library/busybox:v1 #下面定义容器启动前和退出前的操作 lifecycle: postStart: #启动前执行下面的命令 exec: command: ["/bin/sh","-c","echo Hello from the postStart handler > /usr/share/message"] preStop: #容器停止前执行下面的命令 exec: command: ["/bin/sh","-c","echo Hello container stop"]
扫一扫
860
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
