この実験では、Kubernetes クラスターにアプリケーションをデプロイする方法を学びます。まず、Minikube を使用して Kubernetes 環境をセットアップします。次に、クラスターとやり取りし、Kubernetes リソースを管理するための基本的な kubectl コマンドを探索します。その後、簡単な YAML マニフェストファイルを作成し、クラスターに適用して、デプロイメントのステータスを確認します。最後に、kubectl proxy を使用してデプロイされたアプリケーションにアクセスする方法を学びます。
この実験では、クラスターのセットアップ、基本的なリソース管理、アプリケーションのデプロイなど、Kubernetes の基本的なスキルを網羅します。この実験の終わりには、Kubernetes の操作方法と独自のアプリケーションのデプロイ方法について、確かな理解が得られるでしょう。
このステップでは、Minikube を使用して Kubernetes クラスターを起動します。Minikube は、仮想化された環境で単一ノードの Kubernetes クラスターを実行できるため、開発や Kubernetes の学習に最適なツールです。その後、クラスターが正しく実行されており、使用準備ができていることを確認します。
まず、ターミナルを開きます。ここでコンピューターとやり取りするためのコマンドを入力します。Minikube クラスターを起動するには、次のコマンドを入力して Enter キーを押します。
minikube startこのコマンドは、Kubernetes クラスターの作成と起動のプロセスを開始します。Minikube は必要なコンポーネントをダウンロードし、クラスターを構成します。Minikube が起動すると、ターミナルに出力が表示されます。出力例は次のようになります。
😄 minikube v1.29.0 on Ubuntu 22.04
✨ Automatically selected the docker driver
📌 Using Docker driver with root permissions
🔥 Creating kubernetes in kubernetes cluster
🔄 Restarting existing kubernetes cluster
🐳 Preparing Kubernetes v1.26.1 on Docker 20.10.23 ...
🚀 Launching Kubernetes ...
🌟 Enabling addons: storage-provisioner, default-storageclass
🏄 Done! kubectl is now configured to use "minikube" cluster and "default" namespaceMinikube が起動したら、それが実行されており、Kubernetes クラスターが使用準備ができていることを確認しましょう。次のコマンドを順番に実行し、各コマンドの後に Enter キーを押します。
minikube status
kubectl get nodesminikube status コマンドは、Minikube 自体のステータスを示します。kubectl get nodes コマンドは、Kubernetes クラスターと通信し、クラスター内のノード（コンピューター）に関する情報を取得します。Minikube は単一ノードのクラスターであるため、1 つのノードが表示されるはずです。
出力例は次のようになります。
minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured
NAME STATUS ROLES AGE VERSION
minikube Ready control-plane 1m v1.26.1この出力が何を示しているかを分解してみましょう。
minikube のステータスは、host、kubelet、apiserver で Running と表示されています。これは、Minikube のコアコンポーネントが正しく実行されていることを示しています。kubectl get nodes は、STATUS が Ready の minikube という名前のノードを表示します。Ready は、このノードがアプリケーションを実行する準備ができていることを意味します。ROLES の下の control-plane は、このノードが Kubernetes クラスターのコントロールプレーンとして機能し、クラスターの管理とオーケストレーションを行っていることを示しています。これらのコマンドは、次のことを確認します。
Ready 状態であり、使用準備ができています。minikube ノードがコントロールプレーンとして機能する単一ノードの Kubernetes クラスターがあります。このステップでは、基本的な kubectl コマンドを探索します。kubectl は、Kubernetes クラスターとやり取りするためのコマンドラインツールです。Kubernetes リソースの管理に不可欠です。ここでは、kubectl を使用してリソースを表示し、基本的な Kubernetes オブジェクト管理を理解する方法を説明します。
まず、Kubernetes クラスター内の名前空間を探索しましょう。名前空間は、Kubernetes リソースを整理する方法です。デフォルトでは、Kubernetes クラスターにはシステムコンポーネントとユーザーリソースのためのいくつかの名前空間があります。名前空間のリストを表示するには、次のコマンドを実行します。
kubectl get namespacesこのコマンドは、クラスターで利用可能なすべての名前空間を一覧表示します。出力例：
NAME STATUS AGE
default Active 10m
kube-node-lease Active 10m
kube-public Active 10m
kube-system Active 10m通常、少なくともこれらのデフォルトの名前空間が表示されます。
default: 他の名前空間が指定されていない場合に、ユーザーが作成したリソースのデフォルトの名前空間です。kube-node-lease: ノードのヘルス状態をコントロールプレーンが追跡するのに役立つノードリースに使用されます。kube-public: 公開アクセス可能なリソースを意図していますが（ただし、機密情報にはほとんど使用されません）。kube-system: コア Kubernetes コンポーネントなどのシステムレベルのリソースが含まれています。次に、kube-system 名前空間で実行されているシステムコンポーネントを表示しましょう。多くのコア Kubernetes コンポーネントは、この名前空間内のポッドとして実行されます。特定の名前空間のポッドを表示するには、-n または --namespace フラグの後に名前空間名を指定します。kube-system 名前空間のポッドを表示するには、次のコマンドを実行します。
kubectl get pods -n kube-systemこのコマンドは、kube-system 名前空間で実行されているすべてのポッドを一覧表示します。出力例：
NAME READY STATUS RESTARTS AGE
coredns-787d4945fb-j8rhx 1/1 Running 0 15m
etcd-minikube 1/1 Running 0 15m
kube-apiserver-minikube 1/1 Running 0 15m
kube-controller-manager-minikube 1/1 Running 0 15m
kube-proxy-xb9rz 1/1 Running 0 15m
kube-scheduler-minikube 1/1 Running 0 15m
storage-provisioner 1/1 Running 0 15mこの出力は、ポッドの名前、READY ステータス（ポッド内のコンテナが合計のうちいくつ準備ができているか）、STATUS（例：Running）、RESTARTS 回数、および AGE を示しています。これらは Kubernetes を機能させるための不可欠なコンポーネントです。
次に、基本的な kubectl コマンドパターンをいくつか見てみましょう。kubectl コマンドの一般的な構文は次のとおりです。
kubectl [command] [TYPE] [NAME] [flags]これを分解してみましょう。
kubectl: コマンドラインツール自体です。[command]: 実行したいアクションを指定します。一般的なコマンドには次のものがあります。
get: 1 つまたは複数のリソースを表示します。describe: 特定のリソースの詳細を表示します。create: 新しいリソースを作成します。delete: リソースを削除します。apply: リソースに構成を適用します。これは後で頻繁に使用します。[TYPE]: 対話したい Kubernetes リソースの種類を指定します。一般的なリソースの種類には次のものがあります。
pods: Kubernetes で最も小さなデプロイ可能な単位です。deployments: スケーリングと更新のためにポッドのセットを管理します。services: ポッドで実行されているアプリケーションを公開します。nodes: Kubernetes クラスター内のワーカーマシンです。namespaces: リソースの論理的なグループ化です。[NAME]: 特定のリソースの名前です。これはオプションです。名前を省略すると、kubectl は指定された種類のすべてのリソースに対して操作を行います。[flags]: コマンドの動作を変更するためのオプションのフラグ（例：-n <namespace>, -o wide）。例を見てみましょう。
## デフォルトの名前空間のすべてのリソースを取得
kubectl get all
## 特定のリソースタイプ（'minikube' ノード）の詳細を表示
kubectl describe nodes minikubekubectl get all コマンドは、default 名前空間内のすべてのリソースタイプ（サービス、デプロイメント、ポッドなど）に関する情報を取得します。出力例は次のようになります。
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 20mこれは、default 名前空間に kubernetes という名前の service があることを示しています。
kubectl describe nodes minikube コマンドは、minikube ノードに関するステータス、容量、アドレスなど、多くの詳細情報を提供します。これは、ノードの状態と構成を理解するのに役立ちます。
これらのコマンドは、次のことに役立ちます。
kubectl の基本的なコマンド構造と構文を理解します。最初の YAML マニフェストを作成する前に、使用する主要な Kubernetes オブジェクトを理解することが重要です。これらのオブジェクトは、Kubernetes 内でアプリケーションを管理およびオーケストレーションするための構成要素です。
これらのオブジェクトの関係を図で示します。
これらのオブジェクトを理解することは非常に重要です。なぜなら、YAML マニフェストを使用してそれらの望ましい状態と構成を定義するからです。
Kubernetes における YAML マニフェストは、YAML フォーマットで記述されたファイルであり、作成または管理したい Kubernetes オブジェクトを記述します。YAML は人間が読めるデータシリアライゼーション言語です。Kubernetes マニフェストに YAML を使用することには、いくつかの利点があります。
Kubernetes オブジェクトと YAML マニフェストの基本を理解したので、最初のマニフェストを作成する準備ができました。
まず、プロジェクトディレクトリに移動します。ホームディレクトリ（~）に project ディレクトリがあると想定しています。まだない場合は、mkdir project を使用して今すぐ作成してください。次に、cd project を使用して現在のディレクトリを project に変更します。
cd ~/project次に、Kubernetes マニフェストを格納するための新しいディレクトリを作成します。k8s-manifests という名前にしましょう。mkdir コマンドを使用してディレクトリを作成し、次に cd でその中に移動します。
mkdir -p k8s-manifests
cd k8s-manifestsこれで、最初の YAML マニフェストファイルを作成します。まず、NGINX Pod のシンプルなマニフェストから始めましょう。NGINX は人気の高い Web サーバーです。単一の NGINX コンテナを実行する Pod を作成します。nano テキストエディタを使用して、nginx-pod.yaml という名前のファイルを作成します。
nano nginx-pod.yamlnano はターミナルで実行されるシンプルなテキストエディタです。nano が開いたら、次のコンテンツをファイルに貼り付けます。
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80この YAML マニフェストの各部分を理解しましょう。
apiVersion: v1: このオブジェクトを作成するために使用する Kubernetes API バージョンを指定します。v1 はコア API グループであり、Pod、Service、Namespace のような基本的なオブジェクトに使用されます。kind: Pod: Pod リソースを定義していることを示します。metadata:: Pod に関するデータ（名前やラベルなど）が含まれています。
name: nginx-pod: Pod の名前を nginx-pod に設定します。これは、Kubernetes 内でこの Pod を参照する方法です。labels:: ラベルはオブジェクトに添付されるキーと値のペアです。オブジェクトのサブセットを整理および選択するために使用されます。ここでは、この Pod に app: nginx というラベルを追加しています。spec:: Pod の望ましい状態を記述します。
containers:: Pod 内で実行されるコンテナのリストです。この場合、コンテナは 1 つだけです。
- name: nginx: コンテナの名前を nginx に設定します。image: nginx:latest: 使用するコンテナイメージを指定します。nginx:latest は、Docker Hub からの NGINX Docker イメージの最新バージョンを参照します。ports:: このコンテナが公開するポートのリストです。
- containerPort: 80: コンテナがポート 80 を公開することを示します。ポート 80 は標準の HTTP ポートです。コンテンツを貼り付けたら、ファイルを保存して nano を終了します。これを行うには、Ctrl+X（終了）を押し、次に Y（保存してはい）と入力し、最後に Enter を押してファイル名を確認して保存します。
nginx-pod.yaml ファイルを作成したら、Pod を作成するためにクラスターに適用する必要があります。マニフェストを含むファイルを指定する -f フラグと共に kubectl apply コマンドを使用します。
kubectl apply -f nginx-pod.yamlこのコマンドはマニフェストを Kubernetes クラスターに送信し、Kubernetes は定義どおりに Pod を作成します。次のような出力が表示されるはずです。
pod/nginx-pod createdPod が作成され、実行されていることを確認するには、kubectl get pods コマンドを使用します。これにより、デフォルトの名前空間のすべての Pod が一覧表示されます。kubectl describe pod nginx-pod を使用して、nginx-pod に関する詳細情報を取得することもできます。これらのコマンドを実行します。
kubectl get pods
kubectl describe pod nginx-podkubectl get pods の出力例：
NAME READY STATUS RESTARTS AGE
nginx-pod 1/1 Running 0 1mこの出力は、nginx-pod が READY（1 つのコンテナのうち 1 つが準備完了）であり、その STATUS が Running であることを示しています。これは、NGINX Pod が正常に作成され、実行されていることを意味します。
次に、より複雑なリソースである Deployment のマニフェストを作成しましょう。Deployment は Pod のセットを管理し、指定された数のレプリカが実行されていることを保証します。nano を使用して nginx-deployment.yaml という名前の新しいファイルを作成します。
nano nginx-deployment.yamlnginx-deployment.yaml に次のコンテンツを貼り付けます。
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80nginx-pod.yaml マニフェストと比較して、主な違いと新しい部分を強調しましょう。
apiVersion: apps/v1: Deployment では、apps/v1 API バージョンを使用します。これは apps API グループの一部であり、より高レベルのアプリケーション管理リソースを処理します。kind: Deployment: Deployment リソースを定義していることを示します。spec:: Deployment の spec セクションは、Deployment が Pod をどのように管理するかを定義するため、より複雑です。
replicas: 3: これは新しい部分です。Pod のレプリカ（コピー）を 3 つ実行したいことを指定します。Deployment は、template で定義された基準に一致する Pod が常に 3 つあることを保証します。selector:: セレクターは、Deployment がどの Pod を管理するかを識別するために使用されます。
matchLabels:: この Deployment によって選択される Pod が持つ必要があるラベルを定義します。ここでは、app: nginx というラベルを持つ Pod を選択します。template:: template は、Deployment が新しい Pod を作成するために使用する Pod 仕様を定義します。これは基本的に、metadata.labels および spec.containers を含む、nginx-pod.yaml の例と同じ Pod 定義です。重要: ここ template.metadata.labels で定義されたラベルは、Deployment がこれらの Pod を管理できるように、selector.matchLabels と一致する必要があります。nano を保存して終了します（Ctrl+X、Y、Enter）。
次に、この Deployment マニフェストをクラスターに適用します。
kubectl apply -f nginx-deployment.yaml次のような出力が表示されるはずです。
deployment.apps/nginx-deployment createdDeployment とそれが作成した Pod を検証します。Deployment のステータスを確認するには kubectl get deployments を使用し、Pod を表示するには kubectl get pods を使用します。
kubectl get deployments
kubectl get pods出力例：
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 3/3 3 3 1m
NAME READY STATUS RESTARTS AGE
nginx-deployment-xxx-yyy 1/1 Running 0 1m
nginx-deployment-xxx-zzz 1/1 Running 0 1m
nginx-deployment-xxx-www 1/1 Running 0 1mkubectl get deployments は、nginx-deployment が READY 3/3、UP-TO-DATE 3、AVAILABLE 3 であることを示しています。これは、Deployment が 3 つの Pod を正常に作成し、管理しており、それらすべてが準備完了で利用可能であることを意味します。kubectl get pods は、nginx-deployment- で始まる名前を持つ 3 つの Pod を一覧表示します。これらは、nginx-deployment によって作成および管理されている Pod です。このステップでは、kubectl apply コマンドについて詳しく説明し、Kubernetes マニフェストを適用するさまざまな方法を学びます。前のステップの YAML ファイルを基に、マニフェストを適用するためのさまざまなテクニックを実演します。
まず、正しいディレクトリにいることを確認してください。
cd ~/project/k8s-manifestsマニフェストをさらに整理するために、新しいサブディレクトリを作成しましょう。manifests という名前のディレクトリを作成し、その中に移動します。
mkdir -p manifests
cd manifests次に、単一のファイルに Deployment と Service の両方を含むシンプルな Web アプリケーションのマニフェストを作成しましょう。nano を使用して web-app.yaml という名前の新しいファイルを作成します。
nano web-app.yamlweb-app.yaml に次のコンテンツを追加します。
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-app
spec:
replicas: 2
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: web
image: nginx:alpine
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: web-service
spec:
selector:
app: web
type: ClusterIP
ports:
- port: 80
targetPort: 80このマニフェストは、単一のファイルに 2 つの Kubernetes リソースを定義しており、--- で区切られています。これは、関連するリソースをまとめてグループ化する一般的な方法です。新しく追加された部分を詳しく見てみましょう。
web-app.yaml ファイルには、Deployment と Service の 2 つの別個の Kubernetes リソース定義が含まれています。--- 区切り文字は、それらを区別するために使用されます。kind: Service: これは Service リソースを定義します。
spec.selector.app: web: この Service は、app: web というラベルを持つ Pod をターゲットにします。これは、web-app Deployment によって作成された Pod に設定したラベルと一致します。spec.type: ClusterIP: Service のタイプを ClusterIP に指定します。これは、Service がクラスター内の内部 IP アドレスで公開されることを意味し、通常はクラスター内の Service 間通信に使用されます。spec.ports: Service がポートをターゲット Pod にどのようにマッピングするかを定義します。
port: 80: アクセスする Service 自体のポートです。targetPort: 80: Service がトラフィックを転送するターゲット Pod のポートです。次に、これらのマニフェストをさまざまな方法で適用しましょう。
方法 1: ファイル全体を適用する
これはマニフェストを適用する最も一般的な方法です。kubectl apply -f の後にファイル名を指定します。
kubectl apply -f web-app.yamlこのコマンドは、web-app.yaml で定義された Deployment と Service の両方を作成します。次のような出力が表示されるはずです。
deployment.apps/web-app created
service/web-service created方法 2: ディレクトリから適用する
ディレクトリ内のすべてのマニフェストを一度に適用できます。manifests ディレクトリに複数のマニフェストファイルがある場合、特定のファイルを指定する代わりにディレクトリを指定することで、すべてを適用できます。
kubectl apply -f .. は現在のディレクトリを表します。kubectl はこのディレクトリ内の YAML ファイルを検索し、すべてを適用します。これは、マニフェストをディレクトリ内の複数のファイルに整理した場合に便利です。
方法 3: URL から適用する（オプション）
kubectl apply は、URL から直接マニフェストを適用することもできます。これは、オンラインでホストされているサンプルアプリケーションや構成をすばやくデプロイする場合に便利です。たとえば、Kubernetes のサンプルリポジトリから Redis マスターデプロイメントをデプロイできます。
kubectl apply -f https://raw.githubusercontent.com/kubernetes/examples/master/guestbook/redis-master-deployment.yamlこれにより、URL からマニフェストがダウンロードされ、クラスターに適用されます。注意：信頼できない URL からのマニフェストの適用には注意してください。クラスターを変更する可能性があります。
kubectl apply の追加オプションをいくつか見てみましょう。
Dry Run
--dry-run=client フラグを使用すると、クラスターに変更を加えることなく、マニフェストの適用をシミュレートできます。これは、マニフェストが有効かどうかを確認し、どのリソースが作成または変更されるかを確認するのに役立ちます。
kubectl apply -f web-app.yaml --dry-run=clientこのコマンドは、実際に変更をクラスターに適用せずに、作成または変更される内容を出力します。
詳細出力
kubectl apply からの詳細な出力を得るには、-v フラグの後に詳細レベル（例：-v=7）を指定できます。詳細レベルが高いほど、より詳細な情報が表示され、デバッグに役立ちます。
kubectl apply -f web-app.yaml -v=7これにより、行われている API リクエストとマニフェストの処理に関するさらに多くの情報が表示されます。
web-app.yaml を適用して作成されたリソースを確認します。kubectl get deployments および kubectl get services を使用して、クラスター内の Deployment と Service を一覧表示します。
## デプロイメントを一覧表示
kubectl get deployments
## サービスを一覧表示
kubectl get services
## デプロイメントの詳細を表示するには記述します
kubectl describe deployment web-appkubectl get deployments の出力例：
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 3/3 3 3 3m33s
redis-master 0/1 1 0 23s
web-app 2/2 2 2 42skubectl get services の出力例：
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 8m28s
web-service ClusterIP 10.106.220.33 <none> 80/TCP 46sこれで、2/2 の READY レプリカを持つ web-app Deployment と、ClusterIP タイプ の web-service があることに注意してください。
Kubernetes における宣言的な管理と命令的な管理の違いについて、特に kubectl apply と kubectl create のコンテキストで簡単に説明しましょう。
kubectl apply: 宣言的なアプローチを使用します。マニフェストファイルで望ましい状態を定義し、kubectl apply はその状態を達成しようとします。同じマニフェストで kubectl apply を複数回実行した場合、マニフェストの望ましい状態とクラスターの現在の状態との間に違いがある場合にのみ、Kubernetes は変更を行います。kubectl apply は、より堅牢で時間の経過とともに変更を管理しやすいため、Kubernetes リソースの管理には一般的に推奨されます。リソースの構成を追跡し、増分更新を可能にします。kubectl create: 命令的なアプローチを使用します。Kubernetes にリソースを作成するように直接指示します。既に存在するリソースに対して kubectl create を実行しようとすると、通常はエラーになります。kubectl create は、kubectl apply と比較して、更新や変更の管理においては柔軟性が低いです。ほとんどの場合、特にアプリケーションデプロイメントの管理においては、宣言的な性質と更新および構成管理の優れた処理能力により、kubectl apply が最も好ましく推奨される方法です。
このステップでは、さまざまな kubectl コマンドを使用して、Kubernetes デプロイメントやその他のリソースのステータスを検査および検証する方法を学びます。Kubernetes クラスター内で実行中のアプリケーションとそのヘルスに関する情報を収集するさまざまな方法を探索します。
まず、プロジェクト内の manifests ディレクトリにいることを確認してください。
cd ~/project/k8s-manifests/manifests現在の名前空間（変更していない場合は default）のすべてのデプロイメントを一覧表示することから始めましょう。kubectl get deployments を使用します。
kubectl get deploymentsこのコマンドは、デプロイメントの簡潔な概要を提供します。出力例：
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 3/3 3 3 4m44s
redis-master 1/1 1 1 94s
web-app 2/2 2 2 113s各列の意味は次のとおりです。
NAME: デプロイメントの名前。READY: 準備完了レプリカの数と望ましいレプリカの数を示します（例：3/3 は 3 つの望ましいレプリカが準備完了であることを意味します）。UP-TO-DATE: 最新の望ましい状態に更新されたレプリカの数を示します。AVAILABLE: 現在トラフィックを提供できるレプリカの数を示します。AGE: デプロイメントが実行されている期間。より詳細な情報を広い形式で取得するには、kubectl get deployments で -o wide フラグを使用できます。
kubectl get deployments -o wide出力例：
NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR
nginx-deployment 3/3 3 3 4m58s nginx nginx:latest app=nginx
redis-master 1/1 1 1 108s master registry.k8s.io/redis:e2e app=redis,role=master,tier=backend
web-app 2/2 2 2 2m7s web nginx:alpine app=web-o wide 出力には、CONTAINERS、IMAGES、SELECTOR のような追加の列が含まれており、デプロイメントに関する追加のコンテキストを提供します。
特定のデプロイメントの一部である Pod を検査するには、ラベルを使用できます。web-app デプロイメントマニフェストでは、Pod に app: web というラベルを設定したことを思い出してください。このラベルを使用して、kubectl get pods -l <label_selector> で Pod をフィルタリングできます。web-app デプロイメントに関連付けられた Pod を表示するには、次を実行します。
kubectl get pods -l app=web出力例：
NAME READY STATUS RESTARTS AGE
web-app-xxx-yyy 1/1 Running 0 10m
web-app-xxx-zzz 1/1 Running 0 10mこれにより、web-app デプロイメントによって管理されている Pod であるラベルセレクター app=web に一致する Pod が一覧表示されます。
特定のデプロイメントの詳細については、kubectl describe deployment <deployment_name> を使用します。web-app デプロイメントを記述しましょう。
kubectl describe deployment web-appkubectl describe は、以下を含むデプロイメントに関する豊富な情報を提供します。
Available、Progressing）。describe 出力の Conditions および Events セクションを確認してください。これらのセクションは、デプロイメントに問題がある場合に手がかりを提供することがよくあります。たとえば、デプロイメントが Available にならない場合、Events にはイメージのプルに関するエラー、Pod 作成の失敗などが表示される可能性があります。
Service のステータスを確認するには、同様のコマンドを使用できます。まず、すべてのサービスを一覧表示します。
kubectl get services出力例：
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 10m
web-service ClusterIP 10.106.220.33 <none> 80/TCP 2m47sこれにより、web-service とその TYPE（この場合は ClusterIP）、CLUSTER-IP、および公開されている PORT(S) が表示されます。
Service の詳細については、kubectl describe service <service_name> を使用します。
kubectl describe service web-servicedescribe service の出力には以下が含まれます。
ClusterIP）。デプロイメントステータスを検証する際には、確認すべき主な点は次のとおりです。
READY ステータス: 望ましい数のレプリカが表示されていることを確認します（例：web-app の場合は 2/2）。STATUS: すべての Pod は Running ステータスである必要があります。Endpoints: Service にエンドポイントがあり、それらが実行中の Pod の IP アドレスに対応していることを確認します。エンドポイントがない場合は、Service のセレクターと Pod のラベルをトラブルシューティングしてください。kubectl describe deployment <deployment_name> および kubectl describe service <service_name> の出力で、Events セクションに異常な条件やエラーがないか確認してください。これらの kubectl コマンドを使用することで、Kubernetes でデプロイメントと Service のステータスを効果的に監視および検証し、アプリケーションが期待どおりに実行されていることを確認できます。
このステップでは、kubectl proxy を使用して Kubernetes アプリケーションにアクセスする方法を学びます。kubectl proxy は Kubernetes API サーバーへの安全なプロキシ接続を作成し、現在の環境からクラスターサービスや Pod にアクセスできるようにします。これは、特に外部に公開されていないサービスにアクセスしたい場合、開発やデバッグに非常に役立ちます。
まず、プロジェクトディレクトリにいることを確認してください。
cd ~/project/k8s-manifests/manifestskubectl proxy をバックグラウンドで起動します。このコマンドはプロキシを別のプロセスで実行するため、ターミナルを使い続けることができます。
kubectl proxy --port=8080 &コマンドの末尾にある & は、バックグラウンドで実行することを意味します。次のような出力が表示されるはずです。
Starting to serve on 127.0.0.1:8080このコマンドを実行した後、ターミナルがハングしたように見える場合は、プロンプトに戻るために Ctrl+C を一度押す必要があるかもしれません。プロキシはバックグラウンドで実行されたままのはずです。
次に、web-app デプロイメントの一部である Pod の名前を見つけましょう。以前にも使用した kubectl get pods -l app=web を再度使用できます。
## 'web-app' の Pod 名を取得
kubectl get pods -l app=web出力例：
NAME READY STATUS RESTARTS AGE
web-app-xxx-yyy 1/1 Running 0 20m
web-app-xxx-zzz 1/1 Running 0 20mPod の名前のいずれか（例：web-app-xxx-yyy）をメモしてください。この Pod 名を使用して、その Pod で実行されている NGINX Web サーバーにアクセスするための API パスを構築します。
Kubernetes API リソースには、特定のパスを通じてアクセスできます。kubectl proxy を介して Pod にアクセスするには、次のような URL を構築する必要があります。
http://localhost:8080/api/v1/namespaces/<namespace>/pods/<pod_name>/proxy/この URL を分解しましょう。
http://localhost:8080: kubectl proxy が実行されているアドレスです。デフォルトでは、現在の環境のポート 8080 でリッスンします。/api/v1: Kubernetes API バージョン（v1）を指定します。/namespaces/<namespace>: Pod が実行されている名前空間です。この場合、default です。/pods/<pod_name>: アクセスしたい Pod の名前です。<pod_name> を実際の Pod 名（例：web-app-xxx-yyy）に置き換えてください。/proxy/: Pod への接続をプロキシしたいことを示します。URL で Pod 名を簡単に使用できるように、最初の Pod の名前をシェル変数に格納しましょう。このコマンドを実行して、kubectl get pods と jsonpath を使用して、ラベル app=web を持つ最初の Pod の名前を抽出します。
## ラベル 'app=web' を持つ最初の Pod の名前を取得
POD_NAME=$(kubectl get pods -l app=web -o jsonpath='{.items[0].metadata.name}')
echo $POD_NAME ## オプション: Pod 名を表示して確認これで、curl コマンドで $POD_NAME 変数を使用して、Pod が提供する NGINX のデフォルトページにアクセスできます。curl を使用してプロキシ URL に HTTP リクエストを送信します。URL の ${POD_NAME} を、先ほど設定した変数に置き換えてください。
curl http://localhost:8080/api/v1/namespaces/default/pods/${POD_NAME}/proxy/すべてが正しく機能していれば、このコマンドはデフォルトの NGINX へようこそページ（Welcome to nginx!）の HTML コンテンツを返します。出力例は、次のような HTML コンテンツになります。
<!doctype html>
<html>
<head>
<title>Welcome to nginx!</title>
...
</head>
<body>
<h1>Welcome to nginx!</h1>
...
</body>
</html>この出力は、kubectl proxy を介して Pod 内で実行されている NGINX Web サーバーに正常にアクセスできたことを確認します。
kubectl proxy でできることをいくつかさらに見てみましょう。
プロキシ経由でデフォルト名前空間のすべての Pod を一覧表示:
プロキシを介して Kubernetes API に直接アクセスできます。たとえば、default 名前空間のすべての Pod を一覧表示するには、次の URL を使用できます。
curl http://localhost:8080/api/v1/namespaces/default/pods/これにより、default 名前空間のすべての Pod に関する情報を含む JSON レスポンスが返されます。
プロキシ経由で特定の Pod の詳細情報を取得:
特定の Pod の詳細情報（kubectl describe pod と同様）を取得するには、Pod の API エンドポイントに直接アクセスできます。
curl http://localhost:8080/api/v1/namespaces/default/pods/${POD_NAME}これにより、指定された Pod に関する詳細情報を含む JSON レスポンスが返されます。
kubectl proxy の停止:
kubectl proxy の使用が終了したら、停止する必要があります。バックグラウンドで起動したため、プロセス ID（PID）を見つけて終了する必要があります。jobs コマンドを使用してバックグラウンドプロセスを一覧表示できます。
jobsこれにより、現在のターミナルセッションから実行されているバックグラウンドプロセスが表示されます。kubectl proxy が一覧表示されているはずです。停止するには、kill コマンドとその後にプロセス ID を使用できます。たとえば、jobs が [1] Running kubectl proxy --port=8080 & を表示した場合、プロセス ID は 1 です。次のように使用します。
kill %1jobs コマンドによって表示されるジョブ ID を %1 の代わりに指定してください。または、ps aux | grep kubectl proxy を使用してプロセス ID を見つけ、次に kill <PID> を使用することもできます。
kubectl proxy に関して覚えておくべき重要な点は次のとおりです。
kubectl proxy は、Kubernetes API サーバーへの安全で認証された接続を作成します。kubectl proxy は localhost（127.0.0.1）でのみアクセス可能です。サービスを公開するために使用されることを意図していません。この実験では、Minikube を使用して Kubernetes クラスターにアプリケーションをデプロイする方法を習得しました。まず Minikube で Kubernetes クラスターをセットアップし、そのステータスを確認しました。次に、クラスターと対話しリソースを管理するための基本的な kubectl コマンドを探索しました。名前空間を一覧表示し、ノードや Pod の詳細を取得し、kubectl の基本的なコマンド構造を理解する方法を学びました。これらのステップにより、Kubernetes を扱うための強固な基盤が得られました。
Pod および Deployment のシンプルな YAML マニフェストを作成し、kubectl apply を使用してクラスターに適用し、get や describe のようなさまざまな kubectl コマンドを使用してデプロイメントステータスを確認しました。この実践的な経験により、Kubernetes でアプリケーションをデプロイする宣言的なアプローチと、クラスターと効果的に対話する方法を理解することができました。
最後に、kubectl proxy を使用してデプロイされたアプリケーションにアクセスする方法を学びました。これは、クラスターの API と対話し、現在の環境からサービスや Pod にアクセスするための安全な方法を提供します。これは、開発、デバッグ、および Kubernetes 環境の探索に役立つテクニックです。
この実験を完了することで、基本的な Kubernetes の概念とツールに関する実践的な経験を積み、Kubernetes でより複雑なアプリケーションをデプロイおよび管理する道筋を立てることができました。
