K8S有狀態靜態Pod經典示例

研究K8S有一陣子了，這個東西很好用，但是也有很多坑，個人覺得很多地方還有待改進，K8S的靜態Pod是一個利器，但也必須對它有全面的了解才能運作。
今天給大家示例一個從頭到尾自己研究出來的項目，需要一定的基礎，拋磚引玉，大家學會了可以自己去發揮。
K8S最大作用是面向集群業務型的和面向研發CI/CD，我這個例子偏向CI/CD。
步入正題：
環境：
1，首先，你得至少已經搭建了單節點的K8S平臺；
2，會熟悉的部署Dockerfile;
3,?? 會K8S基本的命令操作；
4，對K8S基本運作有比較清晰的認識，不然排錯是一個很大的障礙；

項目說明：
在上K8S之前各種計劃任務，比如，定時備份，定時重啟，定時檢索日志發送郵件等等都是通過一臺CentOS虛擬機的crontab來執行各種shell，python腳本來完成。

但是虛擬機也有因為停電，硬件故障導致系統崩潰的風險，所以，將這臺虛擬機容器化并遷移至K8S內就健壯多了。
只要鏡像在，并且K8S編排腳本在，那么一切都在，并且健康的運行，非常可靠。

最重要的，我需要將所有的管理腳本外置于外部NAS存儲，并且掛載到K8S容器內，來達到數據持久化和代碼集中化管理，

并且，我不需要登入容器，只需要在外部修改好crontab文件，刪除掉當前pod，K8S會很乖的重新起一個容器，順便加載了最新的crontab配置，巧妙利用K8S的特性來簡化管理。

不廢話，上干貨，首先，需要把一切需要的東西封裝到centos鏡像中：
1，我需要在容器內執行python腳本，而且需要3以上的版本；
2，我需要shell執行遠程ssh，那么需要安裝sshpass；(當然你也可以選擇其他方式)
3，我需要expect工具免交互腳本，那么需要安裝expect；

4， 因為容器默認是沒有安裝crontab的，要做任務計劃怎么能少了這個；

5，最重要的是安裝supervisor進程守護管理工具，以免K8S的容器循環重啟；（原理不作解釋）

可能有一些不必要的插件，自己去優化吧，這里達到實驗目的即可，沒有做鏡像大小優化，
貼上Dockerfile源碼：

FROM??????centos:centos7.6.1810
MAINTAINER?gavin.guo<379783667@qq.com>
ENV?TZ?"Asia/Shanghai"
ENV?TERM?xterm
ENV?LANG?en_US.utf8
ADD?aliyun-mirror.repo?/etc/yum.repos.d/CentOS-Base.repo
ADD?aliyun-epel.repo?/etc/yum.repos.d/epel.repo
RUN?yum?install?-y?zlib-devel?bzip2-devel?openssl-devel?ncurses-devel?sqlite-devel?readline-devel?tk-devel?gdbm-devel?db4-devel?libpcap
-devel?xz-devel?&&?\
????yum?install?-y?curl?wget?tar?bzip2?unzip?vim-enhanced?passwd??yum-utils?hostname?net-tools?rsync?man?&&?\
????yum?install?-y?gcc?gcc-c++?git?make?automake?cmake?patch?logrotate?python-devel?libpng-devel?libjpeg-devel?&&?\
????yum?clean?all
ADD?Python-3.6.2.tgz??/root
RUN?cd?/root/Python-3.6.2/??&&?\
????mkdir?/usr/local/python3?;?./configure?--prefix=/usr/local/python3?&&?\
????make?&&?make?install?&&?\
????ln?-s?/usr/local/python3/bin/python3?/usr/bin/python3?;?ln?-s?/usr/local/python3/bin/pip3?/usr/bin/pip3?&&?\
????cd?/root?;?rm?-rf?Python-3.6.2?&&?\
????yum?-y?install?net-snmp-utils?crontabs?sshpass?expect?;?sed?-i?'s/required???pam_loginuid.so/sufficient???pam_loginuid.so/'?/etc/pam.d/crond?&&?\
????pip3?install?supervisor?&&?\
????mkdir?-p?/etc/supervisor.conf.d?&&?\
????mkdir?-p?/var/log/supervisor
COPY?supervisord.conf?/etc/supervisord.conf
COPY?supervisor_crontab.conf?/etc/supervisor.conf.d/crontab.conf
EXPOSE?22
COPY?start.sh?/root/start.sh
RUN?chmod?+x?/root/start.sh
ENTRYPOINT?["/root/start.sh"]

Dockefile 同目錄下，需要放置python3.6的二進制源碼安裝包，防止版本漂移和加快構建速度，和啟動腳本start.sh

#!?/bin/bash
cp?/root/script/root?-f??/var/spool/cron/
/usr/local/python3/bin/supervisord?-n?-c?/etc/supervisord.conf

這個小小的腳本一行都不能少，少了第一行，那么K8S在啟動Pod的時候會報錯，因為找不到shell的執行路徑；

第二行用來每次啟動新的Pod的時候加載最新的crontab文件，而不需要操作pod容器；

第三行，啟動supervisord，保證pod健康運行而不退出；

crontab的supervisord的啟動配置文件貼一下：

[program:crond]
directory=/
command=/usr/sbin/crond?-n
user=root
autostart=true
autorestart=true
stdout_logfile=/var/log/supervisor/%(program_name)s.log
stderr_logfile=/var/log/supervisor/%(program_name)s.log

使用命令開始封裝鏡像：

docker?build?-t??gavin/mycron:v1?.

封裝完成后，開始編寫K8S編排文件：

創建一個mycron.yaml文件：

apiVersion:?v1
kind:?Pod
metadata:
??name:?mycron
spec:
??containers:
??-?name:?mycron
????image:?gavin/mycron:v1
????ports:
????-?containerPort:?22
????volumeMounts:
????-?name:?script
??????mountPath:?/root/script
??volumes:
??-?name:?script
????hostPath:
??????path:?/root/K8S_PV/script
??????type:?DirectoryOrCreate

代碼很簡單，但我們重點看主機磁盤卷的掛載，這里雖然用的是hostPath，但是/root/K8S_PV/Script并不是普通的本地路徑，而是我掛載到本地的NAS共享文件夾：

注意：

使用命令將配置好的NAS共享文件掛載到K8S宿主機內，并用hostPath的方式將其映射到master節點的Pod內，這個是官方教程和權威指南里面都沒有說過的，不是親身實驗是無從得知的，但理論和實際上都是可行的；

講操作：

掛載NAS共享文件夾：

mount?-o?username=XXX,password=XXX?//NAS服務器的IP/K8S_PV???/root/K8S_PV

K8S允許掛載NFS的PV，但是遇上NAS是有權限驗證的，有權限驗證的NFS如何引入PV,? 官方和網上都沒有資料，這也是我說它為什么需要改進的，不能都要求用戶去單獨搭一個NFS服務器吧！

而且對于小型存儲需求來講，PV和PVI這一套顯得繁瑣，沒有本地直接掛載然后hostPath簡單粗暴好用。

掛載完畢后，然后在K8S_PV里面新建一個目錄script，將所有腳本丟進去即可；

將mycron.yaml文件復制到目錄/etc/kubernetes/manifests/, K8S會自動啟動靜態Pod；

那么我們進入容器內看看是否一切正常：

kubectl?exec?-it?mycron-master??/bin/bash
運行crontab?-e

發現定時任務配置已經順利同步：

并且腳本路徑順利加載至pod:

以后我們需要修改定時任務或者腳本，只需要在NAS服務器上修改下文件，刪除一下Pod即可，非常快捷方便，并且做到高可用，高可靠，集中化管理。

◆★◆★◆排錯◆★◆★◆

在我后面修改了root賬戶下的crontab的配置文件，在K8S里面刪除這個pod，異想天開以為美好的事情會按照預期的發生，卻發現問題來了，crontab并沒有更新到容器內，反復試了多次依然如故。

分析：

我們知道靜態Pod是不受kubelet直接干預的特殊pod，K8S內置一套檢查和恢復機制去完成它，刪除k8s內創建的靜態Pod實例（我們目的是為了得到新的更新實例）有三種途徑，：

1，釜底抽薪，直接干掉或者移除/etc/kubernetes/manifests/內的yaml編排文件，K8S會自我銷毀創建的靜態Pod，完畢再復制yaml文件回去，它又將自我重建；

2，在K8S-dashboard的web頁面操作刪除：

3，使用命令刪除：

目前第一種過于繁瑣，我采取的是第二種和第三種方式，發現沒有效果，只要當第一種方式容器內才更新成功，何故？

好，我們來使用docker命令來查看每種刪除方式后的容器發生了什么變化，來找出問題在哪里：

我們發現第二種和第三種方法對容器沒有變化，因為它的容器創建時間和容器名稱沒有發生改變，你大爺還是你大爺。

當使用第一種方式刪除的時候，奇跡出現了，該發生的都發生了，我們可以看到雖然容器注冊名沒有發生改變，但是創建時間改變了，它已經不是從前的它了：

◆★◆★◆思考◆★◆★◆

為什么一定要去撤銷yaml編排文件，容器才能得到徹底銷毀呢？個人覺得，這要從K8S的機制說起，我們知道，K8S系統在容器的基礎上又抽象出一個沙箱概念：Pod，這個豆莢是我們在k8S系統內所能操作的最小單位，但實際上容器實例才是最小顆粒單位。我們刪除pod，并不代表刪除了容器，恰恰相反，由于K8S的各種檢查和恢復，銷毀機制，如果不銷毀yaml文件，那么K8S檢測到容器依然是活躍并健康的，根本不會銷毀和置換一個新的容器給你，而是重新套上一個pod包裝箱，事實上容器連停止和重啟的動作都不會進行。這也是為什么刪除pod和啟動新的pod為什么速度那么快，因為K8S只是換了個Pod而沒有換容器。不要感覺被騙了，因為K8S覺得沒有那個必要，這就是它自作聰明之處。

知道這個道理后，那么我們知道如何去應對，有幾種方式去重建容器：

1，K8S只有當容器出現崩潰或者說不健康了，才會銷毀和重建容器（這種是自然發生，不可控）

2，銷毀或者說改動yaml編排文件，那么意味著新的部署，容器才能得以徹底銷毀重建；

3，使用docker rm -f 容器名，強制刪除容器，那么也會得到新的容器；

4，如果你能分析K8S源碼，能欺騙健康檢查機制去銷毀和重建容器也是可以的，但是一般人做不到；

個人認為非常經典的一個實驗，實踐了以下內容：

1，靜態Pod的創建；

2，hostPath存儲的掛載，外部NAS存儲的巧妙引用；

3，測試了靜態Pod的特性；

4，Docker鏡像的封裝, 關鍵點還在于入口腳本的設置；

5，了解了pod和容器之間的關系和行為；

???? 一般來說，通常Dockerfile的最后一行為：

?ENTRYPOINT?["/usr/local/python3/bin/supervisord"?,"-n","-c"?"/etc/supervisord.conf"]

?這個是supervisord的啟動進程命令，但是很多時候并不是這么簡單，可能在容器啟動的時候有很多初始化的復雜操作，那么全部放入一個start腳本里面去執行，并且保證supervisord在最后執行即可；

就像本例，我需要在啟動進程前將掛載存儲路徑里面的配置文件更新到相應的目錄，來達到重起容器即更新配置的目的，那么非腳本不可。

學會了嗎？試試看，打造你的私有鏡像并且使用啟動腳本來更新容器，可能更有妙用。