在極客時間的“深入剖析 Kubernetes”專欄中，作者用的系統是 Ubuntu 16.04 LTS，安裝 Kubernetes 1.11. 我讀這個專欄的時候，已經有了 Ubuntu 18.04，而 Kubernetes 已經發布1.14版本了。碼農在學習的過程中頻繁遇到這樣的問題，一般一本書出版的時候，軟件已經發布了好幾個新版本，書里的內容就略微過時了。但是雖然版本有更新，根基不會變得這么快，我們學習應該把重點放在靠下的原理層面，而不是新的語法、功能這些，所以好的教程、書籍仍有非常大的價值。為了跟隨作者的腳步好好體驗一番，我決定按文中的思路，安裝1.11版本的 Kubernetes. 這里就記錄一下專欄文章里沒有寫到的東西，以及因為軟件版本引發的一些問題的解決辦法。
先說明一下，我的網絡稍微特殊，可以訪問 k8s.gcr.io，quay.io。
准備虛擬機
先用 VirtualBox 准備兩台虛擬機。實際上我是安裝了一台，稍微配置一下以后 Clone 出另一台的。
我給它們各4GB內存，網卡用 bridged network 配置，這樣里面的系統就可以訪問公網，而且虛擬機之間、宿主機之間都可以互相訪問。
安裝 Ubuntu 用的是 minimal installation. 安裝完成后做了下面操作，默認不啟動圖形界面，安裝 ssh，vim 等工具：
sudo apt update
sudo apt upgrade
sudo apt install ssh vim
sudo systemctl set-default multi-user.target
兩台需要分別配置 hostname：
hostnamectl set-hostname k8s[master|node].mydomain.com
安裝 Kubernetes
按照文中命令下載 apt key 的時候，遇到了 SSL 相關的錯誤，我稍微查了一下沒找到解決辦法，於是在 Mac 上下載后傳入了虛擬機，用 apt-key add 導入。
apt.kubernetes.io 無法訪問，改成 USTC 的鏡像：
deb http://mirrors.ustc.edu.cn/kubernetes/apt/ kubernetes-xenial main
安裝 docker.io 和 kubeadm 的時候要注意了，因為二者都有新的版本，所以需要指定版本安裝。雖然是依賴，kubelet 也需要指定這個低版本，不然會安裝最新的1.14。使用命令 apt policy PACKAGE 可以查看一個軟件在源中提供的所有版本號。
sudo apt install kubeadm=1.11.9-00 docker.io=18.06.1-0ubuntu1.2~18.04.1 kubelet=1.11.9-00 kubectl=1.11.9-00
kubeadm 我用了 1.11.9 這個 1.11 里最高的版本號。kubeadm preflight check 對 docker 這個版本還是會有警告，但是我決定試一下，因為 apt policy 找到的最低的版本號是 17.12，還是比 kubeadm 說的 Max validated version: 17.03 高。如果是 docker 18.09，kubeadm preflight check 會報錯。
Kubernetes 要求禁用 swap：
sudo swapoff -a
sudo sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab
默認 docker daemon 不讓普通用戶連接，如果覺得不方便，把自己加到 docker 組里：
sudo usermod -a -G docker $USER
我用文章里的 kubeadm.yaml 初始化 master 的時候，發現 kubeadm 會因無法訪問 dl.k8s.io 而退出。查了一下發現因為我們寫的版本是 stable-1.11，它要去 https://dl.k8s.io/release/stable-1.11.txt 這個 URL 去找一個小版本列表。既然這樣，那就指定一個版本：
kubernetesVersion: "v1.11.9"
k8s.gcr.io 無法訪問怎么辦？從鏡像 pull 然后 tag：
docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/kube-controller-manager-amd64:v1.11.9
docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/kube-apiserver-amd64:v1.11.9
docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/kube-scheduler-amd64:v1.11.9
docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/etcd-amd64:3.2.18
docker tag registry.cn-hangzhou.aliyuncs.com/google_containers/kube-controller-manager-amd64:v1.11.9 k8s.gcr.io/kube-controller-manager-amd64:v1.11.9
docker tag registry.cn-hangzhou.aliyuncs.com/google_containers/kube-apiserver-amd64:v1.11.9 k8s.gcr.io/kube-apiserver-amd64:v1.11.9
docker tag registry.cn-hangzhou.aliyuncs.com/google_containers/kube-scheduler-amd64:v1.11.9 k8s.gcr.io/kube-scheduler-amd64:v1.11.9
docker tag registry.cn-hangzhou.aliyuncs.com/google_containers/etcd-amd64:3.2.18 k8s.gcr.io/etcd-amd64:3.2.18
# 不是 master 節點的話只需 pull 這幾個 image 即可：
docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/coredns:1.1.3
docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/kube-proxy-amd64:v1.11.9
docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/pause:3.1
docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/kubernetes-dashboard-amd64:v1.10.1
docker tag registry.cn-hangzhou.aliyuncs.com/google_containers/coredns:1.1.3 k8s.gcr.io/coredns:1.1.3
docker tag registry.cn-hangzhou.aliyuncs.com/google_containers/kube-proxy-amd64:v1.11.9 k8s.gcr.io/kube-proxy-amd64:v1.11.9
docker tag registry.cn-hangzhou.aliyuncs.com/google_containers/pause:3.1 k8s.gcr.io/pause:3.1
docker tag registry.cn-hangzhou.aliyuncs.com/google_containers/kubernetes-dashboard-amd64:v1.10.1 k8s.gcr.io/kubernetes-dashboard-amd64:v1.10.1
最新的 rook 部署稍微有變動，在前面加了一條命令：
kubectl apply -f https://raw.githubusercontent.com/rook/rook/master/cluster/examples/kubernetes/ceph/common.yaml
kubectl apply -f https://raw.githubusercontent.com/rook/rook/master/cluster/examples/kubernetes/ceph/operator.yaml
kubectl apply -f https://raw.githubusercontent.com/rook/rook/master/cluster/examples/kubernetes/ceph/cluster.yaml
部署完成后，發現它現在所有的 pod 都放在同一個 namespace "rook-ceph" 中了
期間踩到的坑大概就這些。