-
kube-apiserver基於token的認證機制
kubenetes除了基於ca證書的認證方式,也提供了基於http token的認證方式。各客戶端組件與api server之間的通信方式仍然采用https,但不采用ca數字證書。這種機制與ca證書相比,安全性很低,在生產不建議使用。
采用基於HTTP Token的簡單認證方式時,APIServer對外暴露HTTPS端口,客戶端攜帶Token來完成認證過程。 需要說明的是, kubectl命令行工具比較特殊, 它同時支持CA 證書和簡單認證 兩種方式與 API Server通信, 其他客戶端組件只能配置基於 CA 證書的認證方式或者非安全方式與 API Server通信。
基於Token認證的配置過程如下:
-
創建包括用戶名,密碼和uid的文件token_auth_file,將其放置在合適的目錄下,例如/etc/kubernetes目錄。需要注意的是,這是一個純文本的文件,用戶名,密碼都是明文。較為簡單。
2.設置kube-apiserver的啟動參數,"—token-auth-file",使用上述文件提供安全認證,然后重啟Api server服務。
3.用curl客戶端工具通過token訪問API server:
-
-
使用私有鏡像庫的相關配置
在kubernetes集群中,容器應用都是基於鏡像啟動的,在私有雲環境下建議搭建私有鏡像庫進行鏡像的管理。在公有雲中可以直接使用雲服務商提供的鏡像庫。
私有鏡像選擇:
- docker提供的Registry鏡像庫,詳細說明請參考官網的說明。
- Harbor鏡像倉庫,可以去官網看相關說明,或者看一看harbor權威指南這一書。
此外,kubernetes對於創建pod需要使用一個名為"pause"的鏡像,tag名為"k8s.gcr.io/pause:3.2",默認從鏡像庫k8s.gcr.io下載,在私有雲環境中可以將其上傳到私有鏡像庫,並修改kubelet的啟動參數—pod-infra-container-image,將其設置為使用鏡像庫的鏡像名稱,例如:
--pod-infra-container-image=<my-private-registry>/pause:3.2
-
二進制文件升級
在進行Kubernetes的版本升級之前,需要考慮不中斷正在運行的業務容器的灰度升級方案。 常見的做法是:先更新Master上Kubernetes服務的版本, 再逐個或批量更新集群中的Node上Kubernetes服務的版本。 更新Node的Kubernetes服務的步驟通常包括:先隔離一個或多個Node的業務流量, 等待這些Node上運行的Pod將當前任務全部執行完成后, 停掉業務應用(Pod ), 再更新這些Node上的kubelet和kube-proxy版本 , 更新完成后重啟業務應用(Pod ),並將業務流量導人新啟動的這些Node上,再隔離剩余的Node,逐步完成Node的版本升級, 最終完成整個集群的Kubernetes版本升級。
同時, 應該考慮高版本的Master對低版本的Node的兼容性問題。 高版本的Master 通常可以管理低版本的Node,但版本差異不應過大, 以免某些功能或API版本被棄用后,低版本的Node無法運行。
- 通過官網獲取最新版本的二進制包kubernetes.tar.gz, 解壓后提取服務的二進制文件。
- 更新Master的kube-apiserver、kube-controller-manager、kube-scheduler服務的二進制文件和相關配置(在需要修改時更新)並 重啟服務。
- 逐個或批量隔離Node,等待其上運行的全部容器工作完成后停掉Pod,更新kubelet、kube-proxy服務文件和相關配置(在需要修改時更新), 然后重啟這兩個服務。
-
使用kubeadm進行集群升級
kubeadm提供了upgrade 命令用於對kubeadm安裝的Kubemetes集群進行升級。這一功能提供了從 1.10 到 1.1 l 、從 1.1 l 到 1.12 、從 1.12 至 1.13 及從 1.13 到 1.14 升級的能力, 本節以從 1.13 到 1.14 升級為例進行說明。
升級之前需要注意:
雖然kubeadm的升級不會觸及工作負載,但還是要在升級之前做好備份;
升級過程中可能會因為pod的變化而造成容器重啟。
以centos7為例,首先需要升級的是kubeadm:
yum install -y kubeadm-1.14.0 -disableexcludes=Kubernetes
然后再查看版本既可
接下來查看kubeadm的升級計划
kubeadm upgrade plan