|
| 1 | +--- |
| 2 | +layout: blog |
| 3 | +title: "DIY: Kubernetesで自分だけのクラウドを構築しよう(パート1)" |
| 4 | +slug: diy-create-your-own-cloud-with-kubernetes-part-1 |
| 5 | +date: 2024-04-05T07:30:00+00:00 |
| 6 | +--- |
| 7 | + |
| 8 | +**著者:** Andrei Kvapil (Ænix) |
| 9 | + |
| 10 | +**翻訳者:** [Taisuke Okamoto](https://github.com/b1gb4by) (IDC Frontier Inc), [Junya Okabe](https://github.com/Okabe-Junya) (University of Tsukuba) |
| 11 | + |
| 12 | +Ænixでは、Kubernetesに対する深い愛着があり、近いうちにすべての最新テクノロジーがKubernetesの驚くべきパターンを活用し始めることを夢見ています。 |
| 13 | +自分だけのクラウドを構築することを考えたことはありませんか？きっと考えたことがあるでしょう。 |
| 14 | +しかし、快適なKubernetesエコシステムを離れることなく、最新のテクノロジーとアプローチのみを使ってそれを実現することは可能でしょうか？ |
| 15 | +Cozystackの開発における私たちの経験は、その点を深く掘り下げる必要がありました。 |
| 16 | +自分だけのクラウドを構築することを考えたことはありませんか？ |
| 17 | + |
| 18 | +Kubernetesはこの目的のために設計されたものではなく、ベアメタルサーバー用にOpenStackを使用し、意図したとおりにその内部でKubernetesを実行すればよいのではないかと主張する人もいるかもしれません。 |
| 19 | +しかし、そうすることで、単に責任があなたの手からOpenStack管理者の手に移っただけです。 |
| 20 | +これにより、少なくとも1つの巨大で複雑なシステムがエコシステムに追加されることになります。 |
| 21 | + |
| 22 | +なぜ物事を複雑にするのでしょうか？ |
| 23 | +結局のところ、Kubernetesにはテナント用のKubernetesクラスターを実行するために必要なものがすべて揃っています。 |
| 24 | + |
| 25 | +Kubernetesをベースにしたクラウドプラットフォームの開発における私たちの経験を共有したいと思います。 |
| 26 | +私たち自身が使用しており、あなたの注目に値すると信じているオープンソースプロジェクトを紹介します。 |
| 27 | + |
| 28 | +この一連の記事では、オープンソースのテクノロジーのみを使用して、ベアメタルから管理されたKubernetesを準備する方法についての私たちの物語をお伝えします。 |
| 29 | +データセンターの準備、仮想マシンの実行、ネットワークの分離、フォールトトレラントなストレージのセットアップといった基本的なレベルから、動的なボリュームのプロビジョニング、ロードバランサー、オートスケーリングを備えた本格的なKubernetesクラスターのプロビジョニングまでを扱います。 |
| 30 | + |
| 31 | +この記事から、いくつかのパートで構成されるシリーズを開始します: |
| 32 | + |
| 33 | +- **パート1**: 自分のクラウドの基礎を準備する。ベアメタル上でのKubernetesの準備と運用における課題、およびインフラストラクチャをプロビジョニングするための既成のレシピ。 |
| 34 | +- **パート2**: ネットワーク、ストレージ、仮想化。Kubernetesを仮想マシン起動のためのツールにする方法とそのために必要なもの。 |
| 35 | +- **パート3**: Cluster APIと、ボタンを押すだけでKubernetesクラスターのプロビジョニングを開始する方法。オートスケーリング、ボリュームの動的プロビジョニング、ロードバランサーの仕組み。 |
| 36 | + |
| 37 | +さまざまなテクノロジーをできるだけ独立して説明しようと思いますが、同時に、私たちの経験と、なぜある解決策に至ったのかを共有します。 |
| 38 | + |
| 39 | +まず、Kubernetesの主な利点と、それがクラウドリソースの使用へのアプローチをどのように変えたかを理解しましょう。 |
| 40 | + |
| 41 | +クラウドとベアメタルでは、Kubernetesの使い方が異なることを理解することが重要です。 |
| 42 | + |
| 43 | +## クラウド上のKubernetes |
| 44 | + |
| 45 | +クラウド上でKubernetesを運用する場合、永続ボリューム、クラウドロードバランサー、ノードのプロビジョニングプロセスを気にする必要はありません。 |
| 46 | +これらはすべて、Kubernetesオブジェクトの形式であなたのリクエストを受け入れるクラウドプロバイダーによって処理されます。 |
| 47 | +つまり、サーバー側は完全にあなたから隠されており、クラウドプロバイダーがどのように正確に実装しているかを知る必要はありません。 |
| 48 | +それはあなたの責任範囲ではないからです。 |
| 49 | + |
| 50 | +{{< figure src="cloud.svg" alt="クラウド上のKubernetesを示す図。ロードバランシングとストレージはクラスターの外部で行われています" caption="クラウド上のKubernetesを示す図。ロードバランシングとストレージはクラスターの外部で行われています" >}} |
| 51 | + |
| 52 | +Kubernetesは、どこでも同じように機能する便利な抽象化を提供しているため、あらゆるクラウドのKubernetes上にアプリケーションをデプロイできます。 |
| 53 | + |
| 54 | +クラウドでは、Kubernetesコントロールプレーン、仮想マシン、永続ボリューム、ロードバランサーなど、いくつかの個別のエンティティを持つことが非常に一般的です。 |
| 55 | +これらのエンティティを使用することで、高度に動的な環境を作成できます。 |
| 56 | + |
| 57 | +Kubernetesのおかげで、仮想マシンは今やクラウドリソースを利用するための単なるユーティリティエンティティとしてのみ見られるようになりました。 |
| 58 | +もはや仮想マシンの中にデータを保存することはありません。 |
| 59 | +仮想マシンをすべて削除して、アプリケーションを壊すことなく再作成できます。 |
| 60 | +Kubernetesコントロールプレーンは、クラスター内で何が実行されるべきかについての情報を保持し続けます。 |
| 61 | +ロードバランサーは、新しいノードにトラフィックを送信するためにエンドポイントを変更するだけで、ワークロードにトラフィックを送信し続けます。 |
| 62 | +そして、データはクラウドが提供する外部の永続ボリュームに安全に保存されます。 |
| 63 | + |
| 64 | +このアプローチは、クラウドでKubernetesを使用する際の基本です。 |
| 65 | +その理由はかなり明白です。 |
| 66 | +システムが単純であるほど安定性が高くなり、このシンプルさのためにクラウドでKubernetesを選択するのです。 |
| 67 | + |
| 68 | +## ベアメタル上のKubernetes |
| 69 | + |
| 70 | +クラウドでKubernetesを使用することは本当に簡単で便利ですが、ベアメタルへのインストールについては同じことが言えません。 |
| 71 | +ベアメタルの世界では、Kubernetesは逆に非常に複雑になります。 |
| 72 | +まず、ネットワーク全体、バックエンドストレージ、クラウドバランサーなどは、通常、クラスターの外部ではなく内部で実行されるためです。 |
| 73 | +その結果、このようなシステムは更新と保守がはるかに難しくなります。 |
| 74 | + |
| 75 | +{{< figure src="baremetal.svg" alt="ベアメタル上のKubernetesを示す図。ロードバランシングとストレージはクラスターの内部で行われています" caption="ベアメタル上のKubernetesを示す図。ロードバランシングとストレージはクラスターの内部で行われています" >}} |
| 76 | + |
| 77 | +ご自身で判断してみてください。 |
| 78 | +クラウドでは、通常、ノードを更新するために仮想マシンを削除する(または`kubectl delete node`を使用する)だけで、イミュータブルなイメージに基づいて新しいノードを作成することをノード管理ツールに任せることができます。 |
| 79 | +新しいノードはクラスターに参加し、Kubernetesの世界で非常にシンプルでよく使われるパターンに従って、ノードとして「そのまま動作」します。 |
| 80 | +多くのクラスターでは、安価なスポットインスタンスを利用できるため、数分ごとに新しい仮想マシンをオーダーしています。 |
| 81 | +しかし、物理サーバーを使用している場合は、簡単に削除して再作成することはできません。 |
| 82 | +まず、物理サーバーはクラスターサービスを実行していたり、データを保存していたりすることが多いため、その更新プロセスははるかに複雑になるからです。 |
| 83 | + |
| 84 | +この問題を解決するアプローチはさまざまです。 |
| 85 | +kubeadm、kubespray、k3sが行うようなインプレースアップデートから、Cluster APIとMetal3を通じた物理ノードのプロビジョニングの完全な自動化まで幅広くあります。 |
| 86 | + |
| 87 | +私は、Talos Linuxが提供するハイブリッドアプローチが気に入っています。 |
| 88 | +このアプローチでは、システム全体が単一の設定ファイルで記述されます。 |
| 89 | +このファイルのほとんどのパラメーターは、Kubernetesコントロールプレーンコンポーネントのバージョンを含め、ノードを再起動または再作成することなく適用できます。 |
| 90 | +それでも、Kubernetesの宣言的な性質を最大限に保持しています。 |
| 91 | +このアプローチは、ベアメタルノードを更新する際のクラスターサービスへの不要な影響を最小限に抑えます。 |
| 92 | +ほとんどの場合、マイナーアップデートの際に仮想マシンを移行したり、クラスターファイルシステムを再構築したりする必要はありません。 |
| 93 | + |
| 94 | +## 将来のクラウドの基盤を準備する |
| 95 | + |
| 96 | +さて、自分だけのクラウドを構築することに決めたとしましょう。 |
| 97 | +まずは基盤となるレイヤーが必要です。 |
| 98 | +サーバーにKubernetesをインストールする方法だけでなく、それをどのように更新し、維持していくかについても考える必要があります。 |
| 99 | +カーネルの更新、必要なモジュールのインストール、パッケージやセキュリティパッチなどについても考えなければならないことを考慮してください。 |
| 100 | +クラウド上の既製のKubernetesを使用する際に気にする必要のないことをはるかに多く考えなければなりません。 |
| 101 | + |
| 102 | +もちろん、UbuntuやDebianのような標準的なディストリビューションを使用できますし、Flatcar Container Linux、Fedora Core、Talos Linuxのような特殊なディストリビューションを検討することもできます。 |
| 103 | +それぞれに長所と短所があります。 |
| 104 | + |
| 105 | +私たちのことですか？ |
| 106 | +Ænixでは、ZFS、DRBD、OpenvSwitchなどのかなり特殊なカーネルモジュールを使用しているので、必要なモジュールをすべて事前に含んだシステムイメージを形成する方法を選びました。 |
| 107 | +この場合、Talos Linuxが私たちにとって最も便利であることがわかりました。 |
| 108 | +たとえば、次のような設定で、必要なカーネルモジュールをすべて含むシステムイメージを構築するのに十分です: |
| 109 | + |
| 110 | +```yaml |
| 111 | +arch: amd64 |
| 112 | +platform: metal |
| 113 | +secureboot: false |
| 114 | +version: v1.6.4 |
| 115 | +input: |
| 116 | + kernel: |
| 117 | + path: /usr/install/amd64/vmlinuz |
| 118 | + initramfs: |
| 119 | + path: /usr/install/amd64/initramfs.xz |
| 120 | + baseInstaller: |
| 121 | + imageRef: ghcr.io/siderolabs/installer:v1.6.4 |
| 122 | + systemExtensions: |
| 123 | + - imageRef: ghcr.io/siderolabs/amd-ucode:20240115 |
| 124 | + - imageRef: ghcr.io/siderolabs/amdgpu-firmware:20240115 |
| 125 | + - imageRef: ghcr.io/siderolabs/bnx2-bnx2x:20240115 |
| 126 | + - imageRef: ghcr.io/siderolabs/i915-ucode:20240115 |
| 127 | + - imageRef: ghcr.io/siderolabs/intel-ice-firmware:20240115 |
| 128 | + - imageRef: ghcr.io/siderolabs/intel-ucode:20231114 |
| 129 | + - imageRef: ghcr.io/siderolabs/qlogic-firmware:20240115 |
| 130 | + - imageRef: ghcr.io/siderolabs/drbd:9.2.6-v1.6.4 |
| 131 | + - imageRef: ghcr.io/siderolabs/zfs:2.1.14-v1.6.4 |
| 132 | +output: |
| 133 | + kind: installer |
| 134 | + outFormat: raw |
| 135 | +``` |
| 136 | +
|
| 137 | +`docker`コマンドラインツールを使用して、OSイメージをビルドします: |
| 138 | + |
| 139 | +``` |
| 140 | +cat config.yaml | docker run --rm -i -v /dev:/dev --privileged "ghcr.io/siderolabs/imager:v1.6.4" - |
| 141 | +``` |
| 142 | +
|
| 143 | +その結果、必要なものがすべて含まれたDockerコンテナイメージが得られます。 |
| 144 | +このイメージを使用して、サーバーにTalos Linuxをインストールできます。 |
| 145 | +同じことができます。このイメージには、必要なすべてのファームウェアとカーネルモジュールが含まれます。 |
| 146 | +
|
| 147 | +しかし、新しく形成されたイメージをノードにどのように配信するかという問題が発生します。 |
| 148 | +
|
| 149 | +しばらくの間、PXEブートのアイデアについて考えていました。 |
| 150 | +たとえば、2年前に[記事](/blog/2021/12/22/kubernetes-in-kubernetes-and-pxe-bootable-server-farm/)を書いた**Kubefarm**プロジェクトは、完全にこのアプローチを使用して構築されました。 |
| 151 | +しかし残念ながら、他のクラスターを保持する最初の親クラスターをデプロイするのに役立つわけではありません。 |
| 152 | +そこで今回、PXEアプローチを使用して同じことを行うのに役立つソリューションを用意しました。 |
| 153 | +
|
| 154 | +基本的に必要なのは、コンテナ内で一時的な**DHCP**と**PXE**サーバーを[実行する](https://cozystack.io/docs/get-started/)ことだけです。 |
| 155 | +そうすれば、ノードはあなたのイメージから起動し、Debianベースの簡単なスクリプトを使用して、ノードのブートストラップに役立てることができます。 |
| 156 | +
|
| 157 | +[](https://asciinema.org/a/627123) |
| 158 | +
|
| 159 | +`talos-bootstrap`スクリプトの[ソースコード](https://github.com/aenix-io/talos-bootstrap/)はGitHubで入手できます。 |
| 160 | +
|
| 161 | +このスクリプトを使用すると、ベアメタル上に5分でKubernetesをデプロイし、それにアクセスするためのkubeconfigを取得できます。 |
| 162 | +しかし、まだ多くの未解決の問題が残っています。 |
| 163 | +
|
| 164 | +## システムコンポーネントの配信 |
| 165 | +
|
| 166 | +この段階では、さまざまなワークロードを実行できるKubernetesクラスターがすでに手に入っています。 |
| 167 | +しかし、まだ完全に機能しているわけではありません。 |
| 168 | +つまり、ネットワークとストレージを設定する必要があるだけでなく、仮想マシンを実行するためのKubeVirtや、監視スタックやその他のシステム全体のコンポーネントなど、必要なクラスター拡張機能をインストールする必要があります。 |
| 169 | +
|
| 170 | +従来、これは**Helmチャート**をクラスターにインストールすることで解決されています。 |
| 171 | +ローカルで`helm install`コマンドを実行することで実現できますが、アップデートを追跡したい場合や、複数のクラスターを持っていてそれらを均一に保ちたい場合、このアプローチは不便になります。 |
| 172 | +実際には、これを宣言的に行う方法はたくさんあります。 |
| 173 | +これを解決するには、最高のGitOpsプラクティスを使用することをお勧めします。 |
| 174 | +つまり、ArgoCDやFluxCDのようなツールを指します。 |
| 175 | +
|
| 176 | +ArgoCDはグラフィカルインターフェースと中央コントロールプレーンを備えているため開発目的には便利ですが、一方でFluxCDはKubernetesディストリビューションの作成により適しています。 |
| 177 | +FluxCDを使用すると、どのチャートをどのパラメーターで起動すべきかを指定し、依存関係を記述できます。 |
| 178 | +そうすれば、FluxCDがすべてを処理してくれます。 |
| 179 | +
|
| 180 | +新しく作成したクラスターにFluxCDを1回インストールし、適切に設定することをお勧めします。 |
| 181 | +これにより、FluxCDは必要不可欠なコンポーネントをすべて自動的にデプロイできるようになり、クラスターを目的の状態にアップグレードできます。 |
| 182 | +たとえば、私たちのプラットフォームをインストールすると、システムコンポーネントとともに次の事前設定されたHelmチャートが表示されます: |
| 183 | +
|
| 184 | +``` |
| 185 | +NAMESPACE NAME AGE READY STATUS |
| 186 | +cozy-cert-manager cert-manager 4m1s True Release reconciliation succeeded |
| 187 | +cozy-cert-manager cert-manager-issuers 4m1s True Release reconciliation succeeded |
| 188 | +cozy-cilium cilium 4m1s True Release reconciliation succeeded |
| 189 | +cozy-cluster-api capi-operator 4m1s True Release reconciliation succeeded |
| 190 | +cozy-cluster-api capi-providers 4m1s True Release reconciliation succeeded |
| 191 | +cozy-dashboard dashboard 4m1s True Release reconciliation succeeded |
| 192 | +cozy-fluxcd cozy-fluxcd 4m1s True Release reconciliation succeeded |
| 193 | +cozy-grafana-operator grafana-operator 4m1s True Release reconciliation succeeded |
| 194 | +cozy-kamaji kamaji 4m1s True Release reconciliation succeeded |
| 195 | +cozy-kubeovn kubeovn 4m1s True Release reconciliation succeeded |
| 196 | +cozy-kubevirt-cdi kubevirt-cdi 4m1s True Release reconciliation succeeded |
| 197 | +cozy-kubevirt-cdi kubevirt-cdi-operator 4m1s True Release reconciliation succeeded |
| 198 | +cozy-kubevirt kubevirt 4m1s True Release reconciliation succeeded |
| 199 | +cozy-kubevirt kubevirt-operator 4m1s True Release reconciliation succeeded |
| 200 | +cozy-linstor linstor 4m1s True Release reconciliation succeeded |
| 201 | +cozy-linstor piraeus-operator 4m1s True Release reconciliation succeeded |
| 202 | +cozy-mariadb-operator mariadb-operator 4m1s True Release reconciliation succeeded |
| 203 | +cozy-metallb metallb 4m1s True Release reconciliation succeeded |
| 204 | +cozy-monitoring monitoring 4m1s True Release reconciliation succeeded |
| 205 | +cozy-postgres-operator postgres-operator 4m1s True Release reconciliation succeeded |
| 206 | +cozy-rabbitmq-operator rabbitmq-operator 4m1s True Release reconciliation succeeded |
| 207 | +cozy-redis-operator redis-operator 4m1s True Release reconciliation succeeded |
| 208 | +cozy-telepresence telepresence 4m1s True Release reconciliation succeeded |
| 209 | +cozy-victoria-metrics-operator victoria-metrics-operator 4m1s True Release reconciliation succeeded |
| 210 | +``` |
| 211 | +
|
| 212 | +## まとめ |
| 213 | +
|
| 214 | +結果として、誰にでも提供できる高い再現性を持つ環境を実現でき、意図したとおりに動作することがわかります。 |
| 215 | +これは、実際に[Cozystack](https://github.com/aenix-io/cozystack)プロジェクトが行っていることであり、あなた自身が無料で試すことができます。 |
| 216 | +
|
| 217 | +次の記事では、[仮想マシンを実行するためのKubernetesの準備方法](ja/blog/2024/04/05/diy-create-your-own-cloud-with-kubernetes-part-2/)と[ボタンをクリックするだけでKubernetesクラスターを実行する方法](ja/blog/2024/04/05/diy-create-your-own-cloud-with-kubernetes-part-3/)について説明します。 |
| 218 | +ご期待ください。きっと面白いはずです！ |
0 commit comments