Kubernetes--管理Pod对象的容器(3)

共享节点的网络名称空间

同一个Pod对象的各容器均运行于一个独立的、隔离的Network名称空间中，共享同一个网络协议栈及相关的网络设备。也有一些特殊的Pod对象需要运行于所在节点的名称空间中，执行系统级的管理任务，例如查看和操作节点的网络资源甚至是网络设备等。

通常，以kubeadm部署的Kubernetes集群中的 kube-apiserver、kube-controller-manager、kube-scheduler，以及kube-proxy和kube-flannel等通常都是第二种类型的Pod对象。事实上，仅需要设置spec.hostNetwork的属性为true即可创建共享节点网络名称空间的Pod对象，如下面的配置清单所示：

apiVersion: v1
kind: Pod
metadata:
  name: pod-use-hostnetwork
spec:
  containers:
  - name: myapp
    image: ikubernetes/myapp：v1
  hostNetwork: true

　　将上面的配置清单保存于配置文件中，如pod-use-hostnetwork.yaml，将其创建于集群上，并查看其网络接口的相关属性信息以验证它是否能否共享使用工作节点的网络名称空间：

kubectl apply -f pod-use-hostnetwork.yaml
kubectl exec -it pod-use-hostnetwork -- sh
/ # ifconfig
eth0    Link······
······

　　如上述命令的结果显示所示，它打印出的是工作节点的网络设备及其相关的接口信息。这就意味着，Pod对象中运行的容器化应用也将监听于其所在的工作节点的IP地址之上，这可以通过直接向node03.ilinux.io节点发起请求来验证：

1 2	`curl node03.ilinux.io` `Hello MyApp \| Version：v1 \| <a href="hostname.html">Pod Name</a>`

另外，在Pod对象中时还可以分别使用spec.hostPID和spec.hostPC来共享工作节点的PID和IPC名称空间。

设置Pod对象的安全上下文

Pod对象的安全上下文用于设定Pod或容器的权限和访问控制功能，其支持设置的常用属性包括以下几个方面。

基于用户ID（UID）和组ID（GID）控制访问对象（如文件）时的权限。
以特权或非特权的方式运行。
通过Linux Capabilities为其提供部分特权。
基于Seccomp过滤进程的系统调用。
基于SELinux的安全标签。
是否能够进行权限升级。

Pod对象的安全上下文定义在spec.securityContext字段中，而容器的安全上下文则定义在spec.containers[].securityContext字段中，且二者可嵌套使用的字段还有所不同。下面的配置清单示例为 busybox容器定义了安全上下文，它以uid为1000的非授权用户运行容器，并禁止权限升级：

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-securitycontext
spec:
  containers:
  - name: busybox
    image: busybox
    command: ["/bin/sh","-c","sleep 86400"]
    securityContext:
      runAsNonRoot: true
      runAsUser: 1000
      allowPrivilegeEscalation: false

将上面的配置清单保存于配置文件（如pod-with-securitycontext.yaml文件）中，而后创建于集群中即可验证容器进程的运行者身份：

  kubectl apply -f pod-with-securitycontext.yaml
  kubectl exec pod-with-securitycontext -- ps aux
PID   USER     TIME   COMMAND
    1 1000      0:00  sleep 86400
   14 1000      0:00  pa aux

　　另外，可设置的安全上下文属性还有fsGroup、seLinuxOptions、supplementalGroups、sysctls、capabilities和privileged等，且Pod和容器各自支持的字段也有所不同，感兴趣的可按需对各属性进行测试。