Kubernetes使用Harbor作為私有鏡像倉庫

概述

Harbor使用了基于角色的通路控制政策，當從Harbor中拉去鏡像的時候，首先要進行身份認證，認證通過後才可以拉取鏡像。在指令行模式下，需要先執行

docker login

，登陸成功後，才可以

docker pull

。通常情況下，在私有雲環境中使用kubernetes時，我們要從docker registry拉取鏡像的時候，都會給docker daemo配置

–insecure-registry

屬性來告訴docker daemo我們所使用的docker registry是可信的，這樣才能從私有的docker registry中拉取鏡像，但是如果要使用Harbor作為kubernetes的鏡像倉庫的話，這種方式就不适用了，下面讓我們看看如何來使用Harbor作為kubernetes的鏡像倉庫。

測試

首先在

docker login

成功登入的情況下，不做其他任何配置看k8s能否從Harbor私有倉庫拉取鏡像：

以coredns為例：将本地的

coredns:1.2.6

鏡像上傳到harbor私有倉庫，删除本地

reg.harbor.com/k8s/coredns:1.2.6

鏡像，確定鏡像會從私有倉庫拉取。

docker login -u admin -p Harbor12345 reg.harbor.com
docker tag coredns/coredns:1.2.6 reg.harbor.com/k8s/coredns:1.2.6
docker push reg.harbor.com/k8s/coredns:1.2.6
docker rmi reg.harbor.com/k8s/coredns:1.2.6
           

修改coredns.yaml配置檔案

image: reg.harbor.com/k8s/coredns:1.2.6

啟動：

# kubectl -n kube-system get pod
NAME                                    READY   STATUS         RESTARTS   AGE
coredns-78b7cdf8ff-qtb8t                0/1     ErrImagePull   0          5s
           

describe

檢視報錯：

Failed to pull image "reg.harbor.com/k8s/coredns:1.2.6": rpc error: code = Unknown desc = Error response from daemon: pull access denied for reg.harbor.com/k8s/coredns, repository does not exist or may require 'docker login'
           

鏡像拉取失敗。

實作探索

我們在指令行方式下，輸入

docker login

登陸成功後，會在

/root/.docker/

目前下生成一個

config.json

檔案。打開後可以看到如下的内容：

# cat /root/.docker/config.json 
{
		"auths": {
				"reg.harbor.com": {
						"auth": "YWRtaW46SGFyYm9yMTIzNDU="
				}
		},
		"HttpHeaders": {
				"User-Agent": "Docker-Client/18.09.0 (linux)"
		}
}
           

這裡的内容就是docker daemon用來與docker registry進行認證的，其中，

reg.harbor.com

是docker registry server的位址，

auth

部分是加密後的認證資訊，當輸入指令

docker pull

的時候，docker daemon會擷取該檔案中的資訊，并将auth部分的資訊攜帶在請求的頭部向docker registry server發送請求，docker registry server對請求認證通過後，就可以開始拉取鏡像了。

那麼如何使kubernetes通過docker registry的認證來擷取鏡像呢？

Harbor與K8s的內建，一個核心概念是k8s的

secret

。作為kubernetes中一個重要的資源secret，它的設計初衷是為了解決容器在通路外部網絡或外部資源時驗證的問題，例如通路一個Git倉庫，連接配接一個資料庫，設定一些密碼配置等，需要額外驗證的場景Secret存儲了敏感資料,例如能允許容器接受請求的權限令牌。通過将Harbor的使用者資訊與K8s的Secret相關聯，即達成了兩者的內建。

步驟： 首先在Harbor中建立建立使用者，項目，将項目設定為私有，将建立的使用者加入到項目中，設定使用者的角色為開發者或者為項目管理者。確定該賬戶具有拉取該倉庫鏡像的權限。然後建立K8s下的Secret，其中secret中的使用者名、密碼和郵箱位址資訊為在Harbor中建立的使用者的資訊

使用Harbor私庫中的鏡像在K8s的Namespace中部署應用，指定鏡像下載下傳時使用上面建立的Secret如果隻需要能夠拉取Harbor的鏡像在K8s中部署應用，Harbor中的userD需要在項目中有最低權限的訪客成員角色。

imagePullSecret

在K8s中用來儲存鏡像倉庫的認證資訊，以友善Kubelet在啟動Pod時，能夠獲得鏡像倉庫的認證資訊，確定能Kubelet夠有權限從鏡像倉庫中下載下傳Pod所需的鏡像。

建立k8s中的ImagePull類型的Secret：https://kubernetes.io/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod

實踐

建立Secret：

# kubectl create secret docker-registry registry-secret \
	--namespace=kube-system \
	--docker-server=reg.harbor.com \
	--docker-username=admin \
	--docker-password=Harbor12345

# kubectl edit secret  registry-secret -n kube-system
           

引用Secret：

# vim coredns.yaml
  ....
  containers:
  - name: coredns
    image: reg.harbor.com/k8s/coredns:1.2.6
    imagePullPolicy: IfNotPresent
  ....
  imagePullSecrets:
  - name: registry-secret
           

再次啟動測試：

# kubectl apply -f coredns.yaml

# kubectl -n kube-system get pod                     
NAME                                    READY   STATUS    RESTARTS   AGE
coredns-cf4db5d8c-hfc7g                 1/1     Running   0          2m48s
           

Harbor提供了基于角色的通路控制機制，并通過項目來對鏡像進行組織和通路權限的控制。kubernetes中通過namespace來對資源進行隔離，在企業級應用場景中，通過将兩者進行結合可以有效将kubernetes使用的鏡像資源進行管理和通路控制，增強鏡像使用的安全性。尤其是在多租戶場景下，可以通過租戶、namespace和項目相結合的方式來實作對多租戶鏡像資源的管理和通路控制。

參考連結

https://www.kubernetes.org.cn/164.html

https://www.kubernetes.org.cn/1738.html