版權聲明:本文為部落客汪子熙原創文章,未經部落客允許不得轉載。 https://jerry.blog.csdn.net/article/details/84844088
- 是時候使用Helm了:Helm, Kubernetes的包管理工具
- 簡化Kubernetes應用部署工具-Helm安裝
- Picking the Right Solution
- 吐槽安裝的
- Kubernetes on Ubuntu
- Get Docker EE for Ubuntu
useful shell script
- which kubectl
- kubectl version
- 檢視ubuntu版本:cat /etc/issue
-
set proxy:
export http_proxy=http://duotai:[email protected]:24448
export https_proxy=$http_proxy
Docker設定proxy的檔案: /etc/default/docker
- docker pull hello-world
- docker run hellow-world
- kubectl cluster-info
To further debug and diagnose cluster problems, use ‘kubectl cluster-info dump’.
Unable to connect to the server: context deadline exceeded (Client.Timeout exceeded while awaiting headers)
- systemctl restart kube-apiserver
- kubectl get nodes
- kubectl get svc
- kubectl describe node
- kubectl get endpoints
- kubectl get svc tomcat-service -o yaml
- kubectl get namespaces --namespace=development
- systemctl daemon-reload
- systemctl enable etcd.service - 将服務加入開機啟動清單
- systemctl start etcd.service
- kubectl run nginx --image=nginx:1.12.2
- etcdctl cluster-health - 驗證etcd是否正确啟動
- kubectl describe pods
- kubectl get pods -l environment=production,tier=frontend
- kubectl get pods -l ‘environment in (production),tier in (frontend)’
- export TILLER_NAMESPACE=$(kubectl config view -o json | jq -r “.contexts[0].context.namespace”)
- get -o wide json -o=yaml
- docker ps -a
- nginx image html position: /usr/share/nginx/html
etcd, kube-controller-manager, kube-scheduler這些
Terminology
- CRI Container Runtime Interface
第一章
- 為什麼被8080refused了呢。别着急,還沒有啟動呢,這是沒有成功連接配接kubernetes apiserver的節奏,一切正常,到目前為止,我們隻是下載下傳了一個可執行檔案設定了權限而已。
- 用replicationcontroller建立pod,再建立service,暴露cluster IP. tcp通路。
kubelet是程序,向Master注冊自己
- 一個pod内的容器與另外主機上的pod容器能夠直接通信。
pod的ip加上containerport,組成了endpoint,代表pod裡的一個服務程序的對外通信位址。
m:千分之一個CPU配額。
Master node上的Controller Manager定期巡檢系統中存活的目标pod,確定其執行個體數量等于RC的期望值。
- Deployment -> Replication Set->Pod copy creation
檢查Deployment狀态來看部署動作是否完成
HPA:Horizontal Pod Autoscaling - 橫向自動擴容
通過跟蹤分析RC控制的所有目标POD的負載變化來确定是否需要針對性的調整目标POD的副本數。
監控CPU使用率,目前使用量 / yaml裡的pod request。
HPA本身也是一種kind:HorizontalPodAutoscaler
service就是我們說的微服務。Pod和RC其實都是為Service做鋪墊。
Service和後端pod副本叢集間通過Label Selector實作無縫對接。
rc的作用:保證service的服務能力和品質始終處于預期的标準,服務之間通過TCP/IP通信。每個pod都有單獨的IP,和containerPort一起組成了end point,那組成叢集後的入口是什麼?負載均衡器(軟體或硬體),負責決定請求被轉發到哪個pod。每個node上都運作了kube-proxy程序,實際就是一個智能的軟體負載均衡器,負責把對service的請求轉發到後端某個pod上,并在内部實作服務的負載均衡與會話保持機制。
每個service有一個全局唯一的虛拟IP位址,cluster IP,每個服務具有唯一IP位址的通信節點。整個生命周期内不變。内部pod的endpoint會随銷毀和重新建立而發生變化。
- targetPort: 确定提供宮該服務的容器所暴露的端口号,即具體業務程序在容器内的targetPort上提供TCP/IP接入,而port屬性則定義了service的虛端口。
服務發現 - 如何通過Service name找到cluster ip?
Cluster IP是Service建立後由Kubernetes自動配置設定的,其他pod無法預先知道某個service的cluster IP位址。是以需要一個服務發現機制來找到這個服務。
a. Service生成一些Linux環境變量,pod啟動時注入環境變量。通過Add-On
增值包引入DNS系統,把服務名作為dns域名。通過服務名建立通信連接配接。
- Node ip:
node節點的IP位址。真實存在的實體網絡,Kubernetes叢集外的節點通路叢集内的節點時,必須通過node ip進行通信。
很多服務都存在多個端口,一個端口提供業務服務,另一個端口提供管理服務。
Pod IP是每個pod的ip位址,是Docker engine根據docker0網橋的IP位址段進行配置設定的。通常是一個虛拟的二層網絡。
一個pod裡的容器通路另一個pod裡的容器,就是通過pod IP所在的虛拟二層網絡進行通信的,而真實的tcp/IP流量通過node IP所在的實體網卡流出。
Cluster IP沒有一個實體網絡對象,是以無法被ping。不具備TCP/IP通信基礎,屬于Kubernetes叢集的封閉空間。
叢集内部,node ip,pod IP,cluster IP之間的通信,采用的是一種特殊的路由規則,和IP路由完全不同。
使用nodeport同外界通信。
http://:
nodeport就是一個TCP監聽端口。
GCE - google cloud engine
volume在pod中的意思是能被多個Docker通路的共享目錄。
Kubernetes中的volume與pod的生命周期相同,但與容器的生命周期無關。
給volume定義一個名字,然後mount到docker的某個目錄下。
volume類型:
emptyDir: pod配置設定到node時建立,初始内容為空,無須指定主控端上對應的目錄檔案,由Kubernetes自動配置設定一個目錄,當pod從node上移除時,emptyDir中的資料也被永久删除。
用于臨時空間,一個容器需要從另一個容器中擷取資料的目錄。
hostPath:在pod上挂載主控端上的檔案或目錄。
- 容器應用程式生成的日志檔案需要永久儲存。
-
需要通路主控端上Docker引擎内部資料結構的容器應用,定義hostPath
為/var/lib/docker, 是容器内部應用可直接通路Docker上的檔案系統。
PV隻能是網絡存儲,不屬于任何Node,但可以在每個node上通路。PV不是定義在node上的,而是獨立于pod之外定義。
- namespace:多租戶隔離
不同的分組在共享使用整個叢集資源同時還能被分别管理. 預設是default。
- annotation
annotation和label類似,都是key/value, 但label有嚴格的naming convention,定義的是Kubernetes對象的中繼資料,而且用于label selector,而annotation是使用者任意定義的附加資訊,用于外部工具查找。
第二章
- 可在Google的GCE上安裝。
DNS(Domain Name System,域名系統),網際網路上作為域名和IP位址互相映射的一個分布式資料庫,能夠使使用者更友善的通路網際網路,而不用去記住能夠被機器直接讀取的IP數串。通過域名,最終得到該域名對應的IP位址的過程叫做域名解析(或主機名解析)。DNS協定運作在UDP協定之上,使用端口号53
如果在DNS伺服器處顯示的是個人公司的内部網絡位址,那麼說明該公司的DNS解析工作是交給公司内部的DNS伺服器來完成的,這時需要檢查這個DNS伺服器,在DNS伺服器上進行nslookup操作看是否可以正常解析
工作node上僅需部署kubelet和kube-proxy服務程序。
Master與工作node間會有大量網絡通信,在防火牆上需配置各元件需要互相通信的端口号。
etcd是Kubernetes叢集的主資料庫
Kubernetes各元件與Master之間通過apiserver的非安全端口http://apiserver:8080通路,但如果apiserver需要對外提供服務,或者叢集中某些容器需要通路apiserver以擷取叢集中的某些資訊,CA簽名的雙向數字證書認證。
google_containers/pause的鏡像實作pod的概念
http://gcr.io
第二章有很多指令行參數。
進度
2018-11-12 11:02AM 看到P38 1.4.6 Deployment,飛機上14:16看到42頁。
20:30, p46, 三種ip. 10:15 53 namespace 22:31第一章結束。
Docker
Docker鏡像是由多個檔案系統(隻讀層)疊加而成。當我們啟動一個容器的時候,Docker會加載隻讀鏡像層并在其上(譯者注:鏡像棧頂部)添加一個讀寫層。如果運作中的容器修改了現有的一個已經存在的檔案,那該檔案将會從讀寫層下面的隻讀層複制到讀寫層,該檔案的隻讀版本仍然存在,隻是已經被讀寫層中該檔案的副本所隐藏。當删除Docker容器,并通過該鏡像重新啟動時,之前的更改将會丢失。在Docker中,隻讀層及在頂部的讀寫層的組合被稱為Union File System(聯合檔案系統)。
為了能夠儲存(持久化)資料以及共享容器間的資料,Docker提出了Volume的概念。簡單來說,Volume就是目錄或者檔案,它可以繞過預設的聯合檔案系統,而以正常的檔案或者目錄的形式存在于主控端上。
learn from internet
確定pod數量:它會確定Kubernetes中有指定數量的Pod在運作。如果少于指定數量的pod,Replication Controller會建立新的,反之則會删除掉多餘的以保證Pod數量不變。
確定pod健康:當pod不健康,運作出錯或者無法提供服務時,Replication Controller也會殺死不健康的pod,重新建立新的。
彈性伸縮 :在業務高峰或者低峰期的時候,可以通過Replication Controller動态的調整pod的數量來提高資源的使用率。同時,配置相應的監控功能(Hroizontal Pod Autoscaler),會定時自動從監控平台擷取Replication Controller關聯pod的整體資源使用情況,做到自動伸縮。
滾動更新:滾動更新為一種平滑的更新方式,通過逐漸替換的政策,保證整體系統的穩定,在初始化更新的時候就可以及時發現和解決問題,避免問題不斷擴大。
see:https://www.jianshu.com/p/6bc8e0ae65d1
Docker Swarm vs Kubernetes
minikube相關
- Kubectl: Kubernetes with minikube times out