1、概述
1.1、简介
Kubernetes是通过组合容器将应用放置到一个个的逻辑单元中，达到快速管理业务应用的效果，这个逻辑单元就是Pod。 Pod是Kubernetes中最重要也最基本的概念。
1.2、交付单元历史介绍
1、传统主机阶段 - 单台主机 2、容器环境阶段 - 单个容器 3、任务编排阶段 - Pod(容器集合)
2、Pod的特点解析比较
2.1、Pod vs 容器
1、一个Pod可以有多个容器，彼此间共享网络和存储资源。 2、每一个Pod中有一个Pause容器保存所有容器的状态，通过管理pause容器，达到管理pod中所有容器的效果。 3、只有紧密关系的容器才可以放到一个pod中，不同业务的容器分别放在不同的pod中
2.2、Pod vs 节点
1、同一Pod中的容器总会被调度到相同Node节点 2、不同节点间Pod的通信是基于虚拟二层网络技术实现的。
2.3、Pod vs Pod
普通的Pod和静态Pod(一般不用)
2.4、Pod vs 应用
1、每个Pod都是应用的一个(子应用)实例，有专用的ip，与容器暴露的端口组合为一个service的endpoint地址 2、每个service由kube-proxy转换为本地的ipvs或iptables规则
2.5、应用 vs 应用
1、每个service的enpoint地址由coredns组件解析为对应的服务名称， 2、其他service的pod通过访问该 名称 达到应用间通信的效果
2.6、外部 vs pod
外部流量通过节点网卡进入到k8s集群，基于ipvs或iptables规则找到对应的service，进而找到对应pod地址
3、pod通信
3.1、Pod内多容器通信
容器间通信(容器模型)
3.2、单节点内多Pod通信
主机间容器通信(host模型) docker inspect host
3.3、多节点内多Pod通信
跨主机网络解决方案(overlay模型)
4、Pod核心思想
4.1、应用交付
Kubernetes是一个自动化的容器管理平台，存在的目的就是快速管理各种业务应用。所以它所面对的本 质上就是业务应用。 随着应用的进一步拆分和微服务架构的设计，一个应用被拆分成了多个独立的子模块应用。 虽然Kubernetes将这些应用的各个子模块单独部署在容器上，但是Kubernetes不再是对一个个子应用 容器进行管理，他是将这些子应用容器放在一个逻辑单元中，而这个逻辑单元针对的是应用或服务，通过对逻 辑单元的操作，达到对应用快速管理，从而实现业务的快速交付。 所以说Pod面向的是应用或服务，而不是具体的应用容器或者子应用容器。 一句话： 站得高，可大处着手 看得远，事随心所欲。
4.2、资源管理
kubernetes是一个分布式的资源管理平台，分布的特点就是资源分散，所以Kubernetes的应用，肯定会出
现业务应用的不同模块被分配到多个Node工作结点，那么随之而来，就会出现两种问题：
需要设计一个复杂的资源调度算法，根据业务需求，从不同Node上获取所有特定的数据
强耦合的业务应用，被分配到了不同节点，可能造成不可预测的功能缺失或潜在问题
所以，与其花费大力气解决上述两个问题，还不如把这些功能直接打包到一个逻辑单元pod中：
对内：
所有的子应用容器可以在Pod内部进行单独管理，即使pod在调度到其他Node节点，Pod内部的所
有子应用容器仍可以正常运行。
对外：
对于整个业务系统来说，面向的是一个个的应用或业务功能(即Pod)，可以轻轻松松实现管理。
一句话：
精兵简政，高度自治。
4.3、实现细节
应用业务下放权力到Pod内部了，那么Pod如何管理子应用呢？我们从三个方面来学习： 通信机制： Pod内有个Pause容器，它有独立的ip地址，其他子应用容器基于container网络模式实现统一的对外 服务，大大简化了关联业务容器之间的通信问题。 存储机制： Pod内有专用的数据存储资源对象，其他子应用容器共享该数据卷，实现多容器数据信息的统一存储。 管理机制： 所有子应用容器的信息都保存在pause容器中，通过对pause容器的管理，达到管理所有容器效果。
5、pod管理
5.1、概述
k8s集群通过pod实现了大量业务应用容器的统一管理，而k8s也提供了大量的资源对象来对 pod进行管理： 通过控制器来确保 pod的运行和数量 符合用户的期望状态 通过网络资源来确保 pod的应用服务 可以被外部的服务来进行访问
5.2、pods流程图
5.3、pod关联资源对象图
1、工作负载型资源 Pod、Deployment、DaemonSet、Replica、StatefulSet、Job、Cronjob、Operator 2、服务发现和负载均衡资源 Service、Ingress 3、配置和存储 configMap、Secret、PersistentVolume、PersistentVolumeChain、DownwardAPI 4、动态调整资源 HPA、VPA 5、资源隔离权限控制资源 namespace、nodes、clusterroles、Roles
6、Pod简单实践
6.1、命令行方式
6.1.1、基本语法
命令行创建Pod对象，只需要在命令行中执行一条命令即可 语法：kubectl run NAME --image=image [--port=port] [--replicas=replicas] 参数详解 --dry-run=true 以模拟的方式来进行执行命令 --env=[] 执行的时候，向对象中传入一些变量 --image='' 指定容器要运行的镜像 --labels='' 设定pod对象的标签 --limits='cpu=200m,memory=512Mi' 设定容器启动后的资源配置 --replicas=n 设定pod的副本数量 --port='' 设定容器暴露的端口
6.1.2、运行nginx镜像
]# kubectl run nginx-1 --image=nginx pod/nginx-1 created ]# kubectl run nginx-2 --image=nginx --port=9999 pod/nginx-2 created
6.2、配置文件方式
6.2.1、布署Nginx-创建资源文件
# 创建nginx pod并且传入环境变量
cat >nginx_pod.yml<<'EOF'
apiVersion: v1
kind: Pod
metadata:
name: nginx-test
spec:
containers:
- name: nginx
image: 192.168.10.33:80/k8s/my_nginx:v1
env:
- name: HELLO
value: "Hello kubernetes nginx"
EOF
注意：
资源定义文件中可以同时写多个Pod对象，彼此间使用"---"隔开就可以了
6.2.2、应用资源文件
语法：
kubectl create|apply -f nginx_pod.yml
子命令解析：
create 仅仅是创建一个对象，如果对象已存在，则不会重复创建
apply 比较前后配置差异 而后作变更，如果不加限制此命令，会引起很大的隐患
命令示例：
]# kubectl create -f nginx_pod.yml
pod "nginx-test" created
7、Pod管理
7.1、资源查看
7.1.1、语法
通过命令行工具，查看Pod对象的基本信息 语法： kubectl get pod/po <Pod_name> kubectl get pod/po <Pod_name> -o wide|yaml 注释： -o wide 获取更多详细的信息
7.1.2、查询pod
kubectl get pod kubectl get pod -o yaml [root@master1 ~]# kubectl get pod nginx-test -o custom-columns=NAME:metadata.name,STATUS:status.phase NAME STATUS nginx-test Running
7.2、资源描述
7.2.1、语法
通过命令行工具，查看Pod对象的全部信息 语法：kubectl describe pod/po <Pod_name> 示例： ]# kubectl describe po
7.2.2、描述查询
]# kubectl get pod NAME READY STATUS RESTARTS AGE nginx-deployment-6ff7d5db94-vdsqn 1/1 Running 0 19h nginx-test 1/1 Running 0 26m tomcat-deployment-774f9fdf7d-kw9x4 1/1 Running 0 20h ]# kubectl describe pod nginx-test
7.3、资源修改
7.3.1、语法
修改yaml文件里面的内容 value: "Hello nginx" 更改命令 kubectl replace -f FILENAME [options] 参数详解： --force 表示强制更新 注意： kubectl edit 是实时修改
7.3.2、执行修改
]# kubectl replace -f nginx_pod.yml --force
]# kubectl get pod nginx-test -o yaml | grep value
value: Hello nginx
7.4、资源删除
7.4.1、语法
删除一个Pod对象有三种方式，如下： 语法一：kubectl delete pod --all/[pod_name] 语法二：kubectl delete deployment --all/[deployment_name] 语法三：kubectl delete -f pod_name.yaml 注意： 方法二要求有相应的deployment前提才可以。
7.4.2、执行删除
# 查询deployment和pod # deployment ]# kubectl get deployments.apps NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 1/1 1 1 23h tomcat-deployment 1/1 1 1 20h # pod ]# kubectl get pods NAME READY STATUS RESTARTS AGE nginx-deployment-6ff7d5db94-vdsqn 1/1 Running 0 19h nginx-test 1/1 Running 0 3m53s tomcat-deployment-774f9fdf7d-kw9x4 1/1 Running 0 20h # 方法1：删除pod kubectl delete pod nginx-test # 方法2：删除deployments，对应的pods也会删除，但是service还需要手动删除“kubectl delete service tomcat-web-service” kubectl delete deployments.apps tomcat-deployment # 方法3：此方式删除是把deployment和service都删除的 kubectl delete -f nginx-proxy.yml
8、Pod流程解析
8.1、创建流程
8.1.1、Pod流程示意图
8.1.2、Pod流程解析
用户通过多种方式向master结点上的API-Server发起创建一个Pod的请求 apiserver 将该信息写入 etcd scheduluer 检测到api-Server上有建立Pod请求，开始调度该Pod到指定的Node，同时更新信息到etcd kubelet 检测到有新的 Pod 调度过来，通过Docker引擎运行该 Pod对象 kubelet 通过 container runtime 取到 Pod 状态，并同步信息到 apiserver，由它更新信息到etcd
8.2、Pod生命周期
8.2.1、简介
公司的业务应用项目是有生命周期的，Kubernetes是基于业务应用或服务进行统一管理的平台，每一个应用服务对应一个Pod，所以伴随着业务应用，Pod也有独立的生命周期。
8.2.2、生命周期流程图
三种模式： sideCar模式 - 为主容器提供辅助功能 Adapater模式 - 帮助主容器通信过程中的信息格式修正 Ambassador模式 - 利用pod内多容器共享数据的特性，代理后端容器和外部的其他应用进行交流
8.2.3、流程解析
顺序1：init容器 初始化容器，独立于主容器之外，pod可以拥有任意数量的init容器，init顺序执行。最后一个执行完 成后，才启动主容器。它主要是为了为主容器准备应用的功能，比如向主容器的存储卷写入数据，然后将存储 卷挂载到主容器上。 合理使用就绪探针(Readiness) 顺序2：生命周期钩子 启动后钩子 【与主进程并行运行】 运行中钩子 Liveiness - 判断当前容器是否处于存活状态 Readiness - 判断当前容器是否可以正常的对外提供服务 停止前钩子 先执行钩子，并在钩子执行完成后，向容器发送SIGTERM信号。如果没有优雅终止，则会被杀死。 不管执行成功与否，容器都会终止，如果未成功则告警。 顺序3：pod关闭 当API服务器接收到删除pod对象的命令后，按照下面流程进行： 执行停止前钩子，等待它执行完毕 向容器的主进程发送SIGTERM信号 等待容器优雅关闭或者等待终止宽限期超时 如果容器没有优雅关闭，使用SIGKILL信号强制终止进程 设置终止宽限期 spec.terminationGracePeriod，默认为30s 命令：kubectl delete pod mypod --grace-period=5 强制：kubectl delete pod mypod --grace-period=0 --force 根据我们对上面pod的启动流程的了解，我们发现当容器中的进程启动前或者容器中的进程终止之前都会 有一些额外的动作执行，这是由kubelet所设置的，在这里，我们称之为 pod hook。而Kubernetes 为我 们提供了两种钩子函数：PostStart和PreStop。 关于钩子函数的执行主要有两种方式： Exec - 用于执行一段特定的命令，不过要注意的是该命令消耗的资源会被计入容器。 HTTP - 对容器上的特定的端点执行HTTP请求。
8.3、Pod状态
8.3.1、状态解析
正常情况： 在Kubernetes集群中，真正工作的是Node节点，所以业务的子应用也就是Pod，肯定会被分配到相应 的Node节点上。Pod一旦绑定到Node节点，就永远不会移动，即便Node节点发生重启。 Pod作为一种资源对象，在整个业务生命周期中，会随着操作而出现五种状态： pending，running，succeeded，failed，Unknown 业务应用作为系统的一部分，会有相应的资源对象对它们进行统一管理，所以不建议手工单独创建一个 Pod 异常情况： 业务运行过程中不可避免会出现意外，这个时候有三种策略对Pod进行管理： OnFailure，Never和Always（默认） 参考资料： https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/
8.3.2、pod状态
状态 描述 Pending # APIserver已经创建该server,但pod内有一个或多个容器的镜像还未创建，可能在下载中 Running # Pod内所有的容器已创建，且至少有一个容器处于运行状态，正在启动或重启状态 Succeeded # 所有容器均成功执行退出，且不会再重启 Failed # Pod内所有容器都已退出，其中至少有一个容器退出失败。 Unknown # 由于某种原因无法获取Pod的状态比如网络不通 CrashLookBackOff # k8s曾经启动容器成功，但是后来异常情况下，重启次数过多导致异常终止容器退避算法：第1次0秒立刻重启，第二次10秒后重启，第三次20秒后重启, ...
第6次160秒后重启，第7次300秒后重启，如果仍然重启失败，则置为 CrashLookBackOff状态；其他的比如镜像获取，就无效了 Error # 因为集群配置、安全限制、资源等原因导致Pod 启动过程中发生了错误 Evicted # 集群节点 系统内存或硬盘资源不足 导致Pod出现异常 kubectl explain pods.status.phase
8.3.3、容器状态
容器状态 描述 Waiting # 容器处于 Running 和Terminated 状态之前的状态 Running # 容器能够正常的运行状态 Terminated # 容器已经被成功的关闭了 kubectl explain pods.status.containerStatuses.state
8.3.4、流程状态
流程状态 描述 PodScheduled # Pod被调度到某一个结点 Ready # 准备就绪，Pod可以处理请求 Initialized # Pod中所有初始init容器启动完毕 Unschedulable # 由于资源等限制，导致pod无法被调度 ContainersReady # Pod中所有的容器都启动完毕了 kubectl explain pods.status.conditions.status
8.3.5、重启策略
重启策略 描述 Always # 容器失效时，即重启 OnFailure # 容器终止运行，且退出码不为0 时重启 Never # Pod不重启 kubectl explain pods.spec.containers.imagePullPolicy
8.3.6、镜像拉取状态
拉取策略 描述 Always # 总是拉取新镜像，这是默认值 IfNotPresent # 如果本地仓库不存在的话，再拉取新镜像 Never # 不获取新镜像 kubectl explain pod.spec.containers.imagePullPolicy
9、流程实践
9.1、initContainers实践
9.1.1、简介
主容器启动之前要运行的容器，常用于执行一些预置操作 初始化容器必须运行完成至结束，每个初始化容器都必须按定义顺序串行运行
属性信息：kubectl explain pods.spec.initContainers
9.1.2、初始化等待10秒后，再创建容器
cat >pod_init_test.yml<<'EOF'
apiVersion: v1
kind: Pod
metadata:
name: init-pod
labels:
app: init
spec:
containers:
- name: nginx
image: 192.168.10.33:80/k8s/my_nginx:v1
initContainers:
- name: init-myservice
image: 192.168.10.33:80/k8s/my_nginx:v1
command: ['sh', '-c', 'sleep 10;']
EOF
# 创建pods
kubectl apply -f pod_init_test.yml
# 监控pods是否是10秒后创建
]# kubectl get pods -w
NAME READY STATUS RESTARTS AGE
init-pod 0/1 Init:0/1 0 7s
init-pod 0/1 PodInitializing 0 11s
init-pod 1/1 Running 0 12s
9.2、poststart实践
9.2.1、简介
对于pod的流程启动，主要有两种钩子： postStart，容器创建完成后立即运行，不保证一定会于容器中ENTRYPOINT之前运行 preStop，容器终止操作之前立即运行，在其完成前会阻塞删除容器的操作调用 钩子处理器实现方式：Exec 和 HTTP Exec，在钩子事件触发时，直接在当前容器中运行由用户定义的命令 HTTP，在当前容器中向某Url发起HTTP请求 属性信息：kubectl explain pods.spec.initContainers.lifecycle
9.2.2、创建容器时写入html文件
cat >pod-poststart.yaml<<'EOF'
apiVersion: v1
kind: Pod
metadata:
name: poststart
spec:
containers:
- name: busybox
image: busybox
lifecycle:
postStart:
exec:
command: ["/bin/sh","-c","echo 'lifecycle poststart' > /tmp/poststart.html"]
command: ['sh', '-c', 'echo The app is running! && sleep 3600']
EOF
9.2.3、应用并且看效果
kubectl apply -f pod-poststart.yaml ]# kubectl get pods NAME READY STATUS RESTARTS AGE poststart 1/1 Running 0 2m51s ]# kubectl exec poststart -- ls /tmp/ poststart.html ]# kubectl exec poststart -- cat /tmp/poststart.html lifecycle poststart
9.3、prestop实践
9.3.1、简介
kubectl explain pods.spec.initContainers.lifecycle.preStop 功能：实现pod对象移除之前，我们需要做一些事情 实现方式： exec <Object> httpGet <Object> tcpSocket <Object> 钩子处理程序的日志不会在 Pod 事件中公开。 如果处理程序由于某种原因失败，它将播放一个事件。 对于 PostStart，这是 FailedPostStartHook 事件，对于 PreStop，这是 FailedPreStopHook 事件。 您可以通过运行 kubectl describe pod <pod_name> 命令来查看这些事件。
9.3.2、删除pods后往node节点写入文件【k8s系统自动调度到节点】
# 系统自动调度节点
cat >prestop-pod.yaml<<'EOF'
apiVersion: v1
kind: Pod
metadata:
name: prestop-pod
spec:
volumes:
- name: message
hostPath:
path: /tmp
containers:
- name: prestop-pod
image: 192.168.10.33:80/k8s/my_nginx:v1
volumeMounts:
- name: message
mountPath: /prestop/
lifecycle:
preStop:
exec:
command: ['/bin/sh', '-c', 'echo prestop Handler > /prestop/prestop']
EOF
# 指定调度到node2节点
cat > node2_nginx_pod.yml <<'EOF'
apiVersion: v1
kind: Pod
metadata:
name: prestop-pod
spec:
nodeName: node2
volumes:
- name: message
hostPath:
path: /tmp
containers:
- name: prestop-pod
image: 192.168.10.33:80/k8s/nginx:v1
volumeMounts:
- name: message
mountPath: /prestop/
lifecycle:
preStop:
exec:
command: ['/bin/sh', '-c', 'echo prestop Handler > /prestop/prestop']
EOF
9.3.3、应用并且看效果
# 应用资源清单 kubectl apply -f prestop-pod.yaml # 查看pods是否正常运行 ]# kubectl get pods NAME READY STATUS RESTARTS AGE prestop-pod 1/1 Running 0 12s # 查看目录是否挂载正常 ]# kubectl exec prestop-pod -- df -h | grep prestop /dev/mapper/centos-root 18G 4.8G 13G 28% /prestop # 删除pods ]# kubectl delete pod prestop-pod # 在node查看是否存在这个文件 [root@node1 ~]# cat /tmp/prestop prestop Handler
10、静态Pod
10.1、简介
对于pod来说，基于控制的特性主要有两类：静态pod和动态pod。动态pod其实就是我们一直实践中用 到的pod，也就是可以直接被集群中的kubelet进行增删改查的pod，静态pod在本质上与动态pod没有区别， 只是在于静态pod只能在特定的节点上运行，由特定节点上的kubelet进程来管理，对于集群来说，只能看，不能动。
10.1.1、应用场景
常常用于某些结点上的一些隐私操作或者核心操作，而且这些操作往往受到特定结点的场景约束，比如某 些定向监控、特定操作。
10.2、属性解析
10.2.1、配置文件
所谓的配置文件的方式，其实就是在特定的目录下存放我们定制好的资源对象文件，然后结点上的 kubelet服务周期性的检查该目录下的所有内容，对静态pod进行增删改查。其配置方式主要有两步 1、定制kubelet服务定期检查配置目录 2、增删定制资源文件
10.2.2、http方式
1、准备http方式提供资源文件的web站点 2、工作结点的kubelet配置–manifest-url=<资源文件的url下载地址>
10.2.3、总结
这两种方式实现的原理基本上是一致的，只不过一个是在本地设置资源对象文件，一个是在别处设置，我们通过http的方式来获取。
10.3、kubelet配置文件位置介绍
10.3.1、查看kubelet服务配置位置
[root@master1 deplay]# rpm -ql kubelet /etc/kubernetes/manifests # 创建pod yaml的配置文件位置 /etc/sysconfig/kubelet # 启动kubelet额外增加的命令参数 /usr/bin/kubelet /usr/lib/systemd/system/kubelet.service # 开机自启动配置
10.3.2、配置文件的查找
]# systemctl status kubelet
● kubelet.service - kubelet: The Kubernetes Node Agent
Loaded: loaded (/usr/lib/systemd/system/kubelet.service; enabled; vendor preset: disabled)
Drop-In: /usr/lib/systemd/system/kubelet.service.d
└─10-kubeadm.conf
]# cat /usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf
# Note: This dropin only works with kubeadm and kubelet v1.11+
[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf"
Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
# This is a file that "kubeadm init" and "kubeadm join" generates at runtime, populating the KUBELET_KUBEADM_ARGS variable dynamically
EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
# This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably, the user should use
# the .NodeRegistration.KubeletExtraArgs object in the configuration files instead. KUBELET_EXTRA_ARGS should be sourced from this file.
EnvironmentFile=-/etc/sysconfig/kubelet
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS
]# grep static /var/lib/kubelet/config.yaml
staticPodPath: /etc/kubernetes/manifests
10.4、/etc/kubernetes/manifests/文件查看
10.4.1、master
]# ls /etc/kubernetes/manifests/ etcd.yaml kube-apiserver.yaml kube-controller-manager.yaml kube-scheduler.yaml
# 只有master结点上才有默认启动的核心操作。
10.4.2、node
]# ls /etc/kubernetes/manifests/
10.5、静态pod实践
10.5.1、实现效果
接下来我们直接在 /etc/kubernetes/manifests 目录下创建资源对象文件即可
10.5.2、master查看集群当前效果
]# kubectl get pods No resources found in default namespace.
10.5.3、进入到node1结点的静态目录创建资源对象
cd /etc/kubernetes/manifests/
cat >static-pod.yml<<'EOF'
apiVersion: v1
kind: Pod
metadata:
name: static-pod
spec:
containers:
- name: web
image: 192.168.10.33:80/k8s/my_nginx:v1
EOF
10.5.4、到master节点查看是否创建成功pod
]# kubectl get pods NAME READY STATUS RESTARTS AGE static-pod-node1 1/1 Running 0 69s
10.5.4、总结
1、无需应用资源清单，master自动获取创建pods。 2、master无法删除静态pod，删除后也会自动创建，需要删除的话，到node节点上，把资源清单删除掉。 3、master无法编辑静态pod。 4、master删除pod 对应的podIP地址是不会变的，还是原来的IP地址。
11、Pod策略
11.1、简介
11.1.1、隔离级别
Namespace 隔离内容 UTS 主机名与域名 IPC 信号量、消息队列和共享内存 PID 进程编号 Mount 挂载点（文件系统） Network 网络设备、网络栈、端口等等 User 用户和用户组
11.1.2、约束的作用
根据约束的作用范围主要包括三个级别： Pod级别：针对pod范围内的所有容器 容器级别：仅针对pod范围内的指定容器 PSP级别：PodSecurityPolicy，全局级别的Pod安全策略，涉及到准入控制相关知识
11.1.3、安全上下文属性
apiVersion: v1
kind: Pod
metadata: {…}
spec:
securityContext: # Pod级别的安全上下文，对内部所有容器均有效
runAsUser <integer> # 以指定的用户身份运行容器进程，默认由镜像中的USER指定
runAsGroup <integer> # 以指定的用户组运行容器进程，默认使用的组随容器运行时
supplementalGroups <[]integer> # 为容器中1号进程的用户添加的附加组；
fsGroup <integer> # 为容器中的1号进程附加的一个专用组，其功能类似于sgid
runAsNonRoot <boolean> # 是否以非root身份运行
seLinuxOptions <Object> # SELinux的相关配置
sysctls <[]Object> # 应用到当前Pod上的名称或网络空间级别的sysctl参数设置列表
windowsOptions <Object> # Windows容器专用的设置
containers:
- name: …
image: …
securityContext: # 容器级别的安全上下文，仅生效于当前容器
runAsUser <integer> # 以指定的用户身份运行容器进程
runAsGroup <integer> # 以指定的用户组运行容器进程
runAsNonRoot <boolean> # 是否以非root身份运行
allowPrivilegeEscalation <boolean> # 是否允许特权升级
capabilities <Object> # 于当前容器上添加（add）或删除（drop）的操作内核某些资源的能力
add <[]string> # 添加由列表格式定义的各内核能力
drop <[]string> # 移除由列表格式定义的各内核能力
privileged <boolean> # 是否运行为特权容器
procMount <string> # 设置容器的procMount类型，默认为DefaultProcMount；
readOnlyRootFilesystem <boolean> # 是否将根文件系统设置为只读模式
seLinuxOptions <Object> # SELinux的相关配置
windowsOptions <Object> # windows容器专用的设置
注意：
上面的属性，仅仅是最常用的属性，而不是所有的属性
11.2、资源策略-用户级别
11.2.1、简介
相关的属性 runAsUser、runAsGroup
11.2.1、默认用户级别
cat >pod-test.yml<<'EOF'
apiVersion: v1
kind: Pod
metadata:
name: nginx-test
spec:
nodeName: node2
containers:
- name: nginx
image: 192.168.10.33:80/k8s/my_nginx:v1
env:
- name: HELLO
value: "Hello kubernetes nginx"
EOF
]# kubectl apply -f pod-test.yml
]# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-test 1/1 Running 0 10s
# 默认是以root用户运行
]# kubectl exec -it nginx-test -- id
uid=0(root) gid=0(root) groups=0(root)
]# kubectl delete pod nginx-test
pod "nginx-test" deleted
注意：因为默认情况下，一旦pod创建好后，是不允许对用户归属权限进行任意修改的，所以需要修改的话，必须先关闭，再开启
11.2.2、添加安全属性的资源策略
# 所有NODE节点，创建运行的用户
]# useradd k8s_test
]# id k8s_test
uid=1000(k8s_test) gid=1000(k8s_test) groups=1000(k8s_test)
cat >pod-securityContext.yml<<'EOF'
apiVersion: v1
kind: Pod
metadata:
name: security-context-demo
spec:
securityContext:
runAsUser: 1001
runAsGroup: 1001
containers:
- name: sec-ctx-demo
image: busybox
command: [ "sh", "-c", "sleep 1h" ]
securityContext:
allowPrivilegeEscalation: false
EO
]# kubectl apply -f pod-securityContext.yml
]# kubectl get pods
NAME READY STATUS RESTARTS AGE
security-context-demo 1/1 Running 0 5s
]# kubectl exec -it security-context-demo -- id
uid=1001 gid=1001 groups=1001
11.3、资源策略-安全上下文
11.3.1、简介
相关的安全上下文 CAP_CHOWN：改变UID和GID； CAP_MKNOD：mknod()，创建设备文件； CAP_NET_ADMIN：网络管理权限； CAP_SYS_ADMIN：大部分的管理权限； CAP_SYS_TIME：更改系统的时钟 CAP_SYS_MODULE：装载卸载内核模块 CAP_NET_BIND_SERVER：允许普通用户绑定1024以内的特权端口
11.3.2、默认安全上下文
cat > pod-capabilities.yml <<'EOF'
apiVersion: v1
kind: Pod
metadata:
name: pod-capabilities
spec:
containers:
- name: pod-capabilities
image: 192.168.10.33:80/k8s/pod_test:v0.1
command: ['/bin/sh', '-c']
args: ["/sbin/iptables -t nat -A PREROUTING -p tcp --dport 8080 -j REDIRECT --to-port 80 && /usr/bin/python3 /usr/local/bin/demo.py"]
EOF
]# kubectl apply -f pod-capabilities.yml
]# kubectl get pods
NAME READY STATUS RESTARTS AGE
pod-capabilities 0/1 Error 0 3s
# 报没有权限错误
]# kubectl logs pod-capabilities
getsockopt failed strangely: Operation not permitted
结果提示：
我们知道容器在启动的时候，默认是以linux系统普通用户启动的，所以普通用户是没有权限更改系统级
别的内容的，所以导致我们更改命令权限失败
11.3.3、安全上下文add
cat > pod-capabilities-add.yml <<'EOF'
apiVersion: v1
kind: Pod
metadata:
name: pod-capabilities
spec:
containers:
- name: pod-capabilities
image: 192.168.10.33:80/k8s/pod_test:v0.1
command: ['/bin/sh', '-c']
args: ["/sbin/iptables -t nat -A PREROUTING -p tcp --dport 8080 -j REDIRECT --to-port 80 && /usr/bin/python3 /usr/local/bin/demo.py"]
securityContext:
capabilities:
add: ["NET_ADMIN"]
EOF
]# kubectl apply -f pod-capabilities-add.yml
pod/pod-capabilities created
# 运行成功
]# kubectl get pods
NAME READY STATUS RESTARTS AGE
pod-capabilities 1/1 Running 0 4s
11.3.4、安全上下文drop
# 默认是可以支持授权限
]# kubectl exec -it pod-capabilities -- chown 1001.1001 /etc/hosts
# 禁用授权限的功能
cat > pod-capabilities-drop.yml <<'EOF'
apiVersion: v1
kind: Pod
metadata:
name: pod-capabilities
spec:
containers:
- name: pod-capabilities
image: 192.168.10.33:80/k8s/pod_test:v0.1
command: ['/bin/sh', '-c']
args: ["/sbin/iptables -t nat -A PREROUTING -p tcp --dport 8080 -j REDIRECT --to-port 80 && /usr/bin/python3 /usr/local/bin/demo.py"]
securityContext:
capabilities:
add: ["NET_ADMIN"]
drop: ["CHOWN"]
EOF
注意：
add后面的权限能力必须使用双引号(""),不要使用单引号('')
]# kubectl apply -f pod-capabilities-drop.yml
pod/pod-capabilities created
]# kubectl get pods
NAME READY STATUS RESTARTS AGE
pod-capabilities 1/1 Running 0 4s
# 文件权限不能随意的更改了
]# kubectl exec -it pod-capabilities -- chown 1001.1001 /etc/hosts
chown: /etc/hosts: Operation not permitted
command terminated with exit code 1
11.4、特权模式-sysctls
11.4.1、简介
默认情况下，pod的容器在启动的时候是具备了特权用户权限的。比如我们知道 kubeproxy 会将pod 启动时候的一些规则转换成对应的iptable或者ipvs规则 -- 这就涉及到宿主机内核级别的操作。 对于pod内部的容器名称空间的内核级别(不是系统级别)的参数调整，pod支持三个： kernel.shm_rmid_forced net.ipv4.ip_local_port_range net.ipv4.tcp_syncookies, 而对于这些内核参数的修改，必须要所有的node节点上让 kubelet服务支持 --allowed-unsafesysctls=net.core.somaxconn,net.ipv4.ip_unprivileged_port_start等相关内核参数才行，否则无法更改容器的内核参数。
11.4.2、默认报错
cat >pod-sysctl.yml<<'EOF'
apiVersion: v1
kind: Pod
metadata:
name: pod-sysctl
spec:
securityContext:
sysctls:
- name: net.core.somaxconn
value: "6666"
- name: net.ipv4.ip_local_port_range
value: "1024 65535"
- name: kernel.shm_rmid_forced
value: "0"
containers:
- name: pod-sysctl
image: 192.168.10.33:80/k8s/pod_test:v0.1
EOF
]# kubectl apply -f pod-sysctl.yml
pod/pod-sysctl created
]# kubectl get pods
NAME READY STATUS RESTARTS AGE
pod-sysctl 0/1 SysctlForbidden 0 4s
# 默认情况下，普通用户是不允许修改命名空间里相关内核参数的
]# kubectl logs pod-sysctl
Error from server (BadRequest): container "pod-sysctl" in pod "pod-sysctl" is not available
11.4.3、针对普通用户是不允许修改命名空间里相关内核参数解决方法
# 所有Node都需要修改为如下 ]# cat /etc/sysconfig/kubelet KUBELET_EXTRA_ARGS="--allowed-unsafe-sysctls net.core.somaxconn,net.ipv4.ip_local_port_range" # 参数解析： net.core.somaxconn 网卡入栈的最大连接数 net.ipv4.ip_local_port_range 非特权用户可以使用的端口起始值，默认是1024 # 在所有的node角色节点上配置该文件，然后重启该服务 systemctl restart kubelet
标签：容器,16,kubelet,深入,nginx,kubectl,pod,Pods,Pod From： https://www.cnblogs.com/ygbh/p/17228516.html