Kubernetes運用前に勉強していること基礎編03-05
注意
本記事の内容は個人的な勉強・備忘録を目的としており、勤務先や関係者とは一切関係ありません。
はじめに
Kubernetesの本番環境での運用を始めるにあたり、個人で勉強している内容を整理した記事です。構築や運用に必要な知識、注意点、実践して学んだことを随時更新していきます。基礎編の想定読者はコンテナの知識があり、Kubernetesでコンテナ運用したいがどうすればいいかを迷っている人です。今回は前回の引き続きで、Kubernetesのリソースカテゴリを学ぶことを目的としています。
勉強中の主な内容
- 基礎編
- クラウドネイティブとは
- Kubernetesのアーキテクチャ概要
- Kubernetesのリソース（今回の話）
前提知識
ExternalName と Headless の 2 型は「仮想IPを持たない」特殊な存在である。どちらも kube‑proxy を経由せずDNSだけで、Pod や外部ホストを解決し、以下のように役割が分かれている。
| 型 | 主対象 | DNS 返却内容 | 典型ユースケース |
|---|---|---|---|
| ExternalName | クラスタ外リソース | CNAME | DB、SaaS |
| Headless | クラスタ内 Pod 群 | A/AAAA（複数） | StatefulSet、分散 DB |
ExternalName
特殊なタイプで、ClusterIPを持たず、Service名に対するDNSクエリを特定の外部ドメイン名（例えばdb.example.com）に名前解決させる。クラスタ内のアプリから見ると通常のService名にアクセスしているようで、実際には外部のDNS名に転送される。外部サービスを内部に偽装する用途（例えば、RDSなどのAWSサービスをあたかもクラスタ内サービスのように扱う）に使われる。
Headless
Headlessの場合、 kube‑proxy は 仮想IP を作らず、CoreDNS は Endpointsに登録されたPod IPを丸ごと返却する。
所感
kubenetesを運用するうえで必須のサービスについて勉強を行った。KubernetesのServiceは、動的環境におけるサービスディスカバリとロードバランシングを組み込みで提供するものであることが理解できた。
従来、サービスディスカバリにはDNSやサービスレジストリを手作業で設定したり、ロードバランサも手動設定する必要がありました。現在のシステムも、ELBの管理が大変なので、このあたりを考えてもいいのではないかと思っている。
KubernetesではPodのライフサイクル管理と統合してServiceが作られており、コントロールプレーンがPodの変化を即座にDNS（CoreDNS）やプロキシ（iptables）に伝播させる。これにより、宣言的にサービスエンドポイントを定義するだけで、あとはシステムが自動で環境を整えるという、一貫性の高いモデルを実現していることが理解できた。やはり、IaC的な考え方を徹底させるのにはよいツールに思える。
次の記事は引き続き、ネットワーク関連のIngressについての説明を行っていく。
補足
過去の記事で記載していた内容を補足として追記しています。
Kubernetesのリソースカテゴリ
Kubernetesのリソースカテゴリは、『Kubernetes完全ガイド第二版』をベースとしている。
| カテゴリ | 概要 |
|---|---|
|
Workload APIs |
アプリケーション（コンテナ）の実行を管理するためのリソース |
|
Service APIs |
Pod内のコンテナをネットワーク経由で公開し、アクセスを提供するリソース |
|
Config APIs |
コンテナで利用する設定や機密情報を管理するためのリソース |
|
Storage APIs |
コンテナで利用する永続化データを管理するためのリソース |
|
Cluster APIs |
クラスタ内のリソースの運用や管理、セキュリティを制御するリソース |
|
Metadata APIs |
クラスタ内の他リソースの操作や動的なメタデータ管理を行うリソース |