Kubernetes Introduction

会社で業務に関連する Udemy の講座が受け放題、とのことだったので、とりあえずアカウント発行してもらって、 Kubernetes から受講してみてます。

Docker ベースのコンテナ仮想化知識がある前提で、いったん基礎から Kubernetes を学んでいきます。

その際に重要と思った点と、別途Webなどで調べた内容のメモとして。

用語

Kubernetes: 元々は、ギリシャ語で「操舵手」とか「パイロット」みたいな意味。 若干揺らぎはあるみたいだけど、おおむね発音的には /k(j)uːbəˈnɛtɪs/ あたり。 日本語だと「クーベネティス」って言われてるみたい。
基本的には、Docker のコンテナをうまく管理してくれる仕組み、の解釈

kubectl コマンド： マスターノードに何かしらの操作を行う。 Kubernetes の操作全般に関わり、頻繁に使うコマンド。

Pod: コンテナをグループ化したもので、ワーカーノード上で走る。 また、仮想的な NIC や Volume も Pod 内のコンテナで共有できる。 言ってしまえば、「Pod＝仮想ホスト」のようなイメージ。

Service: Pod をクラスターの内外に公開するための静的IPアドレスを持った仮想的なエンドポイント。 L4ロードバランサとしての機能も持たせられる。
基本的に Pod のIPアドレスは動的なものだが、Service を利用することで、静的な単一のエンドポイントを提供できる。 また、Pod名での名前解決やルーティングのような機能も。

Node: 1つのVMまたは物理的なマシン

Cluster: 1つのコントロールプレーンと、1つ以上のノードを含む単位

Replica: Pod を複製して維持管理と冗長化を行なってくれる仕組みを提供する

Deployment: Pod のデプロイで Rolling update や Rollback といった管理の仕組みを提供する。

ConfigMap: 環境変数などの、Key Value ペアを保存するリソース。

Secret: ConfigMap と似たような仕組みで、こちらはBase64などでエンコードされたデータを保持できる。

PersistentVolume(PV): Node(物理)上にデータを保持し Cluster 内で共有する仕組み。Pod が動的に生成や破棄されてもデータが消えてしまわない性質を持つ。

PersistentVolumeClaim(PVC): PersistentVolume のうち各Podに割り当てたい容量を論理的に切り出し、マウントするためのリソース。

Namespace: リソースを仮想的(論理的に)分けるためのグループのような機能。
わかりにくいので、オフィシャルだとこんな説明。 -> In Kubernetes, namespaces provide a mechanism for isolating groups of resources within a single cluster.

Overlay Network: Kubernetes の文脈では、複数Node環境におけるPod間通信を実現するための仕組み。
一般には、「既存のネットワーク上に仮想的なネットワークレイヤーを追加する技術」と紹介される。 VXLANが代表的な実装。

Container Network Interface(CNI): コンテナ環境でネットワーク接続を管理するための標準となった仕様。 実際には、3rd Party系の Kubernetes 用 Plug-in として機能が提供される。

要点

kubernetes の機能は、Container Orchestration(コンテナオーケストレーション)と呼ばれ、主に開発と運用(インフラ含む)を橋渡しする、 DevOps 領域で利用される。

似たようなソフトウェアに、 Docker Swarm などがあるが、2020年付近では、 Kubernetes がデファクトスタンダードとなっている。 => したがって、コミュニティやドキュメントも豊富

minikube という小規模な Kubernetes 環境をローカル端末上で構築できるツールがあり、これを使えば Kubernetes の学習や開発/テストが本家よりも簡単になる。
※ Windows, Linux, macOS に対応

Container Orchestration ＝ 「複数ホスト上で複数のコンテナを稼働させる」 イメージ。
ここの管理が Docker 単体だと難しいため、 Kubernetes が利用される。

Kubernetes で実現できる機能(の一部)：

• 複数のPod(リソース)による冗長化
• Rolling update に対応(システムの停止をせずに更新する)
• システム稼働中の水平スケーリング
• 複数ホスト＆複数コンテナでの負荷分散
• Authentication & Authorization 機能の提供
• リソース監視
• ログなどの一括管理

Service には、3つの種類がある。

• ClusterIP: Pod同士の通信を行う際に静的IPなどの機能を提供。 Pod のIPに対する抽象化
• NodePort: クラスタの内外にノードのポートを公開する。 Cluster のIPに対する抽象化
• LoadBalancer: クラスタの内外に「L4ロードバランサ」のポートを公開する。 Node のIPに対する抽象化

Ingress: Pod をクラスタ内外に公開する L7ロードバランサ。　URLのPathによって、ロードバランシングを行うなど、L7レベルでのコントロールが可能。

Deployment リソースごとに LoadBalancer を付与する構成も可能だが、コストパフォーマンスが悪いため、Deployment 単位では NodePort Service を生成してその上で Ingress によってバランシングするのがベストプラクティス。

Imperative vs Declarative:

• Imperative: 命令的と訳される。 どのように処理するか？ -> プロセス的な視点の記述。 複雑になりがち。 Python や C など一般的にプログラミング言語と呼ばれるもの
• Declarative: 宣言的と訳される。 最終的に何が欲しいか？ -> リザルト的な視点の記述。 簡潔に記述できる。 SQL や HTML といった言語が代表的

kubectl run コマンドや kubectl expose コマンドに “–dry-run”, “-o yaml” の2つのオプションを追加するだけで生成したいKubernetesリソース の yaml 生成が可能。

Deployment は Pod の Wrapper であるということが、YAMLファイルからも確認できる。
関係的には、 \( \text{Deployment} \supset \text{ReplicaSet} \supset \text{Pod} \) となる。

ConfigMap を Volume としてマウントすることで、Pod から参照することができる。 また、環境変数をkubectl コマンドの引数や、YAMLマニフェストにハードコーディングして扱った場合には静的なものとなってしまうが、ConfigMap を利用することで柔軟性を持たせることができる。

kubectl delete namespace <namespace名> のコマンドで、 Namespace を削除すると、そのNamespace 上に分類されていたリソースも削除される。

Kubernetes 以外の Container Orchestration Tools:

• Docker Swarm: Kubernetes と同様のマスター/ワーカの構成
• Cloud Foundry: VMWare社によって開発されたオーケストレーションツール。 Kubernetes とは設計コンセプトがかなり異なる。
• Red Hat Openshift: Kubernetes をベースに開発されており、 Image Registry や CI/CDパイプラインが標準搭載。 なお、Red Hat社は、2019年にIBMにより買収されている。

まとめ

とりあえず Kubernetes の基礎ぐらいは頭に入ったかと、、、あとはハンズオンでどこまで触れるかなーと。