From 3001d8f574fd5ac5cf61c28d9eaacd7c4640681f Mon Sep 17 00:00:00 2001 From: kahirokunn Date: Thu, 22 Aug 2024 10:00:27 +0900 Subject: [PATCH] docs(ja): add initial Japanese translation to documentation --- docs/ja/01-prerequisites.md | 30 +++ docs/ja/02-jumpbox.md | 121 ++++++++++ docs/ja/03-compute-resources.md | 225 ++++++++++++++++++ docs/ja/04-certificate-authority.md | 108 +++++++++ docs/ja/05-kubernetes-configuration-files.md | 209 ++++++++++++++++ docs/ja/06-data-encryption-keys.md | 30 +++ docs/ja/07-bootstrapping-etcd.md | 76 ++++++ ...08-bootstrapping-kubernetes-controllers.md | 179 ++++++++++++++ .../ja/09-bootstrapping-kubernetes-workers.md | 176 ++++++++++++++ docs/ja/10-configuring-kubectl.md | 80 +++++++ docs/ja/11-pod-network-routes.md | 77 ++++++ docs/ja/12-smoke-test.md | 190 +++++++++++++++ docs/ja/13-cleanup.md | 7 + 13 files changed, 1508 insertions(+) create mode 100644 docs/ja/01-prerequisites.md create mode 100644 docs/ja/02-jumpbox.md create mode 100644 docs/ja/03-compute-resources.md create mode 100644 docs/ja/04-certificate-authority.md create mode 100644 docs/ja/05-kubernetes-configuration-files.md create mode 100644 docs/ja/06-data-encryption-keys.md create mode 100644 docs/ja/07-bootstrapping-etcd.md create mode 100644 docs/ja/08-bootstrapping-kubernetes-controllers.md create mode 100644 docs/ja/09-bootstrapping-kubernetes-workers.md create mode 100644 docs/ja/10-configuring-kubectl.md create mode 100644 docs/ja/11-pod-network-routes.md create mode 100644 docs/ja/12-smoke-test.md create mode 100644 docs/ja/13-cleanup.md diff --git a/docs/ja/01-prerequisites.md b/docs/ja/01-prerequisites.md new file mode 100644 index 0000000..3e03bb6 --- /dev/null +++ b/docs/ja/01-prerequisites.md @@ -0,0 +1,30 @@ +# 前提条件 + +このラボでは、このチュートリアルを進めるために必要なマシンの要件を確認します。 + +## 仮想マシンまたは物理マシン + +このチュートリアルでは、Debian 12 (bookworm) を実行する4台の仮想または物理ARM64マシンが必要です。以下の表に、4台のマシンとそのCPU、メモリ、およびストレージの要件を示します。 + +| 名前 | 説明 | CPU | RAM | ストレージ | +|---------|------------------------|-----|-------|---------| +| jumpbox | 管理ホスト | 1 | 512MB | 10GB | +| server | Kubernetesサーバー | 1 | 2GB | 20GB | +| node-0 | Kubernetesワーカーノード | 1 | 2GB | 20GB | +| node-1 | Kubernetesワーカーノード | 1 | 2GB | 20GB | + +マシンのプロビジョニング方法は任意ですが、各マシンが上記のシステム要件（マシンスペックおよびOSバージョンを含む）を満たしている必要があります。4台のマシンをすべてプロビジョニングしたら、各マシンで `uname` コマンドを実行してシステム要件を確認します。 + +```bash +uname -mov +``` + +`uname` コマンドを実行すると、次のような出力が表示されるはずです。 + +```text +#1 SMP Debian 6.1.55-1 (2023-09-29) aarch64 GNU/Linux +``` + +ここで `aarch64` が表示されることに驚くかもしれませんが、これはArm Architecture 64-bit命令セットの正式名称です。AppleやLinuxカーネルのメンテナは、`aarch64` を指すときに `arm64` を使用することがよくあります。このチュートリアルでは混乱を避けるために一貫して `arm64` を使用します。 + +次へ: [setting-up-the-jumpbox](02-jumpbox.md) diff --git a/docs/ja/02-jumpbox.md b/docs/ja/02-jumpbox.md new file mode 100644 index 0000000..a99d29d --- /dev/null +++ b/docs/ja/02-jumpbox.md @@ -0,0 +1,121 @@ +# Jumpboxのセットアップ + +このラボでは、4台のマシンのうち1台を`jumpbox`として設定します。このマシンはこのチュートリアルでコマンドを実行するために使用されます。専用のマシンを使用して一貫性を確保しますが、これらのコマンドはmacOSやLinuxを実行している個人のワークステーションを含むほぼすべてのマシンから実行することもできます。 + +`jumpbox`を、Kubernetesクラスターをゼロからセットアップする際のホームベースとして使用する管理マシンと考えてください。始める前に、いくつかのコマンドラインユーティリティをインストールし、Kubernetes The Hard Wayのgitリポジトリをクローンする必要があります。このリポジトリには、このチュートリアル全体でさまざまなKubernetesコンポーネントを構成するために使用される追加の設定ファイルが含まれています。 + +`jumpbox`にログインします： + +```bash +ssh root@jumpbox +``` + +すべてのコマンドは`root`ユーザーとして実行されます。これは利便性のために行われており、すべてをセットアップするために必要なコマンドの数を減らすのに役立ちます。 + +### コマンドラインユーティリティのインストール + +`root`ユーザーとして`jumpbox`マシンにログインしたので、チュートリアル全体でさまざまなタスクを実行するために使用されるコマンドラインユーティリティをインストールします。 + +```bash +apt-get -y install wget curl vim openssl git +``` + +### GitHubリポジトリの同期 + +次に、このチュートリアルのコピーをダウンロードします。このコピーには、ゼロからKubernetesクラスターを構築するために使用される設定ファイルとテンプレートが含まれています。`git`コマンドを使用してKubernetes The Hard Wayのgitリポジトリをクローンします： + +```bash +git clone --depth 1 \ + https://github.com/kelseyhightower/kubernetes-the-hard-way.git +``` + +`kubernetes-the-hard-way`ディレクトリに移動します： + +```bash +cd kubernetes-the-hard-way +``` + +これがチュートリアルの残りの部分の作業ディレクトリになります。コマンドを実行する際に迷子になった場合は、`pwd`コマンドを実行して正しいディレクトリにいることを確認してください： + +```bash +pwd +``` + +```text +/root/kubernetes-the-hard-way +``` + +### バイナリのダウンロード + +このセクションでは、さまざまなKubernetesコンポーネントのバイナリをダウンロードします。バイナリは`jumpbox`の`downloads`ディレクトリに保存されます。これにより、Kubernetesクラスターの各マシンに対してバイナリを複数回ダウンロードすることを避け、チュートリアルを完了するために必要なインターネット帯域幅を減らすことができます。 + +`kubernetes-the-hard-way`ディレクトリから`mkdir`コマンドを使用して`downloads`ディレクトリを作成します： + +```bash +mkdir downloads +``` + +ダウンロードされるバイナリは`downloads.txt`ファイルにリストされています。`cat`コマンドを使用して確認できます： + +```bash +cat downloads.txt +``` + +`downloads.txt`ファイルにリストされているバイナリを`wget`コマンドを使用してダウンロードします： + +```bash +wget -q --show-progress \ + --https-only \ + --timestamping \ + -P downloads \ + -i downloads.txt +``` + +インターネット接続速度によっては、`584`メガバイトのバイナリをダウンロードするのに時間がかかる場合があります。ダウンロードが完了したら、`ls`コマンドを使用してリストできます： + +```bash +ls -loh downloads +``` + +```text +total 584M +-rw-r--r-- 1 root 41M May 9 13:35 cni-plugins-linux-arm64-v1.3.0.tgz +-rw-r--r-- 1 root 34M Oct 26 15:21 containerd-1.7.8-linux-arm64.tar.gz +-rw-r--r-- 1 root 22M Aug 14 00:19 crictl-v1.28.0-linux-arm.tar.gz +-rw-r--r-- 1 root 15M Jul 11 02:30 etcd-v3.4.27-linux-arm64.tar.gz +-rw-r--r-- 1 root 111M Oct 18 07:34 kube-apiserver +-rw-r--r-- 1 root 107M Oct 18 07:34 kube-controller-manager +-rw-r--r-- 1 root 51M Oct 18 07:34 kube-proxy +-rw-r--r-- 1 root 52M Oct 18 07:34 kube-scheduler +-rw-r--r-- 1 root 46M Oct 18 07:34 kubectl +-rw-r--r-- 1 root 101M Oct 18 07:34 kubelet +-rw-r--r-- 1 root 9.6M Aug 10 18:57 runc.arm64 +``` + +### kubectlのインストール + +このセクションでは、公式のKubernetesクライアントコマンドラインツールである`kubectl`を`jumpbox`マシンにインストールします。`kubectl`は、後でクラスターがプロビジョニングされた後にKubernetesコントロールと対話するために使用されます。 + +`chmod`コマンドを使用して`kubectl`バイナリを実行可能にし、`/usr/local/bin/`ディレクトリに移動します： + +```bash +{ + chmod +x downloads/kubectl + cp downloads/kubectl /usr/local/bin/ +} +``` + +この時点で`kubectl`がインストールされ、`kubectl`コマンドを実行して確認できます： + +```bash +kubectl version --client +``` + +```text +Client Version: v1.28.3 +Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3 +``` + +この時点で、`jumpbox`はこのチュートリアルのラボを完了するために必要なすべてのコマンドラインツールとユーティリティでセットアップされています。 + +次: [コンピュートリソースのプロビジョニング](03-compute-resources.md) diff --git a/docs/ja/03-compute-resources.md b/docs/ja/03-compute-resources.md new file mode 100644 index 0000000..1db0c25 --- /dev/null +++ b/docs/ja/03-compute-resources.md @@ -0,0 +1,225 @@ +# コンピュートリソースのプロビジョニング + +Kubernetes には、Kubernetes コントロールプレーンとコンテナが最終的に実行されるワーカーノードをホストするための一連のマシンが必要です。このラボでは、Kubernetes クラスターをセットアップするために必要なマシンをプロビジョニングします。 + +## マシンデータベース + +このチュートリアルでは、Kubernetes コントロールプレーンとワーカーノードをセットアップする際に使用されるさまざまなマシン属性を保存するために、マシンデータベースとして機能するテキストファイルを活用します。以下のスキーマは、マシンデータベースのエントリを表しており、1行に1つのエントリが含まれます。 + +```text +IPV4_ADDRESS FQDN HOSTNAME POD_SUBNET +``` + +各列は、マシンの IP アドレス `IPV4_ADDRESS`、完全修飾ドメイン名 `FQDN`、ホスト名 `HOSTNAME`、および IP サブネット `POD_SUBNET` に対応しています。Kubernetes は `pod` ごとに 1 つの IP アドレスを割り当て、`POD_SUBNET` はクラスター内の各マシンに割り当てられた一意の IP アドレス範囲を表します。 + +以下は、このチュートリアルを作成する際に使用されたものと似たサンプルマシーンデータベースの例です。IP アドレスはマスクされています。自分のマシンには、互いに到達可能で `jumpbox` からも到達可能な任意の IP アドレスを割り当てることができます。 + +```bash +cat machines.txt +``` + +```text +XXX.XXX.XXX.XXX server.kubernetes.local server +XXX.XXX.XXX.XXX node-0.kubernetes.local node-0 10.200.0.0/24 +XXX.XXX.XXX.XXX node-1.kubernetes.local node-1 10.200.1.0/24 +``` + +今度は、Kubernetes クラスターを作成するために使用する 3 台のマシンの詳細を `machines.txt` ファイルに追加してください。上記のサンプルマシーンデータベースを使用し、自分のマシンの詳細を追加してください。 + +## SSH アクセスの構成 + +SSH は、クラスター内のマシンを構成するために使用されます。`machines.txt` ファイルに記載されている各マシンに対する `root` SSH アクセスを確認してください。各ノードで `root` SSH アクセスを有効にする必要がある場合は、`sshd_config` ファイルを更新し、SSH サーバーを再起動する必要があります。 + +### root SSH アクセスの有効化 + +自分のマシンで `root` SSH アクセスが既に有効になっている場合は、このセクションをスキップできます。 + +デフォルトでは、新しい `debian` インストールでは `root` ユーザーの SSH アクセスが無効になっています。これは、`root` ユーザーが Linux システムの一般的なユーザーであり、インターネットに接続されているマシンで弱いパスワードが使用されている場合、自分のマシンが他人の所有物になるのは時間の問題であるため、セキュリティ上の理由で行われます。ただし、このチュートリアルの手順を簡素化するために、`root` アクセスを SSH 上で有効にすることにします。セキュリティはトレードオフであり、この場合、便利性を最優先としています。各マシンに SSH を使用してユーザー アカウントでログインし、`su` コマンドを使用して `root` ユーザーに切り替えます。 + +```bash +su - root +``` + +`/etc/ssh/sshd_config` SSH デーモン構成ファイルの `PermitRootLogin` オプションを `yes` に設定します。 + +```bash +sed -i \ + 's/^#PermitRootLogin.*/PermitRootLogin yes/' \ + /etc/ssh/sshd_config +``` + +`sshd` SSH サーバーを再起動して、更新された構成ファイルを読み込むようにします。 + +```bash +systemctl restart sshd +``` + +### SSH キーの生成と配布 + +このセクションでは、`server`、`node-0`、`node-1` マシンでコマンドを実行するために使用される SSH キーペアを生成し、配布します。`jumpbox` マシンから以下のコマンドを実行します。 + +新しい SSH キーを生成します。 + +```bash +ssh-keygen +``` + +```text +秘密鍵と公開鍵のペアを生成します。 +Enter file in which to save the key (/root/.ssh/id_rsa): +パスフレーズを入力してください (パスフレーズを入力しない場合は空のまま): +パスフレーズを再入力してください: +/root/.ssh/id_rsa に識別情報が保存されました。 +/root/.ssh/id_rsa.pub に公開鍵が保存されました。 +``` + +各マシンに SSH 公開鍵をコピーします。 + +```bash +while read IP FQDN HOST SUBNET; do + ssh-copy-id root@${IP} +done < machines.txt +``` + +各キーの追加が完了したら、SSH 公開鍵アクセスが機能していることを確認します。 + +```bash +while read IP FQDN HOST SUBNET; do + ssh -n root@${IP} uname -o -m +done < machines.txt +``` + +```text +aarch64 GNU/Linux +aarch64 GNU/Linux +aarch64 GNU/Linux +``` + +## ホスト名 + +このセクションでは、`server`、`node-0`、`node-1` マシンにホスト名を割り当てます。ホスト名は、`jumpbox` から各マシンに対してコマンドを実行する際に使用されます。ホスト名は、Kubernetes クラスター内でも重要な役割を果たします。Kubernetes クライアントが Kubernetes API サーバーに対してコマンドを発行する際、IP アドレスではなく `server` ホスト名を使用します。ホスト名は、ワーカー マシンである `node-0` と `node-1` が特定の Kubernetes クラスターに登録する際にも使用されます。 + +`machines.txt` ファイルに記載されている各マシンのホスト名を構成するには、`jumpbox` から以下のコマンドを実行します。 + +`machines.txt` ファイルに記載されている各マシンのホスト名を設定します。 + +```bash +while read IP FQDN HOST SUBNET; do + CMD="sed -i 's/^127.0.1.1.*/127.0.1.1\t${FQDN} ${HOST}/' /etc/hosts" + ssh -n root@${IP} "$CMD" + ssh -n root@${IP} hostnamectl hostname ${HOST} +done < machines.txt +``` + +各マシンのホスト名が設定されていることを確認します。 + +```bash +while read IP FQDN HOST SUBNET; do + ssh -n root@${IP} hostname --fqdn +done < machines.txt +``` + +```text +server.kubernetes.local +node-0.kubernetes.local +node-1.kubernetes.local +``` + +## DNS + +このセクションでは、`jumpbox` のローカル `/etc/hosts` ファイルと、チュートリアルで使用する 3 台のマシンの `/etc/hosts` ファイルに追加される DNS `hosts` ファイルを生成します。これにより、各マシンがホスト名（`server`、`node-0`、`node-1`）を使用して到達可能になります。 + +新しい `hosts` ファイルを作成し、ヘッダーを追加してマシンを識別します。 + +```bash +echo "" > hosts +echo "# Kubernetes The Hard Way" >> hosts +``` + +`machines.txt` ファイルに記載されている各マシンに対する DNS エントリを生成し、`hosts` ファイルに追加します。 + +```bash +while read IP FQDN HOST SUBNET; do + ENTRY="${IP} ${FQDN} ${HOST}" + echo $ENTRY >> hosts +done < machines.txt +``` + +`hosts` ファイルの DNS エントリを確認します。 + +```bash +cat hosts +``` + +```text + +# Kubernetes The Hard Way +XXX.XXX.XXX.XXX server.kubernetes.local server +XXX.XXX.XXX.XXX node-0.kubernetes.local node-0 +XXX.XXX.XXX.XXX node-1.kubernetes.local node-1 +``` + +## ローカルマシンへの DNS エントリの追加 + +このセクションでは、`hosts` ファイルの DNS エントリを `jumpbox` マシンのローカル `/etc/hosts` ファイルに追加します。 + +`hosts` の DNS エントリを `/etc/hosts` に追加します。 + +```bash +cat hosts >> /etc/hosts +``` + +`/etc/hosts` ファイルが更新されたことを確認します。 + +```bash +cat /etc/hosts +``` + +```text +127.0.0.1 localhost +127.0.1.1 jumpbox + +# The following lines are desirable for IPv6 capable hosts +::1 localhost ip6-localhost ip6-loopback +ff02::1 ip6-allnodes +ff02::2 ip6-allrouters + + + +# Kubernetes The Hard Way +XXX.XXX.XXX.XXX server.kubernetes.local server +XXX.XXX.XXX.XXX node-0.kubernetes.local node-0 +XXX.XXX.XXX.XXX node-1.kubernetes.local node-1 +``` + +この時点で、`machines.txt` ファイルに記載されている各マシンに対して、ホスト名を使用して SSH できるようになっているはずです。 + +```bash +for host in server node-0 node-1 + do ssh root@${host} uname -o -m -n +done +``` + +```text +server aarch64 GNU/Linux +node-0 aarch64 GNU/Linux +node-1 aarch64 GNU/Linux +``` + +## リモートマシンへの DNS エントリの追加 + +このセクションでは、`machines.txt` テキストファイルに記載されている各マシンの `/etc/hosts` ファイルに `hosts` ファイルの DNS エントリを追加します。 + +`hosts` ファイルを各マシンにコピーし、`/etc/hosts` に追加します。 + +```bash +while read IP FQDN HOST SUBNET; do + scp hosts root@${HOST}:~/ + ssh -n \ + root@${HOST} "cat hosts >> /etc/hosts" +done < machines.txt +``` + +これで、`jumpbox` マシンまたは Kubernetes クラスター内の 3 台のマシンのいずれかから、IP アドレスの代わりにホスト名（`server`、`node-0`、`node-1`）を使用してマシンに接続できるようになりました。 + +次へ: [CA のプロビジョニングと TLS 証明書の生成](04-certificate-authority.md) diff --git a/docs/ja/04-certificate-authority.md b/docs/ja/04-certificate-authority.md new file mode 100644 index 0000000..ec53c21 --- /dev/null +++ b/docs/ja/04-certificate-authority.md @@ -0,0 +1,108 @@ +# CAのプロビジョニングとTLS証明書の生成 + +このラボでは、opensslを使用して[PKIインフラストラクチャ](https://en.wikipedia.org/wiki/Public_key_infrastructure)をプロビジョニングし、Certificate Authorityをブートストラップし、以下のコンポーネントのためのTLS証明書を生成します：kube-apiserver、kube-controller-manager、kube-scheduler、kubelet、およびkube-proxy。このセクションのコマンドは`jumpbox`から実行する必要があります。 + +## Certificate Authority + +このセクションでは、他のKubernetesコンポーネントのために追加のTLS証明書を生成するために使用できるCertificate Authorityをプロビジョニングします。CAの設定と`openssl`を使用した証明書の生成は、特に初めて行う場合には時間がかかることがあります。このラボを効率化するために、各Kubernetesコンポーネントの証明書を生成するために必要な詳細を定義したopenssl設定ファイル`ca.conf`を含めました。 + +`ca.conf`設定ファイルを確認してください： + +```bash +cat ca.conf +``` + +このチュートリアルを完了するために`ca.conf`ファイルのすべてを理解する必要はありませんが、`openssl`と証明書管理の高レベルな設定を学ぶための出発点と考えてください。 + +すべてのCertificate Authorityは、プライベートキーとルート証明書から始まります。このセクションでは自己署名のCertificate Authorityを作成しますが、これはこのチュートリアルに必要なすべてであり、実際のプロダクション環境で行うべきことではありません。 + +CA設定ファイル、証明書、およびプライベートキーを生成します： + +```bash +{ + openssl genrsa -out ca.key 4096 + openssl req -x509 -new -sha512 -noenc \ + -key ca.key -days 3653 \ + -config ca.conf \ + -out ca.crt +} +``` + +結果： + +```txt +ca.crt ca.key +``` + +## クライアントとサーバーの証明書の作成 + +このセクションでは、各KubernetesコンポーネントとKubernetes `admin`ユーザーのためのクライアント証明書を生成します。 + +証明書とプライベートキーを生成します： + +```bash +certs=( + "admin" "node-0" "node-1" + "kube-proxy" "kube-scheduler" + "kube-controller-manager" + "kube-api-server" + "service-accounts" +) +``` + +```bash +for i in ${certs[*]}; do + openssl genrsa -out "${i}.key" 4096 + + openssl req -new -key "${i}.key" -sha256 \ + -config "ca.conf" -section ${i} \ + -out "${i}.csr" + + openssl x509 -req -days 3653 -in "${i}.csr" \ + -copy_extensions copyall \ + -sha256 -CA "ca.crt" \ + -CAkey "ca.key" \ + -CAcreateserial \ + -out "${i}.crt" +done +``` + +上記のコマンドを実行すると、各Kubernetesコンポーネントのプライベートキー、証明書要求、および署名されたSSL証明書が生成されます。以下のコマンドで生成されたファイルをリストできます： + +```bash +ls -1 *.crt *.key *.csr +``` + +## クライアントとサーバーの証明書の配布 + +このセクションでは、各マシンに適切な証明書とプライベートキーをコピーします。Kubernetesコンポーネントが互いに認証するために使用される資格情報としてこれらの証明書を扱う必要があります。 + +`node-0`と`node-1`マシンに適切な証明書とプライベートキーをコピーします： + +```bash +for host in node-0 node-1; do + ssh root@$host mkdir /var/lib/kubelet/ + + scp ca.crt root@$host:/var/lib/kubelet/ + + scp $host.crt \ + root@$host:/var/lib/kubelet/kubelet.crt + + scp $host.key \ + root@$host:/var/lib/kubelet/kubelet.key +done +``` + +`server`マシンに適切な証明書とプライベートキーをコピーします： + +```bash +scp \ + ca.key ca.crt \ + kube-api-server.key kube-api-server.crt \ + service-accounts.key service-accounts.crt \ + root@server:~/ +``` + +> `kube-proxy`、`kube-controller-manager`、`kube-scheduler`、`kubelet`クライアント証明書は、次のラボで認証構成ファイルを生成するために使用されます。 + +次：[認証のためのKubernetes構成ファイルの生成](05-kubernetes-configuration-files.md) diff --git a/docs/ja/05-kubernetes-configuration-files.md b/docs/ja/05-kubernetes-configuration-files.md new file mode 100644 index 0000000..03eb445 --- /dev/null +++ b/docs/ja/05-kubernetes-configuration-files.md @@ -0,0 +1,209 @@ +# 認証のためのKubernetes構成ファイルの生成 + +このラボでは、KubernetesクライアントがKubernetes APIサーバーを見つけて認証できるようにする[Kubernetes構成ファイル](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/)、別名kubeconfigを生成します。 + +## クライアント認証構成 + +このセクションでは、`kubelet`および`admin`ユーザーのためのkubeconfigファイルを生成します。 + +### kubeletのKubernetes構成ファイル + +Kubeletのためのkubeconfigファイルを生成する際には、Kubeletのノード名に一致するクライアント証明書を使用する必要があります。これにより、KubeletがKubernetesの[ノード認可者](https://kubernetes.io/docs/admin/authorization/node/)によって適切に認可されることが保証されます。 + +> 以下のコマンドは、[TLS証明書の生成](04-certificate-authority.md)ラボで使用したディレクトリ内で実行する必要があります。 + +node-0ワーカーノードのためのkubeconfigファイルを生成します： + +```bash +for host in node-0 node-1; do + kubectl config set-cluster kubernetes-the-hard-way \ + --certificate-authority=ca.crt \ + --embed-certs=true \ + --server=https://server.kubernetes.local:6443 \ + --kubeconfig=${host}.kubeconfig + + kubectl config set-credentials system:node:${host} \ + --client-certificate=${host}.crt \ + --client-key=${host}.key \ + --embed-certs=true \ + --kubeconfig=${host}.kubeconfig + + kubectl config set-context default \ + --cluster=kubernetes-the-hard-way \ + --user=system:node:${host} \ + --kubeconfig=${host}.kubeconfig + + kubectl config use-context default \ + --kubeconfig=${host}.kubeconfig +done +``` + +結果： + +```text +node-0.kubeconfig +node-1.kubeconfig +``` + +### kube-proxyのKubernetes構成ファイル + +`kube-proxy`サービスのためのkubeconfigファイルを生成します： + +```bash +{ + kubectl config set-cluster kubernetes-the-hard-way \ + --certificate-authority=ca.crt \ + --embed-certs=true \ + --server=https://server.kubernetes.local:6443 \ + --kubeconfig=kube-proxy.kubeconfig + + kubectl config set-credentials system:kube-proxy \ + --client-certificate=kube-proxy.crt \ + --client-key=kube-proxy.key \ + --embed-certs=true \ + --kubeconfig=kube-proxy.kubeconfig + + kubectl config set-context default \ + --cluster=kubernetes-the-hard-way \ + --user=system:kube-proxy \ + --kubeconfig=kube-proxy.kubeconfig + + kubectl config use-context default \ + --kubeconfig=kube-proxy.kubeconfig +} +``` + +結果： + +```text +kube-proxy.kubeconfig +``` + +### kube-controller-managerのKubernetes構成ファイル + +`kube-controller-manager`サービスのためのkubeconfigファイルを生成します： + +```bash +{ + kubectl config set-cluster kubernetes-the-hard-way \ + --certificate-authority=ca.crt \ + --embed-certs=true \ + --server=https://server.kubernetes.local:6443 \ + --kubeconfig=kube-controller-manager.kubeconfig + + kubectl config set-credentials system:kube-controller-manager \ + --client-certificate=kube-controller-manager.crt \ + --client-key=kube-controller-manager.key \ + --embed-certs=true \ + --kubeconfig=kube-controller-manager.kubeconfig + + kubectl config set-context default \ + --cluster=kubernetes-the-hard-way \ + --user=system:kube-controller-manager \ + --kubeconfig=kube-controller-manager.kubeconfig + + kubectl config use-context default \ + --kubeconfig=kube-controller-manager.kubeconfig +} +``` + +結果： + +```text +kube-controller-manager.kubeconfig +``` + +### kube-schedulerのKubernetes構成ファイル + +`kube-scheduler`サービスのためのkubeconfigファイルを生成します： + +```bash +{ + kubectl config set-cluster kubernetes-the-hard-way \ + --certificate-authority=ca.crt \ + --embed-certs=true \ + --server=https://server.kubernetes.local:6443 \ + --kubeconfig=kube-scheduler.kubeconfig + + kubectl config set-credentials system:kube-scheduler \ + --client-certificate=kube-scheduler.crt \ + --client-key=kube-scheduler.key \ + --embed-certs=true \ + --kubeconfig=kube-scheduler.kubeconfig + + kubectl config set-context default \ + --cluster=kubernetes-the-hard-way \ + --user=system:kube-scheduler \ + --kubeconfig=kube-scheduler.kubeconfig + + kubectl config use-context default \ + --kubeconfig=kube-scheduler.kubeconfig +} +``` + +結果： + +```text +kube-scheduler.kubeconfig +``` + +### adminのKubernetes構成ファイル + +`admin`ユーザーのためのkubeconfigファイルを生成します： + +```bash +{ + kubectl config set-cluster kubernetes-the-hard-way \ + --certificate-authority=ca.crt \ + --embed-certs=true \ + --server=https://127.0.0.1:6443 \ + --kubeconfig=admin.kubeconfig + + kubectl config set-credentials admin \ + --client-certificate=admin.crt \ + --client-key=admin.key \ + --embed-certs=true \ + --kubeconfig=admin.kubeconfig + + kubectl config set-context default \ + --cluster=kubernetes-the-hard-way \ + --user=admin \ + --kubeconfig=admin.kubeconfig + + kubectl config use-context default \ + --kubeconfig=admin.kubeconfig +} +``` + +結果： + +```text +admin.kubeconfig +``` + +## Kubernetes構成ファイルの配布 + +node-0インスタンスに`kubelet`と`kube-proxy`のkubeconfigファイルをコピーします： + +```bash +for host in node-0 node-1; do + ssh root@$host "mkdir /var/lib/{kube-proxy,kubelet}" + + scp kube-proxy.kubeconfig \ + root@$host:/var/lib/kube-proxy/kubeconfig \ + + scp ${host}.kubeconfig \ + root@$host:/var/lib/kubelet/kubeconfig +done +``` + +コントローラーインスタンスに`kube-controller-manager`と`kube-scheduler`のkubeconfigファイルをコピーします： + +```bash +scp admin.kubeconfig \ + kube-controller-manager.kubeconfig \ + kube-scheduler.kubeconfig \ + root@server:~/ +``` + +次: [データ暗号化構成とキーの生成](06-data-encryption-keys.md) diff --git a/docs/ja/06-data-encryption-keys.md b/docs/ja/06-data-encryption-keys.md new file mode 100644 index 0000000..4e43427 --- /dev/null +++ b/docs/ja/06-data-encryption-keys.md @@ -0,0 +1,30 @@ +# データ暗号化構成とキーの生成 + +Kubernetesは、クラスタの状態、アプリケーションの構成、シークレットなど、さまざまなデータを保存します。Kubernetesは、クラスタデータを保存時に[暗号化](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data)（Encryption at Rest）する機能をサポートしています。 + +このラボでは、Kubernetesシークレットを暗号化するのに適した暗号化キーと[暗号化構成](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/#understanding-the-encryption-at-rest-configuration)を生成します。 + +## 暗号化キー + +暗号化キーを生成します： + +```bash +export ENCRYPTION_KEY=$(head -c 32 /dev/urandom | base64) +``` + +## 暗号化構成ファイル + +`encryption-config.yaml`暗号化構成ファイルを作成します： + +```bash +envsubst < configs/encryption-config.yaml \ + > encryption-config.yaml +``` + +`encryption-config.yaml`暗号化構成ファイルを各コントローラーインスタンスにコピーします： + +```bash +scp encryption-config.yaml root@server:~/ +``` + +次: [etcdクラスタのブートストラップ](07-bootstrapping-etcd.md) diff --git a/docs/ja/07-bootstrapping-etcd.md b/docs/ja/07-bootstrapping-etcd.md new file mode 100644 index 0000000..167e241 --- /dev/null +++ b/docs/ja/07-bootstrapping-etcd.md @@ -0,0 +1,76 @@ +# etcdクラスタのブートストラップ + +Kubernetesコンポーネントはステートレスであり、クラスタの状態を[etcd](https://github.com/etcd-io/etcd)に保存します。このラボでは、3ノードのetcdクラスタをブートストラップし、高可用性と安全なリモートアクセスのために設定します。 + +## 前提条件 + +`etcd`バイナリとsystemdユニットファイルを`server`インスタンスにコピーします： + +```bash +scp \ + downloads/etcd-v3.4.27-linux-arm64.tar.gz \ + units/etcd.service \ + root@server:~/ +``` + +このラボのコマンドはすべて`server`マシン上で実行する必要があります。`ssh`コマンドを使用して`server`マシンにログインします。例： + +```bash +ssh root@server +``` + +## etcdクラスタのブートストラップ + +### etcdバイナリのインストール + +`etcd`サーバーと`etcdctl`コマンドラインユーティリティを抽出してインストールします： + +```bash +{ + tar -xvf etcd-v3.4.27-linux-arm64.tar.gz + mv etcd-v3.4.27-linux-arm64/etcd* /usr/local/bin/ +} +``` + +### etcdサーバーの設定 + +```bash +{ + mkdir -p /etc/etcd /var/lib/etcd + chmod 700 /var/lib/etcd + cp ca.crt kube-api-server.key kube-api-server.crt \ + /etc/etcd/ +} +``` + +etcdクラスタの各メンバーには固有の名前が必要です。現在のコンピュートインスタンスのホスト名に一致する名前を設定します： + +`etcd.service` systemdユニットファイルを作成します： + +```bash +mv etcd.service /etc/systemd/system/ +``` + +### etcdサーバーの起動 + +```bash +{ + systemctl daemon-reload + systemctl enable etcd + systemctl start etcd +} +``` + +## 検証 + +etcdクラスタメンバーを一覧表示します： + +```bash +etcdctl member list +``` + +```text +6702b0a34e2cfd39, started, controller, http://127.0.0.1:2380, http://127.0.0.1:2379, false +``` + +次: [Kubernetesコントロールプレーンのブートストラップ](08-bootstrapping-kubernetes-controllers.md) diff --git a/docs/ja/08-bootstrapping-kubernetes-controllers.md b/docs/ja/08-bootstrapping-kubernetes-controllers.md new file mode 100644 index 0000000..2b1470b --- /dev/null +++ b/docs/ja/08-bootstrapping-kubernetes-controllers.md @@ -0,0 +1,179 @@ +# Kubernetesコントロールプレーンのブートストラップ + +このラボでは、Kubernetesコントロールプレーンをブートストラップします。以下のコンポーネントがコントローラーマシンにインストールされます：Kubernetes API Server、Scheduler、およびController Manager。 + +## 前提条件 + +Kubernetesバイナリとsystemdユニットファイルを`server`インスタンスにコピーします： + +```bash +scp \ + downloads/kube-apiserver \ + downloads/kube-controller-manager \ + downloads/kube-scheduler \ + downloads/kubectl \ + units/kube-apiserver.service \ + units/kube-controller-manager.service \ + units/kube-scheduler.service \ + configs/kube-scheduler.yaml \ + configs/kube-apiserver-to-kubelet.yaml \ + root@server:~/ +``` + +このラボのコマンドはすべてコントローラーインスタンス`server`上で実行する必要があります。`ssh`コマンドを使用してコントローラーインスタンスにログインします。例： + +```bash +ssh root@server +``` + +## Kubernetesコントロールプレーンのプロビジョニング + +Kubernetes構成ディレクトリを作成します： + +```bash +mkdir -p /etc/kubernetes/config +``` + +### Kubernetesコントローラーバイナリのインストール + +Kubernetesバイナリをインストールします： + +```bash +{ + chmod +x kube-apiserver \ + kube-controller-manager \ + kube-scheduler kubectl + + mv kube-apiserver \ + kube-controller-manager \ + kube-scheduler kubectl \ + /usr/local/bin/ +} +``` + +### Kubernetes API Serverの構成 + +```bash +{ + mkdir -p /var/lib/kubernetes/ + + mv ca.crt ca.key \ + kube-api-server.key kube-api-server.crt \ + service-accounts.key service-accounts.crt \ + encryption-config.yaml \ + /var/lib/kubernetes/ +} +``` + +`kube-apiserver.service` systemdユニットファイルを作成します： + +```bash +mv kube-apiserver.service \ + /etc/systemd/system/kube-apiserver.service +``` + +### Kubernetes Controller Managerの構成 + +`kube-controller-manager` kubeconfigを適切な場所に移動します： + +```bash +mv kube-controller-manager.kubeconfig /var/lib/kubernetes/ +``` + +`kube-controller-manager.service` systemdユニットファイルを作成します： + +```bash +mv kube-controller-manager.service /etc/systemd/system/ +``` + +### Kubernetes Schedulerの構成 + +`kube-scheduler` kubeconfigを適切な場所に移動します： + +```bash +mv kube-scheduler.kubeconfig /var/lib/kubernetes/ +``` + +`kube-scheduler.yaml`構成ファイルを作成します： + +```bash +mv kube-scheduler.yaml /etc/kubernetes/config/ +``` + +`kube-scheduler.service` systemdユニットファイルを作成します： + +```bash +mv kube-scheduler.service /etc/systemd/system/ +``` + +### コントローラーサービスの起動 + +```bash +{ + systemctl daemon-reload + + systemctl enable kube-apiserver \ + kube-controller-manager kube-scheduler + + systemctl start kube-apiserver \ + kube-controller-manager kube-scheduler +} +``` + +> Kubernetes API Serverの完全な初期化まで最大10秒かかる場合があります。 + +### 検証 + +```bash +kubectl cluster-info \ + --kubeconfig admin.kubeconfig +``` + +```text +Kubernetesコントロールプレーンはhttps://127.0.0.1:6443で実行中です +``` + +## Kubelet認可のためのRBAC + +このセクションでは、Kubernetes API Serverが各ワーカーノードのKubelet APIにアクセスできるようにRBAC権限を構成します。Kubelet APIへのアクセスは、メトリクスの取得、ログの取得、およびポッドでのコマンドの実行に必要です。 + +> このチュートリアルでは、Kubeletの`--authorization-mode`フラグを`Webhook`に設定します。Webhookモードでは、[SubjectAccessReview](https://kubernetes.io/docs/admin/authorization/#checking-api-access) APIを使用して認可を決定します。 + +このセクションのコマンドは、クラスタ全体に影響を与えるため、コントローラーノード上で実行する必要があります。 + +```bash +ssh root@server +``` + +`system:kube-apiserver-to-kubelet` [ClusterRole](https://kubernetes.io/docs/admin/authorization/rbac/#role-and-clusterrole)を作成し、Kubelet APIへのアクセス権限とポッドの管理に関連するタスクの実行権限を付与します： + +```bash +kubectl apply -f kube-apiserver-to-kubelet.yaml \ + --kubeconfig admin.kubeconfig +``` + +### 検証 + +この時点で、Kubernetesコントロールプレーンが稼働しています。`jumpbox`マシンから以下のコマンドを実行して検証します： + +Kubernetesバージョン情報のHTTPリクエストを送信します： + +```bash +curl -k --cacert ca.crt https://server.kubernetes.local:6443/version +``` + +```text +{ + "major": "1", + "minor": "28", + "gitVersion": "v1.28.3", + "gitCommit": "a8a1abc25cad87333840cd7d54be2efaf31a3177", + "gitTreeState": "clean", + "buildDate": "2023-10-18T11:33:18Z", + "goVersion": "go1.20.10", + "compiler": "gc", + "platform": "linux/arm64" +} +``` + +次: [Kubernetesワーカーノードのブートストラップ](09-bootstrapping-kubernetes-workers.md) diff --git a/docs/ja/09-bootstrapping-kubernetes-workers.md b/docs/ja/09-bootstrapping-kubernetes-workers.md new file mode 100644 index 0000000..2366a5d --- /dev/null +++ b/docs/ja/09-bootstrapping-kubernetes-workers.md @@ -0,0 +1,176 @@ +# Kubernetesワーカーノードのブートストラップ + +このラボでは、2つのKubernetesワーカーノードをブートストラップします。以下のコンポーネントがインストールされます: [runc](https://github.com/opencontainers/runc), [container networking plugins](https://github.com/containernetworking/cni), [containerd](https://github.com/containerd/containerd), [kubelet](https://kubernetes.io/docs/admin/kubelet), および [kube-proxy](https://kubernetes.io/docs/concepts/cluster-administration/proxies)。 + +## 前提条件 + +Kubernetesバイナリとsystemdユニットファイルを各ワーカーインスタンスにコピーします: + +```bash +for host in node-0 node-1; do + SUBNET=$(grep $host machines.txt | cut -d " " -f 4) + sed "s|SUBNET|$SUBNET|g" \ + configs/10-bridge.conf > 10-bridge.conf + + sed "s|SUBNET|$SUBNET|g" \ + configs/kubelet-config.yaml > kubelet-config.yaml + + scp 10-bridge.conf kubelet-config.yaml \ + root@$host:~/ +done +``` + +```bash +for host in node-0 node-1; do + scp \ + downloads/runc.arm64 \ + downloads/crictl-v1.28.0-linux-arm.tar.gz \ + downloads/cni-plugins-linux-arm64-v1.3.0.tgz \ + downloads/containerd-1.7.8-linux-arm64.tar.gz \ + downloads/kubectl \ + downloads/kubelet \ + downloads/kube-proxy \ + configs/99-loopback.conf \ + configs/containerd-config.toml \ + configs/kubelet-config.yaml \ + configs/kube-proxy-config.yaml \ + units/containerd.service \ + units/kubelet.service \ + units/kube-proxy.service \ + root@$host:~/ +done +``` + +このラボのコマンドは各ワーカーインスタンス（`node-0`、`node-1`）で実行する必要があります。`ssh`コマンドを使用してワーカーインスタンスにログインします。例: + +```bash +ssh root@node-0 +``` + +## Kubernetesワーカーノードのプロビジョニング + +OS依存関係をインストールします: + +```bash +{ + apt-get update + apt-get -y install socat conntrack ipset +} +``` + +> socatバイナリは`kubectl port-forward`コマンドのサポートを有効にします。 + +### スワップの無効化 + +デフォルトでは、[swap](https://help.ubuntu.com/community/SwapFaq)が有効になっているとkubeletは起動に失敗します。Kubernetesが適切なリソース割り当てとサービス品質を提供できるようにするために、スワップを無効にすることが[推奨](https://github.com/kubernetes/kubernetes/issues/7294)されています。 + +スワップが有効かどうかを確認します: + +```bash +swapon --show +``` + +出力が空であればスワップは有効ではありません。スワップが有効であれば、次のコマンドを実行してスワップを即座に無効にします: + +```bash +swapoff -a +``` + +> 再起動後もスワップが無効のままであることを確認するには、Linuxディストリビューションのドキュメントを参照してください。 + +インストールディレクトリを作成します: + +```bash +mkdir -p \ + /etc/cni/net.d \ + /opt/cni/bin \ + /var/lib/kubelet \ + /var/lib/kube-proxy \ + /var/lib/kubernetes \ + /var/run/kubernetes +``` + +ワーカーバイナリをインストールします: + +```bash +{ + mkdir -p containerd + tar -xvf crictl-v1.28.0-linux-arm.tar.gz + tar -xvf containerd-1.7.8-linux-arm64.tar.gz -C containerd + tar -xvf cni-plugins-linux-arm64-v1.3.0.tgz -C /opt/cni/bin/ + mv runc.arm64 runc + chmod +x crictl kubectl kube-proxy kubelet runc + mv crictl kubectl kube-proxy kubelet runc /usr/local/bin/ + mv containerd/bin/* /bin/ +} +``` + +### CNIネットワークの構成 + +`bridge`ネットワーク構成ファイルを作成します: + +```bash +mv 10-bridge.conf 99-loopback.conf /etc/cni/net.d/ +``` + +### containerdの構成 + +`containerd`構成ファイルをインストールします: + +```bash +{ + mkdir -p /etc/containerd/ + mv containerd-config.toml /etc/containerd/config.toml + mv containerd.service /etc/systemd/system/ +} +``` + +### kubeletの構成 + +`kubelet-config.yaml`構成ファイルを作成します: + +```bash +{ + mv kubelet-config.yaml /var/lib/kubelet/ + mv kubelet.service /etc/systemd/system/ +} +``` + +### Kubernetesプロキシの構成 + +```bash +{ + mv kube-proxy-config.yaml /var/lib/kube-proxy/ + mv kube-proxy.service /etc/systemd/system/ +} +``` + +### ワーカーサービスの起動 + +```bash +{ + systemctl daemon-reload + systemctl enable containerd kubelet kube-proxy + systemctl start containerd kubelet kube-proxy +} +``` + +## 検証 + +このチュートリアルのコンピュートインスタンスではこのセクションを完了する権限がありません。`jumpbox`マシンから次のコマンドを実行してください。 + +登録されているKubernetesノードをリストします: + +```bash +ssh root@server \ + "kubectl get nodes \ + --kubeconfig admin.kubeconfig" +``` + +``` +NAME STATUS ROLES AGE VERSION +node-0 Ready 1m v1.28.3 +node-1 Ready 10s v1.28.3 +``` + +次: [リモートアクセス用のkubectlの構成](10-configuring-kubectl.md) diff --git a/docs/ja/10-configuring-kubectl.md b/docs/ja/10-configuring-kubectl.md new file mode 100644 index 0000000..2c9238b --- /dev/null +++ b/docs/ja/10-configuring-kubectl.md @@ -0,0 +1,80 @@ +# kubectlのリモートアクセス設定 + +このラボでは、`admin`ユーザーの資格情報に基づいて`kubectl`コマンドラインユーティリティ用のkubeconfigファイルを生成します。 + +> このラボのコマンドは`jumpbox`マシンから実行してください。 + +## Admin Kubernetes設定ファイル + +各kubeconfigには接続するKubernetes APIサーバーが必要です。 + +前のラボで設定した`/etc/hosts`のDNSエントリに基づいて、`server.kubernetes.local`にpingできるはずです。 + +```bash +curl -k --cacert ca.crt \ + https://server.kubernetes.local:6443/version +``` + +```text +{ + "major": "1", + "minor": "28", + "gitVersion": "v1.28.3", + "gitCommit": "a8a1abc25cad87333840cd7d54be2efaf31a3177", + "gitTreeState": "clean", + "buildDate": "2023-10-18T11:33:18Z", + "goVersion": "go1.20.10", + "compiler": "gc", + "platform": "linux/arm64" +} +``` + +`admin`ユーザーとして認証するためのkubeconfigファイルを生成します： + +```bash +{ + kubectl config set-cluster kubernetes-the-hard-way \ + --certificate-authority=ca.crt \ + --embed-certs=true \ + --server=https://server.kubernetes.local:6443 + + kubectl config set-credentials admin \ + --client-certificate=admin.crt \ + --client-key=admin.key + + kubectl config set-context kubernetes-the-hard-way \ + --cluster=kubernetes-the-hard-way \ + --user=admin + + kubectl config use-context kubernetes-the-hard-way +} +``` +上記のコマンドを実行すると、`kubectl`コマンドラインツールが使用するデフォルトの場所`~/.kube/config`にkubeconfigファイルが作成されます。これにより、configを指定せずに`kubectl`コマンドを実行できるようになります。 + +## 検証 + +リモートKubernetesクラスターのバージョンを確認します： + +```bash +kubectl version +``` + +```text +Client Version: v1.28.3 +Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3 +Server Version: v1.28.3 +``` + +リモートKubernetesクラスターのノードをリストします： + +```bash +kubectl get nodes +``` + +``` +NAME STATUS ROLES AGE VERSION +node-0 Ready 30m v1.28.3 +node-1 Ready 35m v1.28.3 +``` + +次: [Pod Network Routesのプロビジョニング](11-pod-network-routes.md) diff --git a/docs/ja/11-pod-network-routes.md b/docs/ja/11-pod-network-routes.md new file mode 100644 index 0000000..be6339a --- /dev/null +++ b/docs/ja/11-pod-network-routes.md @@ -0,0 +1,77 @@ +# Podネットワークルートのプロビジョニング + +ノードにスケジュールされたPodは、ノードのPod CIDR範囲からIPアドレスを受け取ります。この時点では、ネットワーク[ルート](https://cloud.google.com/compute/docs/vpc/routes)が欠如しているため、異なるノード上で実行されている他のPodと通信することはできません。 + +このラボでは、各ワーカーノードのPod CIDR範囲をノードの内部IPアドレスにマッピングするルートを作成します。 + +> Kubernetesネットワーキングモデルを実装する[他の方法](https://kubernetes.io/docs/concepts/cluster-administration/networking/#how-to-achieve-this)もあります。 + +## ルーティングテーブル + +このセクションでは、`kubernetes-the-hard-way` VPCネットワークにルートを作成するために必要な情報を収集します。 + +各ワーカーインスタンスの内部IPアドレスとPod CIDR範囲を表示します： + +```bash +{ + SERVER_IP=$(grep server machines.txt | cut -d " " -f 1) + NODE_0_IP=$(grep node-0 machines.txt | cut -d " " -f 1) + NODE_0_SUBNET=$(grep node-0 machines.txt | cut -d " " -f 4) + NODE_1_IP=$(grep node-1 machines.txt | cut -d " " -f 1) + NODE_1_SUBNET=$(grep node-1 machines.txt | cut -d " " -f 4) +} +``` + +```bash +ssh root@server <| +00000080 c4 e9 69 1c 10 7a 9d f7 dc 22 28 89 2c 83 dd 0b |..i..z..."(.,...| +00000090 a4 5f 3a 93 0f ff 1f f8 bc 97 43 0e e5 05 5d f9 |._:.......C...].| +000000a0 ef 88 02 80 49 81 f1 58 b0 48 39 19 14 e1 b1 34 |....I..X.H9....4| +000000b0 f6 b0 9b 0a 9c 53 27 2b 23 b9 e6 52 b4 96 81 70 |.....S'+#..R...p| +000000c0 a7 b6 7b 4f 44 d4 9c 07 51 a3 1b 22 96 4c 24 6c |..{OD...Q..".L$l| +000000d0 44 6c db 53 f5 31 e6 3f 15 7b 4c 23 06 c1 37 73 |Dl.S.1.?.{L#..7s| +000000e0 e1 97 8e 4e 1a 2e 2c 1a da 85 c3 ff 42 92 d0 f1 |...N..,.....B...| +000000f0 87 b8 39 89 e8 46 2e b3 56 68 41 b8 1e 29 3d ba |..9..F..VhA..)=.| +00000100 dd d8 27 4c 7f d5 fe 97 3c a3 92 e9 3d ae 47 ee |..'L....<...=.G.| +00000110 24 6a 0b 7c ac b8 28 e6 25 a6 ce 04 80 ee c2 eb |$j.|..(.%.......| +00000120 4c 86 fa 70 66 13 63 59 03 c2 70 57 8b fb a1 d6 |L..pf.cY..pW....| +00000130 f2 58 08 84 43 f3 70 7f ad d8 30 63 3e ef ff b6 |.X..C.p...0c>...| +00000140 b2 06 c3 45 c5 d8 89 d3 47 4a 72 ca 20 9b cf b5 |...E....GJr. ...| +00000150 4b 3d 6d b4 58 ae 42 4b 7f 0a |K=m.X.BK..| +0000015a +``` + +etcdキーの先頭には`k8s:enc:aescbc:v1:key1`というプレフィックスが付いており、`aescbc`プロバイダーが`key1`暗号化キーを使用してデータを暗号化したことを示しています。 + +## デプロイメント + +このセクションでは、[デプロイメント](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)の作成と管理機能を確認します。 + +[nginx](https://nginx.org/en/)ウェブサーバーのデプロイメントを作成します： + +```bash +kubectl create deployment nginx \ + --image=nginx:latest +``` + +`nginx`デプロイメントによって作成されたポッドをリストします： + +```bash +kubectl get pods -l app=nginx +``` + +```bash +NAME READY STATUS RESTARTS AGE +nginx-56fcf95486-c8dnx 1/1 Running 0 8s +``` + +### ポートフォワーディング + +このセクションでは、[ポートフォワーディング](https://kubernetes.io/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)を使用してアプリケーションにリモートアクセスできるかどうかを確認します。 + +`nginx`ポッドの完全な名前を取得します： + +```bash +POD_NAME=$(kubectl get pods -l app=nginx \ + -o jsonpath="{.items[0].metadata.name}") +``` + +ローカルマシンのポート`8080`を`nginx`ポッドのポート`80`にフォワードします： + +```bash +kubectl port-forward $POD_NAME 8080:80 +``` + +```text +127.0.0.1:8080 -> 80 +[::1]:8080 -> 80 +``` + +新しいターミナルでフォワーディングアドレスを使用してHTTPリクエストを送信します： + +```bash +curl --head http://127.0.0.1:8080 +``` + +```text +HTTP/1.1 200 OK +Server: nginx/1.25.3 +Date: Sun, 29 Oct 2023 01:44:32 GMT +Content-Type: text/html +Content-Length: 615 +Last-Modified: Tue, 24 Oct 2023 13:46:47 GMT +Connection: keep-alive +ETag: "6537cac7-267" +Accept-Ranges: bytes + +``` + +前のターミナルに戻り、`nginx`ポッドへのポートフォワーディングを停止します： + +```text +127.0.0.1:8080 -> 80 +[::1]:8080 -> 80 +8080の接続を処理中 +^C +``` + +### ログ + +このセクションでは、[コンテナーのログを取得](https://kubernetes.io/docs/concepts/cluster-administration/logging/)できるかどうかを確認します。 + +`nginx`ポッドのログを表示します： + +```bash +kubectl logs $POD_NAME +``` + +```text +... +127.0.0.1 - - [01/Nov/2023:06:10:17 +0000] "HEAD / HTTP/1.1" 200 0 "-" "curl/7.88.1" "-" +``` + +### Exec + +このセクションでは、[コンテナ内でコマンドを実行](https://kubernetes.io/docs/tasks/debug-application-cluster/get-shell-running-container/#running-individual-commands-in-a-container)できるかどうかを確認します。 + +`nginx`コンテナ内で`nginx -v`コマンドを実行してnginxのバージョンを表示します： + +```bash +kubectl exec -ti $POD_NAME -- nginx -v +``` + +```text +nginx version: nginx/1.25.3 +``` + +## サービス + +このセクションでは、[サービス](https://kubernetes.io/docs/concepts/services-networking/service/)を使用してアプリケーションを公開できるかどうかを確認します。 + +`nginx`デプロイメントを[NodePort](https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport)サービスを使用して公開します： + +```bash +kubectl expose deployment nginx \ + --port 80 --type NodePort +``` + +> [LoadBalancer](https://kubernetes.io/docs/getting-started-guides/scratch/#cloud-provider)サービスタイプは使用できません。クラスタが[クラウドプロバイダーの統合](https://kubernetes.io/docs/getting-started-guides/scratch/#cloud-provider)が設定されていないためです。このチュートリアルのスコープ外です。 + +`nginx`サービスの割り当てられたノードポートを取得します： + +```bash +NODE_PORT=$(kubectl get svc nginx \ + --output=jsonpath='{range .spec.ports[0]}{.nodePort}') +``` + +ノードのIPアドレスと`nginx`ノードポートを使用してHTTPリクエストを送信します： + +```bash +curl -I http://node-0:${NODE_PORT} +``` + +```text +HTTP/1.1 200 OK +Server: nginx/1.25.3 +Date: Sun, 29 Oct 2023 05:11:15 GMT +Content-Type: text/html +Content-Length: 615 +Last-Modified: Tue, 24 Oct 2023 13:46:47 GMT +Connection: keep-alive +ETag: "6537cac7-267" +Accept-Ranges: bytes +``` + +次: [クリーンアップ](13-cleanup.md) diff --git a/docs/ja/13-cleanup.md b/docs/ja/13-cleanup.md new file mode 100644 index 0000000..b71c676 --- /dev/null +++ b/docs/ja/13-cleanup.md @@ -0,0 +1,7 @@ +# クリーンアップ + +このラボでは、このチュートリアル中に作成したコンピュートリソースを削除します。 + +## コンピュートインスタンス + +コントローラーとワーカーのコンピュートインスタンスを削除します。