🥇Raspberry Pi でゼロから本格的な Kubernetes

つい最近、ある有名な企業がラップトップの製品ラインを ARM アーキテクチャに移行すると発表しました。このニュースを聞いて思い出したのですが、AWS の EC2 の価格を改めて見ていたら、Gravitons が非常に美味しそうな価格を付けていることに気づきました。もちろん、問題はそれが ARM だったということです。そのときは、ARM が非常に深刻であるとは思いもしませんでした...

私にとって、このアーキテクチャは常にモバイルやその他の IoT の分野でした。 ARM 上の「本物の」サーバーは、どういうわけか異常で、ある意味、ワイルドですらあります。しかし、新しい考えが頭に残ったので、ある週末、今日 ARM で何が実行できるのかを確認することにしました。このために、私は身近で大切なもの、つまり Kubernetes クラスターから始めることにしました。そして、ある種の従来の「クラスター」だけではなく、すべてが「大人の方法で」、本番環境で見慣れているものとできるだけ同じになるようにしています。

私の考えによれば、クラスターはインターネットからアクセス可能であり、その中で何らかの Web アプリケーションが実行されており、少なくとも監視が行われている必要があります。このアイデアを実装するには、少なくともモデル 3B+ の Raspberry Pi のペア (または複数) が必要です。 AWS は実験のプラットフォームになる可能性がありましたが、私は (まだ眠っていた)「ラズベリー」に興味がありました。そこで、Ingress、Prometheus、Grafana を含む Kubernetes クラスターをデプロイします。

「ラズベリー」の準備

OSとSSHのインストール

インストールする OS の選択にはあまり悩まず、最新の Raspberry Pi OS Lite をそのまま使用しました。公式サイト。そこで利用可能インストールドキュメント以降のすべてのアクションは、将来のクラスターのすべてのノードで実行する必要があります。次に、次の操作を (すべてのノードで) 実行する必要があります。

モニターとキーボードを接続したら、まずネットワークと SSH を構成する必要があります。

クラスターが動作するには、マスターには静的 IP アドレスが必要で、ワーカーノードには静的 IP アドレスが必要です。私はセットアップを容易にするために、全体的に静的アドレスを好みました。
静的アドレスはOS（ファイル内）で設定できます。 /etc/dhcpcd.conf 適切な例があります)、または使用されている (私の場合は自宅の) ルーターの DHCP サーバーでリースを固定することによっても可能です。
ssh-server は単に raspi-config に含まれています (インターフェースオプション → SSH).

この後、SSH 経由でログインできるようになります (デフォルトのログインは pi、パスワードは raspberry または変更したもの）を選択し、設定を続行します。

その他の設定

ホスト名を設定しましょう。私の例では、彼らは使用します pi-control и pi-worker.
ファイルシステムがディスク全体をカバーするように拡張されていることを確認してみましょう (df -h /）。必要に応じて、raspi-configを使用して拡張できます。
raspi-configでデフォルトのユーザーパスワードを変更しましょう。
スワップファイルをオフにしましょう (これは Kubernetes の要件です。このトピックの詳細に興味がある場合は、を参照してください) 問題番号#53533):
```
dphys-swapfile swapoff
systemctl disable dphys-swapfile
```
パッケージを最新バージョンに更新しましょう。
```
apt-get update && apt-get dist-upgrade -y
```

Docker と追加のパッケージをインストールしましょう。

apt-get install -y docker docker.io apt-transport-https curl bridge-utils iptables-persistent

インストール時 iptables-persistent ipv4 の iptables 設定をファイルに保存する必要があります。 /etc/iptables/rules.v4 - チェーンにルールを追加します FORWARDこのように：

# Generated by xtables-save v1.8.2 on Sun Jul 19 00:27:43 2020
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -s 10.1.0.0/16  -j ACCEPT
-A FORWARD -d 10.1.0.0/16  -j ACCEPT
COMMIT

あとは再起動するだけです。

これで、Kubernetes クラスターをインストールする準備ができました。

Kubernetesのインストール

この段階で、私は K8s クラスターのインストールと構成を自動化するために、私自身と私たちの会社の開発をすべて意図的に脇に置きました。代わりに、公式ドキュメントを使用しましょう kubernetes.io (コメントと略語でわずかに補足されています)。

Kubernetes リポジトリを追加しましょう。

curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
cat <<EOF | sudo tee /etc/apt/sources.list.d/kubernetes.list
deb https://apt.kubernetes.io/ kubernetes-xenial main
EOF
sudo apt-get update

さらにドキュメントでは、CRI (コンテナーランタイムインターフェイス) をインストールすることが推奨されています。 Docker はすでにインストールされているので、次に進んで主要コンポーネントをインストールしましょう。

sudo apt-get install -y kubelet kubeadm kubectl kubernetes-cni

主要コンポーネントをインストールするステップで、すぐに追加しました kubernetes-cni、これはクラスターが動作するために必要です。ここで重要な点があります。それはパッケージです。 kubernetes-cni 何らかの理由で、CNI インターフェイス設定用のデフォルトディレクトリが作成されないため、手動で作成する必要がありました。

mkdir -p /etc/cni/net.d

ネットワークバックエンドが機能するには (後述します)、CNI のプラグインをインストールする必要があります。使い慣れていて理解しやすいポートマッププラグインを選択しました (完全なリストについては、を参照してください。 ドキュメンテーション):

curl -sL https://github.com/containernetworking/plugins/releases/download/v0.7.5/cni-plugins-arm-v0.7.5.tgz | tar zxvf - -C /opt/cni/bin/ ./portmap

Kubernetesの構成

コントロールプレーンを備えたノード

クラスター自体のインストールは非常に簡単です。このプロセスを高速化し、Kubernetes イメージが利用可能であることを確認するには、まず次のコマンドを実行します。

kubeadm config images pull

次に、インストール自体を実行します。クラスターのコントロールプレーンを初期化します。

kubeadm init --pod-network-cidr=10.1.0.0/16 --service-cidr=10.2.0.0/16 --upload-certs

サービスとポッドのサブネットは、相互に、または既存のネットワークと重複しないように注意してください。

最後に、すべてが正常であることを示すメッセージが表示され、同時にワーカーノードをコントロールプレーンに接続する方法が示されます。

Your Kubernetes control-plane has initialized successfully!
To start using your cluster, you need to run the following as a regular user:
 mkdir -p $HOME/.kube
 sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
 sudo chown $(id -u):$(id -g) $HOME/.kube/config
You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
 https://kubernetes.io/docs/concepts/cluster-administration/addons/
You can now join any number of the control-plane node running the following command on each as root:
 kubeadm join 192.168.88.30:6443 --token a485vl.xjgvzzr2g0xbtbs4 
   --discovery-token-ca-cert-hash sha256:9da6b05aaa5364a9ec59adcc67b3988b9c1b94c15e81300560220acb1779b050 
   --contrl-plane --certificate-key 72a3c0a14c627d6d7fdade1f4c8d7a41b0fac31b1faf0d8fdf9678d74d7d2403
Please note that the certificate-key gives access to cluster sensitive data, keep it secret!
As a safeguard, uploaded-certs will be deleted in two hours; If necessary, you can use
"kubeadm init phase upload-certs --upload-certs" to reload certs afterward.
Then you can join any number of worker nodes by running the following on each as root:
kubeadm join 192.168.88.30:6443 --token a485vl.xjgvzzr2g0xbtbs4 
   --discovery-token-ca-cert-hash sha256:9da6b05aaa5364a9ec59adcc67b3988b9c1b94c15e81300560220acb1779b050

ユーザーの構成を追加するための推奨事項に従ってください。同時に、kubectl のオートコンプリートをすぐに追加することをお勧めします。

 kubectl completion bash > ~/.kube/completion.bash.inc
 printf "
 # Kubectl shell completion
 source '$HOME/.kube/completion.bash.inc'
 " >> $HOME/.bash_profile
 source $HOME/.bash_profile

この段階では、クラスター内の最初のノードがすでに表示されています (ただし、まだ準備ができていません)。

root@pi-control:~# kubectl get no
NAME         STATUS     ROLES    AGE   VERSION
pi-control   NotReady   master   29s   v1.18.6

ネットワーク設定

次に、インストール後のメッセージに記載されているように、ネットワークをクラスターにインストールする必要があります。ドキュメントでは、Calico、Cilium、contiv-vpp、Kube-router、Weave Net からの選択肢が提供されています...ここでは、公式の手順から逸脱し、私にとってより馴染みのあるわかりやすいオプションを選択しました。フランネル host-gw モード (利用可能なバックエンドの詳細については、を参照してください) プロジェクトのドキュメント).

クラスターへのインストールは非常に簡単です。まず、マニフェストをダウンロードします。

wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

次に、設定でタイプを変更します vxlan на host-gw:

sed -i 's/vxlan/host-gw/' kube-flannel.yml

...およびポッドのサブネット - デフォルト値からクラスターの初期化中に指定された値まで:

sed -i 's#10.244.0.0/16#10.1.0.0/16#' kube-flannel.yml

その後、リソースを作成します。

kubectl create -f kube-flannel.yml

準備ができて！しばらくすると、最初の K8s ノードが次のステータスに切り替わります。 Ready:

NAME         STATUS   ROLES    AGE   VERSION
pi-control   Ready    master   2m    v1.18.6

ワーカーノードの追加

これでワーカーを追加できるようになりました。これを行うには、上記のシナリオに従って Kubernetes 自体をインストールした後、以前に受け取ったコマンドを実行するだけです。

kubeadm join 192.168.88.30:6443 --token a485vl.xjgvzzr2g0xbtbs4 
    --discovery-token-ca-cert-hash sha256:9da6b05aaa5364a9ec59adcc67b3988b9c1b94c15e81300560220acb1779b050

この時点で、クラスターの準備ができていると想定できます。

root@pi-control:~# kubectl get no
NAME         STATUS   ROLES    AGE    VERSION
pi-control   Ready    master   28m    v1.18.6
pi-worker    Ready    <none>   2m8s   v1.18.6

手元に Raspberry Pi が XNUMX つしかなかったので、そのうちの XNUMX つをプレゼントしますのみコントロールプレーンの下に置きたくありませんでした。そこで、次のコマンドを実行して、自動的にインストールされたテイントを pi-control ノードから削除しました。

root@pi-control:~# kubectl edit node pi-control

...そして行を削除します。

 - effect: NoSchedule
   key: node-role.kubernetes.io/master

クラスタに必要最小限のものを埋め込む

まず第一に必要なのは ヘルメット。もちろん、Helm を使用しなくてもすべての操作を実行できますが、Helm を使用すると、ファイルを編集せずに文字通り一部のコンポーネントを自由裁量でカスタマイズできます。そして実際、これは「パンを要求しない」単なるバイナリファイルです。

それでは、行きましょうヘルム.sh docs/installation セクションに移動し、そこからコマンドを実行します。

curl -s https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bash

その後、グラフリポジトリを追加します。

helm repo add stable https://kubernetes-charts.storage.googleapis.com/

次に、計画どおりにインフラストラクチャコンポーネントをインストールしましょう。

イングレスコントローラー。
プロメテウス。
グラファナ。
証明書マネージャー。

イングレスコントローラー

最初のコンポーネントは イングレスコントローラー - インストールは非常に簡単で、箱から出してすぐに使用できます。これを行うには、次の場所にアクセスしてくださいサイトのベアメタルセクションそこからインストールコマンドを実行します。

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v0.34.1/deploy/static/provider/baremetal/deploy.yaml

ただし、この時点で「ラズベリー」に負担がかかり始め、ディスク IOPS に達しました。実際には、Ingress コントローラーとともに多数のリソースがインストールされ、API に対する多くのリクエストが行われ、それに応じて大量のデータが etcd に書き込まれます。一般に、クラス 10 のメモリカードはあまり生産性がないか、SD カードでは基本的にそのような負荷には十分ではありません。ただし、約 5 分後にすべてが起動しました。

名前空間が作成され、コントローラーとそれに必要なものがすべてその中に表示されました。

root@pi-control:~# kubectl -n ingress-nginx get pod
NAME                                        READY   STATUS      RESTARTS   AGE
ingress-nginx-admission-create-2hwdx        0/1     Completed   0          31s
ingress-nginx-admission-patch-cp55c         0/1     Completed   0          31s
ingress-nginx-controller-7fd7d8df56-68qp5   1/1     Running     0          48s

プロメテウス

次の XNUMX つのコンポーネントは、チャートリポジトリから Helm を介して非常に簡単にインストールできます。

我々は気づく プロメテウス、名前空間を作成し、次のように設定します。

helm search repo stable | grep prometheus
kubectl create ns monitoring
helm install prometheus --namespace monitoring stable/prometheus --set server.ingress.enabled=True --set server.ingress.hosts={"prometheus.home.pi"}

デフォルトでは、Prometheus は Prometheus データ自体と AlertManager データ用の 2 つのディスクを注文します。クラスター内にストレージクラスが作成されていないため、ディスクは注文されず、ポッドは起動しません。ベアメタル Kubernetes インストールの場合、通常は Ceph rbd を使用しますが、Raspberry Pi の場合、これは明らかに過剰です。

したがって、ホストパス上に単純なローカルストレージを作成しましょう。 prometheus-server と prometheus-alertmanager の PV (永続ボリューム) マニフェストが XNUMX つのファイルに結合されています prometheus-pv.yaml в 記事の例を含む Git リポジトリ。 PV用のディレクトリは必須です あらかじめ Prometheus をバインドしたいノードのディスク上に作成します。例では次のように記述されています。 nodeAffinity ホスト名で pi-worker そしてその上にディレクトリが作成されます /data/localstorage/prometheus-server и /data/localstorage/prometheus-alertmanager.

マニフェストをダウンロード (クローン作成) し、Kubernetes に追加します。

kubectl create -f prometheus-pv.yaml

この段階で初めて ARM アーキテクチャの問題に遭遇しました。 Prometheus チャートにデフォルトでインストールされる Kube-state-metrics が起動を拒否しました。エラーが発生しました:

root@pi-control:~# kubectl -n monitoring logs prometheus-kube-state-metrics-c65b87574-l66d8
standard_init_linux.go:207: exec user process caused "exec format error"

実際、kube-state-metrics は ARM 用にコンパイルされていない CoreOS プロジェクトのイメージを使用しています。

kubectl -n monitoring get deployments.apps prometheus-kube-state-metrics -o=jsonpath={.spec.template.spec.containers[].image}
quay.io/coreos/kube-state-metrics:v1.9.7

ちょっとグーグルで検索して、たとえば次のようなものを見つける必要がありました。この画像。これを使用するには、リリースを更新して、kube-state-metrics にどのイメージを使用するかを指定しましょう。

helm upgrade prometheus --namespace monitoring stable/prometheus --set server.ingress.enabled=True --set server.ingress.hosts={"prometheus.home.pi"} --set kube-state-metrics.image.repository=carlosedp/kube-state-metrics --set kube-state-metrics.image.tag=v1.9.6

すべてが開始されたことを確認してみましょう。

root@pi-control:~# kubectl -n monitoring get po
NAME                                             READY   STATUS              RESTARTS   AGE
prometheus-alertmanager-df65d99d4-6d27g          2/2     Running             0          5m56s
prometheus-kube-state-metrics-5dc5fd89c6-ztmqr   1/1     Running             0          5m56s
prometheus-node-exporter-49zll                   1/1     Running             0          5m51s
prometheus-node-exporter-vwl44                   1/1     Running             0          4m20s
prometheus-pushgateway-c547cfc87-k28qx           1/1     Running             0          5m56s
prometheus-server-85666fd794-z9qnc               2/2     Running             0          4m52s

Grafana と証明書マネージャー

チャートとダッシュボードについては、 グラファナ:

helm install grafana --namespace monitoring stable/grafana  --set ingress.enabled=true --set ingress.hosts={"grafana.home.pi"}

出力の最後に、アクセスパスワードを取得する方法が表示されます。

kubectl get secret --namespace monitoring grafana -o jsonpath="{.data.admin-password}" | base64 --decode ; echo

証明書を注文するにはインストールします 証明書マネージャー。インストールするには、以下を参照してください。ドキュメンテーション、Helm に対応するコマンドが提供されます。

helm repo add jetstack https://charts.jetstack.io

helm install 
  cert-manager jetstack/cert-manager 
  --namespace cert-manager 
  --version v0.16.0 
  --set installCRDs=true

家庭で使用する自己署名証明書の場合は、これで十分です。同じものを取得する必要がある場合 暗号化しようの場合は、クラスター発行者も構成する必要があります。これについての詳細は、記事「Kubernetes の cert-manager を使用した Let's Encrypt からの SSL 証明書'。

私自身はからのオプションに落ち着きましたドキュメントの例、LE のステージングオプションで十分であると判断しました。この例では電子メールを変更し、ファイルに保存してクラスターに追加します (証明書マネージャークラスター発行者.yaml):

kubectl create -f cert-manager-cluster-issuer.yaml

これで、たとえば Grafana の証明書を注文できるようになりました。これには、ドメインと外部からクラスターへのアクセスが必要です。私はドメインを持っており、作成したイングレスコントローラーサービスに従ってホームルーターのポート 80 と 443 を転送することでトラフィックを構成しました。

kubectl -n ingress-nginx get svc
NAME                                 TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)                      AGE
ingress-nginx-controller             NodePort    10.2.206.61    <none>        80:31303/TCP,443:30498/TCP   23d

この場合、ポート 80 は 31303 に変換され、ポート 443 は 30498 に変換されます。 (ポートはランダムに生成されるため、実際のものとは異なります。)

証明書の例を次に示します (証明書マネージャー-grafana-certificate.yaml):

apiVersion: cert-manager.io/v1alpha2
kind: Certificate
metadata:
  name: grafana
  namespace: monitoring
spec:
  dnsNames:
    - grafana.home.pi
  secretName: grafana-tls
  issuerRef:
    kind: ClusterIssuer
    name: letsencrypt-staging

それをクラスターに追加します。

kubectl create -f cert-manager-grafana-certificate.yaml

この後、Ingress リソースが表示され、それを通じて Let's Encrypt 検証が行われます。

root@pi-control:~# kubectl -n monitoring get ing
NAME                        CLASS    HOSTS                        ADDRESS         PORTS   AGE
cm-acme-http-solver-rkf8l   <none>   grafana.home.pi      192.168.88.31   80      72s
grafana                     <none>   grafana.home.pi      192.168.88.31   80      6d17h
prometheus-server           <none>   prometheus.home.pi   192.168.88.31   80      8d

検証に合格すると、リソースが certificate 準備はできています、そして上記の秘密で grafana-tls - 証明書とキー。証明書の発行者をすぐに確認できます。

root@pi-control:~# kubectl -n monitoring get certificate
NAME      READY   SECRET        AGE
grafana   True    grafana-tls   13m

root@pi-control:~# kubectl -n monitoring get secrets grafana-tls -ojsonpath="{.data['tls.crt']}" | base64 -d | openssl x509 -issuer -noout
issuer=CN = Fake LE Intermediate X1

グラファナに戻りましょう。生成された証明書と一致するように TLS の設定を変更することで、Helm リリースを若干修正する必要があります。

これを行うには、チャートをダウンロードし、ローカルディレクトリから編集して更新します。

helm pull --untar stable/grafana

ファイル内で編集する grafana/values.yaml TLSパラメータ:

  tls:
    - secretName: grafana-tls
      hosts:
        - grafana.home.pi

ここで、インストールされた Prometheus をすぐに次のように構成できます。 datasource:

datasources:
  datasources.yaml:
    apiVersion: 1
    datasources:
    - name: Prometheus
      type: prometheus
      url: http://prometheus-server:80
      access: proxy
      isDefault: true

次に、ローカルディレクトリから Grafana チャートを更新します。

helm upgrade grafana --namespace monitoring ./grafana  --set ingress.enabled=true --set ingress.hosts={"grafana.home.pi"}

Ingress の内容を確認する grafana ポート 443 が追加され、HTTPS 経由でアクセスできるようになりました。

root@pi-control:~# kubectl -n monitoring get ing grafana
NAME      CLASS    HOSTS                     ADDRESS         PORTS     AGE
grafana   <none>   grafana.home.pi           192.168.88.31   80, 443   63m

root@pi-control:~# curl -kI https://grafana.home.pi
HTTP/2 302
server: nginx/1.19.1
date: Tue, 28 Jul 2020 19:01:31 GMT
content-type: text/html; charset=utf-8
cache-control: no-cache
expires: -1
location: /login
pragma: no-cache
set-cookie: redirect_to=%2F; Path=/; HttpOnly; SameSite=Lax
x-frame-options: deny
strict-transport-security: max-age=15724800; includeSubDomains

Grafana の動作をデモンストレーションするには、ダウンロードして追加できます。 kube-state-metrics のダッシュボード。これは次のようになります。

また、ノードエクスポーター用のダッシュボードを追加することをお勧めします。ダッシュボードには、「ラズベリー」で何が起こっているか (CPU 負荷、メモリ、ネットワーク、ディスク使用量など) が詳細に表示されます。

この後、私はこう思います クラスターはアプリケーションを受け入れて実行する準備ができています。

組み立て上の注意

ARM アーキテクチャ用のアプリケーションを構築するには、少なくとも 4 つのオプションがあります。まず、ARM デバイス上に構築できます。しかし、現在の 4 台の Raspberry Pi の処分状況を見て、これらも組み立てに耐えられないことに気づきました。したがって、私は新しい Raspberry Pi XNUMX (より強力で XNUMX GB ものメモリを搭載) を注文しました。これをベースに構築する予定です。

XNUMX 番目のオプションは、より強力なマシン上にマルチアーキテクチャ Docker イメージを構築することです。このためには、 docker buildx 拡張機能。アプリケーションがコンパイル済み言語である場合、ARM のクロスコンパイルが必要になります。このパスのすべての設定については説明しません。これには別の記事が必要になります。このアプローチを実装すると、「ユニバーサル」イメージを実現できます。ARM マシン上で実行される Docker 自体が、アーキテクチャに対応するイメージを自動的にダウンロードします。

まとめ

実験は私の期待をすべて上回りました。[少なくとも] 必要なベースを備えた「バニラ」Kubernetes は ARM 上で快適に動作し、その構成で生じた微妙な違いはほんの XNUMX つだけでした。

Raspberry Pi 3B+ 自体は CPU に負荷をかけ続けますが、SD カードが明らかなボトルネックになっています。同僚は、一部のバージョンでは SSD を接続できる USB から起動できると提案しました。そうすれば、おそらく状況は改善されるでしょう。

Grafana をインストールするときの CPU 負荷の例を次に示します。

実験や「試してみる」場合、私の意見では、「ラズベリー」上の Kubernetes クラスターは、同じ Minikube よりも操作感がはるかに優れています。これは、クラスターのすべてのコンポーネントがインストールされ、「大人のように」動作するためです。

将来的には、Raspberry Pi 上で完全に実装される CI/CD サイクル全体をクラスターに追加するというアイデアがあります。また、誰かが AWS Gravitons での K8 のセットアップの経験を共有してくれたら嬉しいです。

PS はい、「本番」は私が思っていたよりも近いかもしれません。

PPS

私たちのブログもお読みください:

«ホーム Kubernetes クラスターの冒険'。

出所： habr.com

Raspberry Pi で Kubernetes をゼロから完成させる