Kubernetes是谷歌嚴格保密十幾年的祕密武器——Borg的一個開源版本,是Docker分佈式系統解決方案。php
- Borg
Borg是谷歌內部使用的大規模集羣管理系統,基於容器技術,目的是實現資源管理的自動化,以及跨多個數據中心的資源利用率的最大化;- Endpoint(IP+Port)
標識服務進程的訪問點;- Master
集羣控制節點,負責整個集羣的管理和控制,基本上Kubernetes全部的控制命令都是發給它,它來負責具體的執行過程,咱們後面全部執行的命令基本都是在Master節點上運行的;
- Kubernetes API Server(kube-apiserver),提供Http Rest接口的關鍵服務進程,是Kubernetes裏全部資源的增、刪、改、查等操做的惟一入口,也是集羣控制的入口進程;
- Kubernetes Controller Manager(kube-controller-manager),Kubernetes裏全部資源對象的自動化控制中心,能夠理解爲資源對象的「大總管」;
- Kubernetes Scheduler(kube-scheduler),負責資源調度(Pod調度)的進程,至關於公交公司的「調度室」;
- etcd Server,Kubernetes裏全部的資源對象的數據所有是保存在etcd中;
- Node
除了Master,Kubernetes集羣中的其餘機器被稱爲Node節點,Node節點纔是Kubernetes集羣中的工做負載節點,每一個Node都會被Master分配一些工做負載(Docker容器),當某個Node宕機,其上的工做負載會被Master自動轉移到其餘節點上去;
- kubelet,負責Pod對應的容器的建立、啓停等任務,同時與Master節點密切協做,實現集羣管理的基本功能。一旦Node被歸入集羣管理範圍,kubelet進程就會想Master幾點彙報自身的情報,這樣Master能夠獲知每一個Node的資源使用狀況,並實現高效均衡的資源調度策略。而某個Node超過指定時間不上報信息,會被Master斷定爲「失聯」,Node狀態被標記爲不可用(Not Ready),隨後Master會觸發「工做負載大轉移」的自動流程;
- kube-proxy,實現Kubernetes Service的通訊與負載均衡機制的重要組件;
- Docker Engine(docker),Docker引擎,負責本機的容器建立和管理工做;
- Pod
- 每一個Pod都有一個特殊的被稱爲「根容器」的Pause容器,還包含一個或多個緊密相關的用戶業務容器;
- 一個Pod裏的容器與另外主機上的Pod容器可以直接通訊;
- 若是Pod所在的Node宕機,會將這個Node上的全部Pod從新調度到其餘節點上;
- 普通Pod及靜態Pod,前者存放在etcd中,後者存放在具體Node上的一個具體文件中,而且只能在此Node上啓動運行;
- Docker Volume對應Kubernetes中的Pod Volume;
- 每一個Pod能夠設置限額的計算機資源有CPU和Memory;
- Requests,資源的最小申請量;
- Limits,資源最大容許使用的量;
- Event
是一個事件記錄,記錄了事件最先產生的時間、最後重複時間、重複次數、發起者、類型,以及致使此事件的緣由等信息。Event一般關聯到具體資源對象上,式排查故障的重要參考信息;- Label
Label能夠附加到各類資源對象上,一個資源對象能夠定義任意數量的Label。給某個資源定義一個Label,至關於給他打一個標籤,隨後能夠經過Label Selector(標籤選擇器)查詢和篩選擁有某些Label的資源對象。咱們能夠經過給指定的資源對象捆綁一個或多個Label來實現多維度的資源分組管理功能,以便於靈活、方便的進行資源分配、調度、配置、部署等管理工做;
Label Selector示例:select * from pod where pod’s name=’XXX’,env=’YYY’,支持操做符有=、!=、in、not in;- Replication Controller(RC)
部署和升級Pod,聲明某種Pod的副本數量在任意時刻都符合某個預期值;
- Pod期待的副本數;
- 用於篩選目標Pod的Label Selector;
- 當Pod副本數量小於預期數量的時候,用於建立新Pod的Pod模板(template);
- Replica Set
下一代的Replication Controlle,Replication Controlle只支持基於等式的selector(env=dev或environment!=qa)但Replica Set還支持新的、基於集合的selector(version in (v1.0, v2.0)或env notin (dev, qa)),這對複雜的運維管理帶來很大方便。- Deployment
擁有更加靈活強大的升級、回滾功能。在新的版本中,官方推薦使用Replica Set和Deployment來代替RC,二者類似度>90%,相對於RC一個最大升級是咱們隨時指導當前Pod「部署」的進度。Deployment使用了Replica Set,除非須要自定義升級功能或根本不須要升級Pod,通常狀況下,咱們推薦使用Deployment而不直接使用Replica Set;
典型使用場景:
- 建立一個Deployment對象來生成對應的Replica Set並完成Pod副本的建立過程;
- 檢查更新Deployment的狀態來查看部署動做是否完成(Pod副本的數量是否達到預期的值);
- 更新Deployment以建立新的Pod;(好比鏡像升級)
- 若是當前Deployment不穩定,則回滾到一個早先的Deployment版本;
- 掛起或者回復一個Deployment;
- Horizontal Pod Autoscaler(HPA)
意思是Pod橫向自動擴容,目標是實現自動化、智能化擴容或縮容。
Pod負載度量指標:
- CPUUtilizationPercentage
一般使用一分鐘內的平均值,能夠經過Heapster擴展組件獲取這個值。一個Pod自身的CPU利用率是該Pod當前CPU的使用量除以它的Pod Request的值。例如Pod Request定義值爲0.4,當前Pod使用量爲0.2,則它的CPU使用率爲50%。但若是沒有定義Pod Request值,則沒法使用CPUUtilizationPercentage來實現Pod橫向自動擴容的能力;- 應用程序自定義的度量指標,好比服務在每秒內的相應的請求書(TPS或QPS)
- Service
Service其實就是咱們常常提起的微服務架構中的一個「微服務」,經過分析、識別並建模系統中的全部服務爲微服務——Kubernetes Service,最終咱們的系統由多個提供不一樣業務能力而又彼此獨立的微服務單元所組成,服務之間經過TCP/IP進行通訊,從而造成了咱們強大而又靈活的彈性網絡,擁有了強大的分佈式能力、彈性擴展能力、容錯能力;
如圖示,每一個Pod都提供了一個獨立的Endpoint(Pod IP+ContainerPort)以被客戶端訪問,多個Pod副本組成了一個集羣來提供服務,通常的作法是部署一個負載均衡器來訪問它們,爲這組Pod開啓一個對外的服務端口如8000,而且將這些Pod的Endpoint列表加入8000端口的轉發列表中,客戶端能夠經過負載均衡器的對外IP地址+服務端口來訪問此服務。運行在Node上的kube-proxy其實就是一個智能的軟件負載均衡器,它負責把對Service的請求轉發到後端的某個Pod實例上,而且在內部實現服務的負載均衡與會話保持機制。Service不是共用一個負載均衡器的IP地址,而是每一個Servcie分配一個全局惟一的虛擬IP地址,這個虛擬IP被稱爲Cluster IP。- Node IP
Node節點的IP地址,是Kubernetes集羣中每一個節點的物理網卡的IP地址,是真是存在的物理網絡,全部屬於這個網絡的服務器之間都能經過這個網絡直接通訊;- Pod IP
Pod的IP地址,是Docker Engine根據docker0網橋的IP地址段進行分配的,一般是一個虛擬的二層網絡,位於不一樣Node上的Pod可以彼此通訊,須要經過Pod IP所在的虛擬二層網絡進行通訊,而真實的TCP流量則是經過Node IP所在的物理網卡流出的;- Cluster IP
Service的IP地址。特性以下:
- 僅僅做用於Kubernetes Servcie這個對象,並由Kubernetes管理和分配IP地址;
- 沒法被Ping,由於沒有一個「實體網絡對象」來響應;
- 只能結合Service Port組成一個具體的通訊端口;
- Node IP網、Pod IP網域Cluster IP網之間的通訊,採用的是Kubernetes本身設計的一種編程方式的特殊的路由規則,與IP路由有很大的不一樣;
- Volume
能夠經過以下命令查看Volume信息:
注:Node、Pod、Replication Controller和Service等均可以看做是一種「資源對象」,幾乎全部的資源對象均可以經過Kubernetes提供的kubectl工具執行增、刪、改、查等操做並將其保存在ectd中持久化存儲。node
- 輕裝上陣,小團隊便可輕鬆應付從設計實現到運維的複雜的分佈式系統;
- 全面擁抱微服務架構;
- 遷移方便,能夠很方便的搬遷到公有云或基於OpenStack的私有云上;
- 超強的橫向擴容能力;
64位CentOS7mysql
systemctl disable firewalld
systemctl stop firewalld
yum install -y etcd kubernetes
安裝完畢後,須要修改以下兩個配置文件:
* 修改/etc/sysconfig/docker,將其中OPTIONS內容設置爲:OPTIONS=’–selinux-enabled=false –insecure-registry grc.io’;
* 修改/etc/kubernetes/apiserver,把–admission-control參數的ServiceAccount刪除;linux
systemctl start etcd systemctl start docker systemctl start kube-apiserver systemctl start kube-controller-manager systemctl start kube-scheduler systemctl start kubelet systemctl start kube-proxy
若是不肯定服務是否啓動成功,能夠運行下面命令進行一一確認web
ps aux | grep 服務名
Java Web應用
注:Tomcat有可能沒法正常啓動,緣由是虛機的內存和CPU設置太小,請酌情調大!sql
docker pull kubeguide/tomcat-app:v2apache
docker pull daocloud.io/library/mysql:latest編程
mysql-rc.yaml後端
apiVersion: v1
kind: ReplicationController
metadata:
name: mysql
spec:
replicas: 1
selector:
app: mysql
template:
metadata:
labels:
app: mysql
spec:
containers:
- name: mysql image: mysql ports: - containerPort: 3306 env: - name: MYSQL_ROOT_PASSWORD value: "123456"
kubectl create -f mysql-rc.yaml
kubectl get rc
kubectl get pods
mysql-svc.yaml
apiVersion: v1 kind: Service metadata: name: mysql spec: ports: - port: 3306 selector: app: mysql
kubectl create -f mysql-svc.yaml
kubectl get svc
myweb-rc.yaml
kind: ReplicationController
metadata:
name: myweb
spec:
# Pod的數量 replicas: 1 # spec.selector與spec.template.metadata.labels,這兩個字段必須相同,不然下一步建立RC會失敗。 selector: app: myweb template: metadata: labels: app: myweb # 容器組的定義 spec: containers: # 容器名稱 - name: myweb # 容器對應的鏡像 image: kubeguide/tomcat-app:v1 ports: # 在8080端口上啓動容器進程,PodIP與容器端口組成Endpoint,表明着一個服務進程對外通訊的地址 - containerPort: 8080 env: #此處若是在未安裝域名解析的狀況下,會沒法將mysql對應的IP解析到env環境變量中,所以先註釋掉! # - name: MYSQL_SERVICE_HOST # value: 'mysql' - name: MYSQL_SERVICE_PORT value: '3306'
kubectl create -f myweb-rc.yaml
kubectl get rc
kubectl get pods
myweb-svc.yaml
apiVersion: v1 kind: Service metadata: name: myweb spec: type: NodePort ports: - port: 8080 nodePort: 30001 selector: app: myweb
kubectl create -f myweb-svc.yaml
kubectl get services
瀏覽器中輸入http://虛擬機IP:30001/demo便可呈現以下內容:
tomcat-deployment.yaml
#與RC不一樣之處,版本配置不一樣 apiVersion: extensions/v1beta1 #與RC不一樣之處,Kind不一樣 kind: Deployment metadata: name: frontend spec: replicas: 1 selector: matchLabels: tier: frontend matchExpressions: - {key: tier, operator: In, values: [frontend]} template: metadata: labels: app: app-demo tier: frontend spec: containers: - name: tomcat-demo image: tomcat # 設置資源限額,CPU一般以千分之一的CPU配額爲最小單位,用m來表示。一般一個容器的CPU配額被定義爲100~300m,即佔用0.1~0.3個CPU; resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m" imagePullPolicy: IfNotPresent ports: - containerPort: 8080
kubectl create -f tomcat-deployment.yaml
kubectl get deployments
- DESIRED,Pod副本數量的指望值,及Deployment裏定義的Replica;
- CURRENT,當前Replica實際值;
- UP-TO-DATE,最新版本的Pod的副本數量,用於指示在滾動升級的過程當中,有多少個Pod副本已經成功升級;
- AVAILABLE,當前集羣中可用的Pod的副本數量;
kubectl get rs
看一下這裏的名稱與Deployment裏面名稱的關係;
kubectl get pods
看一下這裏Pod的命名以Deployment對應的Replica Set的名字爲前綴;
kubectl describe deployments
php-apache.yaml
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控制的目標對象爲一個名叫php-apache的Deployment裏的Pod副本,當這些Pod副本的CPUUtilizationPercentage超過90%時會觸發自動擴容行爲,擴容或縮容時必須知足的一個約束條件是Pod的副本數要介於1與10之間;
kubectl autoscale deployment php-apache –cpu-percent=90 –min=1 –max=10
tomcat-service.yaml
apiVersion: v1 kind: Service metadata: name: tomcat-service spec: # 服務若是想被外部調用,必須配置type type: NodePort ports: - port: 8080 name: service-port # 服務若是想被外部調用,必須配置nodePort nodePort: 31002 - port: 8005 name: shutdown-port selector: tier: frontend
上述內容定義了一個名爲「tomcat-service」的Servcie,它的服務端口爲8080,擁有「tier=frontend」這個Label的全部Pod實例都屬於它;
這裏的NodePort沒有徹底解決外部訪問Service的全部問題,好比負載均衡,假如咱們又10個Node,則此時最好有一個負載均衡器,外部的請求只需訪問此負載均衡器的IP地址,由負載局衡器負責轉發流量到後面某個Node的NodePort上。這個負載均衡器能夠是硬件,也能夠是軟件方式,例如HAProxy或者Nginx;
若是咱們的集羣運行在谷歌的GCE公有云上,那麼只要咱們把Service的type=NodePort改成type=LoadBalancer,此時Kubernetes會自動建立一個對應的LoadBalancer實例並返回它的IP地址供外部客戶端使用。其它公有云提供商只要實現了支持此特性的驅動,則也能夠達到上述目的;
kubectl create -f tomcat-service.yaml
kubectl get endpoints
kubectl get svc tomcat-service -o yaml
apiVersion: v1 kind: Service metadata: creationTimestamp: 2017-04-21T15:47:43Z name: tomcat-service namespace: default resourceVersion: "227916" selfLink: /api/v1/namespaces/default/services/tomcat-service uid: dbf15b30-26a9-11e7-b185-080027d589d3 spec: # Kubernetes集羣內部的地址,沒法在集羣外部使用這個地址 clusterIP: 10.254.2.210 ports: # 服務的虛端口 - port: 8080 protocol: TCP # 肯定提供該服務的容器所暴露的端口號,默認與port相同 targetPort: 8080 selector: tier: frontend sessionAffinity: None type: ClusterIP status: loadBalancer: {}
docker images
docker rmi 鏡像ID
docker ps
docker exec -it 容器ID sh
docker logs 容器ID
docker rm -f 容器ID
kubectl apply -f XXX.yaml
kubectl delete -f XXX.yaml kubectl create -f XXX.yaml
kubectl get nodes
kubectl describe node 節點名
kubectl scale rc XXX --replicas=3
kubectl describe rc 標籤名或者選擇器名
kubectl replace -f rc.yaml 或 kubect edit replicationcontroller replicationcontroller名
kubectl rolling-update replicationcontroller名 --image=鏡像名
kubectl rolling-update replicationcontroller名 -f XXX.yaml