RaspberryPiでKubernetesを最初から完成させる

最近では、有名な会社が自社のラップトップラインをARMアーキテクチャに移行すると発表しました。このニュースを聞いて、私は思い出しました。AWSでEC2の価格をもう一度調べていると、非常においしい価格のGravitonsに気づきました。もちろん、キャッチはそれがARMだということでした。そのとき、ARMがかなり深刻であるとは思いもしませんでした...



私にとって、このアーキテクチャは常に多くのモバイルやその他のIoTのものでした。 ARMの「実際の」サーバーは、なんらかの形で珍しく、ある意味でワイルドです...しかし、新しい考えが頭に浮かんだので、ある週末、今日ARMで何を起動できるかを確認することにしました。そしてこのために、私は親愛なるもの、つまりKubernetesクラスターから始めることにしました。そして、いくつかの条件付きの「クラスター」だけでなく、すべてが「大人の方法で」行われるため、本番環境で見慣れているものと可能な限り同じになります。



私の考えによれば、クラスターはインターネットからアクセス可能であり、いくつかのWebアプリケーションがその中で実行され、少なくとも監視が行われている必要があります。このアイデアを実装するには、ペア（またはそれ以上）のRaspberryPiモデル3B以降が必要です。AWSも実験のプラットフォームになる可能性がありますが、私にとって興味深いのは「ラズベリー」でした（まだアイドル状態でした）。そこで、Ingress、Prometheus、Grafanaを搭載したKubernetesクラスターをデプロイします。

「ラズベリー」の準備

OSとSSHのインストール

インストールするOSの選択については、あまり気にしませんでした。公式Webサイトから最新のRaspberry Pi OSLiteを入手しただけです。インストールドキュメントもそこにあり、そこからのすべてのステップを将来のクラスターのすべてのノードで実行する必要があります。次に、次の操作を実行する必要があります（これもすべてのノードで）。



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

1. クラスタが機能するには、マスターに静的IPアドレスが必要であり、動作ノードに静的IPアドレスが必要です。セットアップを簡単にするために、どこでも静的アドレスを好みました。
2. 静的アドレスは、OSで構成するか（ファイルに/etc/dhcpcd.conf適切な例があります）、使用する（私の場合はホーム）ルーターのDHCPサーバーでリースを修正することで構成できます。
3. ssh-serverはraspi-configに含まれています（インターフェースオプション-> ssh）。

その後、SSH経由でログインし（デフォルトでは、ログインはpiで、パスワードはraspberry変更したものです）、設定を続行できます。

その他の設定

1. ホスト名を設定しましょう。私の例ではpi-control、とが使用されpi-workerます。
2. ファイルシステムがディスク全体に展開されていることを確認しましょう（df -h /）。必要に応じて、raspi-configを使用して拡張できます。
3. raspi-configでデフォルトのユーザーパスワードを変更します。
4. スワップファイルをオフにします（これはKubernetesの要件です。このトピックの詳細に興味がある場合は、問題番号53533を参照してください）。
   
   
   
   

   dphys-swapfile swapoff
   systemctl disable dphys-swapfile

5. パッケージを最新バージョンに更新しましょう。
   
   
   
   

   apt-get update && apt-get dist-upgrade -y

6. 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

7. 再起動するだけです。

これで、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のプラグインをインストールする必要があります。私はportmapプラグインを選択しました。これは私にとってなじみがあり明確です（完全なリストについてはドキュメントを参照してください）。

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

手元にあるラズベリーパイは2つしかなかったので、そのうちの1つをコントロールプレーンの下だけに配置したくありませんでした。そこで、次のコマンドを実行して、自動インストールされた汚染をpi-controlノードから削除しました。

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

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

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

必要最小限でクラスターを埋める

まず、Helmが必要です。もちろん、それがなくてもすべてを行うことができますが、Helmを使用すると、文字通りファイルを編集せずに、必要に応じていくつかのコンポーネントを構成できます。そして実際、それは「パンを要求しない」単なるバイナリファイルです。



したがって、docs / installセクションのhelm.shに移動し、そこからコマンドを実行します。

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

その後、チャートリポジトリを追加します。

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

それでは、次のアイデアに従ってインフラストラクチャコンポーネントをインストールしましょう。

• 入力コントローラー;
• プロメテウス;
• グラファナ;
• cert-manager。

入力コントローラー

最初のコンポーネントであるIngressコントローラーは、インストールが非常に簡単で、箱から出してすぐに使用できます。これを行うには、サイトのベアメタルセクションに移動し、そこからインストールコマンドを実行します。

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

プロメテウス

次の2つのコンポーネントは、チャートリポジトリからHelmを介してインストールするのはかなり簡単です。Prometheus



を見つけ、名前を作成してインストールします。

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（永続ボリューム）マニフェストは、記事の例を含むGitリポジトリ内のファイルprometheus-pv.yamlにマージされます。PVのためのディレクトリをしなければならないで作成された事前の例では：私たちはプロメテウスをバインドする先のノードのディスク上に、ホスト名がされて指定し、ディレクトリとされ、その上に作成されました。nodeAffinitypi-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

証明書を注文するには、cert-managerをインストールします。これをインストールするには、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

家庭で使用する自己署名証明書の場合、これで十分です。同じLet'sEncryptを受け取る必要がある場合は、別のクラスター発行者を構成する必要があります。詳細については、記事「Kubernetesのcert-managerを使用してLet'sEncryptからのSSL証明書」を参照してください。



私自身、ドキュメントの例のバリアントを決定し、ステージングLEバリアントで十分であると判断しました。例の電子メールを変更し、ファイルに保存して、クラスター（cert-manager-cluster-issuer.yaml）に追加します。

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

これで、たとえばGrafanaの証明書を注文できます。これには、ドメインとクラスターへの外部アクセスが必要になります。ドメインがあり、作成されたingress-controllerサービスに従って、ホームルーターのポート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に変換されます（ポートはランダムに生成されるため、異なるポートがあります）。



証明書の例（cert-manager-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'sEncryptの検証が行われます。

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"}

grafanaポート443が Ingressに追加されていること、および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アーキテクチャのアプリケーションを構築するには、少なくとも2つのオプションがあります。まず、ARMデバイス上に構築できます。しかし、2つのラズベリーパイの現在の処分を見て、私はそれらもアセンブリを生き残ることができないことに気づきました。そのため、新しいRaspberry Pi 4を注文しました（より強力で、4 GBのメモリが搭載されています）-その上に構築する予定です。



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

結論

実行された実験は私の期待をすべて上回りました。[少なくとも]必要なベースを備えた「バニラ」KubernetesはARMで快適であり、その構成では、わずか2、3のニュアンスが生じました。



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



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







。実験と「試す」ために、私の意見では、「ラズベリー」上のKubernetesクラスターは、クラスターのすべてのコンポーネントがインストールされて機能するため、同じMinikubeよりもはるかに優れた操作感覚を伝えます。 「大人の方法で。」



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



PSはい、「生産」は私が思っていたよりも近いかもしれません：

PPS

私たちのブログも読んでください：

• 「ホームKubernetesクラスターでの冒険。」