Kubernetes入門：コンテナオーケストレーター

spinny:~/writing $ vim introduction-to-kubernetes.md

1~
2ソフトウェア開発の世界で働いているなら、Kubernetesという言葉をきっと聞いたことがあるでしょう。しかし、それは一体何であり、なぜコンテナ化されたアプリケーションを管理するためのデファクトスタンダードになったのでしょうか？このガイドでは、基本から始めて、実践的な例と図を使って基本的な概念を理解する手助けをします。
3~
4## Kubernetes以前：少し歴史を振り返って
5~
6Kubernetesがなぜそれほど革命的であるかを理解するために、一歩下がってみましょう。
7~
81.  **従来のデプロイメント**：当初、アプリケーションは物理サーバー上で実行されていました。このアプローチはコストが高く、スケーリングが難しく、リソースの競合が発生しやすいものでした。
92.  **仮想化デプロイメント**：次に仮想マシン（VM）が登場しました。VMにより、同じハードウェア上で複数の隔離されたアプリケーションを実行できるようになり、リソースの利用率とセキュリティが向上しました。しかし、各VMは完全なオペレーティングシステムを実行するため、多くのリソースを消費します。
103.  **コンテナ化デプロイメント**：コンテナ（Dockerなど）は次の進化です。コンテナは同じホストオペレーティングシステムを共有しますが、隔離されたプロセスを実行します。軽量で、起動が速く、ポータブルです。
11~
12コンテナはポータビリティの問題を解決しましたが、別の問題を生み出しました。それは、本番環境で数百（または数千）のコンテナをどのように管理するかということです。それらが常に実行されていること、互いに通信できること、そして負荷に応じてスケールすることを確認するにはどうすればよいでしょうか？
13~
14ここで**Kubernetes**が登場します。
15~
16## Kubernetesとは？
17~
18Kubernetes（しばしば**K8s**と略されます）は、コンテナオーケストレーションのためのオープンソースプラットフォームです。簡単に言えば、コンテナ化されたアプリケーションのデプロイ、スケーリング、管理を自動化します。Googleによって作成され、現在はCloud Native Computing Foundation（CNCF）によって維持されており、Kubernetesはマイクロサービスを大規模に扱うすべての人にとって頼りになるツールとなっています。
19~
20## Kubernetesクラスターのアーキテクチャ
21~
22Kubernetes環境は**クラスター**と呼ばれます。クラスターは、アプリケーションを実行する一連のマシン（**ノード**と呼ばれます）で構成されています。アーキテクチャは、コントロールプレーンとワーカーノードの2つの主要部分に分かれています。
23~
24```mermaid
25graph TD
26    subgraph "コントロールプレーン (Master)"
27        A["APIサーバー"]
28        B["etcd"]
29        C["スケジューラ"]
30        D["コントローラーマネージャー"]
31    end
32~
33    subgraph "ワーカーノード1"
34        E["Kubelet"] --- F["コンテナランタイム"]
35        G["Kube-proxy"]
36        F --- H["Pod"]
37        F --- I["Pod"]
38    end
39~
40    subgraph "ワーカーノード2"
41        J["Kubelet"] --- K["コンテナランタイム"]
42        L["Kube-proxy"]
43        K --- M["Pod"]
44    end
45~
46    A -- "通信" --> E
47    A -- "通信" --> J
48    User -- "kubectl" --> A
49    C -- "Podをノードに割り当てる" --> E
50    D -- "状態を維持" --> A
51    A -- "状態を保存/読み取り" --> B
52```
53~
54### コントロールプレーン
55~
56コントロールプレーンはクラスターの「頭脳」です。グローバルな決定（スケジューリングなど）を行い、クラスターイベントを検出して応答します。その主要なコンポーネントは次のとおりです。
57~
58-   **APIサーバー (`kube-apiserver`)**：クラスターへのゲートウェイです。Kubernetes APIを公開し、ユーザー（`kubectl`経由）、クラスターコンポーネント、外部ツールが通信するために使用します。
59-   **etcd**：一貫性があり、高可用性のキーバリューデータベースです。すべてのクラスターデータを保存し、システムの望ましい状態と現在の状態を表します。
60-   **スケジューラ (`kube-scheduler`)**：新しく作成されたPodを、リソース要件、ポリシー、その他の制約を考慮して利用可能なワーカーノードに割り当てます。
61-   **コントローラーマネージャー (`kube-controller-manager`)**：コントローラーを実行します。これらは、クラスターの状態を監視し、それを望ましい状態にするために働く制御ループです。たとえば、`Node Controller`はノードを管理し、`Replication Controller`は正しい数のPodが実行されていることを確認します。
62~
63### ワーカーノード
64~
65ワーカーノードは、アプリケーションが実際に実行されるマシン（物理または仮想）です。各ノードはコントロールプレーンによって管理され、次のコンポーネントが含まれています。
66~
67-   **Kubelet**：各ノードで実行されるエージェントです。Podで記述されたコンテナが実行され、正常であることを確認します。
68-   **Kube-proxy**：ノード上のネットワークルールを管理するネットワークプロキシです。クラスター内外のネットワークセッションからPodへのネットワーク通信を可能にします。
69-   **コンテナランタイム**：コンテナの実行を担当するソフトウェアです。Dockerが最も有名ですが、Kubernetesは`containerd`や`CRI-O`などの他のランタイムもサポートしています。
70~
71## Kubernetesの基本オブジェクト
72~
73Kubernetesでは、すべてが**オブジェクト**によって表されます。これらのオブジェクトは「意図の記録」です。オブジェクトを作成すると、Kubernetesはそれが存在し、望ましい状態と一致することを保証するために常に働きます。
74~
75最も重要なものは次のとおりです。
76~
77### Pod
78~
79**Pod**はKubernetesで最小の実行単位です。同じノードで一緒に実行される1つ以上のコンテナを表し、ネットワークやストレージなどのリソースを共有します。
80~
81通常、Podごとに1つのコンテナしか実行しませんが、高度なシナリオ（ロギングやモニタリングのための「サイドカーコンテナ」など）では、複数持つことができます。
82~
83Podを直接作成することはほとんどありません。Deploymentのような高レベルの抽象化を使用します。
84~
85### Deployment
86~
87**Deployment**は、最も頻繁に使用するオブジェクトです。同一のPodのグループの望ましい状態を記述します。Deploymentコントローラーは、次のことを担当します。
88~
89-   **ReplicaSet**（特定の数のPodのレプリカが常に実行されていることを保証する別のオブジェクト）を作成および管理します。
90-   Podの数を**スケーリング**（増減）します。
91-   ダウンタイムなしで、制御された方法でアプリケーションの**更新**（例：*ローリングアップデート*）を管理します。
92~
93以下は、NGINXサーバーの3つのレプリカを実行するDeploymentのYAMLファイルの例です。
94~
95```yaml
96# nginx-deployment.yaml
97apiVersion: apps/v1
98kind: Deployment
99metadata:
100  name: nginx-deployment
101spec:
102  replicas: 3
103  selector:
104    matchLabels:
105      app: nginx
106  template:
107    metadata:
108      labels:
109        app: nginx
110    spec:
111      containers:
112      - name: nginx
113        image: nginx:1.14.2
114        ports:
115        - containerPort: 80
116```
117~
118### Service
119~
120KubernetesのPodは一時的なものです。いつでも作成および破棄できます。各Podには独自のIPアドレスがありますが、このIPは安定していません。では、どうすればアプリケーションを確実に公開できるのでしょうか？
121~
122**Service**を使用します。Serviceは、論理的なPodのセットとそれらにアクセスするためのポリシーを定義する抽象化です。Podのグループに**安定したアクセスポイント**（仮想IPアドレスとDNS名）を提供します。
123~
124```mermaid
125graph TD
126    subgraph "Service (nginx-service)"
127        A["ClusterIP: 10.96.0.10"]
128    end
129~
130    subgraph "Pods"
131        B("Pod 1 - IP: 192.168.1.2")
132        C("Pod 2 - IP: 192.168.1.3")
133        D("Pod 3 - IP: 192.168.1.4")
134    end
135~
136    A -- "Selector: app=nginx" --> B
137    A -- "Selector: app=nginx" --> C
138    A -- "Selector: app=nginx" --> D
139~
140    Client -- "nginx-serviceへのリクエスト" --> A
141```
142~
143Serviceは、`labels`に基づく`selector`を使用して、トラフィックを転送するPodを見つけます。
144~
145以下は、NGINX Deployment用のServiceを作成する方法です。
146~
147```yaml
148# nginx-service.yaml
149apiVersion: v1
150kind: Service
151metadata:
152  name: nginx-service
153spec:
154  selector:
155    app: nginx
156  ports:
157    - protocol: TCP
158      port: 80
159      targetPort: 80
160  type: ClusterIP # デフォルト - クラスター内でのみサービスを公開
161```
162~
163Serviceにはさまざまな種類があります。
164- `ClusterIP`：クラスター内部IPでサービスを公開します（デフォルト）。
165- `NodePort`：各ワーカーノードの静的ポートでサービスを公開します。
166- `LoadBalancer`：クラウドプロバイダー（AWS、GCPなど）に外部ロードバランサーを作成し、サービスにパブリックIPを割り当てます。
167~
168### Ingress
169~
170`LoadBalancer`タイプのServiceは素晴らしいですが、サービスごとに作成するとコストがかかる可能性があります。複数のHTTP/HTTPSサービスを外部に公開するには、**Ingress**を使用します。
171~
172Ingressは、外部トラフィックの「インテリジェントなルーター」として機能します。ホスト（例：`api.mysite.com`）またはパス（例：`mysite.com/api`）に基づいてルーティングルールを定義できます。
173~
174```mermaid
175graph LR
176    User -- "mysite.com/api" --> Ingress
177    User -- "mysite.com/ui" --> Ingress
178~
179    subgraph "Cluster"
180        Ingress -- "/api" --> ServiceA("api-service")
181        Ingress -- "/ui" --> ServiceB("ui-service")
182~
183        ServiceA --> PodA1("API Pod 1")
184        ServiceA --> PodA2("API Pod 2")
185~
186        ServiceB --> PodB1("UI Pod 1")
187        ServiceB --> PodB2("UI Pod 2")
188    end
189```
190~
191以下はIngressの例です。
192```yaml
193# example-ingress.yaml
194apiVersion: networking.k8s.io/v1
195kind: Ingress
196metadata:
197  name: example-ingress
198spec:
199  rules:
200  - host: mysite.com
201    http:
202      paths:
203      - path: /api
204        pathType: Prefix
205        backend:
206          service:
207            name: api-service
208            port:
209              number: 8080
210      - path: /ui
211        pathType: Prefix
212        backend:
213          service:
214            name: ui-service
215            port:
216              number: 3000
217```
218~
219### その他の便利なオブジェクト
220~
221-   **Namespace**：物理クラスター内に「仮想クラスター」を作成できます。環境（例：`development`、`staging`、`production`）やチームを隔離するのに便利です。
222-   **ConfigMapとSecret**：コンテナイメージから切り離して、設定データやシークレット（パスワードやAPIキーなど）を管理します。
223-   **StatefulSet**：Deploymentに似ていますが、安定したネットワークIDと永続ストレージを必要とするステートフルなアプリケーション（データベースなど）に特化しています。
224-   **PersistentVolume (PV)とPersistentVolumeClaim (PVC)**：クラスター内の永続ストレージを管理します。
225~
226## 結論
227~
228Kubernetesは非常に強力なツールですが、学習曲線が急な場合があります。このガイドは表面をなぞっただけですが、基本的な概念をしっかりと理解する助けになったことを願っています。
229~
230**次に何をすべきか？**
231- **ローカルで実験する**：[Minikube](https://minikube.sigs.k8s.io/docs/start/)または[Kind](https://kind.sigs.k8s.io/docs/user/quick-start/)をインストールして、お使いのコンピューターにKubernetesクラスターを作成します。
232- **`kubectl`を使用する**：クラスターと対話するための主要なツールである`kubectl`コマンドに慣れましょう。この記事のNGINX DeploymentとServiceを作成してみてください。
233- **公式チュートリアルを調べる**：[Kubernetesドキュメント](https://kubernetes.io/docs/tutorials/)は、例が豊富な素晴らしいリソースです。
234~
235コンテナオーケストレーションは、クラウドネイティブの世界における基本的なスキルであり、Kubernetesをマスターすれば、可能性の世界が広がります。楽しんでください！

NORMAL · introduction-to-kubernetes.md [readonly]235 lines · :q to close

2ソフトウェア開発の世界で働いているなら、Kubernetesという言葉をきっと聞いたことがあるでしょう。しかし、それは一体何であり、なぜコンテナ化されたアプリケーションを管理するためのデファクトスタンダードになったのでしょうか？このガイドでは、基本から始めて、実践的な例と図を使って基本的な概念を理解する手助けをします。

4## Kubernetes以前：少し歴史を振り返って

6Kubernetesがなぜそれほど革命的であるかを理解するために、一歩下がってみましょう。

81. **従来のデプロイメント**：当初、アプリケーションは物理サーバー上で実行されていました。このアプローチはコストが高く、スケーリングが難しく、リソースの競合が発生しやすいものでした。

92. **仮想化デプロイメント**：次に仮想マシン（VM）が登場しました。VMにより、同じハードウェア上で複数の隔離されたアプリケーションを実行できるようになり、リソースの利用率とセキュリティが向上しました。しかし、各VMは完全なオペレーティングシステムを実行するため、多くのリソースを消費します。

103. **コンテナ化デプロイメント**：コンテナ（Dockerなど）は次の進化です。コンテナは同じホストオペレーティングシステムを共有しますが、隔離されたプロセスを実行します。軽量で、起動が速く、ポータブルです。

11~

12コンテナはポータビリティの問題を解決しましたが、別の問題を生み出しました。それは、本番環境で数百（または数千）のコンテナをどのように管理するかということです。それらが常に実行されていること、互いに通信できること、そして負荷に応じてスケールすることを確認するにはどうすればよいでしょうか？

13~

14ここで**Kubernetes**が登場します。

15~

16## Kubernetesとは？

17~

18Kubernetes（しばしば**K8s**と略されます）は、コンテナオーケストレーションのためのオープンソースプラットフォームです。簡単に言えば、コンテナ化されたアプリケーションのデプロイ、スケーリング、管理を自動化します。Googleによって作成され、現在はCloud Native Computing Foundation（CNCF）によって維持されており、Kubernetesはマイクロサービスを大規模に扱うすべての人にとって頼りになるツールとなっています。

19~

20## Kubernetesクラスターのアーキテクチャ

21~

22Kubernetes環境は**クラスター**と呼ばれます。クラスターは、アプリケーションを実行する一連のマシン（**ノード**と呼ばれます）で構成されています。アーキテクチャは、コントロールプレーンとワーカーノードの2つの主要部分に分かれています。

23~

24```mermaid

25graph TD

26 subgraph "コントロールプレーン (Master)"

27 A["APIサーバー"]

28 B["etcd"]

29 C["スケジューラ"]

30 D["コントローラーマネージャー"]

31 end

32~

33 subgraph "ワーカーノード1"

34 E["Kubelet"] --- F["コンテナランタイム"]

35 G["Kube-proxy"]

36 F --- H["Pod"]

37 F --- I["Pod"]

38 end

39~

40 subgraph "ワーカーノード2"

41 J["Kubelet"] --- K["コンテナランタイム"]

42 L["Kube-proxy"]

43 K --- M["Pod"]

44 end

45~

46 A -- "通信" --> E

47 A -- "通信" --> J

48 User -- "kubectl" --> A

49 C -- "Podをノードに割り当てる" --> E

50 D -- "状態を維持" --> A

51 A -- "状態を保存/読み取り" --> B

52```

53~

54### コントロールプレーン

55~

56コントロールプレーンはクラスターの「頭脳」です。グローバルな決定（スケジューリングなど）を行い、クラスターイベントを検出して応答します。その主要なコンポーネントは次のとおりです。

57~

58- **APIサーバー (`kube-apiserver`)**：クラスターへのゲートウェイです。Kubernetes APIを公開し、ユーザー（`kubectl`経由）、クラスターコンポーネント、外部ツールが通信するために使用します。

59- **etcd**：一貫性があり、高可用性のキーバリューデータベースです。すべてのクラスターデータを保存し、システムの望ましい状態と現在の状態を表します。

60- **スケジューラ (`kube-scheduler`)**：新しく作成されたPodを、リソース要件、ポリシー、その他の制約を考慮して利用可能なワーカーノードに割り当てます。

61- **コントローラーマネージャー (`kube-controller-manager`)**：コントローラーを実行します。これらは、クラスターの状態を監視し、それを望ましい状態にするために働く制御ループです。たとえば、`Node Controller`はノードを管理し、`Replication Controller`は正しい数のPodが実行されていることを確認します。

62~

63### ワーカーノード

64~

65ワーカーノードは、アプリケーションが実際に実行されるマシン（物理または仮想）です。各ノードはコントロールプレーンによって管理され、次のコンポーネントが含まれています。

66~

67- **Kubelet**：各ノードで実行されるエージェントです。Podで記述されたコンテナが実行され、正常であることを確認します。

68- **Kube-proxy**：ノード上のネットワークルールを管理するネットワークプロキシです。クラスター内外のネットワークセッションからPodへのネットワーク通信を可能にします。

69- **コンテナランタイム**：コンテナの実行を担当するソフトウェアです。Dockerが最も有名ですが、Kubernetesは`containerd`や`CRI-O`などの他のランタイムもサポートしています。

70~

71## Kubernetesの基本オブジェクト

72~

73Kubernetesでは、すべてが**オブジェクト**によって表されます。これらのオブジェクトは「意図の記録」です。オブジェクトを作成すると、Kubernetesはそれが存在し、望ましい状態と一致することを保証するために常に働きます。

74~

75最も重要なものは次のとおりです。

76~

77### Pod

78~

79**Pod**はKubernetesで最小の実行単位です。同じノードで一緒に実行される1つ以上のコンテナを表し、ネットワークやストレージなどのリソースを共有します。

80~

81通常、Podごとに1つのコンテナしか実行しませんが、高度なシナリオ（ロギングやモニタリングのための「サイドカーコンテナ」など）では、複数持つことができます。

82~

83Podを直接作成することはほとんどありません。Deploymentのような高レベルの抽象化を使用します。

84~

85### Deployment

86~

87**Deployment**は、最も頻繁に使用するオブジェクトです。同一のPodのグループの望ましい状態を記述します。Deploymentコントローラーは、次のことを担当します。

88~

89- **ReplicaSet**（特定の数のPodのレプリカが常に実行されていることを保証する別のオブジェクト）を作成および管理します。

90- Podの数を**スケーリング**（増減）します。

91- ダウンタイムなしで、制御された方法でアプリケーションの**更新**（例：*ローリングアップデート*）を管理します。

92~

93以下は、NGINXサーバーの3つのレプリカを実行するDeploymentのYAMLファイルの例です。

94~

95```yaml

96# nginx-deployment.yaml

97apiVersion: apps/v1

98kind: Deployment

99metadata:

100 name: nginx-deployment

101spec:

102 replicas: 3

103 selector:

104 matchLabels:

105 app: nginx

106 template:

107 metadata:

108 labels:

109 app: nginx

110 spec:

111 containers:

112 - name: nginx

113 image: nginx:1.14.2

114 ports:

115 - containerPort: 80

116```

117~

118### Service

119~

120KubernetesのPodは一時的なものです。いつでも作成および破棄できます。各Podには独自のIPアドレスがありますが、このIPは安定していません。では、どうすればアプリケーションを確実に公開できるのでしょうか？

121~

122**Service**を使用します。Serviceは、論理的なPodのセットとそれらにアクセスするためのポリシーを定義する抽象化です。Podのグループに**安定したアクセスポイント**（仮想IPアドレスとDNS名）を提供します。

123~

124```mermaid

125graph TD

126 subgraph "Service (nginx-service)"

127 A["ClusterIP: 10.96.0.10"]

128 end

129~

130 subgraph "Pods"

131 B("Pod 1 - IP: 192.168.1.2")

132 C("Pod 2 - IP: 192.168.1.3")

133 D("Pod 3 - IP: 192.168.1.4")

134 end

135~

136 A -- "Selector: app=nginx" --> B

137 A -- "Selector: app=nginx" --> C

138 A -- "Selector: app=nginx" --> D

139~

140 Client -- "nginx-serviceへのリクエスト" --> A

141```

142~

143Serviceは、`labels`に基づく`selector`を使用して、トラフィックを転送するPodを見つけます。

144~

145以下は、NGINX Deployment用のServiceを作成する方法です。

146~

147```yaml

148# nginx-service.yaml

149apiVersion: v1

150kind: Service

151metadata:

152 name: nginx-service

153spec:

154 selector:

155 app: nginx

156 ports:

157 - protocol: TCP

158 port: 80

159 targetPort: 80

160 type: ClusterIP # デフォルト - クラスター内でのみサービスを公開

161```

162~

163Serviceにはさまざまな種類があります。

164- `ClusterIP`：クラスター内部IPでサービスを公開します（デフォルト）。

165- `NodePort`：各ワーカーノードの静的ポートでサービスを公開します。

166- `LoadBalancer`：クラウドプロバイダー（AWS、GCPなど）に外部ロードバランサーを作成し、サービスにパブリックIPを割り当てます。

167~

168### Ingress

169~

170`LoadBalancer`タイプのServiceは素晴らしいですが、サービスごとに作成するとコストがかかる可能性があります。複数のHTTP/HTTPSサービスを外部に公開するには、**Ingress**を使用します。

171~

172Ingressは、外部トラフィックの「インテリジェントなルーター」として機能します。ホスト（例：`api.mysite.com`）またはパス（例：`mysite.com/api`）に基づいてルーティングルールを定義できます。

173~

174```mermaid

175graph LR

176 User -- "mysite.com/api" --> Ingress

177 User -- "mysite.com/ui" --> Ingress

178~

179 subgraph "Cluster"

180 Ingress -- "/api" --> ServiceA("api-service")

181 Ingress -- "/ui" --> ServiceB("ui-service")

182~

183 ServiceA --> PodA1("API Pod 1")

184 ServiceA --> PodA2("API Pod 2")

185~

186 ServiceB --> PodB1("UI Pod 1")

187 ServiceB --> PodB2("UI Pod 2")

188 end

189```

190~

191以下はIngressの例です。

192```yaml

193# example-ingress.yaml

194apiVersion: networking.k8s.io/v1

195kind: Ingress

196metadata:

197 name: example-ingress

198spec:

199 rules:

200 - host: mysite.com

201 http:

202 paths:

203 - path: /api

204 pathType: Prefix

205 backend:

206 service:

207 name: api-service

208 port:

209 number: 8080

210 - path: /ui

211 pathType: Prefix

212 backend:

213 service:

214 name: ui-service

215 port:

216 number: 3000

217```

218~

219### その他の便利なオブジェクト

220~

221- **Namespace**：物理クラスター内に「仮想クラスター」を作成できます。環境（例：`development`、`staging`、`production`）やチームを隔離するのに便利です。

222- **ConfigMapとSecret**：コンテナイメージから切り離して、設定データやシークレット（パスワードやAPIキーなど）を管理します。

223- **StatefulSet**：Deploymentに似ていますが、安定したネットワークIDと永続ストレージを必要とするステートフルなアプリケーション（データベースなど）に特化しています。

224- **PersistentVolume (PV)とPersistentVolumeClaim (PVC)**：クラスター内の永続ストレージを管理します。

225~

226## 結論

227~

228Kubernetesは非常に強力なツールですが、学習曲線が急な場合があります。このガイドは表面をなぞっただけですが、基本的な概念をしっかりと理解する助けになったことを願っています。

229~

230**次に何をすべきか？**

231- **ローカルで実験する**：[Minikube](https://minikube.sigs.k8s.io/docs/start/)または[Kind](https://kind.sigs.k8s.io/docs/user/quick-start/)をインストールして、お使いのコンピューターにKubernetesクラスターを作成します。

232- **`kubectl`を使用する**：クラスターと対話するための主要なツールである`kubectl`コマンドに慣れましょう。この記事のNGINX DeploymentとServiceを作成してみてください。

233- **公式チュートリアルを調べる**：[Kubernetesドキュメント](https://kubernetes.io/docs/tutorials/)は、例が豊富な素晴らしいリソースです。

234~

235コンテナオーケストレーションは、クラウドネイティブの世界における基本的なスキルであり、Kubernetesをマスターすれば、可能性の世界が広がります。楽しんでください！