はじめに
アプリケーションの開発を行うエンジニアであっても、インフラに関する事もある程度は知っておく必要がありそう…。
というわけでコンテナオーケストレーションについて理解を深めておこうと思い、kubernetesの基本概念について理解してみたので、その備忘録を残す。
※本記事内の操作は以下のように、docker/minikube/kubectlのそれぞれが利用可能な状態である事が前提となっている。環境構築については今後記事を執筆予定。
[root@control-plane docker-kubernetes]# docker version
Client: Docker Engine - Community
Version: 20.10.7
API version: 1.41
...
Server: Docker Engine - Community
Engine:
Version: 20.10.7
API version: 1.41 (minimum version 1.12)
...
[root@control-plane docker-kubernetes]# kubectl version
Client Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.2", GitCommit:"092fbfbf53427de67cac1e9fa54aaa09a28371d7", GitTreeState:"clean", BuildDate:"2021-06-16T12:59:11Z", GoVersion:"go1.16.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.7", GitCommit:"132a687512d7fb058d0f5890f07d4121b3f0a2e2", GitTreeState:"clean", BuildDate:"2021-05-12T12:32:49Z", GoVersion:"go1.15.12", Compiler:"gc", Platform:"linux/amd64"}
[root@control-plane docker-kubernetes]# minikube status
minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured
kubernetesでHello World!
まずは最初になる事としてはお決まりの"Hello World!"をやってみたいと思う。
やる事としては、hello-worldのDockerイメージをkubernetes（k8s）上で実行し、k8s内のログを確認して削除する、というもの。
実際にk8s上で動かしてみると以下の画像のようになる。
※一応、コマンドで何をしているか？を見ていくと、
-
kubectl run hello-world --image=hello-world --restart=Never
指定したイメージをクラスタ上で実行している--restart=Neverは通常のpodを作成するための引数
https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#run -
kubectl get pod
ps出力形式で全podのリストを表示
※pod or podsなのか良く分かっていない…。podでも一覧が表示されるが、https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#get を見る限りkubectl get podsが正しいのかもしれない -
kubectl logs pod/hello-world
Podのログをダンプする（標準出力で）
これも公式を見る限り、pod/はなくてもkubectl logs hello-worldでログが見れるのでそれでいいのかもしれない
https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#logs -
kubectl delete pod/hello-worldkubectl deleteはファイル、標準出力、またはラベルセレクター、リソースセレクター、リソースを指定して、リソースを削除するコマンドで、今回はpodを削除している
これも公式を見る限り、pod/ではなくkubectl delete pod hello-worldで削除できたのでそれでいいのかもしれない
https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#delete
という感じ。コマンド実行時に出てきたpodなどのkubernetesの概念は以下の章で見ていく。
- 参考：status
- 参考：Operations（日本語はここ）
基本概念
kubernetesとは
一言で言うと「コンテナオーケストレーション（実際の物理リソースに対し、大量のコンテナをデプロイ・管理していく）」仕組み。これだけだと？になると思うのでもう少し概念について詳細を見ていく。
そもそも何でkubernetesというものが登場したのか？という背景としては、今までのシステム運用での課題が分かると分かりやすい気がしたのでその観点でまとめてみると、以下のようになるだろう。
| # | 今までは… | kuberbetesになると… |
|---|---|---|
| 1 |
 システムのリソースの利用率に無駄がある… |
 複数のコンテナを共存させ、リソースを最大限効率的に利用できるように！ |
| 2 |
突発的な大量アクセスでシステムが応答しなくなった… |
システムを構成するサーバーの台数を増やし、システム全体の処理能力を高める事ができるように！（水平スケール） |
| 3 |
突然、一部のシステムがダウンしてしまいサービスが利用不可になってしまった… |
システムの稼働状況を監視・必要であれば自動デプロイができるようになり、継続的なサービス運用が可能に！ |
| 4 |
リリースのたびにサービス停止が発生してしまう… |
複数の稼働中サーバーに対して一定数づつ新しいアプリケーションをデプロイ・リリースができるように！（ローリングデプロイ） |
※詳細についてはWhat is Kubernetes?（日本語はここ）を参照。
どのような仕組みで動いているか？
kuberbetesで複数のリソースサーバをどのように管理していくか？だが、以下の図のようにnodeという単位が登場し、実際のリソースサーバはworker nodeと呼ばれ、そのworker nodeを束ねて管理するものとしてmaster nodeというものがある、という構成になっている。
そして各リソースサーバであるworker nodeは、master nodeからの命令を受ける形で管理される（ユーザーがリソースサーバを管理する際には、master nodeに対して、kubectl（日本語はここ）を利用して各リソースサーバ（worker node）に対して命令を行う）。
※上記の事を見て分かるが、kubernetesの各Node＝実サーバ（サーバーの実態）である
kubernetesのリソース
上記のどのような仕組みで動いているか？でリソースサーバという言い方をしていたが、kubernetesにはいったいどんなリソースがあるのか（リソースサーバー上で動くリソースとは）？についてここでは見ていく（どのような仕組みで動いているか？でkubectlでリソースへの操作・命令できるといったが、以下のようなリソースを管理するためのコマンドがkubectl）。
一覧としては以下のようなものがある（ようである）。
| 分類 | リソースの種別 |
|---|---|
| ワークロード | ・Pod：最小単位。コンテナの集合。 ・ReplicaSet：Podのレプリカ（複製品）の集合 ・Deployment：Pod（ReplicaSet）の集合（ReplicaSetを管理するもの） ・StatefulSet：Podの集合。Podの識別子が順序付けされる。 |
| サービス | ・Service：Podの論理的なセットや、そのPodのセットにアクセスするためのポリシー（IPアドレスなど）を定義する。L4ロードバランサー。 ・Ingress：L7ロードバランサー。 |
| 設定 | ・ConfigMap：機密性のない設定情報を保存 ・Secret：機密性のある設定情報を保存 |
| ストレージ | ・PersistentVolume：永続データそのもの（実態） ・PersistentVolumeClaim：永続データを要求するもの |
- 参考：Kubernetesのリソースの一覧と省略形
- 参考：Kubernetes Components（日本語はここ）
ワークロード
Pod
kubernetesでDockerコンテナを管理するための最小単位で、Dockerコンテナの集合。Dockerコンテナを単独で管理するのではなく、グループとして管理することで、Dockerコンテナの使いにくさを解消することができる。
- 参考：Pods（日本語はここ）
- KubernetesのPod機能
ReplicaSet
複数のPodのレプリカ（複製品）をセットで作成する機能で、Podの集合と言える。例えば、kubernetes起動時のレプリカ数を3にすると、kubernetesは同じ機能のPodを3つ自動的に起動する。
※ReplicaSetの存在意義だが、それはmaster nodeがkubernetes上で指定した数のレプリカが動作することを保証する＝何らかのトラブル（node障害など）でPodが減少した場合には別のnodeで自動的にPodを起動してレプリカ数を維持する、という事をやってくれるので障害に強くなるという事（だと思っている）。
※自動的にPodのレプリカ数を維持してくれるので、ある意味Podのスケールを行うものと考える事もできる？かも。
- 参考：ReplicaSet（日本語はここ）
- 参考：Kubernetesのレプリカセットとデプロイメント
Deployment
Pod（ReplicaSet）をまとめたもの（集合体）（ReplicaSetを管理するもの）。kubernetesでは基本的にPodを単独で起動する事はなく、ReplicaSetなどの管理用のオブジェクトを介してPodを利用するようだが、DeploymentはそのReplicaSetの管理のためのもので、ReplicaSetの世代管理（ロールバック・ロールフォワード）をする役割を持つ。
※このDeploymentを作成すると、ある理想的な状態（目的の状態）を定義しておくだけでkubernetesのDeploymentコントローラが、現状の状態を目的の状態へ、指定された頻度で変更してくれる。実際にアプリケーションの本番リリースとかで使われる（と思っている）。
- 参考：Deployments（日本語はここ）
- 参考：Deploymentとは
StatefulSet
これもDeploymentと同様に、Podの集合。ただし、Podの順序と一意性を保証するのでスケールする際の名前が一定になる（各Podにおいて管理が大変な同一性を維持する）。
※StatefulSetもDeployment同様にPodの集合であるが、Deploymentとの違いとしては、
- DeploymentでReplicaSetを作成（レプリカ）した場合（Deploymentで管理されるPod）
→PodにはランダムのIDが付与される - StatefulSetで管理されるPod
→Podには順序付けされた一意の識別子が付与される
という感じ。
サービス
Service
Podの論理的なセットや、そのPodのセットにアクセスするためのポリシー（IPアドレスなど）を定義するもの。外部公開・名前解決（接続先のIPアドレスの解決）・L4ロードバランサー（送信元IP、送信元ポート、宛先IP、宛先ポート、プロトコルの５つ（5タプルハッシュ）の条件を利用して振り分け先を決めるもの、ロードバランサが送信先のipをapplicationサーバーに書き換える）を担うと思えばいい。
※このServiceが必要な理由としては、公式に書かれている通りで、そもそもPodはNodeに散らばっているため、それぞれのPodと通信するにはそのIPIPアドレスを知る必要がある。ただ、kubernetesの特性上、NodeのIPアドレスは一定にならないため、突然Podと通信できなくなる可能性がある（PodのIPアドレスを探し出したり、そのIPアドレスを記録し続けなければならなくなる）。
→そこで、複数のPod・NodeのIPアドレスをクライアントが意識せずに単一のエンドポイントで通信するできるようにするために、Pod,Nodeの存在を抽象化し、Podとの通信に単一のエンドポイントを提供する、という事をやる。このための仕組みがService。
- 参考：Service（日本語はここ）
- 参考：Kubernetesの Service についてまとめてみた
Ingress
ServiceへのHTTPとHTTPSのルートを公開するもの。外部公開・L7ロードバランサー（URLのドメイン名（ホストベース）やパス名（パスベース）により振り分け先を決めるもの、ロードバランサがapplicationサーバーと通信を行う＝applicationサーバーから見た送信元ipはロードバランサになる）を担うと思えばいい
- 参考：Ingress（日本語はここ）
- L4 L7ロードバランサーの違いを30秒で
設定
ConfigMap
機密性のない設定情報を保存するリソース。具体的には環境変数、コマンドライン引数、ボリューム内の設定ファイルとして使われる。
- 参考：ConfigMaps（日本語はここ）
Secret
機密情報を保存するためのリソース。具体的には、パスワード、OAuthトークン、SSHキーのようなものを保存する。base64でエンコードされた文字列を保存するのがルール。
ストレージ
PersistentVolume
永続データの実態（永続化ボリュームそれ自体についてのリソース）。実際の物理ストレージへの接続情報を持ち、ストレージを抽象化する役割がある。
- 参考：Persistent Volumes（日本語はここ）
- 参考：Kubernetes道場 12日目 - PersistentVolume / PersistentVolumeClaim / StorageClassについて
PersistentVolumeClaim
永続データの要求（取得する命令をする）もの（永続化ボリュームの利用請求をするリソース）。抽象化されたストレージを要求する役割がある
。
- 参考：Persistent Volumes（日本語はここ）
- 参考：Kubernetes道場 12日目 - PersistentVolume / PersistentVolumeClaim / StorageClassについて
kubernetesのネットワークのイメージ
上記のどのような仕組みで動いているか？で見たように、リソース（kubernetesのリソースで取り上げたもの）は各ワーカーノードに分散されて配置される（以下のようなイメージ）。
上記の図において、各ワーカーノード間はネット―ワークでつながっており、そのネットワークはクラスターネットワークと呼ぶ（クラスターネットワークに対して、マスターノードとワーカーノード間のネットワークは外部ネットワークという事になる）。以下の図に書いたように、クラスターネットワークへは外部からは直接アクセスできない。
あるコンテナ（Pod内で起動しているコンテナ）の動作確認をするには以下の3つのアプローチがある。
| # | アプローチ詳細 | |
|---|---|---|
| 1 | kubectlを使ってマスターノード経由でPodのコンテナに直接入る ※kubernetesでHello World!でやったhello-worldコンテナに対して kubectl logs pod/hello-worldとしたのがこれにあたる |
 |
| 2 | 踏み台に対してkubectlで直接入り、そのコンテナ経由でアクセスする |  |
| 3 | サービス経由でアクセスする |  |
※kubernetesでHello World!を実行した環境のネットワークとしては、以下のようにマスターノード/ワーカーノードの区別がないシングルノードのネットワークとなる（以下、公式からの引用）。
PC上のVM内でシングルノードのKubernetesクラスタを実行する
