はじめに
この実験では、強力なコンテナオーケストレーションプラットフォームである Kubernetes のアーキテクチャを探ります。Kubernetes クラスタを構成する主要なコンポーネントを調べ、コンテナ化されたアプリケーションを管理するためにどのように相互作用するかを学びます。この実験は初心者向けに設計されており、Kubernetes アーキテクチャの実践的な紹介を提供します。
コントロールプレーンコンポーネントを探る
まずは、Minikube を使って Kubernetes クラスタを起動し、コントロールプレーンコンポーネントを調べてみましょう。
まず、ターミナルを開きます。デフォルトでは /home/labex/project ディレクトリにいるはずです。そうでない場合は、次のコマンドで移動します:
cd ~/project
次に、次のコマンドで Minikube を起動します:
minikube start
このコマンドは、ローカルマシン上で単一ノードの Kubernetes クラスタを初期化します。完了するまで数分かかる場合があります。たくさんの出力が表示されても心配しないでください — これは正常です。
Minikube が起動したら、コントロールプレーンコンポーネントを探索しましょう。コントロールプレーンは Kubernetes の脳であり、クラスタの全体的な状態を管理する責任があります。これらのコンポーネントの状態を確認するには、次のコマンドを実行します:
kubectl get componentstatuses
次のような出力が表示されるはずです:
NAME STATUS MESSAGE ERROR
scheduler Healthy ok
controller-manager Healthy ok
etcd-0 Healthy {"health":"true"}
これらのコンポーネントがそれぞれ何をするか解説しましょう:
- スケジューラ:このコンポーネントは、割り当てられていないノードの新しく作成された Pod を監視し、それらが実行するノードを選択します。
- コントローラマネージャ:これはコントローラプロセスを実行し、システムの状態を調整します。たとえば、リプリケーションコントローラは、正しい数の Pod レプリカが実行されていることを確認します。
- etcd:これは分散型のキーバリューストアであり、Kubernetes のすべてのクラスタデータのバッキングストアとして機能します。
すべてのコンポーネントが「Healthy」と表示されれば、コントロールプレーンは正常に機能しています。エラーが表示された場合は、minikube delete の後に minikube start を実行して Minikube を再起動することが考えられます。
ノードコンポーネントを調べる
コントロールプレーンを見てきたので、次にノードコンポーネントを調べてみましょう。Kubernetes では、ノードはアプリケーションを実行するワーカーマシンです。クラスタの筋肉のように考えてください。コンテナを実行する重い作業を行っています。
クラスタ内のノードを表示するには、次のコマンドを実行します:
kubectl get nodes
次のような出力が表示されるはずです:
NAME STATUS ROLES AGE VERSION
minikube Ready control plane 10m v1.20.0
この出力は、単一ノードクラスタを使用しているため、「minikube」という名前の 1 つのノードがマスター(コントロールプレーン)であり、ワーカーノードでもあることを示しています。本番環境では、通常、マスターノードとワーカーノードが別々の複数のノードがあります。
「Ready」ステータスは、ノードが正常で、Pod を受け入れる準備ができていることを意味します。
ノードに関する詳細情報を取得するには、次のコマンドを使用します:
kubectl describe node minikube
このコマンドは、ノードに関する豊富な情報を提供します。圧倒的に感じるかもしれませんが、心配しないでください。いくつかの重要なセクションを解説しましょう:
- ノードの状態:これは、さまざまなノードの状態(たとえば、Ready、DiskPressure、MemoryPressure)を示します。
- 容量:これは、ノードに利用可能な合計リソース(CPU とメモリ)を示します。
- 割り当て可能:これは、Pod が使用できるリソースを示します。
- システム情報:これは、ノードのオペレーティングシステム、カーネルバージョン、コンテナランタイムに関する情報を提供します。
直接は見えませんが、ノード上で実行されている重要なノードコンポーネントには、次が含まれます:
- kubelet:これは主要なノードエージェントです。割り当てられたノードの Pod を監視し、それらが実行されていることを確認します。
- kube-proxy:これは、ノード上のネットワークルールを維持し、クラスタの内部または外部から Pod へのネットワーク通信を可能にします。
Pod の作成と調査
入り込む前に、Kubernetes で YAML がどのように機能するかを理解しましょう:
graph TB
A[YAML コンフィグファイル] -->|宣言された望ましい状態| B[Kubernetes API]
B -->|作成/管理| C[実行中のコンテナ]
D[kubectl CLI] -->|読み取り| A
Kubernetes の YAML ファイルは「コードとしてのインフラストラクチャ」として機能します:
- Kubernetes に何を望むかを伝える「メニュー」のように考えてください
- 人が読みやすい形式で望ましいシステム状態を記述します
- チームコラボレーションのためにバージョン管理が可能です
最初の YAML ファイルを作成しましょう。simple-pod.yaml を作成します:
nano ~/project/simple-pod.yaml
次の内容を追加します:
## --- YAML ファイルの始まり ---
## 1. 使用する Kubernetes API バージョンを指定します
apiVersion: v1
## 2. 作成したいリソースの種類を宣言します
kind: Pod
## 3. このリソースのメタデータを設定します
metadata:
name: nginx-pod ## Pod の名前
labels: ## ラベルは、Pod を見つけて整理するのに役立ちます
app: nginx
## 4. Pod に含まれるものを定義します
spec:
containers: ## Pod は 1 つ以上のコンテナを実行できます
- name: nginx ## コンテナの名前
image: nginx:latest ## 使用するコンテナイメージ
ports: ## 公開するポート
- containerPort: 80 ## Nginx はデフォルトでポート 80 を使用します
YAML ファイルの構造は木のようになっています:
Pod (ルート)
├── metadata (枝)
│ ├── name (葉)
│ └── labels (葉)
└── spec (枝)
└── containers (枝)
└── - name, image, ports (葉)
Pod を作成します:
kubectl apply -f simple-pod.yaml ## -f はファイルから読み取ることを意味します
このコマンドは次のことを行います:
- YAML ファイルを読み取ります
- それを Kubernetes API に送信します
- Kubernetes は記述された状態を達成するために作業します
Pod の作成を確認します:
kubectl get pods
次のように表示されるはずです:
NAME READY STATUS RESTARTS AGE
nginx-pod 1/1 Running 0 30s
READY の下の「1/1」は、Pod 内の 1 つのコンテナのうち 1 つが準備完了していることを意味します。STATUS の下の「Running」は、最初の YAML コンフィギュレーションが機能したことを意味します!
💡 プロのヒント:
- YAML のインデントは重要です - タブではなくスペースを使用してください
kubectl explain podを使用して、フィールドのドキュメントを表示します- 保守性を向上させるために常にコメントを追加してください
Pod に関する詳細情報を取得するには:
kubectl describe pod nginx-pod
このコマンドは、次のような多くの情報を提供します:
- Pod が実行されているノード
- Pod の IP アドレス
- Pod 内のコンテナ
- Pod に関連する最近のイベント
これらの情報は、アプリケーションのデバッグと状態の理解に不可欠です。
サービスの作成
実行中の Pod があるので、それを公開するためのサービスを作成しましょう。Kubernetes では、サービスは論理的な Pod のセットとそれらにアクセスするためのポリシーを定義する抽象化です。クラスタ内または外部のどちらかで、アプリケーションをネットワークに公開する方法と考えてください。
プロジェクトディレクトリに nginx-service.yaml という名前のファイルを作成します:
nano ~/project/nginx-service.yaml
ファイルに次の内容を追加します:
apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
selector:
app: nginx
ports:
- protocol: TCP
port: 80
targetPort: 80
type: NodePort
この YAML ファイルを解説しましょう:
selector:これは、サービスがトラフィックを送信する Pod を決定します。この場合、app: nginxというラベルが付いた任意の Pod を選択します。ports:これは、サービスが使用するポートを指定します。type: NodePort:これは、サービスがクラスタ内の各ノードのポートでアクセス可能であることを意味します。
ファイルを保存してエディタを終了します。
次に、次のコマンドを実行してサービスを作成します:
kubectl apply -f nginx-service.yaml
サービスの状態を確認するには、次のコマンドを使用します:
kubectl get services
次のような出力が表示されるはずです:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 1h
nginx-service NodePort 10.110.126.65 <none> 80:30080/TCP 30s
nginx-service の行は、サービスが作成されたことを示しています。PORT(S) の下の 80:30080/TCP は、クラスタ内のポート 80 がノード上のポート 30080 にマッピングされていることを意味します。
サービスに関する詳細情報を取得するには、次のコマンドを使用します:
kubectl describe service nginx-service
このコマンドは、サービスのタイプ、IP アドレス、ポート、エンドポイントに関する情報を提供します。エンドポイントは、サービスがトラフィックを送信する Pod の IP アドレスです。
アプリケーションへのアクセス
アプリケーションを実行する Pod とそれを公開するサービスがあるので、アプリケーションにアクセスしましょう。このステップでは、設定したすべてのコンポーネントがどのように協働してアプリケーションにアクセス可能にするかを示します。
まず、Minikube がサービスに割り当てた URL を調べる必要があります:
minikube service nginx-service --url
このコマンドは URL を出力し、それは http://192.168.64.2:30080 のように見えるはずです。IP アドレスはあなたのマシンでは異なる場合があります。
アプリケーションにアクセスするには、URL の後に curl コマンドを使用します:
curl $(minikube service nginx-service --url)
これは、デフォルトの Nginx の歓迎ページの HTML を返すはずです。<!DOCTYPE html> で始まる HTML 出力が表示された場合、おめでとうございます!あなたは正常にアプリケーションにアクセスしました。
さっき何が起こったか解説しましょう:
- あなたの要求はまず、作成した NodePort サービスに到達しました。
- その後、サービスは要求を Nginx コンテナを実行している Pod に転送しました。
- Nginx コンテナは要求を処理し、デフォルトの歓迎ページを返しました。
これは、Kubernetes が根底にあるインフラストラクチャを抽象化し、アプリケーションがどの特定のマシン上で実行されているかを心配することなく、アプリケーションに集中できるようにする方法を示しています。
まとめ
この実験では、Kubernetes の主要なコンポーネントとそれらの相互作用を調べることで、Kubernetes のアーキテクチャを探りました。Minikube を使って Kubernetes クラスタを起動し、コントロールプレーンとノードコンポーネントを調べ、アプリケーションを実行するための Pod を作成し、サービスを使ってアプリケーションを公開し、最後にアプリケーションにアクセスしました。
graph TB
subgraph Control Plane
API[API Server]
CM[Controller Manager]
SCH[Scheduler]
ETCD[etcd]
API --> ETCD
API --> CM
API --> SCH
end
subgraph Worker Node
KL[kubelet]
KP[kube-proxy]
CR[Container Runtime]
subgraph Workloads
POD1[Pod]
POD2[Pod]
end
SVC[Service]
KL --> CR
POD1 --> CR
POD2 --> CR
KP --> SVC
SVC --> POD1
SVC --> POD2
end
API --> KL
Client[External Client] --> SVC
学んだことは以下の通りです。
- API サーバー、スケジューラー、コントローラーマネージャーなどのコントロールプレーンコンポーネント
- kubelet や kube-proxy などのノードコンポーネント
- Kubernetes で最小の展開可能単位である Pod
- アプリケーションを公開するための方法であるサービス
この実践的な経験は、Kubernetes のアーキテクチャを理解するための堅牢な基礎を提供します。Kubernetes は多くの動きのある部分を持つ複雑なシステムであり、すべてをすぐに理解できなくても大丈夫です。Kubernetes を使い続けるうちに、これらの概念はより慣れ親しんで直感的になります。
Kubernetes の学習の次のステップとしては、アプリケーションの複数のレプリカを管理するためのデプロイメント、構成管理のための ConfigMaps とシークレット、データストレージのための永続ボリュームについて学ぶことが挙げられます。さらに探求して、楽しい Kubernetes の学習を続けましょう!


