kubernetes1.4 基礎篇：Learn Kubernetes 1.4 by 6 steps_Kubernetes中文社群

9月底k8s發行了1.4版，在此版中增加了kubeadm似乎是在向swarm致敬，但是極大方便了k8s的叢集搭建。本系列教程將從搭建一個3個節點的k8s的叢集開始，用一些簡單的動手例項來學習一下k8s相關的基本概念以及k8s的核心用法。

由來

本教程受Kubernetes官方最新更新的文件所觸發，之所以沒有做單純的翻譯是因為如下幾個原因：

Kubernetes官方此教程基於minikube，個人對minikube可能有偏見，覺得像玩具。
Minikube更新較慢，不久前試的仍然只是能模擬kubernetes1.3，kubeadm也出來了，只是用於教程的話完全可以取代。
google的此教程提供了一個互動式的體驗視窗，但是本來就不復雜的東西，就不想用它們的互動式的介面，感覺不真實,同時自己搭建可以先看什麼就看什麼,另外google目前提供的版本仍不是最新的。

Kubernetes入門雖然不復雜，但是一般使用者第一個hello world的時間成本從接觸到可用可能還是以天為計算單位，太浪費。但是確實作為對Kubernetes基本概念的理解的入門教程很不錯，自己再重新看的時候也能溫故而知新。從中糅出這幾篇文章分享給大家，希望有所幫助。

Kubernetes基礎

此係列教程中會著重於圍繞Kubernetes叢集編排相關的基本概念展開，同時通過容器化的應用如何在Kubernetes中部署/擴充套件/更新為主線而展開。我們將會學到：

將容器化的應用部署到叢集上
擴充套件應用部署
更新容器化的應用程式版本
除錯容器化的應用程式

Kubernetes是什麼

Kubernetes是在整個計算機叢集中對應用容器進行編排和執行的一個可以用於生產環境級別的開源平臺。（瞭解更多內容 https://www.kubernetes.org.cn/kubernetes是什麼）

Kubernetes能做什麼

對於現代的web service，用於期待它應該是24×7的高可用，而開發者則期待能夠每天都能對這些應用程式釋出幾個版本（雖然我沒有這麼想過）。容器化則能幫助打包應用程式完成這些目標，使得應用程式能夠無宕機地平穩快速釋出。Kubernetes則能夠幫助做到剩下的事情。打完包的容器化應用執行在叢集上需要做什麼呢：

在哪個節點上執行
什麼時候執行
使用那些resouce
如何在這個叢集中調整這些resource
……

這些問題都需要進行考慮的，而現在kubernetes的編排和執行功能則為能為你排憂解難。而且Kubernetes不但是可以用於生產級別，而且還積累了google的多年容器化執行的經驗，有前人踏坑的可用軟體自然是大家競相追逐的。

基本內容

本系列教程將以容器化的應用如何在Kubernetes叢集上進行部署/更新/擴充套件按照如下六個步驟按序展開。
20161207102903

Step 1. Create a Kubernetes cluster
Step 2. Deploy an app
Step 3. Explore your app
Step 4. Expose your app publicly
Step 5. Scale up your app
Step 6. Update your app

組成要素

Kubernetes叢集包含如下兩種型別的資源：

型別	作用
Master	協調和操控叢集
Node	實際用於執行應用容器的”worker”

叢集構成

qq%e6%88%aa%e5%9b%be20161207102912

構成說明

Master的主要職責在於管理叢集，協調叢集上的所有活動，比如：

編排應用
維護應用狀態
擴充套件應用
更新應用等

Node

Node就是一臺在kubernetes叢集中擔任worker的VM或者物理機。在每個Node上都有一個kubelet，而Kubelet就是一個用於管理node和Master之間的溝通的agent。在node上需要安裝docker，或者說用於管理容器操作的工具，因為kubernetes並不繫結docker，我們以前介紹過的rkt在kubernetes中也是支援的。而且明眼人都能看出來，rkt純粹是google用於制衡docker的，rkt和kubernetes深度融合，但是是否能得到市場的認可這並不是一個純粹技術的問題。

一個在生產環境中能夠大體使用的kubernetes叢集至少要有3個node。本來就是node的協調和編排，你就一個node，也非要用kubernetes，雖然可以任性，但是屠龍寶刀只用來裁牆紙多少會有大材小用的唏噓。

Master

Master則用來管理叢集。當你在kubernetes叢集上部署應用的時候，你可能會需要Master啟動某個應用容器。 Master在叢集中協調用於啟動此容器的node，而node使用kubernetes API和master進行通訊（當然，使用者也可以直接使用kubernetes API和叢集進行互動）。

Kubernetes叢集建立

Kubernetes叢集可以被部署到物理機或者虛擬機器上。可以使用minikube，但是本文將使用kubeadm方式建立一個3 node + 1 Master的叢集。

構成

項番	類別	host名	IP
No.1	Master	host31	192.168.32.31
No.2	Node	host32	192.168.32.32
No.3	Node	host33	192.168.32.33
No.4	Node	host34	192.168.32.34

easypack_kubernetes.sh

K8S在1.4出來的時候向全世界宣佈2條命令建立叢集，在VPN的環境下，的確是這樣，因為這些依賴關係1.4會根據需要自動的去pull，但是pull不到google_container的就這樣被無比簡單的一件事情堵在外面。本著利己利人的出發點，寫了個指令碼，放到了github上（https://github.com/liumiaocn/easypack/tree/master/k8s），指令碼的使用基本上是sh easypack_kubernetes.sh MASTER來建立Master，sh easypack_kubernetes.sh NODE token MASTERIP來join，其他的諸如docker和kubelet/kubectl/kubeadm等的安裝，container的事前下載都寫進去了，版本全部目前統一為1.4.1的版本，指令碼及其簡單，無非將google的步驟放到一起而已，可以自行按自己需要進行修改。

建立Master

建立master在kubernetes1.4的版本只需要一條命令，kubeadm init, 但是其前提是能夠聯上網路，kubeadm會自動地按照需求去pull相應的image的版本，所以省去了翻來覆去的確認各個image等的版本，但是安裝過程會慢一些，如果你檢視linux的系統日誌你就會發現/var/log/messages中只有在安裝的時候在本地找不到正確版本的image的時候才回去pull，所以事前把所需要的內容都pull下來是一個很好的主意。

命令：
git clone https://github.com/liumiaocn/easypack
cd easypack/k8s
sh easypack_kubernetes.sh MASTER
>實際執行的時候不需要一定設定本地git，將上面github上面的指令碼easypack_kubernetes.sh的內容copy下來在本地vi生成一個即可

安裝耗時：10分鐘（基本上都是在pull google_container的映象）
輸出參照：
[[email protected] ~]# git clone https://github.com/liumiaocn/easypack
Cloning into 'easypack'...
remote: Counting objects: 67, done.
remote: Compressing objects: 100% (52/52), done.
remote: Total 67 (delta 11), reused 0 (delta 0), pack-reused 15
Unpacking objects: 100% (67/67), done.
[[email protected] ~]# cd easypack/k8s
[[email protected] k8s]# sh easypack_kubernetes.sh MASTER
Wed Nov 9 05:05:53 EST 2016
##INSTALL LOG : /tmp/k8s_install.1456.log
##Step 1: Stop firewall ...

Wed Nov  9 05:05:53 EST 2016
##Step 2: set repository and install kubeadm etc...
  install kubectl in Master...
#######Set docker proxy when needed. If ready, press any to continue...
注意：此處需要回車一下才能繼續，因為需要給安裝完docker還要設定docker的代理的提供一個手動處理的方式，不通過代理的直接回車即可

Wed Nov  9 05:07:04 EST 2016
##Step 3: pull google containers...
Now begin to pull images from liumiaocn
No.1 : kube-proxy-amd64:v1.4.1 pull begins ...
No.1 : kube-proxy-amd64:v1.4.1 pull ends   ...
No.1 : kube-proxy-amd64:v1.4.1 rename      ...
No.1 : kube-proxy-amd64:v1.4.1 untag       ...

No.2 : kube-discovery-amd64:1.0 pull begins ...
No.2 : kube-discovery-amd64:1.0 pull ends   ...
No.2 : kube-discovery-amd64:1.0 rename      ...
No.2 : kube-discovery-amd64:1.0 untag       ...

No.3 : kube-scheduler-amd64:v1.4.1 pull begins ...
No.3 : kube-scheduler-amd64:v1.4.1 pull ends   ...
No.3 : kube-scheduler-amd64:v1.4.1 rename      ...
No.3 : kube-scheduler-amd64:v1.4.1 untag       ...

No.4 : kube-controller-manager-amd64:v1.4.1 pull begins ...
No.4 : kube-controller-manager-amd64:v1.4.1 pull ends   ...
No.4 : kube-controller-manager-amd64:v1.4.1 rename      ...
No.4 : kube-controller-manager-amd64:v1.4.1 untag       ...

No.5 : kube-apiserver-amd64:v1.4.1 pull begins ...
No.5 : kube-apiserver-amd64:v1.4.1 pull ends   ...
No.5 : kube-apiserver-amd64:v1.4.1 rename      ...
No.5 : kube-apiserver-amd64:v1.4.1 untag       ...

No.6 : pause-amd64:3.0 pull begins ...
No.6 : pause-amd64:3.0 pull ends   ...
No.6 : pause-amd64:3.0 rename      ...
No.6 : pause-amd64:3.0 untag       ...

No.7 : etcd-amd64:2.2.5 pull begins ...
No.7 : etcd-amd64:2.2.5 pull ends   ...
No.7 : etcd-amd64:2.2.5 rename      ...
No.7 : etcd-amd64:2.2.5 untag       ...

No.8 : kubedns-amd64:1.7 pull begins ...
No.8 : kubedns-amd64:1.7 pull ends   ...
No.8 : kubedns-amd64:1.7 rename      ...
No.8 : kubedns-amd64:1.7 untag       ...

No.9 : kube-dnsmasq-amd64:1.3 pull begins ...
No.9 : kube-dnsmasq-amd64:1.3 pull ends   ...
No.9 : kube-dnsmasq-amd64:1.3 rename      ...
No.9 : kube-dnsmasq-amd64:1.3 untag       ...

No.10 : exechealthz-amd64:1.1 pull begins ...
No.10 : exechealthz-amd64:1.1 pull ends   ...
No.10 : exechealthz-amd64:1.1 rename      ...
No.10 : exechealthz-amd64:1.1 untag       ...

No.11 : kubernetes-dashboard-amd64:v1.4.1 pull begins ...
No.11 : kubernetes-dashboard-amd64:v1.4.1 pull ends   ...
No.11 : kubernetes-dashboard-amd64:v1.4.1 rename      ...
No.11 : kubernetes-dashboard-amd64:v1.4.1 untag       ...

All images have been pulled to local as following
gcr.io/google_containers/kube-controller-manager-amd64   v1.4.1              ad7b34f5ecb8        11 days ago         142.4 MB
gcr.io/google_containers/kube-apiserver-amd64            v1.4.1              4a76dd338dfe        4 weeks ago         152.1 MB
gcr.io/google_containers/kube-scheduler-amd64            v1.4.1              f9641959ec72        4 weeks ago         81.67 MB
gcr.io/google_containers/kube-proxy-amd64                v1.4.1              b47199222245        4 weeks ago         202.7 MB
gcr.io/google_containers/kubernetes-dashboard-amd64      v1.4.1              1dda73f463b2        4 weeks ago         86.76 MB
gcr.io/google_containers/kube-discovery-amd64            1.0                 c5e0c9a457fc        6 weeks ago         134.2 MB
gcr.io/google_containers/kubedns-amd64                   1.7                 bec33bc01f03        10 weeks ago        55.06 MB
gcr.io/google_containers/kube-dnsmasq-amd64              1.3                 9a15e39d0db8        4 months ago        5.126 MB
gcr.io/google_containers/pause-amd64                     3.0                 99e59f495ffa        6 months ago        746.9 kB

Wed Nov  9 05:14:18 EST 2016
Wed Nov  9 05:14:18 EST 2016
##Step 4: kubeadm init
Running pre-flight checks
注意：此處被卡的原因在於不符合安裝要求，基本上將提示的問題對應即可，一般是/etc/kubernetes下面事前已經有內容了，一些埠已經被佔用了等等。
<master/tokens> generated token: "77eddc.77edc19a7ade45d6"
<master/pki> generated Certificate Authority key and certificate:
Issuer: CN=kubernetes | Subject: CN=kubernetes | CA: true
Not before: 2016-11-09 10:14:19 +0000 UTC Not After: 2026-11-07 10:14:19 +0000 UTC
Public: /etc/kubernetes/pki/ca-pub.pem
Private: /etc/kubernetes/pki/ca-key.pem
Cert: /etc/kubernetes/pki/ca.pem
<master/pki> generated API Server key and certificate:
Issuer: CN=kubernetes | Subject: CN=kube-apiserver | CA: false
Not before: 2016-11-09 10:14:19 +0000 UTC Not After: 2017-11-09 10:14:19 +0000 UTC
Alternate Names: [192.168.32.31 10.0.0.1 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local]
Public: /etc/kubernetes/pki/apiserver-pub.pem
Private: /etc/kubernetes/pki/apiserver-key.pem
Cert: /etc/kubernetes/pki/apiserver.pem
<master/pki> generated Service Account Signing keys:
Public: /etc/kubernetes/pki/sa-pub.pem
Private: /etc/kubernetes/pki/sa-key.pem
<master/pki> created keys and certificates in "/etc/kubernetes/pki"
<util/kubeconfig> created "/etc/kubernetes/kubelet.conf"
<util/kubeconfig> created "/etc/kubernetes/admin.conf"
<master/apiclient> created API client configuration
<master/apiclient> created API client, waiting for the control plane to become ready
注意：此處是容易被卡住的最多的地方，從這裡開始基本上是google_container沒有下載下來或者是沒有下載到正確版本，詳細可以參看另外一篇單獨講解使用kubeadm進行安裝的文章。
<master/apiclient> all control plane components are healthy after 17.439551 seconds
<master/apiclient> waiting for at least one node to register and become ready
<master/apiclient> first node is ready after 4.004373 seconds
<master/apiclient> attempting a test deployment
<master/apiclient> test deployment succeeded
<master/discovery> created essential addon: kube-discovery, waiting for it to become ready
<master/discovery> kube-discovery is ready after 2.001892 seconds
<master/addons> created essential addon: kube-proxy
<master/addons> created essential addon: kube-dns

Kubernetes master initialised successfully!

You can now join any number of machines by running the following on each node:

kubeadm join --token=77eddc.77edc19a7ade45d6 192.168.32.31
注意：這個一定要注意，token是別的node用來join的時候必須的
Wed Nov  9 05:14:46 EST 2016
##Step 5: taint nodes...
node "host31" tainted
NAME      STATUS    AGE
host31    Ready     5s
注意：Master一般不是作為node來用的使用這種方法，這樣可以折衷。
Wed Nov  9 05:14:46 EST 2016
##Step 6: confirm version...
Client Version: version.Info{Major:"1", Minor:"4", GitVersion:"v1.4.1", GitCommit:"33cf7b9acbb2cb7c9c72a10d6636321fb180b159", GitTreeState:"clean", BuildDate:"2016-10-10T18:19:49Z", GoVersion:"go1.6.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"4", GitVersion:"v1.4.1", GitCommit:"33cf7b9acbb2cb7c9c72a10d6636321fb180b159", GitTreeState:"clean", BuildDate:"2016-10-10T18:13:36Z", GoVersion:"go1.6.3", Compiler:"gc", Platform:"linux/amd64"}
kubeadm version: version.Info{Major:"1", Minor:"5+", GitVersion:"v1.5.0-alpha.1.409+714f816a349e79", GitCommit:"714f816a349e7978bc93b35c67ce7b9851e53a6f", GitTreeState:"clean", BuildDate:"2016-10-17T13:01:29Z", GoVersion:"go1.6.3", Compiler:"gc", Platform:"linux/amd64"}
Wed Nov  9 05:14:47 EST 2016
##Step 7: set weave-kube ...
daemonset "weave-net" created
[[email protected] k8s]#

新增節點

建立完MASTER之後，就可以向這個叢集新增節點了，首先新增host32。

命令：sh easypack_kubernetes.sh NODE 77eddc.77edc19a7ade45d6 192.168.32.31

安裝耗時：10分鐘左右（基本上也是docker pull的時間，但是同時取決於你的網速和dockhub的狀況）
安裝參照：
[[email protected] k8s]# sh easypack_kubernetes.sh NODE 77eddc.77edc19a7ade45d6 192.168.32.31
Wed Nov 9 05:43:10 EST 2016
##INSTALL LOG : /tmp/k8s_install.10517.log
##Step 1: Stop firewall ...

Wed Nov  9 05:43:10 EST 2016
##Step 2: set repository and install kubeadm etc...
#######Set docker proxy when needed. If ready, press any to continue...

Created symlink from /etc/systemd/system/multi-user.target.wants/kubelet.service to /etc/systemd/system/kubelet.service.

Wed Nov  9 05:44:04 EST 2016
##Step 3: pull google containers...
Now begin to pull images from liumiaocn
No.1 : kube-proxy-amd64:v1.4.1 pull begins ...
No.1 : kube-proxy-amd64:v1.4.1 pull ends   ...
No.1 : kube-proxy-amd64:v1.4.1 rename      ...
No.1 : kube-proxy-amd64:v1.4.1 untag       ...

No.2 : kube-discovery-amd64:1.0 pull begins ...
No.2 : kube-discovery-amd64:1.0 pull ends   ...
No.2 : kube-discovery-amd64:1.0 rename      ...
No.2 : kube-discovery-amd64:1.0 untag       ...

No.3 : kube-scheduler-amd64:v1.4.1 pull begins ...
No.3 : kube-scheduler-amd64:v1.4.1 pull ends   ...
No.3 : kube-scheduler-amd64:v1.4.1 rename      ...
No.3 : kube-scheduler-amd64:v1.4.1 untag       ...

No.4 : kube-controller-manager-amd64:v1.4.1 pull begins ...
No.4 : kube-controller-manager-amd64:v1.4.1 pull ends   ...
No.4 : kube-controller-manager-amd64:v1.4.1 rename      ...
No.4 : kube-controller-manager-amd64:v1.4.1 untag       ...

No.5 : kube-apiserver-amd64:v1.4.1 pull begins ...
No.5 : kube-apiserver-amd64:v1.4.1 pull ends   ...
No.5 : kube-apiserver-amd64:v1.4.1 rename      ...
No.5 : kube-apiserver-amd64:v1.4.1 untag       ...

No.6 : pause-amd64:3.0 pull begins ...
No.6 : pause-amd64:3.0 pull ends   ...
No.6 : pause-amd64:3.0 rename      ...
No.6 : pause-amd64:3.0 untag       ...

No.7 : etcd-amd64:2.2.5 pull begins ...
No.7 : etcd-amd64:2.2.5 pull ends   ...
No.7 : etcd-amd64:2.2.5 rename      ...
No.7 : etcd-amd64:2.2.5 untag       ...

No.8 : kubedns-amd64:1.7 pull begins ...
No.8 : kubedns-amd64:1.7 pull ends   ...
No.8 : kubedns-amd64:1.7 rename      ...
No.8 : kubedns-amd64:1.7 untag       ...

No.9 : kube-dnsmasq-amd64:1.3 pull begins ...
No.9 : kube-dnsmasq-amd64:1.3 pull ends   ...
No.9 : kube-dnsmasq-amd64:1.3 rename      ...
No.9 : kube-dnsmasq-amd64:1.3 untag       ...

No.10 : exechealthz-amd64:1.1 pull begins ...
No.10 : exechealthz-amd64:1.1 pull ends   ...
No.10 : exechealthz-amd64:1.1 rename      ...
No.10 : exechealthz-amd64:1.1 untag       ...

No.11 : kubernetes-dashboard-amd64:v1.4.1 pull begins ...
No.11 : kubernetes-dashboard-amd64:v1.4.1 pull ends   ...
No.11 : kubernetes-dashboard-amd64:v1.4.1 rename      ...
No.11 : kubernetes-dashboard-amd64:v1.4.1 untag       ...

All images have been pulled to local as following
gcr.io/google_containers/kube-controller-manager-amd64   v1.4.1              ad7b34f5ecb8        11 days ago         142.4 MB
gcr.io/google_containers/pause-amd64                     latest              19047b725e84        3 weeks ago         746.9 kB
gcr.io/google_containers/kube-apiserver-amd64            v1.4.1              4a76dd338dfe        4 weeks ago         152.1 MB
gcr.io/google_containers/kube-scheduler-amd64            v1.4.1              f9641959ec72        4 weeks ago         81.67 MB
gcr.io/google_containers/kube-proxy-amd64                v1.4.1              b47199222245        4 weeks ago         202.7 MB
gcr.io/google_containers/kubernetes-dashboard-amd64      v1.4.1              1dda73f463b2        4 weeks ago         86.76 MB
gcr.io/google_containers/kube-proxy-amd64                v1.4.0              1f6aa6a8c3dc        6 weeks ago         202.8 MB
gcr.io/google_containers/kube-apiserver-amd64            v1.4.0              828dcf2a8776        6 weeks ago         152.3 MB
gcr.io/google_containers/kube-controller-manager-amd64   v1.4.0              b77714f7dc16        6 weeks ago         142.2 MB
gcr.io/google_containers/kube-scheduler-amd64            v1.4.0              9ed70b516ca8        6 weeks ago         81.8 MB
gcr.io/google_containers/kube-discovery-amd64            1.0                 c5e0c9a457fc        6 weeks ago         134.2 MB
gcr.io/google_containers/kubedns-amd64                   1.7                 bec33bc01f03        10 weeks ago        55.06 MB
gcr.io/google_containers/kube-dnsmasq-amd64              1.3                 9a15e39d0db8        4 months ago        5.126 MB
gcr.io/google_containers/pause-amd64                     3.0                 99e59f495ffa        6 months ago        746.9 kB

Wed Nov  9 05:52:49 EST 2016
Wed Nov  9 05:52:49 EST 2016
##Step 4: kubeadm join
Running pre-flight checks
<util/tokens> validating provided token
<node/discovery> created cluster info discovery client, requesting info from "http://192.168.32.31:9898/cluster-info/v1/?token-id=77eddc"
<node/discovery> cluster info object received, verifying signature using given token
<node/discovery> cluster info signature and contents are valid, will use API endpoints [https://192.168.32.31:6443]
注意：此處有可能被卡，比如此host的時間日期和Master都不一致等會導致被卡，其他被卡被坑的情況可以參照Master或者另外一片文章的整理。
<node/bootstrap> trying to connect to endpoint https://192.168.32.31:6443
<node/bootstrap> detected server version v1.4.1
<node/bootstrap> successfully established connection with endpoint https://192.168.32.31:6443
<node/csr> created API client to obtain unique certificate for this node, generating keys and certificate signing request
<node/csr> received signed certificate from the API server:
Issuer: CN=kubernetes | Subject: CN=system:node:host32 | CA: false
Not before: 2016-11-09 10:49:00 +0000 UTC Not After: 2017-11-09 10:49:00 +0000 UTC
<node/csr> generating kubelet configuration
<util/kubeconfig> created "/etc/kubernetes/kubelet.conf"

Node join complete:
* Certificate signing request sent to master and response
  received.
* Kubelet informed of new secure connection details.

Run 'kubectl get nodes' on the master to see this machine join.
Wed Nov  9 05:52:55 EST 2016
##Step 5: confirm version...
kubeadm version: version.Info{Major:"1", Minor:"5+", GitVersion:"v1.5.0-alpha.1.409+714f816a349e79", GitCommit:"714f816a349e7978bc93b35c67ce7b9851e53a6f", GitTreeState:"clean", BuildDate:"2016-10-17T13:01:29Z", GoVersion:"go1.6.3", Compiler:"gc", Platform:"linux/amd64"}[[email protected] k8s]#

結果確認

使用kubectl get nodes在Master上即可查看出叢集的構成

[root@host31 k8s]# kubectl get nodes
NAME      STATUS    AGE
host31    Ready     42m
host32    Ready     17m
host33    Ready     3m
host34    Ready     5m
[root@host31 k8s]#

什麼是Deployment

在Kubernetes中，Deployment是用來負責建立和更新應用程式例項的

為什麼要容器化

在Kubernetes中，為了能夠被部署，應用程式需要被打包成為其所支援的容器格式（docker/rkt）

Kubernetes Deployment

我們建立了一個具有3個node的kubernetes叢集.

qq%e6%88%aa%e5%9b%be20161207102927

有了這個叢集，接下來我們就可以把容器化了的應用部署到其中了。

qq%e6%88%aa%e5%9b%be20161207102933

首先，我們要建立一個kubernetes的Deployment。這個Deployment是用來負責建立和更新我們應用程式例項的。
而一旦這個應用建立好了之後，Kubernetes的Master會協調在叢集的哪個node上倆建立應用例項。
而一旦應用例項被建立之後，Kubernetes的Deployment Controller就會持續的監視這些應用例項。
一旦發生機器故障或者其他不可預知的情況導致應用例項停止時，一直在監視的Deployment Controller就立即知道這一情況，然後它就會重新生成新的應用例項
Kubernetes提供了這種在故障發生時的自愈機制,這個機制也是使用Kubernetes提案的時候反覆被背書的能力。

建立Deployment

可以使用Kubernetes的命令列介面kubectl，kubectl只安裝在Master上，通過使用kubernetes的API與叢集進行互動。

確認版本

命令：kubectl version。其實我們在安裝完成的時候如果你還有印象的話就會記得已經用過這條命令了，其結果顯示如下，client和Server均為1.4.1版本

[[email protected] ~]# kubectl version
Client Version: version.Info{Major:"1", Minor:"4", GitVersion:"v1.4.1", GitCommit:"33cf7b9acbb2cb7c9c72a10d6636321fb180b159", GitTreeState:"clean", BuildDate:"2016-10-10T18:19:49Z", GoVersion:"go1.6.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"4", GitVersion:"v1.4.1", GitCommit:"33cf7b9acbb2cb7c9c72a10d6636321fb180b159", GitTreeState:"clean", BuildDate:"2016-10-10T18:13:36Z", GoVersion:"go1.6.3", Compiler:"gc", Platform:"linux/amd64"}
[[email protected] ~]#

確認構成

命令：kubectl get nodes。通過這條命令我們可以確認到此叢集的構成以及各組成node的狀態是否都是ready

[root@host31 ~]# kubectl get nodes
NAME      STATUS    AGE
host31    Ready     2h
host32    Ready     1h
host33    Ready     1h
host34    Ready     1h
[root@host31 ~]#

建立Deployment

事前準備

可以使用kubectl run的方式建立也可以使用yaml檔案+kubectl create的方式進行建立。本次我們採用後者。首先下載一下kubernetes-dashboard.yaml。而這個檔案和easypack_kubernetes.sh在同級目錄，上篇文章中在git clone取得的時候已經在本地了。

[root@host31 k8s]# pwd
/root/easypack/k8s
[root@host31 k8s]# ls
easypack_kubernetes.sh  kubernetes-dashboard.yaml  README.md
[root@host31 k8s]#

此檔案根官方最新檔案的不同點僅在於其版本號我們使用的是前面下載下來的1.4.1，現在最新應該已經是1.4.2了。另外還有一點就是imagePullPolicy我們從Always修改成IfNotPresent了。不然，無論如何它都回去pull這個映象，網路有不允許，基本上kubernetes1.4的安裝和使用就只有和這點相關的有些小坑，體驗真心不錯。

建立

命令： kubectl create -f kubernetes-dashboard.yaml

[root@host31 k8s]# kubectl create -f kubernetes-dashboard.yaml
deployment "kubernetes-dashboard" created
service "kubernetes-dashboard" created
[root@host31 k8s]#

可以看到「deployment “kubernetes-dashboard” created」的提示資訊，這表明已經成功建立了一個Deployment，同時還有一個service也被創建出來了，至於service在Kubernetes中扮演什麼角色, 後續的文章中會專門講解，此處不再贅述。

確認Deployment

get deployments

使用kubectl get deployments可以列出當前的Deployment及其他資訊

[root@host31 k8s]# kubectl get deployments --namespace=kube-system
NAME                   DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
kube-discovery         1         1         1            1           2h
kube-dns               1         1         1            1           2h
kubernetes-dashboard   1         1         1            1           3m
[root@host31 k8s]#

確認Dashboard

命令：kubectl describe svc kubernetes-dashboard –namespace=kube-system
使用此條命令可以確認出該service對外暴露出的可以訪問的埠，通過此埠我們可以訪問Kubernetes的Dashboard UI介面

[[email protected] k8s]# kubectl describe svc kubernetes-dashboard --namespace=kube-system
Name:                   kubernetes-dashboard
Namespace:              kube-system
Labels:                 app=kubernetes-dashboard
Selector:               app=kubernetes-dashboard
Type:                   NodePort
IP:                     10.4.41.47
Port:                   <unset> 80/TCP
NodePort:               <unset> 31276/TCP
Endpoints:              10.36.0.1:9090
Session Affinity:       None
No events.[[email protected] k8s]#
註解：NodePort 31276 為此服務對外暴露的埠號，通過它和IP即可訪問Kubernetes1.4的Dashboard了

訪問URL：http://192.168.32.31:31276

qq%e6%88%aa%e5%9b%be20161207102946

namespace和node資訊，可以清楚地看到其是由4臺機器構成的kubernetes叢集。

qq%e6%88%aa%e5%9b%be20161207102955

當然號稱可以完成cli的90%功能的dashbaord不僅僅限於檢視一下構成而已。詳細使用方法可以自行探索，此處不再廢話。

Pod

我們在前面講到過node，node就是作為整個叢集中的worker，它是和Master這個節點向比較的。而pod是什麼呢，我們在上一篇文章中建立了一個dashboard的Deployment，這就是一個容器化了的應用被部署的例項。而Pod是kubernetes的一組應用容器的抽象，為什麼要做這層抽象呢，容器間資源的共享。比如容器的Volume，在比如容器的port，如何在多個容器之間共享，docker-compose就是基於這個目的對docker機能的擴充套件和延伸。pod裡面可以是單獨的一個container也可以是多個。pod將一組耦合度很高的容器緊密地結合在一起作為一個整體的方式。比如我們在DevOps的Automation的時候很多專案都倒入了Sonarqube，sonarqube使用一個內部預設的DB的話一個容器就解決問題，但是如果我們希望把資料能單獨進行管理比如使用mysql或者mariadb等的話，我們至少可能需要2個容器，這個時候就可以使用一個pod把這兩個都塞進去就可以了。

qq%e6%88%aa%e5%9b%be20161207103002

比如上圖中的Pod4，我們就可以理解為有多個被容器化了的應用程式的組合，這些應用程式共享一個叢集內部的IP10.10.10.4，共享內部的Volume。

Node

瞭解完pod之後，在來審視一下塞了pod的node吧。pod作為kubernetes上的最小單位，當我們建立一個kubernetes的Deployment的時候，Deployment其實也自然會使用所需的容器建立pod。通過kubernetes的分配，pod會與node建立聯絡。我們過去通過使用小機作雙機雙活等技巧在kubernetes面前顯得非常無力，無論是從規模還是控制等，在這裡死掉一個pod希望其自動恢復之需要調整它的重啟策略，node發生故障的時候也可以在其他的node上自動啟動該pod，而這些都可以調整。多年之前給客戶做的Tuxedo+MC/SG等作的負載均衡和高可用的架構驕傲過幾天，而從去年看到象kubernetes這樣的神器的出現感到極其的悲傷和無力，又有很多技能和知識變成廢紙了。在這裡，所有需要做的已經沒有什麼了，調節一下引數的程度。

qq%e6%88%aa%e5%9b%be20161207103008

使用kubectl故障排查

我們已經使用過kubectl做過好多事情，在接下來的內容中我們將會進一步的使用kubectl來探尋我們已經部署到kubernetes上的應用，而這些將會是在使用kubernetes進行工作的時候故障排查和確認所會使用的最常用的命令。

命令	說明
kubectl get	諸如kubectl get nodes等等列出資源一覽
kubectl describe	對kubectl取到的資訊進一步對某一resource進行更深入的確認
kubectl logs	確認pod的某個container的log資訊
kubectl exec	類似於docker exec，可以在某個container中執行命令等

確認應用配置資訊

我們在前面提到過建立Deployment會建立pod，接下來我們會使用kubectl get pods來進行確認

[root@host31 ~]# kubectl get pods --namespace=kube-system
NAME                                    READY     STATUS    RESTARTS   AGE
dummy-2088944543-rp84q                  1/1       Running   0          6h
etcd-host31                             1/1       Running   0          6h
kube-apiserver-host31                   1/1       Running   0          6h
kube-controller-manager-host31          1/1       Running   0          6h
kube-discovery-982812725-t71i9          1/1       Running   0          6h
kube-dns-2247936740-eez6o               3/3       Running   0          6h
kube-proxy-amd64-4jxh6                  1/1       Running   0          5h
kube-proxy-amd64-5ahum                  1/1       Running   0          6h
kube-proxy-amd64-6wql2                  1/1       Running   0          5h
kube-proxy-amd64-qu4bs                  1/1       Running   0          5h
kube-scheduler-host31                   1/1       Running   0          6h
kubernetes-dashboard-3000474083-y1htc   1/1       Running   0          3h
weave-net-7tvvm                         2/2       Running   0          5h
weave-net-q17ey                         2/2       Running   0          5h
weave-net-uktxs                         2/2       Running   0          6h
weave-net-y8zpe                         2/2       Running   0          5h
[root@host31 ~]#

我們清楚地看到kubernetes-dashboard-3000474083-y1htc作為其中一個pod果然被生成了，接下來想進一步察看這個pod的話需要使用kubectl describe pods來進行了。

[[email protected] ~]# kubectl describe pods kubernetes-dashboard-3000474083-y1htc --namespace=kube-system
Name:           kubernetes-dashboard-3000474083-y1htc
Namespace:      kube-system
Node:           host34/192.168.32.34
Start Time:     Wed, 09 Nov 2016 07:37:22 -0500
Labels:         app=kubernetes-dashboard
                pod-template-hash=3000474083
Status:         Running
IP:             10.36.0.1
Controllers:    ReplicaSet/kubernetes-dashboard-3000474083
Containers:
  kubernetes-dashboard:
    Container ID:       docker://f97b36f8de62d911356b20f3e8840c14b7ed11a35443a865ae78d79d439a7667
    Image:              gcr.io/google_containers/kubernetes-dashboard-amd64:v1.4.1
    Image ID:           docker://sha256:1dda73f463b239955d4cf94a9cd525ab5306bee0eb53c17534d3282bc50ae7aa
    Port:               9090/TCP
    State:              Running
      Started:          Wed, 09 Nov 2016 07:37:24 -0500
    Ready:              True
    Restart Count:      0
    Liveness:           http-get http://:9090/ delay=30s timeout=30s period=10s #success=1 #failure=3
    Volume Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-852jy (ro)
    Environment Variables:      <none>
Conditions:
  Type          Status
  Initialized   True
  Ready         True
  PodScheduled  True
Volumes:
  
              
           
              
              
            
            相關推薦
			   
            
            
            
 

    

    
    kubernetes1.4 基礎篇：Learn Kubernetes 1.4 by 6 steps_Kubernetes中文社群
      
						9月底k8s發行了1.4版，在此版中增加了kubeadm似乎是在向swarm致敬，但是極大方便了k8s的叢集搭建。本系列教程將從搭建一個3個節點的k8s的叢集開始，用一些簡單的動手例項來學習一下k8s相關的基本概念以及k8s的核心用法。
由來
本教程受Kubernetes官方最新更新的文件所觸 

  
 

    

    
    kubernetes1 4 基礎篇 Learn Kubernetes 1 4 by 6 steps（1） 概要
      零基礎   ria   快速發布   不但   clas   的人   搭建   pda   級別    


9月底k8s發行了1.4版，在此版中增加了kubeadm似乎是在向swarm致敬，但是極大方便了k8s的集群搭建。本系列教程將從搭建一個3個節點的k8s的集群開始，用一些簡單的動手實例來學習一下k8 

  
 

    

    
    kubernetes1 4 基礎篇 Learn Kubernetes 1 4 by 6 steps（5） Step 4
      們的   scribe   鍵值對   rip   畫面   利用   演示   多項目   就是   

在上一篇文章中我們了解了如何在kubectl get/describe等確認進一步的信息以進行故障排除等，本文我們將圍繞kubernetes中的lable和service兩個概念展開。

Kuberne 

  
 

    

    
    kubernetes1.4新特性：增加新節點健康狀況型別DiskPressure_Kubernetes中文社群
      
						背景資料
在Kubernetes架構圖中可以看到，節點（Node）是一個由管理節點委託執行任務的worker。 它能執行一個或多個Pods，節點（Node）提供了執行容器環境所需要的所有必要條件，在Kubernetes之前版本中叫做Minion。

相關結構體
通過下面這張圖可以看到在Kube 

  
 

    

    
    搜狗BizCloud：基於Kubernetes的私有云實踐_Kubernetes中文社群
      
						【編者的話】隨著搜狗業務的快速增長，需要更有效地控制成本，提升研發效率，我們基於Docker和Kubernetes構建了一站式私有云管理平臺——BizCloud，此平臺涵蓋服務管理、彈性伸縮、灰度釋出、自動運維、持續整合等功能。本文將簡要介紹BizCloud的設計思路、架構及服務發現、授權、灰 

  
 

    

    
    是時候使用Helm了：Helm, Kubernetes的包管理工具_Kubernetes中文社群
      
						目前我們的一個產品共有4套環境:dev環境、test環境、staging環境、production環境。 其中dev, test, staging環境在一個Kubernetes叢集上以不同namespace部署，production環境部署在另一個Kubernetes叢集上。這個產品總共有14 

  
 

    

    
    Fission：基於 Kubernetes 的 Serverless 函式框架_Kubernetes中文社群
      
						本文編譯自 Kubernetes 的官方博文，原文為 Platform9 的軟體工程師 Soam Vasani 所寫，講解了一個基於 Kubernetes 的 Serverless 函式（FaaS）框架——Fission。
簡單的來講，Fission 是一個構建在 Kubernetes 之上的 

  
 

    

    
    Kubernetes 1 4 基礎篇 kubeadm方式安裝
       
  
  kubernetes在9月份推出了1.4的版本，在這個版本中最招人眼球的就是它推出了kubeadm的方式進行安裝，簡化了很多流程。終於，至少這個版本的kubernetes像docker1.12內建的swarm一樣方便的建立叢集了。本文將會介紹一下如何在centos7下安裝單節點可用的叢集。親測可 

  
 

    

    
    基礎篇：4.2）規範化：3d軟件工程圖紙用模板
      auto   有趣的   規範   方便   的人   mic   所在   bsp   內容   本章目的：給讀者一些標準模板，方便作圖時使用
這篇博文的分享內容作者會定時的更新
 
1.標準的工程圖模板
標準的工程圖模板可以幫助機械工程師更加偷懶地畫出更好的產品，如下圖所示：

 作者以後會將 

  
 

    

    
    Rancher 1.4釋出：Kubernetes體驗的大邁進_Kubernetes中文社群
      
						Rancher 1.4已全面釋出！一如往常，我們首推您通過Rancher GitHub上的Releases Notes全面瞭解Rancher最新版本。不過在這裡，我們想著重向您介紹新版本中的幾個顯著變化，以及這些變化背後的緣由。
Dashboard和Helm
為了繼續向著更好的Kubernet 

  
 

    

    
    Repractise基礎篇：Web應用開發七日談
      一些事   mit   個人   性能   簡單的   第五天   第一天   ogg   喜歡   
        Repractise基礎篇：Web應用開發七日談

本來想的僅僅是畫一個例如以下的七日圖來說說Web開發的。隨後又想了想這似乎是一個非常棒的Web開發相關的知識介紹。應用開發是一個非常有意 

  
 

    

    
    [Python]學習基礎篇：常見的Python內置函數及模塊
      快樂學習python內置函數常見的Python內置函數詳解函數列表進制轉換函數函數名稱及參數功能用例bin（x）將數值x轉化為二進制>>> x=10 >>> bin(10) 10hex（x）將數值x轉化為十六進制>>> x=10 >>>  

  
 

    

    
    [Python]學習基礎篇：列表(List)的淺解
      python中list的一身鞏固列表首先先說明中python中數組下標的使用，在java，c或者c++中，每個數組的下標必須是正數，不能出現負數，如在java，c或者c++中使用a[-1]，編輯器會報錯，而在python中數組的訪問時可以出現負數下標，表示倒數第幾個元素。list列表的定義 Python中列表 

  
 

    

    
    [Python]學習基礎篇：字符串的處理
      sring的那些事字符串在每個編程語言中都有對於字符串的處理，字符串是每個編程語言必不可少的存在，對於字符串我們經常會對字符串進行合並，刪除，轉換，判斷等操作的處理。字符串的格式化 字符串的格式化在編程中我們經常會遇到，在java中有很多類的方法會提供我們我們使用，但對於格式化我們經常要把字符串轉化為相應的數 

  
 

    

    
    [Python]學習基礎篇：函數
      函數的那些事函數函數是一段特定功能的，被封裝的，可重用的程序代碼段。給這段程序一個名稱，然後就可以在其他程序的任何地方通過這個名稱任意地運行這個斷碼塊。函數的定義及調用 對於Python函數的定義，不同於大家熟知的c,java等編程語言的定義，以java為例，在定義函數時，要指明函數的返回值類型，要麽為voi 

  
 

    

    
    [Python]學習基礎篇：文件和目錄
      python中文件的那點事文件文件是數據在外部介質上的數據的集合，對於文件在Linux系統上包括普通文件，目錄文件，二進制文件，設備文件等。文件的打開或者創建 方法：open(‘file_name’,’打開方式’[,buf_size]) buf_size:參數指的是文件緩存區的大小，0代表不緩存，1代表緩存， 

  
 

    

    
    [Python]學習基礎篇：字典
      創建   clas   over   code   ini   normal   占用空間   trace   增加   字典字典這個數據結構的功能和它的名字一樣，根據key得到value值。字典的定義 方法： dict={‘key1’:value1,’key2’:value2……..} 對於字典，key值在 

  
 

    

    
    [Python]學習基礎篇：面向對象編程
      必須   outline   func   pad   order   ola   項目設計   tom   return   面向對象編程是種具有對象概念的程序編程典範，同時也是一種程序開發的抽象方針。它可能包含數據、屬性、代碼與方法。對象則指的是類的實例。它將對象作為程序的基本單元，將程序和數據封裝其中， 

  
 

    

    
    基礎篇：6.10）通用公差規則
      nbsp   ros   最終   測量   基礎篇   dimens   質量保證   所表   做的   本章目標：不管是用線性尺寸標註或形位公差標註，基礎的公差標註規則需要遵守。
 
1.通用公差規則（Fundamental Dimension Rule）
基本工程圖紙尺寸公差尺寸規則 (ASME 

  
 

    

    
    基礎篇：3.3.2）壓鑄件-材料選擇
      表現   nbsp   size   sof   pan   3.3   基礎   mic   family    
2.5 壓鑄件的常用材料：

常用的壓鑄鋁合金一般有：ADC12，YL113,YL102,A380,A360等常用的壓鑄鋅合金一般有：3#Zn；
目前，珠江三角洲地區普遍用的鋁合金是A