Kubernetes クラスタを探索する

KubernetesBeginner
オンラインで実践に進む

はじめに

この実験では、Minikube を使ってローカルの Kubernetes クラスタを探索します。クラスタを起動し、そのセットアップを確認し、ポッドやデプロイメントなどの基本的なクラスタ リソースを調べます。この実践的な経験は、Kubernetes 環境の基本的なコンポーネントとコマンドを理解するのに役立ち、さらなる探索と開発の基礎を築きます。

まず、ローカル マシンに Minikube クラスタをセットアップし、クラスタが稼働して使用可能であることを確認します。次に、kubectl cluster-infokubectl get nodes などの必須の kubectl コマンドを使って、クラスタの構成とヘルス状態を確認します。最後に、ポッドやデプロイメントを含む基本的なクラスタ リソースを調べて、Kubernetes オブジェクト モデルとクラスタの全体的な状態を慣れ親します。

ローカルの Kubernetes クラスタを起動する

このステップでは、Minikube を使ってローカルの Kubernetes クラスタを起動して確認します。Minikube は、学習や開発用のシングル ノードの Kubernetes 環境をセットアップするための簡単な方法を提供します。

まず、プロジェクト ディレクトリに移動します。

cd ~/project

Minikube クラスタを起動します。

注:無料ユーザーはインターネットに接続できないため、実験を開始するときに minikube は既に事前に起動されています。クラスタの状態を確認するには、以下のコード セクションにジャンプできます。プロユーザーにアップグレードして、自分でクラスタを起動する練習を行います。

プロユーザー限定
minikube start

出力例:

😄  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" namespace

複数のコマンドを使ってクラスタの状態を確認します。

minikube status

出力例:

minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured

クラスタのノードを確認します。

kubectl get nodes

出力例:

NAME       STATUS   ROLES           AGE   VERSION
minikube   Ready    control-plane   1m    v1.26.1

これらのコマンドは、以下のことを確認します。

  1. Minikube が正常に起動した
  2. ローカルの Kubernetes クラスタが稼働している
  3. クラスタが使用可能である
  4. コントロール プレーン機能を備えたシングル ノード クラスタがある

Minikube クラスタは、ローカル マシン上に完全な Kubernetes 環境を提供し、フルマルチノード クラスタを必要とせずにアプリケーションの開発とテストを行うことができます。

Kubernetes アーキテクチャの概要

Kubernetes はクライアント - サーバー モデルで動作し、クラスタの状態を管理する集中型のコントロール プレーンと、ワークロードを実行する一連のワーカー ノードから構成されています。大まかに言えば、ユーザー(多くの場合、開発者)はコマンドライン ツールまたは API を介して Kubernetes クラスタとやり取りします。コントロール プレーンは、何がどこで実行されるべきかについて決定し、クラスタのヘルス状態を監視し、望ましい状態が達成されることを確認します。ワーカー ノードは、1 つ以上のコンテナのグループであるポッド内にアプリケーションをホストし、それらを実行するために必要なコンピューティングおよびストレージ リソースを提供します。

コントロール プレーン

これはクラスタの「脳」であり、全体的なシステムを管理するために一緒に機能するいくつかのコンポーネントで構成されています。

  • kube-apiserver (API): クラスタの玄関口として機能します。すべての管理コマンドとリソース要求がここを通ります。
  • etcd (キーバリュー ストア): すべての構成データとクラスタの現在の状態を保存します。etcd データを失うと、クラスタの状態も失います。
  • kube-scheduler (SCH): リソース要件、制約条件、およびポリシーに基づいて、ポッドをノードに割り当てます。
  • kube-controller-manager (CTLM): さまざまなコントローラを実行し、クラスタの状態を継続的に調整して、展開と構成によって定義された望ましい状態と実際の状態が一致することを確認します。

ノード(ワーカー マシン)

ノードはワークロードが実行される場所です。各ノードには以下があります。

  • kubelet (KLT): コントロール プレーンと通信するノードレベルのエージェントです。ポッドが実行されていることを確認し、その状態をコントロール プレーンに報告します。
  • コンテナ ランタイム (CR): コンテナを実行および管理するソフトウェア(たとえば、Docker または containerd)です。ポッド内のコンテナ化されたアプリケーションを作成および管理します。

ポッド

ポッドは Kubernetes で最小の展開可能単位であり、通常、実行中のアプリケーションの単一インスタンスを表します。ポッドには、同じネットワーク名前空間とストレージ ボリュームを共有する 1 つ以上のコンテナを含めることができます。

サービス

サービスは、論理的なポッドのセットとそれらにアクセスする方法のポリシーを定義する抽象化です。サービスは、安定した IP アドレス、DNS 名、およびロードバランシングを提供し、外部のコンシューマーや他のクラスタ コンポーネントが、ポッドがノード間を移動したり、スケーリングやローリング アップデート中に置き換えられたりしても、確実にアプリケーションに接続できるようにします。

クラスタとのやり取り

  • 開発者と管理者は、kube-apiserver を介してクラスタとやり取りします。このとき、多くの場合 kubectl やその他の Kubernetes クライアントを使用します。
  • 新しいアプリケーションが展開されると、コントロール プレーンのコンポーネント(スケジューラ、コントローラ)が協働して、ポッドを適切なノードに配置します。
  • 各ノード上の kubelet は、ポッドが健全であり、指示通りに実行されていることを確認します。
  • サービスはトラフィックを正しいポッドにルーティングし、クライアントがポッドの場所の変更を追跡することなくアプリケーションにアクセスできるようにします。
flowchart TB %% User interacting with the cluster User((Developer)) User -->|kubectl CLI| API[kube-apiserver] %% Control Plane Components subgraph ControlPlane[Control Plane] API ETCD[etcd - Key Value Store] SCH[kube-scheduler] CTLM[kube-controller-manager] API --> ETCD API --> SCH API --> CTLM end %% Worker Node 1 subgraph Node1[Worker Node] KLT1[kubelet] CR1[Container Runtime] subgraph Pods1[Pods] P1[Pod] P2[Pod] end KLT1 --> CR1 CR1 --> P1 CR1 --> P2 end %% Worker Node 2 subgraph Node2[Worker Node] KLT2[kubelet] CR2[Container Runtime] subgraph Pods2[Pods] P3[Pod] P4[Pod] end KLT2 --> CR2 CR2 --> P3 CR2 --> P4 end %% Connections between Control Plane and Nodes API --> KLT1 API --> KLT2 %% Service connecting to Pods across different Nodes Service[Service] Service --> P1 Service --> P2 Service --> P3 Service --> P4

この図では:

  • 開発者は kubectl のような CLI ツールを介して kube-apiserver (API) とやり取りします。
  • コントロール プレーンのコンポーネント(API、etcd、スケジューラ、コントローラ マネージャー)は、クラスタの状態を管理し、ワークロードをオーケストレートします。
  • 各ワーカー ノードは、kubelet とコンテナ ランタイムを実行し、複数のポッドをホストします。
  • サービスは、外部または内部のトラフィックを正しいポッドにルーティングし、ポッドのライフサイクルと IP 変更の複雑さを抽象化した安定したエンドポイントを提供します。

このメンタル モデルは、クラスタの状態を調べたり、ノードのヘルス状態を確認したり、ポッドを一覧表示したり、サービスを照会したりする際に見るものを理解するのに役立ちます。これらの概念は、kubectl コマンドを使って Kubernetes をさらに探索する際に適用するものです。

クラスタのセットアップを確認する

このステップでは、必須の kubectl コマンドを使って Kubernetes クラスタの構成とヘルス状態を確認する方法を学びます。これらのコマンドは、クラスタの現在の状態と接続性を理解するのに役立ちます。

まず、クラスタ情報を確認します。

kubectl cluster-info

出力例:

Kubernetes control plane is running at https://192.168.49.2:8443
CoreDNS is running at https://192.168.49.2:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'

このコマンドは、Kubernetes コントロール プレーンと CoreDNS のようなコア サービスに関する詳細を提供します。

次に、クラスタ ノードの詳細なビューを取得します。

kubectl get nodes -o wide

出力例:

NAME       STATUS   ROLES           AGE    VERSION   INTERNAL-IP    EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION
minikube   Ready    control-plane   15m    v1.26.1   192.168.49.2   <none>        Ubuntu 22.04 LTS    5.15.0-72-generic

ノードの詳細をもう少し包括的に調べましょう。

kubectl describe node minikube

出力例(一部):

Name:               minikube
Roles:              control-plane
Labels:             beta.kubernetes.io/arch=amd64
                    beta.kubernetes.io/os=linux
                    kubernetes.io/arch=amd64
                    kubernetes.io/hostname=minikube
                    kubernetes.io/os=linux
                    minikube.k8s.io/commit=86a3b7e45a9a35cdcf8f4c80a4c6a46d20dda00f
Annotations:        node.alpha.kubernetes.io/ttl: 0
                    volumes.kubernetes.io/controller-managed-attach-detach: true
CreationTimestamp:  [Current Timestamp]
Capacity:
  cpu:                2
  ephemeral-storage:  17784212Ki
  memory:             1947748Ki
  pods:               110
Allocatable:
  cpu:                2
  ephemeral-storage:  16388876Ki
  memory:             1845348Ki
  pods:               110

これらのコマンドから得られる重要な洞察:

  1. クラスタ コントロール プレーンが稼働していることを確認する
  2. ノードの状態(Ready/NotReady)を確認する
  3. ノードのリソースと構成を理解する
  4. Kubernetes のバージョンとノードの詳細を確認する

基本的なクラスタ リソースを調べる

このステップでは、すべての名前空間にわたって基本的な Kubernetes リソース(ポッド、デプロイメント、サービスなど)を調べます。-A(または --all-namespaces)フラグを使用することで、クラスタ全体にわたるリソースの組織化方法を確認できます。これは、Kubernetes の 名前空間 の概念を導入し理解する良い機会です。

名前空間:リソースの隔離

名前空間は、Kubernetes クラスタ内の論理的な区分であり、リソースの組織化と管理に役立ちます。関連するオブジェクトをグループ化し、ポリシー、アクセス制御、およびリソース クォータを細かいレベルで適用する方法を提供します。リソースを異なる名前空間に分離することで、以下のことができます。

  • 組織化の向上: 関連するワークロードをグループ化する(たとえば、プロジェクト、チーム、または環境による区分 — 開発、テスト、本番など)。
  • セキュリティとアクセス制御の強化: 特定の名前空間内のリソースを表示または変更できるユーザーまたはサービス アカウントを制限する。
  • リソース管理の簡素化: リソース制限、ネットワーク ポリシー、およびその他のクラスタ全体の構成をより効果的に適用する。

-A(または --all-namespaces)フラグでリソースを一覧表示すると、Kubernetes システムに属するコンポーネントが kube-system 名前空間にあることに気付きます。この名前空間はクラスタレベルのインフラストラクチャ用に割り当てられています。ユーザーが作成したアプリケーションは通常、default 名前空間または定義したその他のカスタム名前空間にあります。

名前空間とリソース

flowchart LR %% User interacts with the cluster via kube-apiserver User((Developer)) User -->|kubectl get pods -A| API[kube-apiserver] %% Control Plane Subgraph subgraph ControlPlane[Control Plane] API ETCD[etcd] SCH[kube-scheduler] CTLM[kube-controller-manager] end API --> ETCD API --> SCH API --> CTLM %% kube-system namespace subgraph kube-system[Namespace: kube-system] SysDeployment[Deployment: coredns] SysPod1[Pod: coredns-xxx] SysService[Service: kube-dns] SysDeployment --> SysPod1 SysService --> SysPod1 end %% default namespace (renamed to avoid parse issues) subgraph defaultNs[Namespace: default] DefDeployment[Deployment: my-app] DefPod1[Pod: my-app-pod1] DefPod2[Pod: my-app-pod2] DefService[Service: my-app-service] DefDeployment --> DefPod1 DefDeployment --> DefPod2 DefService --> DefPod1 DefService --> DefPod2 end %% dev namespace subgraph dev[Namespace: dev] DevDeployment[Deployment: dev-app] DevPod[Pod: dev-app-pod] DevService[Service: dev-app-service] DevDeployment --> DevPod DevService --> DevPod end %% Demonstration of communication API --> kube-system API --> defaultNs API --> dev

この図では:

  • コントロール プレーン は、クラスタ全体を管理し、ノードと通信してワークロードを制御します。
  • 名前空間kube-systemdefaultdev など)は、クラスタ内のリソースを論理的に分離します。
    • kube-system には、CoreDNS や kube-dns のようなシステムレベルのコンポーネントがあります。
    • default は一般的なワークロード用に一般的に使用され、ここでは my-app デプロイメントで表されています。
    • dev は、本番ワークロードから隔離された開発環境を表す場合があります。

すべての名前空間にわたるリソースを表示することで、これらの論理的な区分が組織化されたセキュアなクラスタを維持する方法を包括的に理解できます。

例:

すべての名前空間にわたるすべてのポッドを一覧表示するには:

kubectl get pods -A

出力例:

NAMESPACE     NAME                               READY   STATUS    RESTARTS      AGE
kube-system   coredns-787d4945fb-j8rhx           1/1     Running   0             20m
kube-system   etcd-minikube                      1/1     Running   0             20m
kube-system   kube-apiserver-minikube            1/1     Running   0             20m
kube-system   kube-controller-manager-minikube   1/1     Running   0             20m
kube-system   kube-proxy-xb9rz                   1/1     Running   0             20m
kube-system   kube-scheduler-minikube            1/1     Running   0             20m
kube-system   storage-provisioner                1/1     Running   1 (20m ago)   20m

ここでは、kube-system 名前空間に実行されているすべてのシステム関連のポッドが表示されます。異なる名前空間に他のデプロイメントやサービスがある場合、それらもこの一覧に表示され、それぞれが名前空間によって明確にスコープ付けられます。

すべての名前空間にわたるすべてのデプロイメントを一覧表示するには:

kubectl get deployments -A

出力例:

NAMESPACE     NAME      READY   UP-TO-DATE   AVAILABLE   AGE
kube-system   coredns   1/1     1            1           20m

coredns デプロイメントは kube-system 名前空間にあります。

すべての名前空間にわたるすべてのリソースの包括的なビューを取得するには:

kubectl get all -A

このコマンドは、異なる名前空間にわたるポッド、サービス、およびデプロイメントの概要を表示し、これらのリソースがクラスタ全体にどのように分布しているかを理解するのに役立ちます。

要点:

  • 名前空間 は、Kubernetes クラスタ内で論理的な隔離と組織化を提供します。
  • 異なる Kubernetes コンポーネントとリソースは、特定の名前空間に組織化されています(たとえば、コア サービス用の kube-system、一般的なワークロード用の default、および作成するその他の名前空間)。
  • すべての名前空間にわたるリソースを表示するために -A を使用することで、クラスタがどのように構成されており、名前空間がリソースの組織化とアクセス制御の境界としてどのように機能するかを洞察することができます。

名前空間が論理的な環境としてどのように機能するかを理解することで、特にデプロイを拡大し、Kubernetes 環境により多くの複雑さを導入する際に、ワークロードと関連するクラスタ リソースをより良くナビゲートし、隔離し、管理することができます。

まとめ

この実験では、Minikube を使ってローカルの Kubernetes クラスタを起動して確認しました。Minikube は、学習や開発用のシングル ノードの Kubernetes 環境をセットアップするための簡単な方法を提供します。Minikube クラスタが正常に起動し、ローカルの Kubernetes クラスタが稼働し、クラスタが使用可能であり、コントロール プレーン機能を備えたシングル ノード クラスタがあることを確認しました。また、kubectl cluster-infokubectl get nodes などの必須の kubectl コマンドを使って Kubernetes クラスタの構成とヘルス状態を確認する方法を学び、クラスタの現在の状態と接続性を理解するのに役立ちました。