- 說明
- kubefromscratch-ansible和kubefromscratch介紹
- 使用前准備
- 代碼編譯
- 部署規划
- 機器初始化
- 組件證書生成
- 部署系統
- 在其它機器上安裝管理員文件
- 集群的關停、啟動、銷毀
- 在集群中安裝插件
- 部署應用
- 總結
- 參考
說明
本系列所有文章可以在系列教程匯總中找到，演示和講解視頻位於網易雲課堂·IT技術快速入門學院 ，課程說明、資料和QQ交流群見 Kubernetes1.12從零開始（初）：課程介紹與官方文檔匯總，探索過程遇到的問題記錄在：Kubernetes1.12從零開始（一）：遇到的問題與解決方法。
下面的操作中會從github上直接拉取kubernets以及依賴的組件的代碼，在本地完成編譯后，在Kubernetes1.12從零開始（一）：部署環境准備中准備的三台虛擬機上部署kubernetes集群，三台機器都同時是master和node。
kubefromscratch-ansible和kubefromscratch介紹
Github: kubefromscratch-ansible是一套標准的ansible腳本，inventories目錄中是不同部署環境，roles中是幾組不同的操作，根目錄下幾個yml文件分別是幾組操作的集合。
Github: kubefromscratch是最開始寫的的一套編譯部署腳本，但是用它來部署還是比較麻煩，后來專門寫了kubefromscratch-ansible，將部署過程獨立了出來。kubefromscratch中依然保留了部署部分的腳本，但是不建議使用，也不再維護這部分腳本，以后只維護編譯部分的腳本。
kubefromscratch-ansible在執行編譯操作的以后，會自動下載kubefromscratch，kubefromscratch在編譯各個組件的時候，會自動下載各個組件的代碼。
因此后續操作只需要在kubefromscratch-ansible中執行。
git clone https://github.com/introclass/kubefromscratch-ansible.git
cd kubefromscratch-ansible
使用前准備
使用yum安裝Docker，可能會因為qiang的原因安裝失敗，因此這套腳本采用提前下載docker的rpm，將docker的rpm上傳的方式安裝，需要事先將docker的rpm下載到下面的目錄中：
mkdir -p roles/docker/files/
pushd roles/docker/files/
wget https://download.docker.com/linux/centos/7/x86_64/stable/Packages/docker-ce-18.03.1.ce-1.el7.centos.x86_64.rpm
popd
Docker的版本發布計划可以到moby、docker-ce與docker-ee中了解。這里沒有嚴格論證哪個版本的Docker是更可靠的，請根據自己的需要選擇版本。
創建獨立的python運行環境，在virtualenv創建的python運行環境中，執行后續的操作，可以避免系統上的python包的影響：
virtualenv env
source env/bin/activate
pip install -r requirements.txt
本地機器上需要安裝有ansible、docker、git，並能聯網拉取docker鏡像和github代碼，mac上可以用brew安裝：
brew install ansible
brew install git
brew cask install docker
代碼編譯
使用下面的命令直接編譯所有代碼：
ansible-playbook -i inventories/staging/hosts build.yml
執行結果應當如下所示，這一步耗時會非常長，可能有10~20分鍾：
$ ansible-playbook -i inventories/staging/hosts build.yml
PLAY [localhost] **********************************************************
TASK [Gathering Facts] ****************************************************
ok: [localhost]
TASK [build : checkout] ***************************************************
changed: [localhost]
TASK [build : build component] ********************************************
changed: [localhost] => (item=build-cni-plugins)
changed: [localhost] => (item=build-cni)
changed: [localhost] => (item=build-etcd)
changed: [localhost] => (item=build-kube-router)
[changed: [localhost] => (item=build-kubernetes)
PLAY RECAP ****************************************************************
localhost : ok=3 changed=2 unreachable=0 failed=0
編譯過程中kubefromscratch代碼，在roles/build/tasks/main.yml中指定，可以根據需要修改這個文件中內容：
- name: checkout
tags: build
git:
repo: https://github.com/lijiaocn/kubefromscratch.git
dest: ""
version: master
force: yes
- name: build component
tags: build
command: "//build.sh"
args:
chdir: "/"
with_items:
- build-cni-plugins
- build-cni
- build-etcd
- build-kube-router
- build-kubernetes
# - build-coredns //something is wrong
build-coredns組件被注釋了，一是因為coredns的代碼依賴管理做的不好，部分代碼沒有被納入vendor管理，二是dns服務可以在kubernetes集群部署完成之后，用插件的方式安裝，管理起來更方便。
kubefromscratch被下載到output/build目錄中，編譯過程就是到它到每個子目錄中執行build.sh腳本。
編譯時需要拉取指定版本的代碼、生成編譯鏡像，時間會比較長，特別是編譯kubernetes的時候。
如果執行出錯，可以不使用anbile，直接到./out/build/build-XXX中對每個組件進行單獨編譯，確保編譯成功，例如：
pushd output/build/;
for i in build-cni-plugins build-cni build-etcd build-kube-router build-kubernetes
do
pushd $i
./build.sh
popd
done
popd
一定要確保所有組件都成功編譯。
編譯使用的目錄./out/build中存放的是kubefromscratch項目中的文件。
在編譯kubeneters的時候特別注意，如果是在Mac上編譯，因為Mac上的Docker實際上是在一個虛擬機中運行的，虛擬機默認內存是2G，在編譯kubernetes中的部署組件，例如kubelet的時候，可以會因為內存不足，用來編譯的容器被殺死：
+++ [1110 18:33:03] Building go targets for linux/amd64:
cmd/kubelet
/usr/local/go/pkg/tool/linux_amd64/link: signal: killed
!!! [1110 18:34:41] Call tree:
!!! [1110 18:34:41] 1: /go/src/github.com/kubernetes/kubernetes/hack/lib/golang.sh:600 kube::golang::build_some_binaries(...)
!!! [1110 18:34:41] 2: /go/src/github.com/kubernetes/kubernetes/hack/lib/golang.sh:735 kube::golang::build_binaries_for_platform(...)
!!! [1110 18:34:42] 3: hack/make-rules/build.sh:27 kube::golang::build_binaries(...)
!!! [1110 18:34:42] Call tree:
!!! [1110 18:34:42] 1: hack/make-rules/build.sh:27 kube::golang::build_binaries(...)
!!! [1110 18:34:42] Call tree:
!!! [1110 18:34:42] 1: hack/make-rules/build.sh:27 kube::golang::build_binaries(...)
make: *** [all] Error 1
修改Mac上的Docker使用的虛擬機的配置的方法： 點擊Docker圖標，選擇“preference”->“advanced”。
每個build.sh腳本有多個自命令：
./build.sh 編譯，如果沒有編譯環境則創建
./build.sh bash 進入到編譯容器中
./build.sh reset 銷毀編譯環境
如果執行./build.sh提示已經存在同名的代碼目錄，且版本不匹配， 將同名的目錄刪除，重新執行build.sh。
部署規划
部署規划主要是修改inventories/staging/group_vars/all中的變量，和inventories/staging/hosts中的機器IP。
inventories/staging/group_vars/all中主要定義了安裝路徑，Servic IP地址段、Cluster IP地址段等：
topdir: "/output/staging"
build_path: "/output/build"
log_path: "/log"
certs_path: "/certs"
ca_path: "/ca"
APISERVER: "https://"
APISERVER_INCLUSTER_IP: "172.16.0.1"
CLUSTER_DOMAIN: "cluster.local"
CLUSTER_DNS: "172.16.0.2"
SERVICE_CLUSTER_IP_RANGE: "172.16.0.0/17"
CLUSTER_CIDR: "172.16.128.0/17"
...
需要注意的是其中的APISERVER和APISERVER_INCLUSTER_IP：前者應該是指向三個master的負載均衡器的IP，這里用虛擬機准備環境沒有負載均衡器，因此選用了第一個apiserver的IP；后者是kubernetes服務的cluster ip，是apiserver在集群內部的IP，它需要與SERVICE_CLUSTER_IP_RANGE對應。
CLUSTER_DNS是kubernetes中部署的dns服務的ClusterIP，后面在用插件的方式部署kube-dns的時候，會用到這個IP。
另外SERVICE_CLUSTER_IP_RANGE和CLUSTER_CIDR需要是兩個不重疊的網段。
inventories/staging/hosts中，在每個組件下填入要安裝該組件的機器的IP：
[etcd]
192.168.33.11
192.168.33.12
192.168.33.13
[master]
192.168.33.11
192.168.33.12
192.168.33.13
[node]
192.168.33.11
192.168.33.12
192.168.33.13
[coredns]
#192.168.33.11
#192.168.33.12
#192.168.33.13
[kube-router]
192.168.33.11
192.168.33.12
192.168.33.13
機器初始化
先確保本地有ssh證書，如果沒有則生成：
$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/lijiao/.ssh/id_rsa):
...
下面的操作將ssh證書上傳到機器、並安裝依賴軟件、設置時區等：
ansible-playbook -u root -k -i inventories/staging/hosts prepare.yml
vagrant創建的虛擬機root密碼默認是vagrant。
初始化后，執行下面的命令，確定可以直接使用root用戶免密碼登錄所有機器：
(env) lijiaos-mbp:kubefromscratch-ansible lijiao$ ansible all -u root -i inventories/staging/hosts -m command -a "pwd"
192.168.33.13 | SUCCESS | rc=0 >>
/root
192.168.33.11 | SUCCESS | rc=0 >>
/root
192.168.33.12 | SUCCESS | rc=0 >>
/root
組件證書生成
這一步操作會為Kubernetes集群的所有的組件生成需要的證書：
ansible-playbook -i inventories/staging/hosts gencerts.yml
生成的證書都存放在output目錄中，后面部署的時候，將組件和它們各自的證書一起上傳到目標機器上。
(env) lijiaos-mbp:kubefromscratch-ansible lijiao$ tree output/staging/certs/
output/staging/certs/
├── apiserver
│ ├── 192.168.33.11
│ │ ├── cert.csr
│ │ └── key.pem
│ ├── 192.168.33.12
│ │ ├── cert.csr
│ │ └── key.pem
│ ├── 192.168.33.13
│ │ ├── cert.csr
...
部署系統
這一步操作在目標機器上部署kubernetes集群：
ansible-playbook -u root -i inventories/staging/hosts site.yml
執行后耐心等待即可，如果出現“文件找不到”之類錯誤，回顧一下前面的步驟，看一看是否有遺漏，特別是編譯過程，是不是都成功的生成二進制文件了。
每個組件在/opt/app/k8s目錄中占有一個目錄，里面是該組件運行需要的所有文件，二進制文件、配置文件、證書，以及它們運行時生成的日志。
# ls
admin apiserver cni controller etcd kubelet kube-router scheduler
組件使用supervisord：進程管理工具supervisord啟動的，沒有采用systemd，這樣的一個好處是可以將kubernetes組件與系統上的其它服務區分開，supervisord在ubuntu系統上也可以使用，在容器中也可以使用，以后要適配其它部署環境時可以復用。
supervisorctl status命令查看用supervisord啟動的服務：
[root@192.168.33.11 k8s]# supervisorctl status
etcd RUNNING pid 2998, uptime 0:08:33
kube-apiserver RUNNING pid 2989, uptime 0:08:33
kube-controller-manager RUNNING pid 2994, uptime 0:08:33
kube-router RUNNING pid 2988, uptime 0:08:33
kube-scheduler RUNNING pid 2987, uptime 0:08:33
kubelet RUNNING pid 2993, uptime 0:08:33
注意部署過程中，可能會出現下面的錯誤（這個問題已經修復，supervisord正在執行reload，還沒有加載完成，緊接着執行supervisorctl restart XXX導致的，已經將reload過程修改為supervisorctl reread && supervisorctl update all）：
RUNNING HANDLER [kubelet : restart kubelet] ************************************************************************************************************************************************************************************************************************************
fatal: [192.168.33.11]: FAILED! => {"changed": true, "cmd": "supervisorctl restart kubelet", "delta": "0:00:00.182922", "end": "2018-11-10 23:24:05.443215", "msg": "non-zero return code", "rc": 2, "start": "2018-11-10 23:24:05.260293", "stderr": "", "stderr_lines": [], "stdout": "error: <class 'xmlrpclib.Fault'>, <Fault 6: 'SHUTDOWN_STATE'>: file: /usr/lib64/python2.7/xmlrpclib.py line: 794", "stdout_lines": ["error: <class 'xmlrpclib.Fault'>, <Fault 6: 'SHUTDOWN_STATE'>: file: /usr/lib64/python2.7/xmlrpclib.py line: 794"]}
fatal: [192.168.33.12]: FAILED! => {"changed": true, "cmd": "supervisorctl restart kubelet", "delta": "0:00:00.477207", "end": "2018-11-10 23:24:05.693513", "msg": "non-zero return code", "rc": 2, "start": "2018-11-10 23:24:05.216306", "stderr": "", "stderr_lines": [], "stdout": "error: <class 'xmlrpclib.Fault'>, <Fault 6: 'SHUTDOWN_STATE'>: file: /usr/lib64/python2.7/xmlrpclib.py line: 794", "stdout_lines": ["error: <class 'xmlrpclib.Fault'>, <Fault 6: 'SHUTDOWN_STATE'>: file: /usr/lib64/python2.7/xmlrpclib.py line: 794"]}
只是執行handler的時候，而且是隨機出現，暫時還不清楚是怎么回事，實際上機器上的kubelet已經啟動了。找出原因后，我會將修改提交到github。2018-11-10 23:37:02
在每個master中還有一個admin目錄，里面存放的是集群管理員的文件，可以用里面的./kubectl.sh腳本管理集群，擁有最高權限：
[root@192.168.33.11 app]# cd /opt/app/k8s/admin/
[root@192.168.33.11 admin]# ./kubectl.sh get cs
NAME STATUS MESSAGE ERROR
controller-manager Healthy ok
scheduler Healthy ok
etcd-2 Healthy {"health": "true"}
etcd-1 Healthy {"health": "true"}
etcd-0 Healthy {"health": "true"}
只有看到類似上面的信息，所有組件狀態都是Healthy的時候，才能判定部署初步成功。
如果有組件不正常，查看它的文件目錄中的日志，根據日志查找原因。
核實kubernetes服務的ClusterIP，需要與前面配置的APISERVER_INCLUSTER_IP相同：
[root@192.168.33.11 admin]# ./kubectl.sh get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 172.16.0.1 <none> 443/TCP 51m
在其它機器上安裝管理員文件
安裝管理文件的操作在role/admin中，只需要為目標機器設置這個role就可以了，例如項目中cli.yml，是在ansible所在的機器上安裝管理員文件。
(env) lijiaos-mbp:kubefromscratch-ansible lijiao$ cat cli.yml
- hosts: localhost
roles:
- admin
這一步操作在其它機器上部署kubernetes集群的管理員文件：
ansible-playbook -u root -i inventories/staging/hosts cli.yml
執行完成之后，就可以在本地的/opt/app/k8s/目錄中看到admin目錄：
$ ls /opt/app/k8s/admin/
apiserver.curl.sh bin cert kubeconfig-single.sh kubeconfig.yml kubectl.sh kubelet.curl.sh
需要注意的安裝的管理文件中/bin/kubectl命令是ELF格式的，只能在linux上執行。
我這里用的mac的系統，就比較麻煩，需要再編譯或者下載一個mac上可以運行kubectl程序，好在brew更新的比較快，里面有最新版本的kubectl：
$ brew info kubectl
kubernetes-cli: stable 1.12.2 (bottled), HEAD
Kubernetes command-line interface
https://kubernetes.io/
...
因此直接用brew安裝：
$ brew install kubectl
然后替換掉/opt/app/k8s/admin/bin/kubectl：
cp /usr/local/bin/kubectl /opt/app/k8s/admin/bin/kubectl
然后就可以在本地的/opt/app/k8s/admin目錄中使用kubectl.sh管理集群：
lijiaos-MacBook-Pro:admin lijiao$ ./kubectl.sh version
Client Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.2", GitCommit:"17c77c7898218073f14c8d573582e8d2313dc740", GitTreeState:"clean", BuildDate:"2018-10-30T21:40:58Z", GoVersion:"go1.11.1", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.2", GitCommit:"17c77c7898218073f14c8d573582e8d2313dc740", GitTreeState:"clean", BuildDate:"2018-11-10T15:47:58Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"linux/amd64"}
可以用下面的方式將集群管理員的kubeconfig.yml以及證書打包到一個文件中，方便提供給其他用戶使用：
$ ./kubeconfig-single.sh
執行后會得到一個kubeconfig-single.yml文件，這個文件中包含了所有的配置。
如果要在任意地方使用kubectl命令管理集群，可以在/.kube目錄中做一個名為config的連接，連接到kubeconfig-single.yml：
$ ln -s /opt/app/k8s/admin/kubeconfig-single.yml ~/.kube/config
$ kubectl config view
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: REDACTED
server: https://10.39.0.121
name: secure
contexts:
- context:
cluster: secure
namespace: default
user: admin
name: secure.admin.default
current-context: secure.admin.default
kind: Config
preferences:
colors: true
users:
- name: admin
user:
client-certificate-data: REDACTED
client-key-data: REDACTED
kubectl以及kubernetic等工具默認是從~./kube目錄中讀取配置的。
可以用下面的方式將kubeconfig-single.yml轉換為json格式：
$ yum install -y python2-pip
$ pip install yq
$ bash kubeconfig-single.sh
$ cat kubeconfig-single.yml | yq . >kubeconfig-single.json
集群的關停、啟動、銷毀
啟動集群:
ansible-playbook -u root -i inventories/staging/hosts start.yml
關閉集群:
ansible-playbook -u root -i inventories/staging/hosts stop.yml
用這套anbile部署的腳本內置了很多很方便的小工具，可以用來查詢數據。
查看etcd中的數據，登錄到部署了etcd的機器上操作，etcd使用的是etcd v3，在v3中沒有了目錄的概念，用下面的方式獲取指定前綴的key：
$ cd /opt/app/k8s/etcd
$ ./etcdctl3.sh get /kubernetes --prefix --keys-only
/kubernetes/services/endpoints/default/kubernetes
/kubernetes/services/endpoints/kube-system/kube-controller-manager
/kubernetes/services/endpoints/kube-system/kube-scheduler
/kubernetes/services/specs/default/kubernetes
...
用get命令讀取key的值，-w指定輸出格式：
./etcdctl3.sh get /kubernetes/services/endpoints/kube-system/kube-scheduler -w json
./etcdctl3.sh get /kubernetes/services/endpoints/kube-system/kube-scheduler -w fields
集群管理員文件中，除了用來管理集群的kubectl.sh，還有一個apiserver.curl.sh和kubelet.curl.sh文件，它兩用來直接訪問apiserver和kubelet的http接口，例如：
[root@192.168.33.11 admin]# ./kubelet.curl.sh 192.168.33.11:10255/metrics
# HELP apiserver_audit_event_total Counter of audit events generated and sent to the audit backend.
# TYPE apiserver_audit_event_total counter
apiserver_audit_event_total 0
...
這兩個腳本可以用於調試。
在集群中安裝插件
很多功能都可以插件的方法部署，譬如網絡組件、DNS、日志采集、監控等，最簡單的kubernetes集群需要的只有master的apiserver、scheduler、controller-manager，node上的kubelet和docker，以及一個etcd集群。
前面部署的是一個較為精簡的Kubernetes集群，不是最精簡的，kube-route組件是可以不部署的，它只是kubernete網絡方案中的一種，可以用插件的方法安裝，從而可以隨時更換。
這里沒有將kube-router作為組件部署，只是因為最初的想法是將所有的需要組件都單獨部署，而不是以插件的方式部署。單獨部署的好處是排查問題的時候比較方便，而且與Kubernetes解耦，但是從靈活性和方便程度上來說，用插件的形式部署更好一些，也更符合發展的方向，越來越多組件都是用插件的形式發布的。
如果你要使用其它的插件，部署之前，把前面的hosts文件中kube-router一節注釋掉，然后用后面類似於dns插件安裝的操作，安裝想用的網絡插件即可。
//把這一節刪除或者注釋
[kube-router]
192.168.33.11
192.168.33.12
192.168.33.13
現在用的比較多的網絡插件是flannel和calico，主要是因為它兩出現的比較早，最先被使用，並且用法簡單，很多文檔中都是以它們為例，功能和效果都還可以，一般情況下夠用了。
kube-router出現的比較晚，相對比較小眾，但我覺得它的設計很好，它具備了kube-proxy的功能，可以省去一個組件，所以選擇了它。
需要特別注意是，我目前還沒有在生產環境中使用kube-router的經驗，只是嘗鮮使用，生產環境用的是flannel和calico，也沒有更換的計划和動力。
kubernetes/cluster/addons中是kubernetes的項目中的插件目錄，下面是1.12.2版本代碼中的包含插件：
(env) lijiaos-mbp:kubefromscratch-ansible lijiao$ ls output/build/build-kubernetes/kubernetes/cluster/addons/
BUILD dashboard ip-masq-agent prometheus
README.md device-plugins kube-proxy python-image
addon-manager dns metadata-agent rbac
calico-policy-controller dns-horizontal-autoscaler metadata-proxy runtimeclass
cluster-loadbalancing fluentd-elasticsearch metrics-server storage-class
cluster-monitoring fluentd-gcp node-problem-detector
接下來演示其中一些插件的安裝方法。
安裝kube-dns插件
cluter/addons/dns目錄中有兩個dns插件，一個是kube-dns，一個是coredns。kube-dns使用的是經典的dnsmasq軟件，coredns是一個全新的dns服務器軟件。
$ ls output/build/build-kubernetes/kubernetes/cluster/addons/dns
OWNERS coredns kube-dns
下面演示是1.12.2版本中的kube-dns的安裝，
如果是在mac上操作，需要安裝有gettext：
brew install -y gettext
echo 'export PATH="/usr/local/opt/gettext/bin:$PATH"' >> ~/.zshrc && source ~/.zshrc
#或者
echo 'export PATH="/usr/local/opt/gettext/bin:$PATH"' >> ~/.bash_profile && source ~/.bash_profile
然后設置DNS相關的環境變量，以cluster/addons/dns/kube-dns/kube-dns.yaml.sed為模版，生成kube-dns的部署文件：
export DNS_DOMAIN=cluster.local
export DNS_SERVER_IP=172.16.0.2
cat output/build/build-kubernetes/kubernetes/cluster/addons/dns/kube-dns/kube-dns.yaml.sed | envsubst >./kube-dns.yaml
上面的DNS_DOMAIN、DNS_SERVER_IP分別與kubelet的--cluster-domain、--cluster-dns參數配置相同，一定不要忘了先設置環境變量，否則kube-dns.yam中會缺少相關信息。
kube-dns.yaml中用到下面的幾個鏡像，這些鏡像因為“牆”的原因，在國內無法直接獲取，我這里在電腦上開啟了全局的VPN，虛擬機也能翻出去，所以能下載這些鏡像。如果你不能翻，或者部署在公司內網中，需要將這些鏡像替換為你提前下載好鏡像，或公司內網中的鏡像。
lijiaos-MacBook-Pro:admin lijiao$ cat kube-dns.yaml |grep image
image: k8s.gcr.io/k8s-dns-kube-dns:1.14.13
image: k8s.gcr.io/k8s-dns-dnsmasq-nanny:1.14.13
image: k8s.gcr.io/k8s-dns-sidecar:1.14.13
得到部署文件kube-dns.yaml之后，直接用下面的命令部署：
lijiaos-MacBook-Pro:admin lijiao$ kubectl create -f kube-dns.yaml
service/kube-dns created
serviceaccount/kube-dns created
configmap/kube-dns created
deployment.extensions/kube-dns created
確保pod都是running的狀態：
lijiaos-MacBook-Pro:admin lijiao$ kubectl -n kube-system get pod
NAME READY STATUS RESTARTS AGE
kube-dns-596fbb8fbd-zcfxp 3/3 Running 0 100s
部署了網絡組件和安裝kube-dns插件之后，就可以在kubernetes中部署應用了，只不過缺少了日志、監控等插件時，會顯得比較簡陋。
安裝dashboard插件
dashboard插件位於cluster/addons/dashboard/目錄中，直接部署其中的yaml文件即可：
$ ls *.yaml
dashboard-configmap.yaml dashboard-controller.yaml dashboard-rbac.yaml
dashboard-secret.yaml dashboard-service.yaml
這里推薦一個名為kubernetic的kubernetes客戶端軟件，用來查看集群內部信息很方便。
開源項目的Dashboard的一般都做的很簡單，只能拿來看看數據啥的，企業使用，一般都是自己開發Dashboard，一些圍繞開源項目做產品的公司，其實是在開發dashboard…
部署應用
kubernetes-yamls中是我正在積攢的一些yaml格式的部署文件。
這里演示部署一個名為webshell的應用：
$ kubectl create -f https://raw.githubusercontent.com/introclass/kubernetes-yamls/master/all-in-one/webshell-all-in-one.yaml
namespace/demo-webshell created
ingress.extensions/webshell-ingress created
service/webshell created
service/webshell-nodeport created
deployment.apps/webshell created
應用部署在一個新的名為demo-webshell的namespace中，這個pod中包含了兩個容器：
$ kubectl -n demo-webshell get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE
webshell-594b49d7-wfcw7 2/2 Running 0 2m13s 172.16.129.3 192.168.33.12 <none>
可以在集群內直接通過pod的IP訪問：
[root@192.168.33.11 admin]# curl 172.16.129.3
<html> <head> <meta content="text/html; charset=utf-8"> <title>WebShell</title> </head> ... 創建了兩個Service，一個是CluserIP模式的，只能在集群內訪問，另一個是NodePort模式的，可以在集群為通過32295端口訪問：
$ kubectl -n demo-webshell get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
webshell ClusterIP 172.16.46.6 <none> 80/TCP,22/TCP 3m50s
webshell-nodeport NodePort 172.16.83.52 <none> 80:32295/TCP 3m50s
可以直接在瀏覽器中打開192.168.33.11:32295，可以是任意一個node的IP。
這個應用的名為ssh的容器提供了sshd服務，可以在集群內通過用賬號密碼登陸到容器內部：
[root@192.168.33.11 admin]# ssh root@172.16.129.3
The authenticity of host '172.16.129.3 (172.16.129.3)' can't be established.
ECDSA key fingerprint is SHA256:3T66QjaSacx901O3M8Y0K1UNAOA3u74j15oTC+xGHRU.
ECDSA key fingerprint is MD5:b8:df:61:73:aa:31:46:c9:c0:b0:37:01:2b:fe:36:4e.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '172.16.129.3' (ECDSA) to the list of known hosts.
root@172.16.129.3's password:
[root@webshell-594b49d7-wfcw7 ~]# ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.1 11684 1420 ? Ss 19:25 0:00 bash /root/entrypoint.sh
root 29 0.0 0.1 112812 1512 ? Ss 19:25 0:00 /usr/sbin/sshd -E /root/sshd_log -f /root/sshd_config -p 22
root 78 0.0 0.0 4360 352 ? S 19:31 0:00 sleep 60
root 81 1.0 0.5 149048 5900 ? Ss 19:32 0:00 sshd: root@pts/0
root 83 0.3 0.1 15252 1976 pts/0 Ss 19:32 0:00 -bash
root 97 0.0 0.1 55140 1856 pts/0 R+ 19:32 0:00 ps aux
總結
從編譯到自動部署的講解，暫時就這么多內容了。Kubernetes的使用細節非常多，它在PaaS領域中的位置，如同Linux在操作系統領域中的地位，換個說法就是，Kubernetes就是PaaS的操作系統。它所包含的內容，以后只會越來越多，現在開始學習還不算晚，是最好的上車時間。
后面我會盡力演示一下Kubernetes中各種各樣的玩法，一般都是我在工作中遇到的一些場景，相關的筆記是一定會有的，就發布在這個www.lijiaocn.com這個博客上，一些業余時間寫的腳本類工具也都會在github上公開。
但視頻演示不一定有，制作視頻需要准備環境和素材，並錄制講解，中間往往要折騰好多次，比較占用時間和精力，我會盡力錄制簡單、精煉的視頻，讓視頻成為比較好的輔助內容，幫助有困惑和疑問的朋友，打通關鍵環節。