Kubernetes の怠け者開発者ガイド

この記事は、開発者が Kubernetes をすぐに学習するためのガイドとして使用できます。基本的なトピックから、Helm Charts などのより高度なトピックまで、そしてこれらすべてが開発者にどのように影響するかについて説明します。

Kubernetes for Lazy Developers からの翻訳です。 marcobehler による。

導入

Kubernetes を一度も使用したことがない開発者、または Kubernetes の知識を磨いて DevOps の同僚に良い印象を与えたい開発者にとって、このガイドは最適です。

質問です: Kubernetes が K8s と略されるのはなぜですか?

回答: このガイドの最後で魔法のように明らかにされますが、それはガイドを完全に読んだ後のみです。だから、これ以上時間を無駄にしないようにしましょう。

どうやってここに来たのでしょうか?

私がこれまでのキャリアで出会った多くの開発者は、アプリケーションのライフサイクルにおける「コードを書いたからには、どこかで実行する必要がある」という部分を必ずしも気にしていません。 (これは、DevOps という用語に対する会社の定義と理解によって異なる場合があります)。

でもゆっくり始めましょう。アプリケーションを実行するとは、実際にはどういう意味ですか?

これは、使用しているプログラミング言語のエコシステムによって部分的に異なります。たとえば、Java や最新の Web アプリケーションでは、すべてのソース コードを 1 つの実行可能な .jar ファイルにコンパイルし、簡単なコマンドで実行できます。

 java -jar myNewAIStartup.jar

実稼働環境でのデプロイメントでは、通常、データベースの資格情報やその他のシークレットを設定するためのプロパティもいくつか必要になります。上記の Java Spring Boot の場合、最も簡単な方法は application.properties ファイルを使用することですが、外部のシークレット管理サービスを使用することもできます。

とにかく、上記のコマンドは、ベアメタル、VM、Docker コンテナ、Kubernetes の有無、さらには Java 搭載トースターであっても、アプリケーションをデプロイするために実行する必要があるすべてのコマンドです。

1 つのコマンドを実行するだけでは十分ではありません。問題のボトルネックはどこにあるのでしょうか?

アプリケーションを展開するときに発生する可能性のある問題については、Web 上で多くのことが書かれています。

• DEV 環境と PRD 環境の間でライブラリ/OS/インフラストラクチャなどのバージョンの非互換性がある場合はどうなりますか?
• 必要なオペレーティング システム パッケージが不足している場合はどうなりますか?
• アプリケーションをクラウド サービスではなく潜水艦にデプロイしたい場合はどうすればよいでしょうか?

これらの問題へのアプローチは、使用するプログラミング言語のエコシステムによって大きく異なる可能性があります。これは、オンラインの議論では見落とされがちなトピックです。

純粋な Java Web アプリケーションの場合、上記の問題 (データベースなどの潜水艦やより実用的なインフラストラクチャ部分は除く) はほとんど問題になりません。サーバー/VM/コンテナ/潜水艦に JDK をインストールし、java -jar を実行すると、その後は問題なく動作します。

PHP、Python、または Node の場合、状況は異なり、開発環境、テスト環境、または本番環境間でバージョンの非互換性が簡単に発生する可能性があります。そのため、人々はこれらの問題を解決するソリューション、つまりコンテナを熱望しています。

Docker、Docker Compose、Swarm: レビュー

ドッカー万歳！

おそらく、Docker とは何か、どのように使用するのかはすでにご存知でしょう。 (もしわからず、Docker 固有のガイドを見たい場合は、以下にコメントしてください。リクエストが多ければ多いほど、公開が早くなります)。簡単に要約すると次のようになります。

• ソース コードを jar ファイルなどのデプロイ可能なファイルにビルドします。
• さらに、jar ファイルを含む新しい Docker イメージを構築します。
• この Docker イメージには、正常に実行するために必要な追加のソフトウェアと構成オプションもすべて含まれています。

→ .jar ファイルをデプロイする代わりに、Docker イメージをデプロイして Docker コンテナを実行します。

この方法の利点は、ターゲット マシンに Docker がインストールされていれば (そしてホスト OS に Docker コンテナーと互換性のあるカーネルがあれば)、任意の Docker イメージを実行できることです。

 docker run --name my-new-ai-startup -p 80:8080 -d mynewaistartup // yay, your application is deployed // This will start a Docker container based on the `_mynewaistartup_` Docker image. // That image will, that other things, contain your eg -jar file, // a web application which runs on port 8080, as well as instructions on how to run it. // Hint: These instructions are `_java -jar mynewaistartup.jar_`.

Docker イメージを「デプロイする」とは何ですか?

あなたまたはあなたの CI/CD サーバーは、アプリケーションを Docker イメージにすることに成功しました。しかし、この Docker イメージは最終的にターゲットのデプロイメント サーバー上でどのように実行されるのでしょうか?

理論的には、Docker イメージを .tar ファイルとして保存し、それを最終サーバーにコピーして、そこにロードすることができます。しかし、より現実的には、Docker イメージを Docker レジストリ (Dockerhub、Amazon ECR、または GitLab のような無数のセルフホスト型コンテナレジストリのいずれか) にプッシュすることになります。

イメージがレジストリに正常にアップロードされると、ターゲット サーバーのレジストリにログインできるようになります。

 docker login mysupersecret.registry.com

レジストリにログインすると、docker run でカスタム イメージを見つけることができるようになります。

 docker run --name my-new-ai-startup -p 80:8080 -d mynewaistartup //.... SUCCESS!

Docker Compose: 複数のコンテナを同時に実行する

たとえば、98,354 個のマイクロサービスを実行する必要があるため、アプリケーションが単一の Docker コンテナーだけではなく複数のコンテナーで構成されている場合はどうなるでしょうか?

Docker Compose が救世主です。すべてのサービスとその依存関係 (最初にこれを実行するか、あれを実行するか) を、従来のクラシック YAML ファイルである compose.yaml ファイルで定義します。以下は、Web サービスと Redis サービスの 2 つのサービスを定義する例です。

 services: web: build: . ports: - "8000:5000" volumes: - .:/code - logvolume01:/var/log depends_on: - redis redis: image: redis volumes: logvolume01: {}

次に、docker compose up を実行するだけで、環境全体 (個別の Docker コンテナで実行されているすべての個別のサービスで構成) が起動します。これは、すべてのコンテナが同じマシン上で実行されることを意味することに注意してください。これを複数のマシンにスケールアウトする場合は、Docker Swarm を使用する必要があります。

Docker Compose は主に開発環境やテスト環境を迅速に立ち上げるために使用されますが、実際には (単一ホストの) 本番環境展開にも適しています。アプリケーションが...

• 特別な高可用性要件はありません
• 多少の手作業（sshログイン、docker composeの起動/停止）やAnsibleのようなヘルパーツールの使用を気にしない
• あるいは、DevOpsチームに多額の資金を投資したくないだけかもしれません

…本番環境のデプロイメントに Docker Compose を使用すると、大きなメリットが得られます。

Kubernetes 101: 基礎と概念

では、なぜ Kubernetes が必要なのでしょうか?

数百、数千（またはその倍数）のコンテナを実行し始めると、状況は面白くなり始めます。これらのコンテナがどのハードウェア/ホスト上で実行されるかを気にしない、または知りたくないが、それでもこれらすべてを適切に管理したい場合は、Kubernetes が便利です。

(注: かなり前に Kubernetes に関する本を読んだのですが、その序文で Kubernetes の実行が意味を持ち始める下限値が指定されていました。数百から数千から始まったと記憶していますが、正確な本はもう見つかりません。)

Kubernetes の基本的な概念を簡単に確認してみましょう。

写真

（ワーカー）ノード

ソフトウェア (Kubernetes 用語ではワークロード) は、仮想マシンでも物理マシンでも、どこかで実行する必要があります。 Kubernetes では、この場所はノードと呼ばれます。

さらに、Kubernetes はコンテナをデプロイして実行します。こんにちは、私の古い友人である Docker です! (注: Kubernetes は、containerd、CRI-O、Docker Engine など、多くのコンテナ ランタイムをサポートしていますが、最も一般的に使用されているのは Docker です)

実のところ、これは完全に真実ではありません。 Kubernetes の用語では、ポッドをデプロイ (スケジュール) し、ポッドには 1 つ以上のコンテナが含まれます。

わかりました。ノード上でポッドを実行しますが、それらのノードを誰が制御し、それらのノード上で何を実行するかをどのように決定するのでしょうか?

(ヒント: 小さなマッピング テーブル)

コントロールプレーン

コントロール プレーンを理解します。簡単にするために、これを制御ノードの 1 つのコンポーネントとして考えることができます (制御ノードに含まれる約 9472 個のコンポーネントとは対照的です)。コントロール プレーンは、他の多くの機能の中でも特に...

• アプリケーションを実行およびスケジュールできるようにします。つまり、ノードにポッドを配置できるようにします。
• すべての Pod が期待どおりの状態であることを確認します。例:応答していますか、それともいずれか 1 つを再起動する必要がありますか?
• すべてのエンジニアの夢を叶えます。「最終的に 10 倍にスケールする必要があるので、すぐにポッドを増やしましょう!」

ポッドとノード

Pod と Node の違いがまだよくわからない場合。 Kubernetes には、いわゆるスケジューラがあります。スケジューラは、スケジュールする必要がある新しいポッド（== コンテナ）を検出するたびに、そのポッドに最適なノードを見つけようとします。つまり、複数の Pod を同じノードまたは異なるノードで実行することが可能になります。このトピックについてさらに詳しく知りたい場合は、「ノード選択」とそれに影響を与える方法に関する公式ドキュメントを読むことをお勧めします。

クラスターとクラウド

複数のノードとコントロール プレーンを使用すると、クラスターが作成されます。

複数のクラスターを使用すると、開発環境、テスト環境、本番環境、またはチーム、プロジェクト、さまざまな種類のアプリケーションを分離できます。

さらに一歩進んで、マルチクラウド Kubernetes を試し、異なるプライベート クラウド プラットフォームやパブリック クラウド プラットフォームで複数のクラスターを実行してみましょう (おめでとうございます。達成したことは決して小さな成果ではありません)。

拡張機能

Kubernetes 拡張機能も多数あります。

開発者にとって最も重要なのは、クラスターの基本的な管理に使用できる Web UI/ダッシュボードがあることです。

Kubernetes セットアップを自己ホストしない場合は、Google Cloud、AWS、その他の多数のクラウド プロバイダーなど、クラウド プロバイダーが提供する UI をそのまま使用できます。

Kubernetes 101 はもうやめましょう

上記の 4 つの 101 のセクションでは、Kubernetes を使い始めるのに十分なメンタル モデルが (願わくば) 提供され、概念についてまとめます。

正直に言うと、https://learning.oreilly.com で「Kubernetes」を検索すると、ショックを受けるでしょう。学習リソースの検索結果は何千件にも上り、その多くは 500 ページを超えています。雨の降る冬の日に読むのに最適な本です!良いニュースは、開発者として、クラスターの設定、保守、管理の方法を学ぶこれらの本の内容のほとんどを気にする必要がないことです。ただし、その複雑さを理解しておくことは役に立ちます。

これらすべてを実際に見るには何をする必要がありますか?

• Kubernetes のインストール (これについては後で詳しく説明します)
• ヤム、ヤム、ヤム！
• Kubernetes クラスターを操作するためのツール: kubectl

kubectl はどこで入手できますか?

kubectl をダウンロードできます。これは基本的に、Kubernetes クラスターで必要な操作をすべて実行するための CLI ツールです。このページでは、特定のオペレーティング システムに kubectl をインストールするさまざまな方法を示します。

kubectl をどのように読みますか? †

https://www.youtube.com/watch?v=9oCVGs2oz28 をご覧ください。 「キューブコントロール」と発音します。

kubectl はどのように機能しますか?

Kubernetes クラスターにアクセスできるようにする kubeconfig という構成ファイルが必要です。

デフォルトでは、このファイルは ~/.kube/config にあります。この構成ファイルは、Kubernetes 機能を適切に設定するために、お気に入りの IDE (IntelliJ IDEA など) でも読み取られることに注意してください。

kubeconfig ファイルはどこで入手できますか?

オプション 1 マネージド Kubernetes インストール (EKS、GKE、AKS) を使用している場合は、対応するドキュメント ページを確認してください。はい、リンクをクリックするだけで、正しいページにリンクされます。つまり、CLI ツールを使用してファイルを生成/ダウンロードすることになります。

オプション 2: Minikube がローカルにインストールされている場合は、kubeconfig ファイルが自動的に作成されます。

オプション3 Kubernetesマスターノードを知っていて、SSH経由でログインできる場合は、次を実行します: cat /etc/kubernetes/admin.conf または cat ~/.kube/config

kubeconfig ファイルについて他に知っておくべきことはありますか?

kubeconfig ファイルは従来の YAML で構成され、多くのもの (クラスター、ユーザー、コンテキスト) を含めることができます。ご興味のある方は、公式ドキュメントをご覧ください。

現時点では、ユーザーとコンテキストを無視して、開発やテストなど、接続できるクラスターだけを kubeconfig ファイルに含めるように簡素化できます。

以下は、Kubernetes の公式ドキュメントから抜粋したサンプル kubeconfig ファイルです。

(心配しないでください。このファイルを 1 行ずつ理解する必要はありません。これらのファイルがどのように見えるかを把握するためだけです)

 apiVersion: v1 clusters: - cluster: certificate-authority: fake-ca-file server: https://1.2.3.4 name: development - cluster: insecure-skip-tls-verify: true server: https://5.6.7.8 name: test contexts: - context: cluster: development namespace: frontend user: developer name: dev-frontend - context: cluster: development namespace: storage user: developer name: dev-storage - context: cluster: test namespace: default user: experimenter name: exp-test current-context: "" kind: Config preferences: {} users: - name: developer user: client-certificate: fake-cert-file client-key: fake-key-file - name: experimenter user: # Documentation note (this comment is NOT part of the command output). # Storing passwords in Kubernetes client config is risky. # A better alternative would be to use a credential plugin # and store the credentials separately. # See https://kubernetes.io/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins password: some-password username: exp

Kubernetes 101 入門

Kubectl で今何ができるでしょうか?最初に、目標はポッド (n 個以上のコンテナ) を用意し、それをノード (サーバー) 上でスケジュールする (実行する) ことだと述べたことを思い出してください。

これを行うには、クラスターの望ましい状態を記述した yaml ファイル (yay) を kubectl に渡すと、クラスターが望ましい状態に設定されます。

ポッドマニフェスト

たとえば、次の内容を含む marcocodes-pod.yaml というファイルを作成できます...

 apiVersion: v1 kind: Pod metadata: name: marcocodes-web spec: containers: - image: gcr.io/marco/marcocodes:1.4 name: marcocodes-web ports: - containerPort: 8080 name: http protocol: TCP

…そして、次の kubectl コマンドを使用して、それを Kubernetes クラスターに入力します。

 kubectl apply -f marcocodes-pod.yaml

この yaml ファイルのアプリケーションは何を行うのでしょうか?さて、ステップごとに理解していきましょう:

Kubernetes はさまざまないわゆるオブジェクトを認識します。Pod はその 1 つですが、後ほど他のオブジェクトについても説明します。簡単に言えば、この .yaml ファイルはデプロイする Pod を記述します。

 metadata: name: marcocodes-web

Kubernetes 内のすべてのオブジェクト、つまりすべての .yaml ファイルには、メタデータ タグが埋め込まれます。この場合、ポッドに marcocodes_web という名前を付けました。このメタデータは何の目的で使用されますか?簡単に言えば、Kubernetes にはクラスター内のリソースを一意に識別する方法が必要です。つまり、marcocodes_web という名前のポッドがすでに実行されているか、それとも新しいポッドを開始する必要があるかということです。これがメタデータの目的です。

 spec: containers: - image: gcr.io/marco/marcocodes:1.4 name: marcocodes-web ports: - containerPort: 8080 name: http protocol: TCP

Kubernetes にポッドがどのようになるべきかを伝える必要があります。覚えておいてください、n 個以上のコンテナを指定できるので、通常は 1 つのコンテナのみを指定しますが、YAML ファイルでコンテナのリストを指定できます。

特定の Docker イメージとそのバージョンを指定し、そのコンテナーのポート 8080 を http 経由で公開します。それでおしまい。

この yaml ファイルはどうなったのでしょうか?

簡単に言うと、 kubectl apply を実行すると、yaml ファイルが Kubernetes API サーバーに送信され、最終的に Kubernetes システムは、クラスター内の正常で利用可能なノードで実行されるポッド (marcocodes 1.4 コンテナーを含む) をスケジュールします。

より技術的に言えば、Kubernetes には調整ループという概念があり、これはスケジューラを表す専門用語です。

「これが現在の Kubernetes クラスターの状態です。これがユーザーの yaml ファイルです。この 2 つを調整します。ユーザーは新しいポッドを必要としていますか? それを作成します。ユーザーはストレージを必要としていますか? それをコンテナーにアタッチします、などです。」

ストレージといえば...

リソースとボリューム

コンテナ イメージを指定するだけでは十分ではありません。まず、コンテナのリソース消費に注意する必要があります。

 # .... spec: containers: - image: gcr.io/marco/marcocodes:1.4 resources: requests: cpu: "500m" memory: "128Mi" # ....

これにより、コンテナーは少なくとも 500m (または 0.5) の CPU と 128MB のメモリを取得できるようになります (超過できない上限を指定することもできます)。

さらに、ポッドが削除されたりコンテナが再起動されたりすると、コンテナ ファイル システム内のデータも削除されます。これを回避するには、データを永続ボリュームに保存することをお勧めします。

 # .... spec: volumes: - name: "marcocodes-data" hostPath: path: "/var/lib/marcocodes" containers: - image: gcr.io/marco/marcocodes:1.4 name: marcocodes volumeMounts: - mountPath: "/data" name: "marcocodes-data" ports: - containerPort: 8080 name: http protocol: TCP # ....

marcocodes-data というボリュームが作成され、コンテナの /data の下にマウントされ、ホスト マシンの /var/lib/marcocodes の下に存在します。

何か注意すべき点はありますか？

1 つ以上の Docker イメージ、リソース消費ルール、ボリューム定義から構成されるポッドがあることを学びました。

このすべての YAML を配置することで、単一の静的な使い捨てポッドを正常にスケジュールできました。ここで疑問が湧きます。docker run -d --publish 8080:8080 gcr.io/marco/marcocodes:1.4 を単に実行するのと比べて、どのような利点があるのでしょうか?

まあ、実際のところ、現時点ではそうではありません。

そのため、ReplicaSet と Deployment の概念を詳しく調べる必要があります。

レプリカセット

私たちは謙虚になる必要があります。最初は自動スケーリングは必要ありませんが、アプリケーションの冗長インスタンスと負荷分散があれば、デプロイメントがよりプロフェッショナルに見えるので便利ですよね。

Kubernetes ReplicaSet が救世主です!

このような最小限の ReplicaSet を定義する marcocodes-replica.yaml ファイルを見てみましょう。

 apiVersion: apps/v1 kind: ReplicaSet # metadata: # ... spec: replicas: 2 selector: "you will learn this later" # ... template: metadata: "you will learn this later" # ... spec: containers: - name: marcocodes-web image: "gcr.io/marco/marcocodes:3.85"

この YAML ファイルでは多くの行 (および複雑さ) を省略しましたが、現時点で最も興味深いのは次の 2 つの変更です。

この .yaml では、Pod ではなく ReplicaSet が記述されるようになりました。

ここでのポイントは、常に 2 つのレプリカ = ポッドが常に実行されるようにすることです。ここで 10 を入力すると、Kubernetes は 10 個のポッドが同時に実行されるようにします。

この .yaml ファイルを適用すると...

 kubectl apply -f marcocodes-rs.yaml

Kubernetes は Kubernetes API から Pod のリストを取得し (メタデータに基づいて結果をフィルタリングし)、返された Pod の数に応じて追加のレプリカを開始または停止します。とても簡単です。

レプリカセット: 概要

ReplicaSets はほぼ希望どおりですが、1 つ問題があります。それは、コンテナ イメージの特定のバージョン (この場合は 3.85) に関連付けられており、実際には変更できないことです。また、ReplicaSets はソフトウェアのローリング リリース (ダウンタイムゼロ) には対応できません。

したがって、新しいバージョンのリリースを管理するための新しい概念が必要です。出会い：展開。

 apiVersion: apps/v1 kind: Deployment metadata: "ignore for now" # ... spec: progressDeadlineSeconds: 600 replicas: 2 revisionHistoryLimit: 10 selector: "ignore for now" # ... strategy: rollingUpdate: maxSurge: 25% maxUnavailable: 25% type: RollingUpdate template: "ignore for now" # ...

デプロイメントには、学習する必要がある他の 92,387 個の YAML キーと値のペアがありますが、この記事ではすでにそれらについてかなりの時間をかけて調べました。重要な点は、Kubernetes ではさまざまなソフトウェア リリース戦略 (rollingUpdate または再作成) を使用できることです。

• 再作成すると、古いバージョンのすべてのポッドが終了し、新しいバージョンで再作成されます。これにより、ユーザーにダウンタイムが発生します。
• RollingUpdate は、古いポッドを介してトラフィックを処理しながら更新を実行するため、通常はこれが推奨されます。

K8sの静的性質

これまで見てきたものはすべて本質的に静的であったことに注意してください。 YAML ファイルがあり、上記の Deployment オブジェクトを使用していても、コンテナーの新しいバージョンがある場合は、.yaml ファイルを編集して保存し、適用する必要があります。これにはかなりの手作業が必要になります。

より動的な処理をしたい場合は、以下で説明する https://helm.sh/ などの追加ツールを使用する必要があります。

ローリングアップデート：信じられないほど素晴らしい

コンテナの新しいバージョンのデプロイについて話していますが...

いつものことですが、悪魔は細部に潜んでいます。ローリング アップデートは、たとえそれが SSH コマンドをトリガーするバッチ スクリプトだけであったとしても、Kubernetes が存在するずっと前から行われてきました。

率直に言えば、問題はアプリケーションをシャットダウンして新しいインスタンスを起動できないことではなく、短期間 (デプロイメント中) にアプリケーションが基本的に 2 つのアプリケーション バージョンを適切にサポートする必要があることです。これは常に興味深い問題であり、特にデータベース間またはフロントエンド API とバックエンド API 間の大規模なリファクタリングが関係する場合はなおさらです。

したがって、簡単なローリング アップデートを売り込むマーケティング資料には注意してください。実際の課題は Kubernetes とはまったく関係ありません。

注記: 自己治癒能力

同様の文脈で、「自己治癒」という用語にも同じことが当てはまります。 Kubernetes はヘルスチェックを実行し、応答しないポッドを終了して、新しいポッドの起動をスケジュールすることができます。これも、何らかの形で常に存在してきた機能です。お気に入りの Linux ディストリビューションは、現在のマシンに限定されるものの、さまざまな方法でサービスを監視および再起動する機能を本質的に備えています。

Kubernetes は、不適切なデータベース移行によって発生したアプリケーション エラーを自動的に処理して、破損したデータベース列を修復することでクラスターを魔法のように修復することはできません。

自己修復システムに関する議論では後者の意味合いがしばしばあるように感じますが (おそらく経営陣の間では)、実際には自己修復システムはより基本的な機能です。

サービス検出、負荷分散、イングレス

これまで、ポッドの動的な生成について説明してきましたが、ネットワーク トラフィックが実際にアプリケーションに到達する方法については説明していませんでした。 Kubernetes は本質的に動的であるため、いつでも新しいポッドを生成したり、シャットダウンしたりできます。

Kubernetes には、Service オブジェクト (クラスターの一部を外部に公開できるようにする) から Ingress オブジェクト (HTTP ロード バランシングを可能にする) まで、これに役立つ概念がいくつかあります。繰り返しになりますが、これには大量の YAML とかなりの量の読み取りが必要になりますが、結局のところ、Kubernetes を使用すると、アプリケーションが受信するすべてのトラフィックをクラスターにルーティングでき、その逆も可能です。

(Ingress の豆知識: Ingress コントローラーをインストールする必要があります (Kubernetes には標準コントローラーが組み込まれていません)。これにより、負荷分散が行われます。オプションは多数あります。AWS などのプラットフォームでは、単に ELB を使用できます。ベアメタル Kubernetes を使用している場合は、Contour を使用できます。)

最後になりましたが、ConfigMapとシークレット管理

Kubernetes が実行するさまざまなタスクに加えて、Kubernetes を使用して構成のキーと値のペアやシークレット (データベースや API の認証情報など) を保存することもできます。

(シークレットはデフォルトでは暗号化されずに保存されるため、このページの「シークレットを安全に使用する」セクションのアドバイスに従うか、AWS、GCP、Azure のソリューションから HashiCorp の Vault まで、外部のシークレット ストアを完全にプラグインする必要があります。)

十分！これらの YAML ファイルは乱雑になりませんか?

そうですね...Kubernetes を使用して WordPress のようなアプリケーションをデプロイすることを考えている場合は、Deployment に加えて、ConfigMap と、場合によっては Secret も必要になります。さらに、まだ説明していないサービスやオブジェクトもいくつかあります。つまり、YAML の行数は数千行または数万行になるということです。これは本質的に混沌としたものではありませんが、この小さな段階で、すでに DevOps の複雑さがかなり伴っています。

ただし、あなたも開発者であり、必ずしもこれらのファイルを保守する必要はないでしょう。

必要に応じて、IDE の Kubernetes サポート (私の場合は IntelliJ IDEA) を使用して、Helm チャート、Kustomize ファイルなどのサポートをエンコードすると、非常に役立ちます。ああ、まだそれについて話してないですね。話しましょう。 IntelliJ 用の Kubernetes プラグインについて詳しく説明するビデオをご紹介します。

Kubernetes: 追加トピック

Helm とは何ですか? Helm Chart とは何ですか?

Helm は Kubernetes のパッケージ マネージャーと考えることができます。いくつかの概念を理解しましょう:

上で述べたように、Kubernetes クラスターに WordPress をインストールするだけで、数千行の YAML コードが生成される可能性があります。このすべての YAML コードを自分で記述する代わりに、事前に構築されたパッケージを使用して、途中でいくつかの変数を置き換えることができれば、非常に便利です。

これは Helm Chart であり、特定のディレクトリ構造内に配置された一連の YAML ファイルとテンプレートです。特定のチャートのインストールを開始すると、Helm はそれをダウンロードし、テンプレートを解析し、値とともに従来の Kubernetes YAML ファイル/マニフェストを生成して、Kubernetes に送信します。

次に、いくつかのプレースホルダーを含む、このようなテンプレート ファイル (展開マニフェスト用) の小さなスニペットを示します。

 apiVersion: apps/v1 kind: Deployment metadata: name: {{ include "myChart.name" . }} labels: {{- include "myChart.labels" . | nindent 4 }}

これらのチャートをリポジトリで共有できます。デフォルトのチャート リポジトリは 1 つもありません。人気のあるチャートリポジトリを見つけるのに適した場所は https://artifacthub.io/ です。

つまり、Helm を使用するワークフローは次のようになります。

1. Helmクライアントをインストールする
2. お気に入りのチャートをインストールする - パート 1

 helm install my-release oci://registry-1.docker.io/bitnamicharts/wordpress

このコマンドは、人気のある Bitnami チャート リポジトリから WordPress チャートをクラスターにインストールし、最終結果として WordPress インストールが実行されます。 OCI とは何か疑問に思っている方のために説明します。Open Containers Initiative 標準をサポートするコンテナ レジストリ (Amazon ECR、Docker Hub、Artifactory など) で Helm チャートをホストできます。

3. お気に入りのチャートをインストールする - パート 2

ほとんどの場合、いくつかの設定値を上書きする必要があるため (WordPress の場合は、ここで膨大なパラメータのリストを確認できます)、インストール コマンドに特定の値を指定する必要があります。値は、values.yaml という名前の YAML ファイル経由で渡すことも、コマンドライン フラグを使用して直接渡すこともできます。したがって、インストール コマンドは次のようになります。

 helm install my-release oci://registry-1.docker.io/bitnamicharts/wordpress --values values.yaml // OR helm install my-release oci://registry-1.docker.io/bitnamicharts/wordpress --set wordpressUsername=m4rc0 // etc...

4. 注: helm を使用してインストールをアップグレードすることもできます。新しいバージョンのチャート (新しいリリースを考慮) にアップグレードするか、 helm upgrade コマンドを使用してインストールされた構成をアップグレードすることができます。

Helm についてさらに詳しく知りたい場合は、『Learning Helm』という本を読むことを強くお勧めします。

Kustomize とは何ですか?

先ほど、Helm はテンプレートを使用して Kubernetes マニフェストを生成することを学びました。つまり、誰かが Kubernetes マニフェストを Helm テンプレートに作成し、それを保守し、エンドユーザーが helm コマンドライン クライアントを使用してそれを適用できる必要があります。

Kustomize の開発者は別の方法を選択しました。つまり、元のマニフェストの上に追加の変更を重ねることで、マニフェストのカスタム バージョンを作成できるようになりました。したがって、テンプレートを作成してその中に「プレースホルダー」を配置する代わりに、次のようなファイル構造になります。

 ├── deployment.yaml // your original Kubernetes manifest filef └── kustomization.yaml // // (in more relalistic scenarios, you'deven have 'overlays' subfolders for different environments, like development/staging/prod etc

次に、kustomize build を実行して、Kustomize がオーバーレイを適用し、最終的な YAML 結果をレンダリングできるようにします。この結果は、kubectl コマンドに直接入力できます (または、単に kubectl apply -k を実行することもできます)。

 kustomize build . | kubectl apply -f -

kustomization.yaml ファイルの構造を理解したい場合は、こちらをご覧ください。

Helm と Kustomize のどちらが優れていますか?

物議を醸す意見であっても、Reddit の意見はみんな大好きです: https://www.reddit.com/r/kubernetes/comments/w9xug9/helm_vs_kustomize/。

Terraform とは何ですか? Kubernetes とどう違うのですか?

ありがたいことに、このガイドも終わりに近づいており、Terraform についてさらに 1,000 語も費やす必要はありません (ヒント: いつものように、Terraform に関する書籍や学習リソースは多数あります)。そのため、ここでは簡単に説明します。

Kubernetes はコンテナ オーケストレーションに関するものです。 「この YAML ファイルで何が欲しいか教えてください。コンテナを実行してください。」

Terraform はインフラストラクチャの作成に関するものです。「これらの HashiCorp 構成言語 (HCL、.tf) ファイルで何が欲しいか教えてください。選択したクラウドで、サーバー 5 台、ロード バランサー数台、データベース 2 台、キュー数台、監視機能を作成してください。」または、「AWS 上にこれらの Kubernetes クラスター (EKS) を設定してください。」

Kubernetes をローカルで開発するにはどうすればよいですか?

ローカル開発の場合、基本的に 2 つの選択肢があります。

ローカルの Kubernetes クラスターを実行し、そこにアプリケーションをデプロイできます。これを実現するには、おそらく Minikube を使用することになります。 「アプリケーションが変更されたので、コンテナ イメージをビルドして、それをクラスターにデプロイする」というプロセス全体を手動で実行するのは非常に面倒なので、Skaffold などのツールを使用すると便利です。このワークフローを開始する方法については、このチュートリアルをご覧ください。この設定は効果的ですが、かなりの複雑さやリソースの消費を伴います。

ここで、2 番目のオプションであるソリューションが登場します。ローカル開発の場合、基本的に Kubernetes を無視し、必要な構成を独自の docker-compose.yml ファイルに複製して、それを実行するだけです。これははるかに簡単なセットアップですが、2 セットの構成 (docker-compose.yml + K8s マニフェスト ファイル) を維持する必要があるという欠点があります。

すでに Kubernetes を使用している場合は、ローカル開発をどのように処理しているかを以下のコメント セクションでお知らせください。

本当にこれらすべてが必要なのでしょうか?

これは素晴らしい質問です。Kubernetes の実際の逸話をいくつか紹介するのに最適なタイミングです。システム管理者がリソースを調整したため、Pod の起動に時間がかかりすぎました。時間がかかりすぎたため、Pod は不健全とマークされて終了し、Pod の作成と終了の無限サイクルが発生しましたが、長い説明は別の機会に残しておきます。

開発者としては、決定権がないことが多いのですが、全体像は次のとおりです。

この記事の前半で述べたように、「マネージド」Kubernetes クラスターに関する学習資料は無数にあります。ここでは、ベアメタルでの「セルフホスティング」だけでなく、マネージド Kubernetes バリアントの使用についても説明します。社内に専門知識がある場合:

• こうした余分な複雑さに対処する
• この記事で説明したすべての概念をすべての開発者に詳しく説明することができます
• そして何よりもまず、数百または数千のコンテナを管理する正当なニーズがある場合（突然の魔法のようなスケーリングのニーズではありません）、Kubernetes を選択します。しかし、多くの企業は、よりシンプルなアプローチを採用し、Google 規模のインフラストラクチャの課題を夢見ることなく、多くの時間、費用、ストレスを節約できると私は信じています。

一般的な Kubectl コマンド

開発者が必要とする可能性のある kubectl コマンドに関する興味深い情報がある場合は、以下にコメントを残してください。最もよく使用されるコマンドを、きちんとグループ化/並べ替えられたリストとしてここに追加します。

Kubernetes が K8s と略されるのはなぜですか?

もう忘れてしまったかも知れませんよ！以下は Kubernetes ドキュメントからの引用です。

「Kubernetes という名前は、操舵手またはパイロットを意味するギリシャ語に由来しています。K8s は、「K」と「s」の間に 8 つの文字があるため、略語として使用されています。」 Google は 2014 年に Kubernetes プロジェクトをオープンソース化しました。」

結論

ここまでで、Kubernetes の概要をかなり理解できたはずです。フィードバック、訂正、ランダムなコメントはすべて歓迎します!下記にコメントを残してください。

読んでくれてありがとう。

次期バージョンの計画

以下のいずれかまたはすべてを実現したい場合は、コメント セクションで投票してください。

• 読者が理解しやすいように、コピー＆ペーストコマンド*K8sファイルを用意する
• 可能: kubectl コマンド
• 可能: Kubernetes と Docker Compose の並列構成の例
• 可能: GitOps
• 推奨事項: Kubernetes に接続するには、Kubectl/K9s/Lens IDE または IntelliJ Kubernetes プラグインを使用します。
• 推奨事項: Istio を使用したサービス メッシュ - マイクロサービスを扱う際の一般的なユース ケース。

謝辞と参考文献

コメント、修正、議論をしていただいた Maarten Balliauw、Andreas Eisele、Andrei Efimov、Anton Aleksandrov、Garth Gilmour、Marit van Dijk、Paul Everitt、Mukul Mantosh に感謝します。 『Getting Started with Kubernetes』および『Learning Helm』の著者に特に感謝します。