深入剖析Kubernetes学习笔记:Pod基本概念(14)

一、凡是调度、网络、存储,以及安全相关的属性,基本上是 Pod 级别的。

1、这些属性的共同特征是,它们描述的是“机器”这个整体,而不是里面运行的“程序”。

1、比如,配置这个“机器”的网卡(即:Pod 的网络定义),
2、配置这个“机器”的磁盘(即:Pod 的存储定义),
3、配置这个“机器”的防火墙(即:Pod 的安全定义)。
4、更不用说,这台“机器”运行在哪个服务器之上(即:Pod 的调度)。

2、NodeSelector:是一个供用户将 Pod 与 Node 进行绑定的字段

apiVersion: v1
kind: Pod
...
spec:
 nodeSelector:
   disktype: ssd

这样的一个配置,意味着这个 Pod 永远只能运行在携带了“disktype: ssd”标签(Label)的节点上;否则,它将调度失败。

3、NodeName:一旦Pod的这个字段被赋值,Kubernetes 项目就会被认为这个 Pod 已经经过了调度

调度的结果就是赋值的节点名字。所以,这个字段一般由调度器负责设置,但用户也可以设置它来“骗过”调度器,
当然这个做法一般是在测试或者调试的时候才会用到。

4、HostAliases:定义了Pod的hosts文件(比如 /etc/hosts)里的内容

apiVersion: v1
kind: Pod
...
spec:
  hostAliases:
  - ip: "10.1.2.3"
    hostnames:
    - "foo.remote"
    - "bar.remote"
...

在这个 Pod 的 YAML 文件中,我设置了一组 IP 和 hostname 的数据。这样,这个 Pod 启动后,/etc/hosts 文件的内容将如下所示:

cat /etc/hosts
# Kubernetes-managed hosts file.
127.0.0.1 localhost
...
10.244.135.10 hostaliases-pod
10.1.2.3 foo.remote
10.1.2.3 bar.remote

二、凡是跟容器的 Linux Namespace 相关的属性,也一定是 Pod 级别的

这个原因也很容易理解:Pod 的设计,就是要让它里面的容器尽可能多地共享 Linux Namespace,仅保留必要的隔离和限制能力。

这样,Pod 模拟出的效果,就跟虚拟机里程序间的关系非常类似了。

1、shareProcessNamespace=true这个 Pod 里的容器要共享 PID Namespace。

举个例子,在下面这个 Pod 的 YAML 文件中,我定义了 shareProcessNamespace=true:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  shareProcessNamespace: true
  containers:
  - name: nginx
    image: nginx
  - name: shell
    image: busybox
    stdin: true
    tty: true

这就意味着这个 Pod 里的容器要共享 PID Namespace。

2、tty和stdin等同于设置了 docker run 里的 -it(-i 即 stdin,-t 即 tty)参数。

如果你还是不太理解它们俩的作用的话,可以直接认为 tty 就是 Linux 给用户提供的一个常驻小程序,用于接收用户的标准输入,返回操作系统的标准输出。

当然,为了能够在 tty 中输入信息,你还需要同时开启 stdin(标准输入流)。

于是,这个 Pod 被创建后,你就可以使用 shell 容器的 tty 跟这个容器进行交互了。我们一起实践一下

$ kubectl create -f nginx.yaml

接下来,我们使用 kubectl attach 命令,连接到 shell 容器的 tty 上:

$ kubectl attach -it nginx -c shell

这样,我们就可以在 shell 容器里执行 ps 指令,查看所有正在运行的进程:

$ kubectl attach -it nginx -c shell
/ # ps ax
PID   USER     TIME  COMMAND
    1 root      0:00 /pause
    8 root      0:00 nginx: master process nginx -g daemon off;
   14 101       0:00 nginx: worker process
   15 root      0:00 sh
   21 root      0:00 ps ax

三、凡是 Pod 中的容器要共享宿主机的 Namespace,也一定是 Pod 级别的定义

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  hostNetwork: true
  hostIPC: true
  hostPID: true
  containers:
  - name: nginx
    image: nginx
  - name: shell
    image: busybox
    stdin: true
    tty: true

1、hostNetwork: true这个 Pod 里的所有容器,会直接使用宿主机的网络、直接与宿主机进行 IPC 通信

在这个 Pod 中,我定义了共享宿主机的 Network、IPC 和 PID Namespace。这就意味着,这个 Pod 里的所有容器,

会直接使用宿主机的网络、直接与宿主机进行 IPC 通信、看到宿主机里正在运行的所有进程。

2、Containers

1、Containers的分类

2、Container 的主要字段

3、ImagePullPolicy镜像拉取的策略

它定义了镜像拉取的策略。而它之所以是一个 Container 级别的属性,是因为容器镜像本来就是 Container 定义中的一部分。

1、Always

2、Never 或者 IfNotPresent

4、Lifecycle在容器状态发生变化时触发一系列“钩子

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: lifecycle-demo-container
    image: nginx
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]
      preStop:
        exec:
          command: ["/usr/sbin/nginx","-s","quit"]

1、postStart

2、preStop

3、优雅退出

四、Pod 对象在 Kubernetes 中的生命周期。

Pod 生命周期的变化,主要体现在 Pod API 对象的Status 部分,这是它除了 Metadata 和 Spec 之外的第三个重要字段。其中,pod.status.phase,

就是 Pod 的当前状态,它有如下几种可能的情况:

1、Status 部分

1、Pending

2、Running

3、Succeeded

4、Failed

5、Unknown

2、造成当前 Status 的具体原因是什么。

更进一步地,Pod 对象的 Status 字段,还可以再细分出一组 Conditions。这些细分状态的值包括:PodScheduled、Ready、Initialized,以及 Unschedulable。它们主要用于描述造成当前 Status 的具体原因是什么。

1、Unschedulable

2、Ready

Pod 的这些状态信息,是我们判断应用运行情况的重要标准,尤其是 Pod 进入了非“Running”状态后,你一定要能迅速做出反应,根据它所代表的异常情况开始跟踪和定位,而不是去手忙脚乱地查阅文档。

3、在学习完这篇文章后,我希望你能仔细阅读

$GOPATH/src/k8s.io/kubernetes/vendor/k8s.io/api/core/v1/types.go 里,type Pod struct ,尤其是 PodSpec 部分的内容。

争取做到下次看到一个 Pod 的 YAML 文件时,不再需要查阅文档,就能做到把常用字段及其作用信手拈来。

 

posted @ 2020-02-21 19:08  活的潇洒80  阅读(734)  评论(0编辑  收藏  举报