docs(ja): add initial Japanese translation to documentation

pull/805/head
kahirokunn 2024-08-22 10:00:27 +09:00
parent a9cb5f7ba5
commit 3001d8f574
No known key found for this signature in database
13 changed files with 1508 additions and 0 deletions

View File

@ -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)

121
docs/ja/02-jumpbox.md Normal file
View File

@ -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)

View File

@ -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)

View File

@ -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)

View File

@ -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)

View File

@ -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)

View File

@ -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)

View File

@ -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)

View File

@ -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 <none> 1m v1.28.3
node-1 Ready <none> 10s v1.28.3
```
次: [リモートアクセス用のkubectlの構成](10-configuring-kubectl.md)

View File

@ -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 <none> 30m v1.28.3
node-1 Ready <none> 35m v1.28.3
```
次: [Pod Network Routesのプロビジョニング](11-pod-network-routes.md)

View File

@ -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 <<EOF
ip route add ${NODE_0_SUBNET} via ${NODE_0_IP}
ip route add ${NODE_1_SUBNET} via ${NODE_1_IP}
EOF
```
```bash
ssh root@node-0 <<EOF
ip route add ${NODE_1_SUBNET} via ${NODE_1_IP}
EOF
```
```bash
ssh root@node-1 <<EOF
ip route add ${NODE_0_SUBNET} via ${NODE_0_IP}
EOF
```
## 検証
```bash
ssh root@server ip route
```
```text
default via XXX.XXX.XXX.XXX dev ens160
10.200.0.0/24 via XXX.XXX.XXX.XXX dev ens160
10.200.1.0/24 via XXX.XXX.XXX.XXX dev ens160
XXX.XXX.XXX.0/24 dev ens160 proto kernel scope link src XXX.XXX.XXX.XXX
```
```bash
ssh root@node-0 ip route
```
```text
default via XXX.XXX.XXX.XXX dev ens160
10.200.1.0/24 via XXX.XXX.XXX.XXX dev ens160
XXX.XXX.XXX.0/24 dev ens160 proto kernel scope link src XXX.XXX.XXX.XXX
```
```bash
ssh root@node-1 ip route
```
```text
default via XXX.XXX.XXX.XXX dev ens160
10.200.0.0/24 via XXX.XXX.XXX.XXX dev ens160
XXX.XXX.XXX.0/24 dev ens160 proto kernel scope link src XXX.XXX.XXX.XXX
```
次: [スモークテスト](12-smoke-test.md)

190
docs/ja/12-smoke-test.md Normal file
View File

@ -0,0 +1,190 @@
# スモークテスト
このラボでは、Kubernetesクラスターが正しく機能していることを確認するための一連のタスクを完了します。
## データ暗号化
このセクションでは、[データを保存時に暗号化する](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/#verifying-that-data-is-encrypted)Encryption at Rest機能を確認します。
汎用シークレットを作成します:
```bash
kubectl create secret generic kubernetes-the-hard-way \
--from-literal="mykey=mydata"
```
etcdに保存されている`kubernetes-the-hard-way`シークレットのヘックスダンプを表示します:
```bash
ssh root@server \
'etcdctl get /registry/secrets/default/kubernetes-the-hard-way | hexdump -C'
```
```text
00000000 2f 72 65 67 69 73 74 72 79 2f 73 65 63 72 65 74 |/registry/secret|
00000010 73 2f 64 65 66 61 75 6c 74 2f 6b 75 62 65 72 6e |s/default/kubern|
00000020 65 74 65 73 2d 74 68 65 2d 68 61 72 64 2d 77 61 |etes-the-hard-wa|
00000030 79 0a 6b 38 73 3a 65 6e 63 3a 61 65 73 63 62 63 |y.k8s:enc:aescbc|
00000040 3a 76 31 3a 6b 65 79 31 3a 9b 79 a5 b9 49 a2 77 |:v1:key1:.y..I.w|
00000050 c0 6a c9 12 7c b4 c7 c4 64 41 37 97 4a 83 a9 c1 |.j..|...dA7.J...|
00000060 4f 14 ae 73 ab b8 38 26 11 14 0a 40 b8 f3 0e 0a |O..s..8&...@....|
00000070 f5 a7 a2 2c b6 35 b1 83 22 15 aa d0 dd 25 11 3e |...,.5.."....%.>|
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)

7
docs/ja/13-cleanup.md Normal file
View File

@ -0,0 +1,7 @@
# クリーンアップ
このラボでは、このチュートリアル中に作成したコンピュートリソースを削除します。
## コンピュートインスタンス
コントローラーとワーカーのコンピュートインスタンスを削除します。