怎么使用k3s+樹莓派在生產中構建輕量K8S裸機集群

怎么使用k3s+樹莓派在生產中構建輕量K8S裸機集群，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

Boogie Software是歐洲著名的金融科技公司，多年來致力于為銀行提供Fintech、AI、大數據高性能后端、移動應用程序、數據分析及UX等創新服務，幫助銀行推動數字化轉型。憑借過去十多年在該領域的獨特經驗，Boogie已成為數字銀行服務提供商中的領導者。

Boogie Software的IT團隊在很多客戶銀行的核心銀行業務數字化的項目中使用到了Kubernetes和容器技術，因此我們始終在想Kubernetes能如何使用更合適的硬件在本地工作。在本文中，我將詳細介紹我們如何在樹莓派上構建輕量級裸機集群，以在公司網絡中運行應用程序和服務。

我們之所以這么做，有兩個原因：第一，通過建立集群，我們將可以擁有一個平臺，來可靠、靈活地運行公司網絡內部應用程序和服務；第二，我們可以通過這次機會學習更多關于Kubernetes、微服務以及容器的技能。如果你也想要參照我們的經驗來構建一個相似的系統，我建議你至少要了解關于Docker容器、Kubernetes關鍵概念（節點、pod、服務、deployment等）以及IP網絡的基礎知識。

硬件準備

你需要準備以下設備：

• 樹莓派2B/3B/3B+ 的型號，至少一個。你甚至在單個開發板上運行某些應用程序，但是建議使用兩個或更多的開發板來分散負載并增加冗余。

• 電源和可用于樹莓派的SD卡，現有的以太網交換機或空閑端口以及一些電纜。

在我們的設置中，我們目前有4個樹莓派3代B+開發板，所以在集群中有一個master/server和3個代理節點。如果樹莓派有外殼當然更好，我們的同事用3d打印機設計了一個。此外，機殼的背面有兩個用于冷卻的風扇，每個開發板都位于一個托盤上，該托盤可以熱插拔以進行維護。這些托盤前面還設有activity/heartbeat LED和電源開關的位置，它們都連接到開發板的GPIO接頭。

軟件準備

對于Kubernetes的實現，我們使用的是k3s。k3s是由Rancher Labs推出的一款輕量級、通過CNCF一致性認證的Kubernetes發行版。盡管這是一款剛推出不久的產品，但它真的十分穩定和易用，可以實現秒級啟動。讓k3s從其他輕量的Kubernetes發行版脫穎而出的原因是，k3s可供生產使用，而諸如microk8s或Minikube之類的項目則無法實現這一目的，并且k3s十分輕巧，還可以在基于ARM的硬件上很好地運行。在k3s中，任何設備上安裝Kubernetes所需的一切都包含在這一個40MB的二進制文件當中。

k3s幾乎能在任何Linux發行版中很好地運行，因此我們決定將Raspbian Stretch Lite作為基礎OS，因為我們不需要在開發板上添加任何額外的服務或者桌面UI。k3s確實需要在Linux內核中啟用cgroup，這可以在Raspbian上通過向/boot/cmdline.txt:添加以下參數來實現：

cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory

安裝k3s

k3s非常友好的地方在于，它可以實現平滑安裝過程。你準備好你的server硬件之后，僅需幾分鐘就可以完成設置，因為它僅需一行命令就能安裝server（主節點）：

curl -sfL https://get.k3s.io | sh -

代理節點也是如此：

curl -sfL https://get.k3s.io | K3S_TOKEN=<token_from_server> K3S_URL=https://<server_ip>:6443 sh -

其中token_from_server是來自服務器的文件/ var / lib / rancher / k3s / server / node-token的內容，server_ip是服務器節點的IP地址。至此，我們的集群已經啟動并正在運行，我們可以開始部署工作負載：

root@k3s-server:~# kubectl get nodes
NAME         STATUS   ROLES    AGE    VERSION
k3s-node1    Ready    <none>   40s    v1.13.4-k3s.1
k3s-server   Ready    <none>   108s   v1.13.4-k3s.1

為了管理和監控集群，我們安裝了Kubernetes Dashboard，它能夠提供給非常方便的web界面來查看整個系統的狀態、執行管理員操作并訪問日志。同時，本地安裝和運行kubectl命令也非常有幫助，因為它可以讓你從自己的計算機管理集群，而無需ssh進入集群。為此，你只需要安裝kubectl，然后將集群信息從服務器節點config /etc/rancher/k3s/k3s.yaml復制到本地kubeconfig文件中（通常是${HOME}/.kube/config）。

使用負載均衡器暴露服務

默認情況下，部署在Kubernetes集群上的應用程序僅可以在集群中獲取（默認服務類型是ClusterIP）。如果想要從集群外部獲取應用程序，有兩個選項。你可以使用NodePort類型配置服務，該服務在靜態端口的每個節點IP上暴露服務，你也可以使用負載均衡器（服務類型LoadBalancer）。然而，NodePort服務有限制：它們使用自己專用的端口范圍，我們只能通過端口號來區分應用。k3s內置了一個簡單的負載均衡器，但由于它使用的是節點的IP地址，我們可能很快就會用完IP/端口組合并且無法將服務綁定到某個虛擬IP。基于這些原因，我們決定部署MetalLB——一種用于裸機集群的負載均衡器實現。

只需應用YAML manifest即可安裝MetalLB。在現有網絡中運行MetalLB的最簡單方法是使用所謂的第2層模式，這意味著集群節點通過ARP協議宣布本地網絡中服務的虛擬IP。為此，我們從內部網絡保留了一小部分IP地址用于集群服務。MetalLB的配置如下所示：

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    address-pools:
    - name: company-office
      protocol: layer2
      addresses:
      - 10.10.10.50-10.10.10.99

使用此配置，集群服務將被暴露在范圍為10.10.10.50—10.10.10.99的地址中。為了綁定服務到指定的IP，你可以在服務清單中使用loadBalancerIP參數：

apiVersion: v1
kind: Service
metadata:
  name: my-web-app
spec:
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 8080
  loadBalancerIP: 10.10.10.51
  selector:
    app: my-web-app
  type: LoadBalancer

在負載均衡中，我們面臨諸多挑戰。例如，Kubernetes中限制在單個負載均衡器中同時使用TCP和UDP端口。要解決這一問題，你可以定義兩個服務實例，一個用于TCP端口，另一個用于UDP端口。其缺點是，除非啟用IP地址共享，否則你需要在不同的IP地址中運行這兩個服務。而且，由于MetalLB是一個年輕項目，因此也存在一些小問題，但我們相信這些很快都會得到解決。

添加存儲

k3s暫時沒有內置的存儲解決方案，所以為了使Pod能夠訪問持久性文件存儲，我們需要使用Kubernetes的插件來創建一個。由于Kubernetes的目標之一是使應用程序與基礎架構解耦并使其可移植，因此Kubernetes中用PersistentVolume（PV）和PersistentVolumeClaim（PVC）的概念定義了用于存儲的抽象層。詳細的概念解釋可以參照我們之前發過的文章：詳解Kubernetes存儲關鍵概念。PV是通常由管理員配置并可供應用程序使用的存儲資源。另一方面，PVC描述了應用程序對某種類型和一定數量的存儲的需求。創建PVC（通常作為應用程序的一部分）時，如果有一個尚未使用且滿足應用程序PVC要求的可用PVC，它將綁定到PV。配置和維護所有這些需要手動工作，因此動態配置卷應運而生。

在我們的基礎架構中，我們已經有一個現有的NFS服務器，因此我們決定將其用于集群持久性文件存儲。在我們的案例中，最簡單的方法是使用支持動態配置PV的NFS-Client Provisioner。Provisioner只需在現有的NFS共享上為每個新PV（集群映射到PVC）上創建新目錄，然后將PV目錄掛載在使用它的容器中。這樣就無需配置NFS共享到單個pod中的卷，而是全部動態運行。

為ARM交叉構建容器鏡像

顯然，在基于ARM的硬件上（如樹莓派）運行應用程序容器時，需要根據ARM的架構構建容器。在ARM架構容器中構建自己的應用程序時，可能會遇到一些陷阱。首先，基礎鏡像需要可用于你的目標架構體系。對于樹莓派3來說，通常需要使用arm32v7的基礎鏡像，它們可以在大部分Docker鏡像倉庫中被調用。所以，當交叉構建應用程序時，確保你的Dockerfile包含以下代碼：

FROM arm32v7/alpine:latest

第二件需要注意的事是，你的主機Docker需要能夠運行ARM二進制文件。如果你在mac上運行Docker，那操作將十分輕松，因為它對此有內置支持。如果是在Linux上，你需要執行一些步驟：

添加QEMU二進制文件到你的基礎鏡像

為了在Linux上的Docker中運行ARM二進制文件，鏡像需要一個QEMU二進制文件。你可以選擇一個已經包含了QEMU二進制文件的基礎鏡像，也可以在鏡像構建過程中復制

qemu-arm-static二進制文件到其中，例如，通過將以下行添加到你的Dockerfile中：

COPY --from=biarms/qemu-bin /usr/bin/qemu-arm-static /usr/bin/qemu-arm-static

安全警示：請注意下載和運行未知的容器就如同下載和運行位置的.exe文件。除業余項目外，其他任何項目都應使用掃描/審核過的鏡像（如Docker官方鏡像）或來自信任的組織和公司的容器鏡像。

然后，你需要在創建Docker鏡像的主機OS上注冊QEMU。這可以簡單地通過以下方式實現：

docker run --rm --privileged multiarch/qemu-user-static:register --reset

可以在構建實際鏡像之前將該命令添加到你的構建腳本中。總結一下，你的Dockerfile.arm應該看起來像這樣：

FROM arm32v7/alpine:latest
COPY --from=biarms/qemu-bin /usr/bin/qemu-arm-static /usr/bin/qemu-arm-static
# commands to build your app go here…
# e.g. RUN apk add --update <pkgs that you need…>

并且你的build /CI腳本應該是：

docker run --rm --privileged multiarch/qemu-user-static:register --reset
docker build -t my-custom-image-arm . -f Dockerfile.arm

這將為你提供ARM架構的容器鏡像。如果你對細節很感興趣，請參閱：

https://www.ecliptik.com/Cross-Building-and-Running-Multi-Arch-Docker-Images/

自動化構建和上傳到鏡像倉庫

最后一步是自動化整個流程，以便容器鏡像可以自動構建并且自動上傳到一個鏡像倉庫，在那里可以輕松地將其部署到我們地k3s集群。在內部，我們使用GitLab進行源代碼管理和CI/CD，因此我們自然希望在其中運行這些構建，它甚至包括一個內置的容器鏡像倉庫，因此不需要設置單獨的鏡像倉庫。

關于構建Docker鏡像，GitLab有十分完善的文檔（https://docs.gitlab.com/ee/ci/docker/using_docker_build.html ） ，因此我們不在此贅述。在為docker構建配置GitLab Runner之后，剩下要做的就是為該項目創建.gitlab-ci.yml文件。在我們的例子中，它看起來像這樣：

image: docker:stable

stages:
  - build
  - release
 
variables:
  DOCKER_DRIVER: overlay2
  CONTAINER_TEST_IMAGE: ${CI_REGISTRY_IMAGE}/${CI_PROJECT_NAME}-arm:${CI_COMMIT_REF_SLUG}
  CONTAINER_RELEASE_IMAGE: ${CI_REGISTRY_IMAGE}/${CI_PROJECT_NAME}-arm:latest
 
before_script:
- docker info
- docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY
 
build_image:
  stage: build
  script:
    - docker pull $CONTAINER_RELEASE_IMAGE || true
    - docker run --rm --privileged multiarch/qemu-user-static:register --reset
    - docker build --cache-from $CONTAINER_RELEASE_IMAGE -t $CONTAINER_TEST_IMAGE . -f Dockerfile.arm
    - docker push $CONTAINER_TEST_IMAGE
 
release:
  stage: release
  script:
    - docker pull $CONTAINER_TEST_IMAGE
    - docker tag $CONTAINER_TEST_IMAGE $CONTAINER_RELEASE_IMAGE
    - docker push $CONTAINER_RELEASE_IMAGE

既然在容器鏡像倉庫中我們有了我們的鏡像，我們只需要將它們部署到我們的集群中。為了授予集群訪問鏡像倉庫的權限，我們在GitLab中創建了一個deploy令牌，然后將令牌憑據作為docker-registry 密鑰添加到集群中：

kubectl create secret docker-registry deploycred --docker-server=<your-registry-server> --docker-username=<token-username> --docker-password=<token-password> --docker-email=<your-email>

之后，可以在YAML文件PodSpec中使用deploy 令牌密鑰：

imagePullSecrets:
      - name: deploycred
     containers:
      - name: myapp
        image: gitlab.mycompany.com:4567/my/project/my-app-arm:latest

完成所有這些步驟之后，我們終于擁有了一個從私有鏡像倉庫中的源代碼到ARM容器鏡像的自動CI / CD流水線，可以將其部署到集群中。

總而言之，事實證明，建立和運行自己的裸機Kubernetes集群比預期的要容易。而且k3s確實是在邊緣計算場景中和一般配置較低的硬件上運行容器化服務的明智選擇。

一個小缺點是k3s尚不支持高可用（多主設備配置）。盡管單個主服務器設置已經具有相當的彈性，因為即使主服務器離線，服務仍可在代理節點上繼續運行，我們還是希望為主節點提供一些冗余。顯然，此功能正在開發中，但在此功能可用之前，我們建議從服務器節點配置中進行備份。

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業資訊頻道，感謝您對億速云的支持。