Kubernetes運用前に勉強していること基礎編01
注意
本記事の内容は個人的な勉強・備忘録を目的としており、勤務先や関係者とは一切関係ありません。
はじめに
Kubernetesの本番環境での運用を始めるにあたり、個人で勉強している内容を整理した記事です。構築や運用に必要な知識、注意点、実践して学んだことを随時更新していきます。基礎編の想定読者はコンテナの知識があり、Kubernetesでコンテナ運用したいがどうすればいいかを迷っている人むけです。
勉強中の主な内容
- 基礎編
- クラウドネイティブとは（今回の話）
- Kubernetesの基礎概念
- Kubernetesのリソース
目的
- 本番運用でのトラブル防止
- 安定した運用に向けたベストプラクティスの習得
- 継続的な学習と情報整理
クラウドネイティブとは
クラウドネイティブとは、アプリケーションをクラウド環境に最適化された方法で開発・運用することである。
クラウドネイティブなアプリケーションには以下の特徴がある。
- コンテナ化
- 動的にスケール可能
- 疎結合
- 不変性
- 宣言的管理
CNCF（Cloud Native Computing Foundation）の技術スタックが代表的な例である。
先ほどの特徴をKubernetesでの具体例を示したのが下記の表である。
クラウドネイティブの要点とKubernetesでの具体例
| 概念 | 説明・目的 | Kubernetesでの具体例 |
|---|---|---|
| コンテナ化 | アプリケーションやその依存関係をコンテナとしてパッケージ化することで、環境差をなくし、移植性を高める。 | Podを利用し、Dockerイメージをデプロイして実行する。 |
| 動的スケーリング | 負荷に応じてリソース（Pod数）を自動的に増減させる。 | Horizontal Pod Autoscaler（HPA）を使用して、CPU使用率に応じPodを増減させる。 |
| 疎結合 | コンポーネント同士が強く依存しない設計 | Serviceを介したサービス間通信 |
| 不変性 | 一度作成したリソースを変更せず、新規作成により変更を適用する。 | 新しいコンテナイメージを作成し、Deploymentでローリングアップデートを実施する。 |
| 宣言的管理 | 実現したいシステム状態を事前に定義し、自動で維持する。 | YAMLマニフェストでDeploymentを定義し、宣言的にPodを管理する。 |
新たな抽象化の理解
kubenetesのようなコンテナオーケストレータは分散アプリケーションにまつわる問題に取り組みの新しい基本的な要素と抽象化の仕組みを提供する。次章の「Kubernetesの基礎概念」では詳しく抽象化された世界について説明している。本章では、クラウドネイティブに必要な要素技術を説明する。
クラウドネイティブに至る道
下記の図はクラウドネイティブプラットフォームに必要なコンテナ開発技術のテクニックのレイヤー図である。
 |
| コンテナ開発技術のテクニックのレイヤー図 |
各層の解説と関連性
クリーンコード（最下層）
- 基盤となる土台: すべての優れたソフトウェア開発の出発点
- 特徴: 明確な構造、適切な命名、テスト可能性、保守性
- 上位層への貢献: 変更や拡張が容易なため、コンテナ化の前提条件
- 実践: 継続的なリファクタリング、自動テスト、コードレビュー
ドメイン駆動設計（DDD）
- ビジネスドメインの理解: 現実世界の問題をソフトウェアに反映
- コリキタスなドメインモデル: ビジネス用語と技術用語の統一
- 上位層への貢献: マイクロサービスの境界を決める際の基準を提供
- 実践: ユビキタス言語の使用、境界づけられたコンテキスト、戦略的設計
クリーンアーキテクチャ
- 疎結合なコンポーネント: ビジネスロジックとインフラストラクチャの分離
- 上位層への貢献: マイクロサービスの内部設計に適用され、サービス間の依存関係を最小化
- 実践: ポート&アダプターパターン、依存性逆転の原則、インターフェースを介した通信
マイクロサービスの原則
- 変更に最適化: 独立したデプロイ、スケーリング、進化が可能
- 上位層への貢献: コンテナ化に適した単位を提供、Kubernetesの管理対象となる
- 実践: サービス間の明確な境界、APIゲートウェイ、分散トレーシング、サーキットブレーカー
Kubernetesパターン（最上層）
- 自動化されたコンテナ管理: スケーリング、自己修復、ローリングアップデート
- クラウドネイティブの集大成: 下層のすべての実践を活かす基盤
- 実現する価値: 高可用性、スケーラビリティ、弾力性、観測可能性
- 実践: 宣言的設定、オペレータパターン、サイドカー、アンバサダー
層間の相互作用
- 下から上への構築プロセス:
- クリーンコードの上にドメインモデルを構築
- ドメインモデルをヘキサゴナルアーキテクチャで実装
- マイクロサービスとして分割
- Kubernetesでオーケストレーション
- 上から下へのフィードバック:
- Kubernetesの運用経験がマイクロサービス設計に影響
- マイクロサービスの境界がドメインモデルの洗練に貢献
- アーキテクチャの評価がコード品質改善につながる
クラウドネイティブへの道のメリット
この階層的アプローチにより、開発チームは各レベルでの責任と関心事を明確に分離できる。
段階的に複雑さに取り組み、スキルを構築でき、既存のアプリケーションをクラウドネイティブに移行する際の道筋を理解できる。チームの成熟度に応じて適切なレベルから始め、徐々に上位層へと進化させられることが重要である。
まとめ
クラウドネイティブは、単なる技術的な選択ではなく、コードの品質からKubernetesのオーケストレーションまでの包括的なアプローチである。この階層モデルは、その道のりを体系的に理解し、実践するためのフレームワークを理解する必要がある。
個人の所感
経営層にとってKubernetesは、インフラや運用コストを抑えつつ、柔軟で効率的なシステム構築を可能にする魅力的な技術です。特にクラウド環境での自動化やリソース効率の改善は、経営的な視点から見ると大きなメリットがありそう。これが世の中でKubernetesが流行っている理由かもしれない。
現場の技術者からすると、Kubernetesは単なる「便利な道具」という以上に高度な専門知識を要するシステムだと思いました。設定や運用にはインフラ、ネットワーク、コンテナ化、セキュリティ、監視や障害対応など幅広いスキルが求められます。実際には、小さな改善やトラブルシューティングの積み重ねによって、ようやく安定した環境が構築されるはずです。導入した結果、継続的な知識のアップデートや改善活動が維持できなくなって、失敗するケースが多いように思えます。
経営層の視点では「コスト面で魅力的」なKubernetesも、現場から見れば「高い技術力と継続的な努力」が必要なものであるという認識のギャップがあり、想定した運用ができていない気がしますね。
かなりコストをかけて、勉強する必要がありそう....