kubernatesでのコンテナの起動単位。固有の仮想IPアドレスが割り当てられ、Pod内のコンテナはIPアドレスやポート、ネットワーク名前空間をそれぞれ共有する。ボリュームも共有できることです(後述)。より正確には、Podに共有化されたストレージボリュームを指定することで、Pod内の全てのコンテナがそのストレージにアクセスできるようになる。

IPアドレスやボリュームなどを同一Pod内のコンテナで共有しコンテナ間で密に連携するようなアプリケーションの場合は、1つのPodに複数のコンテナを収めたほうが良い。一部のPodが別のノードに配置された場合にコンテナが連携できなくなるなどの影響を抑止できる

どのような時でも事前に指定した数のPodを維持する。Pod数を監視することで、障害が発生しても事前に定義した必要数を満たしてくれる。また、事前に定義するPod数を後から増減することもできる。

ReplicaSetを管理して、ローリングアップデートやロールバックを実現する。DeploymentとReplicaSetの関係性を整理すると、ReplicaSetはPod数を管理し、DeploymentはそのReplicaSetを管理する。

少しずつ(全体ではなく1台ずつのイメージ)新しい物に入れ替えるアップデート方法。

Kubernetesのクラスタ内外からのPod宛の通信を仮想IPアドレスで振り分けてくれるリソース。この仮想IPアドレスには、Kubernetesクラスタ内の通信を振り分けできる”ClusterIP”、クラスタ外のロードバランサーに仮想IPアドレスを紐付けできる”LoadBalancer”、特定のKubernetesノードのIPアドレスとポートからの通信を振り分ける”ExternalIP”など、複数の種類がある。サービスディスカバリ”機能がある。

例えばServiceとLabelで紐付いたPodが別のノードに再配置されても、通信の振り分け先のPodを検索・判別してくれる機能。判別方法にも複数ありますが、代表的なのがDNSを利用した名前解決方法。また、Serviceの仮想IPアドレスとポートとIngress(前回で紹介)が払い出すURLとを紐付けることで、レイヤーの違うロードバランシングをそれぞれ実現できる。

何かしらの障害でPodが停止するとReplicaSetなどによりSelf-Healingされて稼動を継続できるようになっていますが、復活した後のPodに割り振られたIPアドレスが変わってしまい、稼動を停止したPodのIPアドレスにたどり着けず通信が途絶えてしまう問題があります。この問題を解決してくれるのがService。

Podが停止・再配置されてもアプリケーションの状態を維持するための、Podからマウントする永続なストレージボリューム。 PVはPodのデータを保存する永続ストレージの本体で、PVCは必要なストレージ容量を動的に確保する抽象化したストレージ。

Podやコンテナの設定値と設定ファイルを保存するためのリソース。Podの実行時に必要な環境変数、ポート番号などの構成要素をConfigMapによりPodから分離して保存することでワークロードの移植性が向上し、構成の管理や変更が楽になる

組織内での意味を考慮して、ロールに割り当てる操作そのものにオブジェクト(物)へのアクセス権を設定する。 Kubernetesでは、このRBACを用いてリソースへのアクセス制御を行う。RBACに関連するリソースにはRole、ClusterRole、RoleBinding、ClusterRoleBindingがあり、それぞれ与える影響範囲と機能が異なる。 RoleとClusterRoleは、どのKubernetesのリソースにどのような操作を許可するかを定義し、RoleBindingとClusterRoleBindingは、どのRoleやClusterRoleをどのアカウントに紐付けるかを定義する。

Kubernetes向けのパッケージマネージャ。 「Chart」と呼ばれるパッケージテンプレートを用いてソフトウェア構成を定義していく。また、Chartは公式のレジストリで公開されているものであれば、誰でもそれらを利用してKubernetes上にアプリケーションをデプロイできる。なお、自身で作成したChartを公開せずにプライベートレジストリを構築して管理するといった使い方もできる。HelmによってChart化されているアプリケーションであれば、複雑な記述が必要なManifestファイルを用意しなくても、コマンド1つで容易にKubernetes上にアプリケーションをデプロイできるようになる。

OS上にソフトウェアをインストール／アンインストールする際にソフトウェア間やライブラリとの依存関係を包括管理してくれる。ディストリビューションによって違いはあるが、Linuxでは「yum」や「apt」が有名。

CoreDNSはクラウドネイティブなDNSで、KubernetesクラスタにおけるDNSサービス(名前解決およびサービスディスカバリ)を担う。非常に軽量なこと、プラグイン方式を採用することでetcdやhostsなどの様々なバックエンドに設定を格納・管理できる拡張性をもつ。またKubernetesクラスタ内にCoreDNS用のPodを複数展開することで、CoreDNSへのDNSリクエストを分散させて処理能力を向上できるほか、クラスタのSelf-Healing機能を利用して高可用性を確保することもできる

Prometeusは監視サーバが自ら監視対象サーバの情報を取得しに行くPull型監視方式を採用する。監視対象のサーバやコンテナに導入するexporterと、監視サーバに入れるPrometheusサーバがある。

監視したい対象ごとに分かれて動作する。例えば、監視対象サーバのCPUのリソース情報を取得したい場合には、CPU用のexporterを入れることで監視できる。また、ApacheやTomcatなどのミドルウェアの情報も取得できるなど、監視対象の種類は多岐に渡る。コンテナの場合もexporterを各コンテナに入れることで監視できる

監視対象から取得した情報の取りまとる。Prometheusサーバには、リソース情報をexporterから取得する役割を持つ「Retrieval」、取得したリソース情報を格納する「Storage」、リソース情報を可視化する「PromQL」の3つのコンポーネントがある。ただし、PromQLは単純なグラフしか出力されず非常に見づらくなっているため、「Grafana」や「Kibana」などサードパーティの可視化ツールを使用してPromQLの欠点を補う

1つ目はサーバのようにコンテナに組み込んで起動させる方法。しかし、この方法ではコンテナが再起動されるとインストールした情報が消えてしまう。 そこで使われるのが、2つ目のPrometheus専用のpodをそのままデプロイし、クラスタ上で稼動させるという方法。この方法であれば、1つ目の方法の欠点を補うことができる。