按教程在 VirtualBox 裏搭建 Kubernetes 集羣

在極客時間的「深刻剖析 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" 中了

期間踩到的坑大概就這些。