第一章 Kubernetes入門

第一章 Kubernetes入門

kubernetes是基於容器技術的分佈式架構領先方案，是一個完備的分佈式系統支撐平臺。

kubernetes帶來的好處：1)全面擁抱微服務；2)統能夠隨時隨地總體「搬遷」到公有云上;3)Kubernetes系統架構具有了超強的橫向擴容能力。

基本概念和術語

在Kubernetes中，Node、Pod、Replication Controller、Service等概念均可以看做一種資源對象，經過Kubernetes提供的Kubectl工具或者API調用進行操做，並保存在etcd中。

master

master上運行etcd server，API server，controller Manager，scheduler等進程，每一個kubernetes集羣須要有一個master節點來負責整個集羣的管理和控制。

 node

node做爲工做負載節點，運行如下一組關鍵進程。

kubelet：負責pod對應的容器建立，啓停等任務，同時與master節點密切協做，實現集羣管理的基本功能。

kube-proxy:實現kubernetes Service的通訊與負載均衡機制的重要組件。

Docker Engine：Docker引擎，負責本機的容器建立和管理工做。

查看集羣中多少個node：kubectl get nodes

查看某個Node的詳細信息：kubectl describe node <node_name>

pod

Pod是Kubernetes的最基本操做單元，包含一個活多個緊密相關的容器，相似於豌豆莢的概念。一個Pod能夠被一個容器化的環境看做應用層的「邏輯宿主機」（Logical Host）。一個Pod中的多個容器應用一般是緊耦合的。Pod在Node上被建立、啓動或者銷燬。

apiVersion: v1
kind: Pod
metadata:
name: redis-slave
labels:
name: redis-slave
spec:
containers:
    - name: slave
      image: kubeguide/guestbook-redis-slave
      env:
      - name: GET_HOSTS_FROM
        value: env
      ports:
      - containerPort: 6379
      resources:
        requests:    該資源的最小申請量，系統必須知足要求
           memory:"64Mi"
           cpu:"250m"
         limits:       資源最大容許使用量，超過將重啓
           memory:"128Mi"
           cpu:"500m"

View Code

 

Label

Label以key/value鍵值對的形式附加到各類對象上，如Pod、Service、RC、Node等。Label定義了這些對象的可識別屬性，用來對它們進行管理和選擇。Label能夠在建立時附加到對象上，也能夠在對象建立後經過API進行管理。

基於等式的Label Selector使用等式類的表達式來進行選擇：

1. name = redis-slave: 選擇全部包含Label中key="name"且value="redis-slave"的對象；
2. env != production: 選擇全部包括Label中的key="env"且value不等於"production"的對象。

基於集合的Label Selector使用集合操做的表達式來進行選擇：

1. name in (redis-master, redis-slave): 選擇全部包含Label中的key="name"且value="redis-master"或"redis-slave"的對象；
2. name not in (php-frontend): 選擇全部包含Label中的key="name"且value不等於"php-frontend"的對象。

將多個Label Selector進行組合

　　name=redis-slave,env!=production
　　name not in (php-frontend),env!=production

總結：使用label能夠給對象建立多組標籤，Lable和label Selector共同構成了Kubernetes系統中最核心的應用模型，使得被管理對象可以被精細的分組管理，同時實現了整個集羣的高可用性。

RC

RC定義了一個指望的場景，即聲明某種Pod的副本數量在任意時刻都符合某個預期值，因此RC的定義包括以下幾個部分：

1）pod期待的副本數

2）用於刷選目標Pod的label Selector

3）當pod的副本數量小於預期數量的時候，用於建立新pod的pod模板。

apiVersion: v1
kind: ReplicationController
metadata:
name: redis-slave
labels: redis-slave
name: redis-slave
spec:
replicas: 2
selector:
name: redis-slave      標籤name=redis-slave的pod存在2個副本
template:
metadata:
labels:
name: redis-slave
spec:
container:

        - name: slave
          image: kubeguide/guestbook-redis-slave
          env:
          - name: GET_HOSTS_FROM
            value: env
          ports:
          - containerPort: 6379

View Code

Deployment

deployment在內部使用Replica Set來實現目的，不管從Deployment的做用與目的，它的YAM定義，仍是從它的具體命令行操做來看，咱們均可以把它看作RC的一次升級。

HPA（pod橫向自動擴容）

經過追蹤分析RC控制的全部目標pod的負載變化狀況，來肯定是否須要針對性的調整目標pod的副本數，這是HPA的實現原理。

下面是HPA定義的案例：

apiVersion:autoscaling/v1
kind:HorizontalPodAutoscaler
metadata:
    name:php-apache
    namespace:default
spec:
    maxReplicas:10
    minReplicas:1
    scaleTargetRef:
        kind:Deployment
        name:php-apache
    targetCPUUtilizationPercentage:90

#根據上面的定義，咱們知道這個HPA控制的目標對象爲Deployment裏一個名叫php-apache的Pod副本，這個副本的CPUUtilizationPercentage值超過90%就會觸發自動擴容行爲，伸縮的副本數介於1-10之間。

#經過kubectl create建立HPA資源對象 或者
 kubectl autoscale deployment php-apache --cpu-percent=90 --min=1 --max=10

View Code

service

 

一個Service能夠看做一組提供相同服務的Pod的對外訪問接口。Service做用於哪些Pod是經過Label Selector來定義的。

Pod的IP地址和Service的Cluster IP地址

Pod的IP地址是Docker Daemon根據docker0網橋的IP地址段進行分配的，但Service的Cluster IP地址是Kubernetes系統中的虛擬IP地址，由系統動態分配。Service的Cluster IP地址相對於Pod的IP地址來講相對穩定，Service被建立時即被分配一個IP地址，在銷燬該Service以前，這個IP地址都不會再變化了。而Pod在Kubernetes集羣中生命週期較短，可能被ReplicationContrller銷燬、再次建立，新建立的Pod將會分配一個新的IP地址。

部署一個負載均衡器，爲這組pod開啓一個對外服務端口如8000端口，而且將pod的endpoint列表加入8000端口的轉發列表中，客戶端就能夠經過負載均衡器的對外IP地址+服務端口來訪問此服務，而客戶端的請求最後會被轉發到哪一個pod，則由負載均衡器算法決定。

外部訪問service

Node IP:Node節點的IP地址       Pod IP:Pod的IP地址   Cluster IP:Service的IP地址

Kubernetes支持兩種對外提供服務的Service的type定義：NodePort和LoadBalancer。

NodePort

apiVersion: v1
kind: Service
metadata:
    name: frontend
    labels:
        name: frontend
spec:
    type: NodePort       *
ports:
- port: 80
  nodePort: 30001       *
selector:
    name: frontend   

 LoadBalancer

若是雲服務商支持外接負載均衡器，則能夠經過spec.type=LoadBalaner定義Service，同時須要制定負載均衡器的IP地址。使用這種類型須要指定Service的nodePort和clusterIP。例如：

apiVersion: v1
kind: Service
metadata: {
"kind" "Service",
"apiVersion": "v1",
"metadata": {
"name": "my-service"
},
"spec": {
"type": "LoadBalaner",
"clusterIP": "10.0.171.239",
"selector": {
"app": "MyApp"
},
"ports": [
{
"protocol": "TCP",
"port": 80,
"targetPort": 9376,
"nodePort": 30061
}
],
},
"status": {
"loadBalancer": {
"ingress": [
{
"ip": "146.148.47.155"
}
]
}
}
}

View Code

volume（存儲卷）

Volume是Pod中可以被多個容器訪問的共享目錄。當容器終止或者重啓時，Volume中的數據也不會丟失。另外，Kubernetes支持多種類型的Volume，而且一個Pod能夠同時使用任意多個Volume。Kubernetes提供了很是豐富的Volume類型，下面逐一進行說明。

#舉例來講，咱們要給以前的tomcat pod增長一個名字爲dataVol的volume，而且Mount到容器的/mydata-data目錄，則只要對pod的定義文件作以下修改：
template:
 metadata:
       labels:
          app:app-demo
          tier:frontend
spec:
 volumes: -name:datavol emptyDir:{}
 containers:
 -name:tomcat-demo
 image:tomcat
volumeMount: - mountPath:/mydata-data name:datavol

1. EmptyDir：一個EmptyDir Volume是在Pod分配到Node時建立的。從它的名稱就能夠看出，它的初始內容爲空。在同一個Pod中全部容器能夠讀和寫EmptyDir中的相同文件。當Pod從Node上移除時，EmptyDir中的數據也會永久刪除。
2. hostPath：在Pod上掛載宿主機上的文件或目錄。

   使用宿主主機的/data目錄定義hostPath類型的volume：
   volumes:
   -name:"persistent-storage"
    hostPah:
       path:"/data"

3. gcePersistentDisk：使用這種類型的Volume表示使用谷歌計算引擎（Google Compute Engine，GCE）上永久磁盤（Persistent Disk，PD）上的文件。與EmptyDir不一樣，PD上的內容會永久保存，當Pod被刪除時，PD只是被卸載（Unmount），但不會被刪除。須要注意的是，你須要先建立一個永久磁盤（PD）才能使用gcePersistentDisk。
4. awsElasticBlockStore：與GCE相似，該類型的Volume使用Amazon提供的Amazon Web Service（AWS）的EBS Volume，並能夠掛在到Pod中去。須要注意到是，須要首先建立一個EBS Volume才能使用awsElasticBlockStore。
5. nfs：使用NFS（網絡文件系統）提供的共享目錄掛載到Pod中。在系統中須要一個運行中的NFS系統。
6. iscsi：使用iSCSI存儲設備上的目錄掛載到Pod中。
7. glusterfs：使用開源GlusterFS網絡文件系統的目錄掛載到Pod中。
8. rbd：使用Linux塊設備共享存儲（Rados Block Device）掛載到Pod中。
9. gitRepo：經過掛載一個空目錄，並從GIT庫clone一個git respository以供Pod使用。
10. secret：一個secret volume用於爲Pod提供加密的信息，你能夠將定義在Kubernetes中的secret直接掛載爲文件讓Pod訪問。secret volume是經過tmfs（內存文件系統）實現的，因此這種類型的volume老是不會持久化的。
11. persistentVolumeClaim：從PV（PersistentVolume）中申請所需的空間，PV一般是一種網絡存儲，不屬於任何node，例如GCEPersistentDisk、AWSElasticBlockStore、NFS、iSCSI等。

namespace

Namespace（命名空間）是Kubernetes系統中的另外一個很是重要的概念，經過將系統內部的對象「分配」到不一樣的Namespace中，造成邏輯上分組的不一樣項目、小組或用戶組，便於不一樣的分組在共享使用整個集羣的資源的同時還能被分別管理。
Kubernetes集羣在啓動後，會建立一個名爲「default」的Namespace，經過Kubectl能夠查看到。
使用Namespace來組織Kubernetes的各類對象，能夠實現對用戶的分組，即「多租戶」管理。對不一樣的租戶還能夠進行單獨的資源配額設置和管理，使得整個集羣的資源配置很是靈活、方便。

kubectl get namespaces    --查看命名空間

在yaml中定義名爲development的namespace：
apiVersion:v1
kind:Namespace
metadata:
  name:development

將一個名爲busybox的pod放入到development命名空間中：
apiVersion:v1
kind:Pod
metadata:
  name:busybox
  namespace:development
spec:
  containers:
  ..............
............

在對應的命名空間中查找pod：
kubectl get pods --namespace=development

Annotation

Annotation與Label相似，也使用key/value鍵值對的形式進行定義。Label具備嚴格的命名規則，它定義的是Kubernetes對象的元數據（Metadata），而且用於Label Selector。Annotation則是用戶任意定義的「附加」信息，以便於外部工具進行查找。
用Annotation來記錄的信息包括：

1. build信息、release信息、Docker鏡像信息等，例如時間戳、release id號、PR號、鏡像hash值、docker registry地址等；
2. 日誌庫、監控庫、分析庫等資源庫的地址信息；
3. 程序調試工具信息，例如工具名稱、版本號等；
4. 團隊的聯繫信息，例如電話號碼、負責人名稱、網址等。

總結

Kubernetes集羣由兩類節點組成：Master和Node。在Master上運行etcd、API Server、Controller Manager和Scheduler四個組件，其中後三個組件構成了Kubernetes的總控中心，負責對集羣中全部資源進行管理和調度。在每一個Node上運行Kubelet、Proxy和Docker Daemon三個組件，負責對本節點上的Pod的生命週期進行管理，以及實現服務代理的功能。另外在全部節點上均可以運行Kubectl命令行工具，它提供了Kubernetes的集羣管理工具集。

參考： http://www.jianshu.com/p/63ffc2214788