在配置Pod时,我们可以为其中的每个容器指定需要使用的计算资源(CPU和内存)。计算资源的配置项分为两种:Requests和Limits。
如果Pod运行所在的节点具有足够的可用资源,容器可以使用超出所设置的request资源量。不过,容器不可以使用超出所设置的limit资源量
资源请求量能够保证Pod有足够的资源来运行,资源限制量则是防止某个Pod无限制地使用资源,导致其他Pod崩溃。
我们创建一个pod时,可以指定容器对CPU和内存的资源请求量及资源限制量,它们并不在pod里定义,而是针对每个容器单独指定。
pod对资源的请求量和限制量是它所包含的所有容器的请求量和限制量之和。
CPU和内存的Requests和Limits有如下特点:
官网示例:https://kubernetes.io/zh/docs/concepts/configuration/manage-resources-containers/
Pod和容器的资源请求和限制:
spec.containers[].resources.limits.cpu #定义cpu的资源上限
spec.containers[].resources.limits.memory #定义内存的资源上限
spec.containers[].resources.limits.hugepages-<size> #定义hugepages的资源上限
spec.containers[].resources.requests.cpu #定义创建容器时预分配的CPU资源
spec.containers[].resources.requests.memory #定义创建容器时预分配的内存资源
spec.containers[].resources.requests.hugepages-<size> #定义创建容器时预分配的巨页
CPU资源的request和limit以cpu为单位。Kubernetes中的一个cpu相当于1个VCPU (1个超线程)
Kubernetes也支持带小数CPU的请求。spec.containers [].resources.requests.cpu为0.5的容器能够获得一个cpu的一半CPU资源(类似于cgroup对CPU资源的时间分片)。表达式0.1等价于表达式100m (毫核) ,表示每1000毫秒内容器可以使用的CPU时间总量为0.1*1000毫秒。
内存的request和limit以字节为单位。可以以整数表示,或者以10为底数的指数的单位(E、P,T,G,M,K)来表示,或者以2为底数的指数的单位(Ei, Pi,Ti,Gi、Mi, Ki)来表示。
如: 1KB-10^3-1000, 1MB-10^6-1000000-1000KB, 1GB=10^9-1000000000-1000MB
1KiB-2^10-1024, 1MiB-2 20-1048576-1024KiB
PS:在买硬盘的时候,操作系统报的数量要比产品标出或商家号称的小一些,主要原因是标出的是以MB, GB为单位的, 1GB
就是1,000,000, 000Bte ,而操作系统是以2进制为处理单位的,因此检查硬盘容量时是以MiB, GiB为单位, 1GB-2^30-1,073, 741, 824,相比较而言,1GiB要比1GB多出1,073, 741, 824-1, 000, 000, 000-73, 741, 824Byte,所以检测实际结果要比标出的少一些。
#先在每个节点上清空内存
echo 1 > /proc/sys/vm/drop_caches
echo 2 > /proc/sys/vm/drop_caches
echo 3 > /proc/sys/vm/drop_caches
free -m
[root@master ~]# vim demo1.yaml
apiVersion: v1
kind: Pod
metadata:
name: frontend
spec:
containers:
- name: web
image: nginx
env:
- name: WEB_ROOT_PASSWORD
value: "password"
resources:
#此容器预分配资源:内存为 64Mi ; 每个cpu 分配250m
requests:
memory: "64Mi"
cpu: "250m"
#此容器限制使用资源(最大): 内存最大使用128Mi,每个cpu最大分配500m
limits:
memory: "128Mi"
cpu: "500m"
- name: db
image: mysql
env:
- name: MYSQL_ROOT_PASSWORD
value: "abc123"
resources:
#此容器的预分配资源:内存预分配为512Mi;cpu预分配为每个cpu的50%,即1000*50%=500m
requests:
memory: "512Mi"
cpu: "0.5"
#此容器的限制使用资源配额为:内存最大使用1Gi;cpu最大使用1000m
limits:
memory: "1Gi"
cpu: "1"
#pod有两个容器,web 和db。所以,总的请求资源和限制资源为 web 和db 请求,限制资源总和。
#其中,cpu 的资源请求和限制,是以单个cpu 资源进行计算的。如果有多个cpu,则最终的结果是数值*N
[root@master ~]# kubectl get pod
[root@master ~]# kubectl describe pod frontend
# 查看pod的详细信息,查看pod被调度到了哪个node节点
[root@master ~]# kubectl get pod -o wide
#查看node01 节点的信息
[root@master ~]# kubectl describe nodes node01
健康检查,又名 探针(Probe):探针是由kubelet对容器执行定期诊断。
探针有三种规则:
注:以上规则可以同时定义。在readinessProbe检测成功之前,Pod的running状态是不会变成ready状态。
每次探测,都将会获得以下三种结果之一:
https://kubernetes.io/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-exec
spec:
containers:
- name: liveness
image: k8s.gcr.io/busybox
args:
- /bin/sh
- -c
- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5
探针可选的参数:
在这个配置文件中,可以看到 Pod 中只有一个容器。
periodSeconds
字段指定了 kubelet 应该每 5 秒执行一次存活探测。
initialDelaySeconds
字段告诉 kubelet 在执行第一次探测前应该等待 5 秒。
kubelet 在容器内执行命令 cat /tmp/healthy
来进行探测。 如果命令执行成功并且返回值为 0,kubelet 就会认为这个容器是健康存活的。 如果这个命令返回非 0 值,kubelet 会杀死这个容器并重新启动它。
[root@master ~]#vim exec.yaml
apiVersion: v1
kind: Pod
metadata:
name: liveness-exec
namespace: default
spec:
containers:
- name: liveness-exec-container
image: busybox
imagePullPolicy: IfNotPresent
command: ["/bin/sh","-c","touch /tmp/live ; sleep 30; rm -rf /tmp/live; sleep 3600"]
#存活检查探针,使用exec的方式,进入容器内部,检测是否有文件或目录/tmp/live
livenessProbe:
exec:
command: ["test","-e","/tmp/live"]
initialDelaySeconds: 1
periodSeconds: 3
#创建pod
[root@master ~]# kubectl create -f exec.yaml
#跟踪查看pod 信息
[root@master ~]# kubectl get pod -o wide -w
#新开一个终端,查看pod 的消息信息
[root@master ~]# kubectl describe pod liveness-exec
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-http
spec:
containers:
- name: liveness
image: k8s.gcr.io/liveness
args:
- /server
livenessProbe:
httpGet:
path: /healthz
port: 8080
httpHeaders:
- name: Custom-Header
value: Awesome
initialDelaySeconds: 3
periodSeconds: 3
在这个配置文件中,可以看到 Pod 也只有一个容器。 periodSeconds
字段指定了 kubelet 每隔 3 秒执行一次存活探测。 initialDelaySeconds
字段告诉 kubelet 在执行第一次探测前应该等待 3 秒。 kubelet 会向容器内运行的服务(服务会监听 8080 端口)发送一个 HTTP GET 请求来执行探测。 如果服务器上 /healthz
路径下的处理程序返回成功代码,则 kubelet 认为容器是健康存活的。 如果处理程序返回失败代码,则 kubelet 会杀死这个容器并且重新启动它。
任何大于或等于 200 并且小于 400 的返回代码标示成功,其它返回代码都标示失败。
[root@master ~]# vim httpget.yaml
apiVersion: v1
kind: Pod
metadata:
name: liveness-httpget
namespace: default
spec:
containers:
- name: liveness-httpget-container
image: soscscs/myapp:v1
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 80
livenessProbe:
httpGet:
port: http
path: /index.html
initialDelaySeconds: 1
periodSeconds: 3
timeoutSeconds: 10
#创建pod
[root@master ~]# kubectl create -f httpget.yaml
#删除pod里容器的文件
[root@master ~]# kubectl exec -it liveness-httpget -- rm -rf /usr/share/nginx/html/index.html
#查看pod 状态和 详细信息
[root@master ~]# kubectl get pods
[root@master ~]# kubectl describe pod liveness-httpge
apiVersion: v1
kind: Pod
metadata:
name: goproxy
labels:
app: goproxy
spec:
containers:
- name: goproxy
image: k8s.gcr.io/goproxy:0.1
ports:
- containerPort: 8080
readinessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
livenessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 15
periodSeconds: 20
如你所见,TCP 检测的配置和 HTTP 检测非常相似。 下面这个例子同时使用就绪(readinessProbe)和存活(livenessProbe)探测器。
kubelet 会在容器启动 5 秒后发送第一个就绪探测。 这会尝试连接 goproxy
容器的 8080 端口。 如果探测成功,这个 Pod 会被标记为就绪状态,kubelet 将继续每隔 10 秒运行一次检测。
除了就绪探测,这个配置包括了一个存活探测。 kubelet 会在容器启动 15 秒后进行第一次存活探测。 与就绪探测类似,会尝试连接 goproxy
容器的 8080 端口。 如果存活探测失败,这个容器会被重新启动
[root@master ~]# tcpsocket.yaml
apiVersion: v1
kind: Pod
metadata:
name: probe-tcp
spec:
containers:
- name: nginx
image: soscscs/myapp:v1
livenessProbe:
initialDelaySeconds: 5
timeoutSeconds: 1
tcpSocket:
port: 8080
periodSeconds: 3
[root@master ~]# kubectl create -f tcpsocket.yaml
#查看容器里的端口(查看有无8080端口)
[root@master ~]# kubectl exec -it probe-tcp -- netstat -natp
#查看pod的状态和详细信息
[root@master ~]# kubectl get pods
[root@master ~]# kubectl describe pod probe-tcp
[root@master ~]# vim readiness-httpget.yaml
apiVersion: v1
kind: Pod
metadata:
name: readiness-httpget
namespace: default
spec:
containers:
- name: readiness-httpget-container
image: soscscs/myapp:v1
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 80
readinessProbe:
httpGet:
port: 80
path: /index1.html
initialDelaySeconds: 1
periodSeconds: 3
livenessProbe:
httpGet:
port: http
path: /index.html
initialDelaySeconds: 1
periodSeconds: 3
timeoutSeconds: 10
# 创建pod
[root@master ~]# kubectl create -f readiness-httpget.yaml
#查看pod的详细信息
[root@master ~]# kubectl get pod -w
[root@master ~]# kubectl describe pod readiness-httpget
#此时,因为容器里没有 index1.html文件,所以,httpGet的就绪探测失败
[root@master ~]# kubectl exec -it readiness-httpget -- ls /usr/share/nginx/html
#进入容器,创建index1.html,让就绪探测成功
[root@master ~]# kubectl exec -it readiness-httpget sh
/ # cd /usr/share/nginx/html/
/usr/share/nginx/html # ls
50x.html index.html
/usr/share/nginx/html # echo abc > index1.html
/usr/share/nginx/html # exit
[root@master ~]# kubectl get pods
[root@master ~]# vim readiness-myapp.yaml
apiVersion: v1
kind: Pod
metadata:
name: myapp1
labels:
app: myapp
spec:
containers:
- name: myapp
image: soscscs/myapp:v1
ports:
- name: http
containerPort: 80
readinessProbe:
httpGet:
port: 80
path: /index.html
initialDelaySeconds: 5
periodSeconds: 5
timeoutSeconds: 10
---
apiVersion: v1
kind: Pod
metadata:
name: myapp2
labels:
app: myapp
spec:
containers:
- name: myapp
image: soscscs/myapp:v1
ports:
- name: http
containerPort: 80
readinessProbe:
httpGet:
port: 80
path: /index.html
initialDelaySeconds: 5
periodSeconds: 5
timeoutSeconds: 10
---
apiVersion: v1
kind: Pod
metadata:
name: myapp3
labels:
app: myapp
spec:
containers:
- name: myapp
image: soscscs/myapp:v1
ports:
- name: http
containerPort: 80
readinessProbe:
httpGet:
port: 80
path: /index.html
initialDelaySeconds: 5
periodSeconds: 5
timeoutSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
name: myapp
spec:
selector:
app: myapp
type: ClusterIP
ports:
- name: http
port: 80
targetPort: 80
所有的自主式Pod,name不可以相同。但是使用同一个标签myapp。 service通过标签选择器和对应标签的pod关联
[root@master ~]# kubectl create -f readiness-myapp.yaml
#查看这些资源的详细信息。
[root@master ~]# kubectl get pods,svc,endpoints -o wide
#删除myapp1的 index.html文件,让就绪探测 失败
[root@master ~]# kubectl exec -it myapp1 -- rm -rf /usr/share/nginx/html/index.html
# 查看发现,就绪探测失败的pod被从关联的service中移除ip
[root@master ~]# kubectl get pods,svc,endpoints -o wide
探针有3种:
检查方式3种
探针可选的参数