本系列的前五篇文章：

本實戰練習系列的前五文章：

*   [適合 Kubernetes 初學者的一些實戰練習 (一)](https://xie.infoq.cn/article/27f5f6250a3033ea09c337989)

*   [適合 Kubernetes 初學者的一些實戰練習 (二)](https://xie.infoq.cn/article/580956ea7a92f6a75c9e8c1d6)

*   [適合 Kubernetes 初學者的一些實戰練習 (三)](https://xie.infoq.cn/article/30adca0a20cf419e8768b6b98)

*   [適合 Kubernetes 初學者的一些實戰練習 (四)](https://xie.infoq.cn/article/4fa89f3d074e734f75d74650d)

*   [適合 Kubernetes 初學者的一些實戰練習 (五)](https://xie.infoq.cn/article/361a86fd7bd0f5c2bbbeeac39)

本文繼續我們的 Kubernetes 實戰練習之旅。

# 練習1：Kubernetes 裡 secret 的使用方法介紹

Kubernetes Secret 解決了密碼、token、金鑰等敏感資料的配置問題，使用 Secret 可以避免把這些敏感資料以明文的形式暴露到映象或者 Pod Spec 中。

Secret可以以 Volume 或者環境變數的方式使用。

使用如下命令列建立一個 secret：

> kubectl create secret generic admin-access --from-file=./username.txt --from-file=./password.txt

輸入檔案 username.txt 和 password.txt 需要手動建立，裡面分別維護用於測試的使用者名稱和密碼。

![](https://img-blog.csdnimg.cn/img_convert/3ae2e57d608581ef22680da7c0003088.png)

建立成功後，發現 secret 的型別為 `Opaque`：

![](https://img-blog.csdnimg.cn/img_convert/57670d7066689830554be547c4bf5c29.png)

實際上，Kubernetes 的 secret 有三種型別：

1. Service Account：用來訪問 Kubernetes API，由 Kubernetes 自動建立，並且會自動掛載到 Pod 的 /run/secrets/kubernetes.io/serviceaccount 目錄中；

2. Opaque：base64 編碼格式的 Secret，用來儲存密碼、金鑰等；

3. kubernetes.io/dockerconfigjson ：用來儲存私有 docker registry 的認證資訊。
而我們剛剛建立的 secret 的型別為 Opaque，因此在 kubectl get secrets 的返回結果裡，能看到 password 和 username 的值均為 base64 編碼：

![](https://img-blog.csdnimg.cn/img_convert/001d9d68b7ae008318c7499102e51d34.png)
![](https://img-blog.csdnimg.cn/img_convert/b3828026acb01981ad4ba508cf8b334c.png)

要在 pod 裡消費這個 secret 也很容易，看一個例子：

![](https://img-blog.csdnimg.cn/img_convert/f7a2ca65583b0e817ada91a023cb332d.png)

```yml
apiVersion: v1

kind: Pod

metadata:

name: secret-pod

spec:

restartPolicy: Never

volumes:

- name: credentials

secret:

secretName: admin-access

defaultMode: 0440

containers:

- name: secret-container

image: alpine:3.8

command: [ "/bin/sh", "-c", "cat /etc/foo/username.txt /etc/foo/password.txt" ]

volumeMounts:

- name: credentials

mountPath: "/etc/foo"

readOnly: true
```

建立 pod，自動執行，透過 log 命令檢視 pod 的日誌：

![](https://img-blog.csdnimg.cn/img_convert/19128b0811e55be0f6758ab415d73b08.png)

發現 /bin/sh 命令被執行了，pod mount 的目錄 /etc/foo 下的 username.txt 和password.txt 透過 cat 命令顯示了輸出：

![](https://img-blog.csdnimg.cn/img_convert/d4ecb2e0f648dd9e300036a735846221.png)

# 練習2：Kubernetes pod 裡一個特殊容器 pause-amd64 的深入剖析

大家在使用 Docker 容器或者 Kubernetes 時, 想必都留意過這個容器：

`gcr.io/google_containers/pause-amd64`

![](https://img-blog.csdnimg.cn/img_convert/11565f9ed20045b1a7689593de3c6944.png)

`docker ps`的命令返回的結果：

```sql
[root@k8s-minion1 kubernetes]# docker ps |grep pause
c3026adee957        gcr.io/google_containers/pause-amd64:3.0           "/pause"                 22 minutes ago      Up 22 minutes                           k8s_POD.d8dbe16c_redis-master-343230949-04glm_default_ce3f60a9-095d-11e7-914b-0a77ecd65f3e_66c108d5
202df18d636e        gcr.io/google_containers/pause-amd64:3.0           "/pause"                 24 hours ago        Up 24 hours                             k8s_POD.d8dbe16c_kube-proxy-js0z0_kube-system_2866cfc2-0891-11e7-914b-0a77ecd65f3e_c8e1a667
072d3414d33a        gcr.io/google_containers/pause-amd64:3.0           "/pause"                 24 hours ago        Up 24 hours                             k8s_POD.d8dbe16c_kube-flannel-ds-tsps5_default_2866e3fb-0891-11e7-914b-0a77ecd65f3e_be4b719e
[root@k8s-minion1 kubernetes]#
```

Kubernetes 的官網解釋：

> it's part of the infrastructure. This container is started first in all Pods to setup the network for the Pod.

大意是：pause-amd64 是 Kubernetes 基礎設施的一部分，Kubernetes 管理的所有 pod 裡，pause-amd64 容器是第一個啟動的，用於實現 Kubernetes 叢集裡 pod 之間的網路通訊。

對這個特殊容器的技術實現感興趣的朋友，可以閱讀其[原始碼](https://github.com/kubernetes/kubernetes/tree/master/build/pause)。

我們檢視這個 pause-amd64 映象的 dockerfile，發現實現很簡單，基於一個空白映象開始：

```dockfile
FROM scratch
ARG ARCH
ADD bin/pause-${ARCH} /pause
ENTRYPOINT ["/pause"]
```

ARG 指令用於指定在執行 `docker build` 命令時傳遞進去的引數。
這個 `pause container` 是用C語言寫的：

![](https://img-blog.csdnimg.cn/img_convert/1dbebe1179f848bb7055c75898f3cc94.png)

在執行的 Kubernetes node 上執行 `docker ps`，能發現這些 pause container：

![](https://img-blog.csdnimg.cn/img_convert/a1a16aeb90cfbce6337361fb296314af.png)

pause container 作為 pod 裡其他所有 container 的 parent container，主要有兩個職責：

1. 是 pod 裡其他容器共享 Linux namespace 的基礎
2. 扮演 PID 1的角色，負責處理殭屍程式

在 Linux 裡，當父程式 fork 一個新程式時，子程式會從父程式繼承 namespace.

目前 Linux 實現了六種型別的 namespace，每一個 namespace 是包裝了一些全域性系統資源的抽象集合，這一抽象集合使得在程式的名稱空間中可以看到全域性系統資源。名稱空間的一個總體目標是支援輕量級虛擬化工具 container 的實現，container 機制本身對外提供一組程式，這組程式自己會認為它們就是系統唯一存在的程式。

在 Linux 裡，父程式 fork 的子程式會繼承父程式的名稱空間。與這種行為相反的一個系統命令就是 unshare：

![](https://img-blog.csdnimg.cn/img_convert/11c48edd5a9104bffb1418caf87a71d4.png)

再來聊聊 pause 容器如何處理殭屍程式的。

Pause 容器內其實就執行了一個非常簡單的程式，其邏輯可以從前面提到的 Pause github 倉庫上找到：

```c
static void sigdown(int signo) {
  psignal(signo, "Shutting down, got signal");
  exit(0);
}

static void sigreap(int signo) {
  while (waitpid(-1, NULL, WNOHANG) > 0);
}

int main() {
  if (getpid() != 1)
    /* Not an error because pause sees use outside of infra containers. */
    fprintf(stderr, "Warning: pause should be the first process\n");

if (sigaction(SIGINT, &(struct sigaction){.sa_handler = sigdown}, NULL) < 0)
    return 1;
  if (sigaction(SIGTERM, &(struct sigaction){.sa_handler = sigdown}, NULL) < 0)
    return 2;
  if (sigaction(SIGCHLD, &(struct sigaction){.sa_handler = sigreap,
                                             .sa_flags = SA_NOCLDSTOP},
                NULL) < 0)
    return 3;

for (;;)
    pause();
  fprintf(stderr, "Error: infinite loop terminated\n");
  return 42;
}
```

這個 c 語言實現的程式，核心程式碼就28行：

![](https://img-blog.csdnimg.cn/img_convert/61adf10f469eb8a60f696f11dba4ec74.png)

其中第 24 行裡一個無限迴圈 `for(;;)`, 至此大家能看出來 pause 容器名稱的由來了吧？
這個無限迴圈裡執行的是一個系統呼叫 `pause`:

![](https://img-blog.csdnimg.cn/img_convert/44abb0aeba2e416ffc878cdbeb2cd69d.png)

因此 pause 容器大部分時間都在沉睡，等待有訊號將其喚醒。
接收什麼訊號呢？

一旦收到 SIGCHLD 訊號，pause 程式就執行註冊的 sigreap 函式。

![](https://img-blog.csdnimg.cn/img_convert/282d87945e726c048cd39458107bc3f1.png)

看下 SIGCHLD 訊號的幫助：

![](https://img-blog.csdnimg.cn/img_convert/c5f85f8a6daf8fe46067e5c17d51bc62.png)

SIGCHLD，在一個程式正常終止或者停止時，將 SIGCHLD 訊號傳送給其父程式，按系統預設將忽略此訊號，如果父程式希望被告知其子系統的這種狀態，則應捕捉此訊號。

pause 程式註冊的訊號處理函式 sigreap 裡，呼叫另一個系統呼叫 waitpid 來獲得子程式終止的原因。

![](https://img-blog.csdnimg.cn/img_convert/2a8f02362cc2c67a60f3377d8172ec35.png)

# 總結

本文作為這一系列的第六部分，首先介紹瞭如何在實際 Kubernetes 專案中使用 Secret 來管理 credentials 和 access token 等敏感資訊，以此來避免將其以明文的形式暴露到映象或者 Pod Spec 中的安全問題。接下來透過原始碼分析的形式，剖析了作為 Kubernetes 基礎設施之一的 pause-amd64 容器的設計和實現原理。

本教程前五個部分的文章連結：

*   [適合 Kubernetes 初學者的一些實戰練習 (一)](https://xie.infoq.cn/article/27f5f6250a3033ea09c337989)

*   [適合 Kubernetes 初學者的一些實戰練習 (二)](https://xie.infoq.cn/article/580956ea7a92f6a75c9e8c1d6)

*   [適合 Kubernetes 初學者的一些實戰練習 (三)](https://xie.infoq.cn/article/30adca0a20cf419e8768b6b98)

*   [適合 Kubernetes 初學者的一些實戰練習 (四)](https://xie.infoq.cn/article/4fa89f3d074e734f75d74650d)

*   [適合 Kubernetes 初學者的一些實戰練習 (五)](https://xie.infoq.cn/article/361a86fd7bd0f5c2bbbeeac39)

適合 Kubernetes 初學者的一些實戰練習 (六)

相關文章