kubernetes 0.18.1 安裝 & 部署 & 初試

時間 2019-12-08

標籤 kubernetes 0.18.1 安裝部署初試简体版

原文原文鏈接

不能否認，如今baidu、google中一搜一大把關於kubernetes方面的資料，在學習的過程當中也大量閱覽了其中很多，可是仍然發現不少問題linux

資料中的kubernetes版本略低，當前版本爲0.18.1，文檔中則多爲0.6.x - 0.9.x，變化可想之大。
kubernetes自己變化太快，文檔略跟不上，即便在其官網，文檔的速度也略跟不上版本發展的速度，kubernetes自己的命令、參數也略有不一樣。

基於這兩點，我也只好依照參考爲輔動手爲主的原則來實驗一把,實驗的kubernetes版本爲0.18.1git

先簡單貼上兩張圖來解釋下kubernetes的組件狀況 & master/slave架構：
github

實驗環境，使用兩臺server做爲實驗，之因此不用盛傳的三臺+來實驗，由於2臺server實驗沒有涉及到複雜的網絡模型。
web

組件	ip
etcd; kube-apiserver; kube-controller-manager; kube-scheduler	172.30.12.255/16
kube-proxy; kubelet	172.30.13.0/16

組件介紹：

kube-apiserver：做爲kubernetes系統的入口，封裝了核心對象的增刪改查操做，以RESTFul接口方式提供給外部客戶和內部組件調用。它維護的REST對象將持久化到etcd（一個分佈式強一致性的key/value存儲）。
kube-scheduler：負責集羣的資源調度，爲新建的pod分配機器。這部分工做分出來變成一個組件，意味着能夠很方便地替換成其餘的調度器。
kube-controller-manager：負責執行各類控制器，目前有兩類：
- endpoint-controller：按期關聯service和pod(關聯信息由endpoint對象維護)，保證service到pod的映射老是最新的。
- replication-controller：按期關聯replicationController和pod，保證replicationController定義的複製數量與實際運行pod的數量老是一致的。
kube-proxy：負責爲pod提供代理。它會按期從etcd獲取全部的service，並根據service信息建立代理。當某個客戶pod要訪問其餘pod時，訪問請求會通過本機proxy作轉發。
kubelet：負責管控docker容器，如啓動/中止、監控運行狀態等。它會按期從etcd獲取分配到本機的pod，並根據pod信息啓動或中止相應的容器。同時，它也會接收apiserver的HTTP請求，彙報pod的運行狀態。

組件下載：

etcd：docker

curl -L https://github.com/coreos/etcd/releases/download/v2.0.11/etcd-v2.0.11-... -o etcd-v2.0.11-linux-amd64.tar.gz
tar zxvf etcd-v2.0.11-linux-amd64.tar.gz -C local/
ln -s etcd /usr/bin; ln -s etcdctl /usr/binapache

kubernetes:json

curl -L https://github.com/GoogleCloudPlatform/kubernetes/releases/download/v0...
解壓後，腳本路徑爲：kubernetes/server/kubernetes/server/bin/
後續中，若是沒有說明，默認執行路徑爲此。api

運行命令：

master：

運行etcd：

etcd > /var/log/etcd.log 2>&1 &

運行kube-apiserver：

./kube-apiserver --address=0.0.0.0 \
                 --insecure-port=8080 \
                 --service-cluster-ip-range='10.254.0.0/16' \
                 --log_dir=/var/log/kube  \
                 --kubelet_port=10250 \
                 --v=0 \
                 --logtostderr=false \ 
                 --etcd_servers=http://127.0.0.1:4001 \
                 --allow_privileged=false

kube-apiserver 的參數說明：https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/man...瀏覽器

運行kube-controller-manager：

./kube-controller-manager  --v=0 \
                           --logtostderr=false \
                           --log_dir=/var/log/kube  \
                           --machines=172.30.13.0  \
                           --master=127.0.0.1:8080

kube-controller-manager的參數說明：https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/man...網絡

運行kube-scheduler：

./kube-scheduler  --master='127.0.0.1:8080'  \
                  --v=0  \
                  --log_dir=/var/log/kube

kube-scheduler的參數說明：https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/man...

slave：

運行kube-proxy：

./kube-proxy  --logtostderr=false  \
              --v=0  \
              --master=http://172.30.12.255:8080

kube-proxy的參數說明：https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/man...

運行kubelet:

./kubelet  --logtostderr=false  \
           --v=0  \
           --allow-privileged=false  \
           --log_dir=/var/log/kube  \
           --address=0.0.0.0  \
           --port=10250  \
           --hostname_override=172.30.13.0  \
           --api_servers=http://172.30.12.255:8080

kubelet的參數說明：https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/man...

建立pod：

pod:在Kubernetes系統中，調度的最小顆粒不是單純的容器，而是抽象成一個Pod，Pod是一個能夠被建立、銷燬、調度、管理的最小的部署單元。好比一個或一組容器。

在master上建立json文件：test-pod.json

{
  "id": "fedoraapache",
  "kind": "Pod",
  "apiVersion": "v1beta1",
  "desiredState": {
    "manifest": {
      "version": "v1beta1",
      "id": "fedoraapache",
      "containers": [{
        "name": "fedoraapache",
        "image": "fedora/apache",
        "ports": [{
          "containerPort": 80,
          "hostPort": 8080
        }]
      }]
    }
  },
  "labels": {
    "name": "fedoraapache"
  }
}

運行命令：

./kubectl create -f test-pod.json

理論上，這樣就ok了。
可是！！！！由於有偉大的GFW！！咱們會在slave上看到一連串錯誤輸出，大致爲：

HTTP Error: statusCode=404 No such image: gcr.io/google_containers/pause:0.8.0

好吧，解決方案也山寨下。。。。。在slave上運行命令：

docker pull docker.io/kubernetes/pause
docker tag docker.io/kubernetes/pause gcr.io/google_containers/pause:0.8.0

這樣，運行命令./kubectl create -f test-pod.json就可ok，至少看上去這樣。
查看已經建立好的pod：

./kubectl get pods

輸出大概爲：

POD            IP           CONTAINER(S)   IMAGE(S)        HOST                      LABELS              STATUS    CREATED   MESSAGE
fedoraapache   172.17.0.3                                  172.30.13.0/172.30.13.0   name=fedoraapache   Running   2 hours   
                            fedoraapache   fedora/apache                                                 Running   2 hours

建立ReplicationController：

Replication Controller是Kubernetes系統中最有用的功能，實現複製多個Pod副本，每每一個應用須要多個Pod來支撐，而且能夠保證其複製的副本數，即便副本所調度分配的主宿機出現異常，經過Replication Controller能夠保證在其它主宿機啓用同等數量的Pod。Replication Controller能夠經過repcon模板來建立多個Pod副本，一樣也能夠直接複製已存在Pod，須要經過Label selector來關聯。

在master上建立json文件：

{
    "id": "lianjiatest.com",
    "apiVersion": "v1beta1",
    "kind": "ReplicationController",
    "desiredState": {
      "replicas": 5,
      "replicaSelector": {"name": "liutest"},
      "podTemplate": {
        "desiredState": {
           "manifest": {
             "version": "v1beta1",
             "id": "apacheserver",
             "containers": [{
               "name": "apachetest",
               "image": "fedora/apache",
               "imagePullPolicy": "PullIfNotPresent",
               "ports": [{
                   "containerPort": 80
               }]
             }]
           }
         },
         "labels": {"name": "liutest"}
        }},
    "labels": {"name": "replicationtest"}
  }

在這裏建立了5個副本的pod。
運行命令：

./kubectl create -f replicationcontroller.json

這樣就ok了，而後在master上查看：

./kubectl get rc

CONTROLLER        CONTAINER(S)   IMAGE(S)        SELECTOR       REPLICAS
lianjiatest.com   apachetest     fedora/apache   name=liutest   5

在slave上運行docker ps 能夠看到：

OK！即便在slave刪掉其中的幾個，也會迅速補充到5個~~~~

建立service：

Services是Kubernetes最外圍的單元，經過虛擬一個訪問IP及服務端口，能夠訪問咱們定義好的Pod資源，目前的版本是經過iptables的nat轉發來實現，轉發的目標端口爲Kube_proxy生成的隨機端口

在master上建立test-svc.json：

{
  "id": "webserver",
  "kind": "Service",
  "apiVersion": "v1beta1",
  "selector": {
    "name": "liutest"
  },
  "protocol": "TCP",
  "containerPort": 80,
  "port": 8080
}

運行命令：

./kubectl create -f test-svc.json

而後查看創建好的service：

./kubectl get svc
NAME            LABELS                                    SELECTOR       IP(S)            PORT(S)
kubernetes      component=apiserver,provider=kubernetes   <none>         10.254.0.2       443/TCP
kubernetes-ro   component=apiserver,provider=kubernetes   <none>         10.254.0.1       80/TCP
webserver       <none>                                    name=liutest   10.254.122.245   8080/TCP

如今到slave上看看映射的端口多少，在slave上運行iptables-save：

-A KUBE-PORTALS-HOST -d 10.254.122.245/32 -p tcp -m comment --comment "default/webserver:" -m tcp --dport 8080 -j DNAT --to-destination 172.30.13.161:40391

ok，咱們在瀏覽器中訪問 172.30.13.161:40391，成功，請求是平均負載到建立的5個container中，惋惜在本次測試中體現不出來~~

最後總結下注意點：在replicationcontronllers.json中，"replicaSelector": {"name": "XXXXXX"}要與"labels": {"name": "XXXXXXX"}以及service中的"selector": {"name": "XXXXXXX"｝保持一致；