jsp 网站开发环境,内蒙古微信公众号114查,h5网站制作报价,网站开发人员配备文章目录 1、Pod1.1、定义1.2、Pod的形式1.3、Pod的使用1.4、 Pod生命周期1.5、初始化容器1.6、临时容器1.6.1、定义1.6.2、使用临时容器的步骤 1.7、静态Pod1.8、创建带标签的pod1.9、容器生命周期回调1.10、容器镜像使用秘钥从私有仓库下载1.11、多容器协同工作 2、Probe 探针… 文章目录 1、Pod1.1、定义1.2、Pod的形式1.3、Pod的使用1.4、 Pod生命周期1.5、初始化容器1.6、临时容器1.6.1、定义1.6.2、使用临时容器的步骤 1.7、静态Pod1.8、创建带标签的pod1.9、容器生命周期回调1.10、容器镜像使用秘钥从私有仓库下载1.11、多容器协同工作 2、Probe 探针机制健康检查机制2.1、探针分类2.2、Probe配置项2.3、编写yaml测试探针机制 1、Pod
1.1、定义
Pod 是一组一个或多个 容器docker容器的集合 就像在豌豆荚中这些容器共享存储、网络、以及怎样运行这些容器的声明 -我们一般不直接创建Pod而是创建一些工作负载由他们来创建Pod
1.2、Pod的形式
Pod对容器有自恢复能力Pod自动重启失败的容器Pod自己不能恢复自己Pod如果被删除就真的没了还是希望k8s集群能自己在其他地方再启动这个Pod单容器Pod多容器协同Pod。我们可以把另外的容器称为 SideCar为应用赋能Pod 天生地为其成员容器提供了两种共享资源网络和 存储 一个Pod由一个Pause容器设置好整个Pod里面所有容器的网络、名称空间等信息 systemctl status可以观测到Pod和容器进程关系 kubelet启动一个Pod准备两个容器一个是Pod声明的应用容器nginx另外一个是 PausePause给当前应用容器设置好网络空间 1.3、Pod的使用
可以编写deploy等各种工作负载的yaml文件最终创建出pod也可以直接创建Pod的模板如下
#这里是 Pod 模版
apiVersion: v1
kind: Pod
metadata:name: my-pod
spec:containers:- name: helloimage: busyboxcommand: [sh, -c, echo Hello, Kubernetes! sleep 3600]restartPolicy: OnFailure
#以上为 Pod 模版1.4、 Pod生命周期 Pod启动会先依次执行所有初始化容器有一个失败则Pod不能启动接下来启动所有的应用容器每一个应用容器都必须能一直运行起来Pod开始正式工作一个启动失败就会尝试重启Pod内的这个容器Pod只要是NotReadyPod就不对外提供服务了
1.5、初始化容器
apiVersion: v1
kind: Pod
metadata:name: pod-life-02namespace: defaultlabels:app: pod-life-02
spec:volumes:- name: content-volemptyDir: {}initContainers: ## Pod在启动containers之前先要【运行完】initContainers的所有容器所以这些容器必须有终结不能一直运行- name: init-c-01image: alpine ### 必须有终结的那个时刻一般不要用一直启动的镜像command: [/bin/sh,-c,echo 12222222 /app/index.html;sleep 30;]volumeMounts: - name: content-volmountPath: /app# - name: init-c-02# image: alpine ### 必须有终结的那个时刻一般不要用一直启动的镜像# command: [/bin/sh,-c,echo 12222222 /app/index.html;sleep 30;]# volumeMounts: # - name: content-vol# mountPath: /appcontainers:### docker run alpine 没有在后台一直启动的程序- name: pod-life-01image: nginx # 默认的启动命令是启动nginx。nginx启动在后台一直有了volumeMounts: - name: content-volmountPath: /usr/share/nginx/html- name: pod-life-02image: alpine #pod里面的containers都必须能启动起来Pod会不断的重启这个容器command: [/bin/sh,-c,sleep 30]1.6、临时容器
1.6.1、定义 临时容器线上排错 有些容器基础镜像。线上没法排错。使用临时容器进入这个Pod。临时容器共享了Pod的所有。临时容器有Debug的一些命令拍错完成以后只要exit退出容器临时容器自动删除 临时容器需要开启特性门控 --feature-gates“EphemeralContainerstrue” 在所有组件api-server、kubelet、scheduler、controller-manager都得配置 1.6.2、使用临时容器的步骤
# 1、声明一个临时容器。准备好json文件
{apiVersion: v1,kind: EphemeralContainers,metadata: {name: my-nginx666 //指定Pod的名字},ephemeralContainers: [{command: [sh],image: busybox, //jre的需要jdk来调试imagePullPolicy: IfNotPresent,name: debugger,stdin: true,tty: true,terminationMessagePolicy: File}]
}# 2、使用临时容器应用一下即可
kubectl replace --raw /api/v1/namespaces/default/pods/my-nginx666【pod
名】/ephemeralcontainers -f ec.json1.7、静态Pod 在 /etc/kubernetes/manifests 位置放的所有Pod.yaml文件机器启动kubelet自己就把他启动起来静态Pod一直守护在他的这个机器上 创建一个 k8s-pod-static.yaml的文件放置在 /etc/kubernetes/manifests 位置上 apiVersion: v1
kind: Pod
metadata:name: static-podnamespace: defaultlabels:app: MYAPP
spec:containers:- name: nginximage: nginx最终效果
1.8、创建带标签的pod
apiVersion: v1
kind: Pod
metadata:name: my-nginx-labelsnamespace: hello666labels:aa: bbcc: ddapp: my-nginx
spec:containers:- name: my-nginximage: nginx查看pod携带的标签属性kubectl get pod --show-labels
1.9、容器生命周期回调 postStart这个回调在容器被创建之后立即被执行。 但是不能保证回调会在容器入口点ENTRYPOINT之前执行没有参数传递给处理程序 preStop在容器因 API 请求或者管理事件诸如存活态探针、启动探针失败、资源抢占、资源竞争等 而被终止之前此回调会被调用。 如果容器已经处于已终止或者已完成状态则对 preStop 回调的调用将失败。 在用来停止容器的 TERM 信号被发出之前回调必须执行结束。 Pod 的终止宽限周期在 PreStop 回调被执行之前即开始计数 所以无论回调函数的执行结果如何容器最终都会在 Pod 的终止宽限期内被终止。 没有参数会被传递给处理程序 apiVersion: v1
kind: Pod
metadata:name: pod-lifecyclenamespace: hello666labels:aa: bbcc: ddapp: v1
spec:containers:- name: nginximage: nginxlifecycle:postStart:# exec:httpGet:host: 10.244.85.196 # 容器启动了立即向这个地址发送/请求启动以后的自动回调path: /port: 80scheme: HTTPpreStop:httpGet:host: 10.244.85.196 # 容器删除了立即向这个地址发送/preStop请求删除容器后的自动回调path: /preStopport: 80scheme: HTTP1.10、容器镜像使用秘钥从私有仓库下载
1. 使用 Docker Config 创建 Secret前提需要知道用于向仓库进行身份验证的用户名、密码和客户端电子邮件地址以及它的主机名
kubectl create secret -n 名称空间 docker-registry 生成的密钥名字 \--docker-serverDOCKER_REGISTRY_SERVER \--docker-usernameDOCKER_USER \--docker-passwordDOCKER_PASSWORD \--docker-emailDOCKER_EMAIL # 邮箱可以不指定2. 查看生成的密钥信息: kubectl get secret -n hello666 -n 后面写你的名称空间3. 在 Pod 中引用 ImagePullSecrets
apiVersion: v1
kind: Pod
metadata:name: pod-secret-nginxnamespace: hello666labels:aa: bbcc: ddapp: nginx-secret
spec:imagePullSecrets:- name: 密钥名字这个就是填第一步里生成的密钥名字多个容器可以配置多个密钥名字k8s可以自己判断启动不同的容器去使用不同的密钥containers:# 第一组容器私有的- name: pod-secret-nginximage: 这里写你的私有镜像地址imagePullPolicy: Always # 拉取策略 # 第二组容器官方下载的k8s知道官方的镜像不需要用密钥下载通过镜像名称的前缀区分- name: my-tomcatimage: tomcat4. 最终这个pod里面会生成两个容器1.11、多容器协同工作 实现效果 准备两个容器一个是alpine一个是nginx利用卷挂载出nginx的index.html页面然后使用alpine一直往这个index.html页面里打印当前时间访问这个容器就显示最新的时间信息 apiVersion: v1
kind: Pod
metadata:name: multicontainer-podnamespace: hello666labels:app: multicontainer-pod
spec:volumes: - emptyDir: {} # 类似于docker的匿名挂载, 外部创建一个位置name: nginx-volcontainers:- name: nginx-containerimage: nginxvolumeMounts: - name: nginx-volmountPath: /usr/share/nginx/html- name: content-containerimage: alpinecommand: [/bin/sh,-c,while true;do sleep 1; date /app/index.html;done;]volumeMounts:- name: nginx-volmountPath: /app最终效果
2、Probe 探针机制健康检查机制
2.1、探针分类
每个容器三种探针Probe 启动探针**后来才加的** 一次性成功探针。 只要启动成功了 kubelet 使用启动探针来检测应用是否已经启动。如果启动就可以进行后续的探测检 查。慢容器一定指定启动探针。一直在等待启动启动探针 成功以后就不用了剩下存活探针和就绪探针持续运行 存活探针 kubelet 使用存活探针来检测容器是否正常存活。有些容器可能产生死锁【应用程序在运行但是无法继续执行后面的步骤】 如果检测失败就会**重新启动这个容器 **initialDelaySeconds 3600长了导致可能应用一段时间不可用 5短了陷入无限启 动循环 就绪探针 kubelet 使用就绪探针来检测容器是否准备好了可以接收流量。当一个 Pod 内的所有 容器都准备好了才能把这个 Pod 看作就绪了。用途就是Service后端负载均衡多个 Pod如果某个Pod还没就绪就会从service负载均衡里面剔除 谁利用这些探针探测 kubelet会主动按照配置给Pod里面的所有容器发送响应的探测请求
2.2、Probe配置项
- initialDelaySeconds 容器启动后要等待多少秒后存活和就绪探测器才被初始化默认
是 0 秒最小值是 0。这是针对以前没有
- periodSeconds 执行探测的时间间隔单位是秒。默认是 10 秒。最小值是 1。
- successThreshold 探测器在失败后被视为成功的最小连续成功数。默认值是 1。- 存活和启动探针的这个值必须是 1。最小值是 1。
- failureThreshold 当探测失败时Kubernetes 的重试次数。 存活探测情况下的放弃就
意味着重新启动容器。 就绪探测情况下的放弃 Pod 会被打上未就绪的标签。默认值是 3。最
小值是 1。
- timeoutSeconds 探测的超时后等待多少秒。默认值是 1 秒。最小值是 1。2.3、编写yaml测试探针机制
apiVersion: v1
kind: Pod
metadata:name: nginx-start-probenamespace: defaultlabels:app: nginx-start-probe
spec:volumes:- name: nginx-volhostPath: path: /app- name: nginx-htmlhostPath: path: /htmlcontainers:- name: nginximage: nginxports:- containerPort: 80startupProbe:exec:command: [/bin/sh,-c,cat /app/abc] ## 返回不是0那就是探测失败# initialDelaySeconds: 20 ## 指定的这个秒以后才执行探测periodSeconds: 5 ## 每隔几秒来运行这个timeoutSeconds: 5 ## 探测超时到了超时时间探测还没返回结果说明失败successThreshold: 1 ## 成功阈值连续几次成才算成功failureThreshold: 3 ## 失败阈值连续几次失败才算真失败volumeMounts:- name: nginx-volmountPath: /app- name: nginx-htmlmountPath: /usr/share/nginx/htmllivenessProbe: ## nginx容器有没有 /abc.html就绪探针# httpGet:# host: 127.0.0.1# path: /abc.html# port: 80# scheme: HTTP# periodSeconds: 5 ## 每隔几秒来运行这个# successThreshold: 1 ## 成功阈值连续几次成才算成功# failureThreshold: 5 ## 失败阈值连续几次失败才算真失败exec:command: [/bin/sh,-c,cat /usr/share/nginx/html/abc.html] ## 返回不是0那就是探测失败# initialDelaySeconds: 20 ## 指定的这个秒以后才执行探测periodSeconds: 5 ## 每隔几秒来运行这个timeoutSeconds: 5 ## 探测超时到了超时时间探测还没返回结果说明失败successThreshold: 1 ## 成功阈值连续几次成才算成功failureThreshold: 3 ## 失败阈值连续几次失败才算真失败readinessProbe: ## 就绪检测都是httphttpGet: # host: 127.0.0.1 ## 不用指定hostpath: /abc.html ## 给容器发请求port: 80scheme: HTTP ## 返回不是0那就是探测失败initialDelaySeconds: 2 ## 指定的这个秒以后才执行探测periodSeconds: 5 ## 每隔几秒来运行这个timeoutSeconds: 5 ## 探测超时到了超时时间探测还没返回结果说明失败successThreshold: 3 ## 成功阈值连续几次成才算成功failureThreshold: 5 ## 失败阈值连续几次失败才算真失败# livenessProbe:# exec: [/bin/sh,-c,sleep 30;abc ] ## 返回不是0那就是探测失败# initialDelaySeconds: 20 ## 指定的这个秒以后才执行探测# periodSeconds: 5 ## 每隔几秒来运行这个# timeoutSeconds: 5 ##探测超时到了超时时间探测还没返回结果说明失败# successThreshold: 5 ## 成功阈值连续几次成才算成功# failureThreshold: 5 ## 失败阈值连续几次失败才算真失败健康检查优雅停机 0宕机 start完成以后liveness和readness并存。 liveness失败导致重启。readness失败导致不给Service负载均衡网络中加不接受流量。 kubectl exec -it 就进不去可以利用 kubectl describe 检查
