pod管理调度约束、与健康状态检查

pod的管理

[[email protected] ~]# vim pod.yaml

apiVersion: v1

kind: Pod

metadata:

name: nginx-pod

labels:

app: nginx

spec:

containers:

- name: nginx

image: nginx

创建pod

[[email protected] ~]# kubectl create -f pod.yaml

查看pod信息

[[email protected] ~]# kubectl get all

po/nginx-pod

1/1       Running   0          1m

查看pod的详细信息

[[email protected] ~]# kubectl describe po/nginx-pod

删除创建的pod

[[email protected] ~]# kubectl delete -f pod.yaml

POD的资源管理

[[email protected] ~]# vim pod.yaml

apiVersion: v1

kind: Pod

metadata:

name: nginx-pod

labels:

app: nginx

spec:

containers:

- name: nginx

image: nginx

resources:

requests:

memory: "64Mi"

cpu: "250m"

limits:

memory: "128Mi"

cpu: "500m"

[[email protected] ~]# kubectl create -f pod.yaml

[[email protected] ~]# kubectl describe po/nginx-pod

Limits:

cpu:     500m

memory:  128Mi

pod调度约束与重启策略

[[email protected] ~]# vim pod.yaml

apiVersion: v1

kind: Pod

metadata:

name: nginx-pod

labels:

app: nginx

spec:

nodeName: 192.168.30.22

nodeSelector:

env_role: dev

containers:

- name: nginx

image: nginx

[[email protected] ~]# kubectl create -f pod.yaml

我们指定的是pod在22主机上创建，自然也会分配到这个主机上

[[email protected] ~]# kubectl get pod -o wide

nginx-pod                           1/1       Running   0          2m        172.17.11.3   192.168.30.22

查看主机名标签

[[email protected] ~]# kubectl describe node 192.168.30.22

Name:               192.168.30.22

Roles:              <none>

Labels:             beta.kubernetes.io/arch=amd64

beta.kubernetes.io/os=linux

kubernetes.io/hostname=192.168.30.22

添加标签

[[email protected] ~]# kubectl label nodes 192.168.30.22 env_role=dev

再次查看主机名标签已经把env_role=dev添加进去

[[email protected] ~]# kubectl describe node 192.168.30.22

Name:               192.168.30.22

Roles:              <none>

Labels:             beta.kubernetes.io/arch=amd64

beta.kubernetes.io/os=linux

env_role=dev

kubernetes.io/hostname=192.168.30.22

根据我们的约束再次创建pod已经又放在22主机上了

[[email protected] ~]# kubectl get pod -o wide

nginx-pod2                          1/1       Running   0          1m        172.17.11.5   192.168.30.22

pod健康状态检查

提供 Probe 机制，有以下两种类型：

l livenessProbe

如果检查失败，将杀死容器，根据Pod的restartPolicy来操作。

l readinessProbe

如果检查失败，Kubernetes会把Pod从service endpoints中剔除。

Probe 支持以下三种检查方法：

l httpGet

发送HTTP请求，返回200-400范围状态码为成功。

l exec

执行Shell命令返回状态码是0为成功。

l tcpSocket

发起TCP Socket建立成功。

[[email protected] ~]# vim pod.yaml

apiVersion: v1

kind: Pod

metadata:

name: nginx-pod

labels:

app: nginx

spec:

containers:

- name: nginx

image: nginx

ports:

- containerPort: 80

livenessProbe:

httpGet:

path: /index.html

port: 80

[[email protected] ~]# kubectl create -f pod.yaml

查看详细信息，可以看到这里容器访问80端口的信息

[[email protected] ~]# kubectl describe po/nginx-pod

Restart Count:  0

Liveness:       http-get http://:80/index.html delay=0s timeout=1s period=10s #success=1 #failure=3

Environment:    <none>

通过日志可以看到这里使用kube-probe来访问

[[email protected] ~]# kubectl logs nginx-pod -f

172.17.80.1 - - [08/Jul/2019:10:08:14 +0000] "GET /index.html HTTP/1.1" 200 612 "-" "kube-probe/1.9" "-"

172.17.80.1 - - [08/Jul/2019:10:08:24 +0000] "GET /index.html HTTP/1.1" 200 612 "-" "kube-probe/1.9" "-"

再开一个窗口，进入容器删除index.html看看日志的变化

[[email protected] ~]# kubectl exec -it nginx-pod bash

[email protected]:/# cd /usr/share/nginx/html/

[email protected]:/usr/share/nginx/html# ls

50x.html  index.html

[email protected]:/usr/share/nginx/html# rm index.html

[email protected]:/usr/share/nginx/html# exit

这边10秒后显示404找不到页面了

2019/07/08 10:17:14 [error] 6#6: *55 open() "/usr/share/nginx/html/index.html" failed (2: No such file or directory), client: 172.17.80.1, server: localhost, request: "GET /index.html HTTP/1.1", host: "172.17.80.4:80"

172.17.80.1 - - [08/Jul/2019:10:17:14 +0000] "GET /index.html HTTP/1.1" 404 153 "-" "kube-probe/1.9" "-"

172.17.80.1 - - [08/Jul/2019:10:17:24 +0000] "GET /index.html HTTP/1.1" 404 153 "-" "kube-probe/1.9" "-"

查看pod的详细信息，已经输出404页面，但是它还会再创建一个容器并启动

[[email protected] ~]# kubectl describe pod nginx-pod

Warning  Unhealthy              22s (x3 over 42s)  kubelet, 192.168.30.23  Liveness probe failed: HTTP probe failed with statuscode: 404

Normal   Created                5m (x2 over 14m)  kubelet, 192.168.30.23  Created container

Normal   Started                5m (x2 over 14m)  kubelet, 192.168.30.23  Started container

进入容器再看，容器又有了

[email protected]:~# cd /usr/share/nginx/html

[email protected]:/usr/share/nginx/html# ls

50x.html  index.html

原文地址：https://www.cnblogs.com/zc1741845455/p/11153018.html

时间： 2024-09-29 13:17:09

pod管理调度约束、与健康状态检查的相关文章

完成rs健康状态检查。

VS具有很好的伸缩缩性.可靠性和管埋性,通过LVS要实现的最终目标是:利用linux 操作系统和LVS集群软件实现一个高可用.高性能,低成本的服务器应用集群. LVS集群的组成利用LVS架设的服务器群系统由3个部分组成:最前端的是负栽均衡层(这里用 Lo ad Balancer表示),中间是服务器集群层(用Server Array表示).LVS体系结构如下图所示: 下面对LVS的各个组成部分进行详细介绍负 栽均衡层:位于整个集群系统的最前端,由一台或多台负栽调度器(Dircctm Server)

Oracle 数据库健康状态检查

数据库健康状态检查 使用utl指令.statspack.awr来检查数据库的健康状态 前提: > show parameter time_ timed_statistics; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ timed_statistics boolean TRUE 1:utl ##在8i之前只有这个方式,当然在后续的版本中还是有这个功能

服务器健康状态检查脚本

在日常工作中,我们经常会定期的检查各个服务器的状态,通过此shell脚本系统可以定期的将每日服务器的检查结果发送到邮箱中,此脚本在正式环境中已稳定运行. 因为我们需要通过邮件发送检测结果,首先必须在服务器上开启sendmail服务并设置为开机自启动,然后需要在/etc/mail.rc中设置相应的参数,/etc/mail.rc中参数的设置如下: set from=邮箱地址 set smtp=smtp服务器的地址 set smtp-auth-user=邮箱的用户名 set smtp-auth-pas

如何利用nginx_upstream_check_module-master对nginx的后端机器进行健康状态检查

用nginx做前端反向代理,如果后端服务器宕掉的话,nginx是不会把这台realserver踢出upstream的,还会把请求转发到后端的这台realserver上面.所以当某台机器出现问题时,我们会看到nginx的日志会有一段转发失败然后转发正常的日志.这次借助与淘宝技术团队开发的nginx模快nginx_upstream_check_module来检测后方realserver的健康状态,如果后端服务器不可用,则会将其踢出upstream,所有的请求不转发到这台服务器.当期恢复正常时,将其加

Kubernetes 健康状态检查(九)

强大的自愈能力是 Kubernetes 这类容器编排引擎的一个重要特性.自愈的默认实现方式是自动重启发生故障的容器.除此之外,用户还可以利用 Liveness 和 Readiness 探测机制设置更精细的健康检查,进而实现如下需求: 零停机部署. 避免部署无效的镜像. 更加安全的滚动升级. 一.Liveness 探测 Liveness 探测让用户可以自定义判断容器是否健康的条件.如果探测失败,Kubernetes 就会重启容器. 我们创建一个 Pod 的配置文件liveness.yaml,可以使

利用ldirectord实现lvs后端realserver健康状态检查

ldirectord用来实现LVS负载均衡资源在主.备节点间的故障转移.在首次启动时,ldirectord可以自动创建IPVS表.此外,它还可以监控各RealServer的运行状态,一旦发现某RealServer运行异常时,还可以将其从IPVS表中移除. ldirectord进程通过向RealServer的RIP发送资源访问请求并通过由RealServer返回的响应信息来确定RealServer的运行状态.在Director上,每一个VIP需要一个单独的ldirectord进程.如果RealSe

LVS集群RS健康状态检查

生产中,我们需要检测RS状态,当RS服务异常时,应该将RS移出集群,而当RS恢复之后,再将RS加入到集群中.下面是脚本内容 #!/bin/bash VIP=192.168.10.3 ##集群服务端口号 CPORT=80 RS=(192.168.10.7 192.168.10.8) ###RS主机的状态,1表示状态正常 RSTATUS=(1 1) #权重 RW=(2 1) ###RS主机上实际的服务端口 RPORT=80 ###lVS的模式,这里以DR模式为例 TYPE=g ###add函数表示将

nutanix ncc 健康状态检查

[email protected]:IP:~$ ncc health_checks run_all #################################### # TIMESTAMP : 12/11/2019 11:11:51 AM #################################### ncc_version: 3.8.0.1-e1c40011 cluster id: 437130685937377560 cluster name: node with serv

如何编写LVS对Real Server的健康状态检测脚本

简介:Linux 虚拟服务器(Linux Virtual Server. LVS),是一个由章文松开发的自由软件.利用KVS可以实现高可用的.可伸缩缩的Web, Mail, Cache和Medial等网络股务..井在此基 础上开发支持庞大用户数的,可伸缩的,高可用的电子商务应用.LVS1998年发展到现在,已经变得比较成熟,目前广泛应用在各种网络服务和电了商务应用 中.LVS具有很好的伸缩缩性.可靠性和管埋性,通过LVS要实现的最终目标是:利用linux 操作系统和LVS集群软件实现一个高可用.