pod对象的相位
pod对象启动到完结，总会处于一下生命进程状态中
Pending： Api server将Pod资源 存入etcd中，但是尚未被调度完毕（例如： 资源不够 内存不足等），或者处于下载镜像中。
Running: Pod已经调度到某个子节点，并且已经被kubelet创建完毕并启动完毕，但是容器是否启动不确定。
Successded: Pod中的所有的容器都已经成功终止，并且不会被重启
Failed: 所有容器被终止，但是至少有一个容器终止失败，返回了非0值的退出状态或者被系统终止。
Unknown: Api server 无法正常获取到Pod对象（例如：健康状态）的信息。通常是无法和子节点的kubelet通信导致的。pod创建过程
用户传输提交创建一个Pod，会把次请求调度到Api server，Api server 会把用户未指定的参数按照默认字段的默认值自动补全，然后把请求调度资源存储到etcd数据库中,然后Api server会把一个创建Pod的监控事件通知给Scheduler， 这时候Scheduler会自动监控Pod的创建，然后通过bind算法把Pod的创建(可能是根据资源)的结果返还给Api server，然后Api server会把此结果填充到etcd中,这时候Api server 会把创建Pod的请求发个对应的节点主机Kubelet，对应子节点的kubelet会通过Api server把存储在etcd的数据pod的所有属性调度到本地的docker服务，然后创建容器，创建完成与否都会把结果反馈到本机的kubelet，kubelet把实际结果状态提交给Api server,然后Api server把Pod的实际状态填写到etcd中。
pod的重启机制
Pod的对象应为容器程序崩溃或者容器申请的资源超出限制资源等原因都会导致容器被终止，此时是否应该重启取决于其重启机制(restartPolict)
Always: 只要Pod对象终止就重启，默认策略
NoFaikure：仅仅在Pod对象出现错误时，才重启
Never： 从不重启
Pod终止过程
客户端请求删除一个Pod，会把这个请求发送给 Api server，Api server会把删除Pod记录存储到etcd中，并不会立即删除此Pod(防止正在运行访问的程序进程被误删除)，等待30s宽限期。然后把删除请求访问发送到节点的kubelet，然后通过docker删除正在运行的容器。在返回最终结果到Api server，通过Api server到etcd数据库删除对应Pod的数据库对象。pod级别安全上下文 securityContext
管理容器安全方面的
[[email protected] ~]# kubectl explain pods.spec.securityContext
fsGroup <integer>： 适用于pod中所有容器的特殊补充组
runAsGroup <integer>： 容器内容只能按照定义的组运行 groupid号
runAsNonRoot <boolean>：容器内容只能按照定义的非管理员用户运行 true|false(可以使用管理员)
runAsUser <integer>： 容器内容只能按照定义的用户运行 id号
seLinuxOptions <Object>： 启用selinux管理安全防护，主节点要支持selinux
supplementalGroups <[]integer>：额外补充附属组运行
sysctls <[]Object>： 设定为你的运行容器设定运行内核参数容器级别安全上下文 securityContext 只针对单个容器设定
[email protected] ~]# kubectl explain pods.spec.containers.securityContext
allowPrivilegeEscalation <boolean>： true|falase 允不允许以管理员身份运行 AllowPrivilegeEscalation始终为真
capabilities <Object>： 运行容器时添加/删除功能
privileged <boolean>： true|false 以特权模式运行容器
procMount <string>： procMount表示要用于容器的proc挂载的类型
readOnlyRootFilesystem <boolean>： 此容器是否具有只读根文件系统。默认的是假
runAsGroup <integer>： 用于运行容器进程用户组的GID
runAsNonRoot <boolean>： 指示容器必须作为非根用户运行
runAsUser <integer>： 用于运行容器进程用户的UID
seLinuxOptions <Object>：要应用于容器的SELinux上下文。如果未指定的,容器运行时将为每个对象分配一个随机的SELinux上下文容器。也可以在PodSecurityContext中设置。如果同时设置中指定的值SecurityContext优先。
# 设置容器可以调用那些内核参数capabilities
[[email protected] ~]# kubectl explain pods.spec.containers.securityContext.capabilities
KIND: Pod
VERSION: v1
RESOURCE: capabilities <Object>
DESCRIPTION:
The capabilities to add/drop when running containers. Defaults to the
default set of capabilities granted by the container runtime.
Adds and removes POSIX capabilities from running containers.
FIELDS:
add <[]string>
Added capabilities
drop <[]string>
Removed capabilitiesPod设置优先级 priorityClassName
[[email protected] ~]# kubectl explain pods.spec.priorityClassNamePod 设置容器级别的操作系统 资源(CPU,内存)占用
Kubernetes 作为当下最流行的的容器集群管理平台，需要统筹集群整体的资源使用情况，将合适的资源分配给pod容器使用，既要保证充分利用资源，提高资源利用率，又要保证重要容器在运行周期内能够分配到足够的资源稳定运行。
对于一个pod来说，资源最基础的2个的指标就是：CPU和内存。
Kubernetes提供了个采用requests和limits 两种类型参数对资源进行预分配和使用限制。
limit 会限制pod的资源利用：
当pod 内存超过limit时，会被oom。
当cpu超过limit时，不会被kill，但是会限制不超过limit值。
[[email protected] ~]# kubectl explain pods.spec.containers.resources
limits： 资源上限
requests： 资源下限
.
[[email protected] ~]# vim memory-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: cpu-memory
namespace: prod
spec:
containers:
name: cpustrace
image: nginx
command: ["/usr/bin/ab","-c 100","-n 10000","localhost:8080/login"]
resources:
requests:
memory: "128Mi"
cpu: "200m" #设置0.2颗cpu
limits:
memory: "512Mi" #设置最大使用内存512M
cpu: "400m" #设置最大0.4颗cpu.
resources:
requests:
memory: "128Mi"
cpu: "1" #设置1颗cpu
limits:
memory: "512Mi" #设置最大使用内存512M
cpu: "2" #设置最大使用2颗cpu
超过内存设置 报错OOM信息
原文地址：https://blog.51cto.com/9025736/2400832
时间： 2024-11-13 00:10:54