Kubernetes入門：初心者が知るべき基礎知識

はじめに

こんにちは！インフラエンジニアのnaya(@NayaTaiyo)です。最近、Kubernetesについて学習しています。Kubernetesはドキュメントや記事などで説明される際にKubernetes独自の用語が多く、Kubernetesをこれから学習しようと思っている方や初学者の方がこれらを見た際に理解を早める手助けとなるのを目的として記事を書いてみました。また、本記事ではイメージ図を記載することで、鮮明にイメージがしやすいように作成してみました。

Kubernetesとは

Kubernetesはコンテナの運用管理と自動化を行うために設計されたオープンソースソフトウェアです。また、コンテナ化されているアプリケーションのデプロイやスケーリングなどの自動化のことをコンテナオーケストレーションとも言います。Kubernetesはコンテナオーケストレーションツールの中でもシェア率が高くデファクトスタンダード（業界標準）となっています。

• Kubernetes市場の規模とシェア分析 – 成長動向と予測

https://www.mordorintelligence.com/ja/industry-reports/kubernetes-market

• CI/CDについての記事

https://circleci.com/ja/blog/ci-tool/

DockerとKubernetesで何が違うか？

Kubernetesを学習する際に私が疑問に思っていたことになります。DockerとKubernetesって何が違うんだろう？という点です。Kubernetesを学習する前はどちらも「コンテナを管理」するという大雑把な認識で把握していたのですが、これら二つについて大きく以下の違いがあります。

• Docker
  • 単一ノードで動作
  • コンテナでアプリケーションを実行できるようにするもの
  • コンテナを1単位として扱う
• Kubernetes
  • クラスタで動作
  • コンテナの運用自動化を提供（後述するオートスケーリングや監視)
  • Podを1単位として扱う

Kubernetesはクラスタと呼ばれるノードの総称単位で動作しています。クラスタ内にはコンテナ環境を格納しているPodと呼ばれる機能が存在しており、Podを用いてコンテナの運用を管理しています。他にも多数の違いはあるのですが、ここでは上記の3つに絞ってご紹介させていただきました。

Kubernetesの頻出用語

私がKubernetesの記事を見るときによく見かけるなと思う用語をまとめてみました。

• ノード(node)

ノード(node)は仮想マシン、物理マシンの単位。ホストマシンと表現している記事もあります。

• コントロールプレーン（マスターノード）

ワーカーノードの管理を行うノード(node)

• ワーカーノード(node)

Podをホストしているノード(node)

• Kubernetesクラスタ

コントロールプレーン（マスターノード）とワーカーノードの総称

• Namespace（名前空間）

仮想的にKubernetesクラスタを分離する機能。以下の画像のようにKubernetesクラスタをNamespace_01とNamespace_02として分離することが可能。

• Pod

PodはKubernetesリソースの単位です。Podにはコンテナが1つ以上格納されており、2つ以上格納されているコンテナはお互いにlocalhostでの通信が可能となっております。また、異なるPodやNamespaceでの通信も可能です。しかし、クラスタが別のものに関しては通信が不可能なのでご注意ください。以下の例だと同じPod内に格納しているコンテナ02とコンテナ03はlocalhostで通信可能です。

・コンテナ01

・コンテナ02

・コンテナ03

ひとまず、Pod内のコンテナは同じIPアドレスを持つ。異なるPodはIPは異なるが同じネットワークなので通信可能と覚えておきましょう。

• Minikube

単一のマシンでKubernetes環境を構築することができる。ただし、あくまでも構成できるのはシングルノードとしてなのでマルチノードが必要なKubernetesの機能を使用することができない。単一のマシンでKuberneesの環境を構築したい場合は後述するkind(Kubernetes in docker)を使用することを推奨。

• kind(Kubernetes in docker)

ノードをコンテナ内で動作させることができます。以下ホストマシン内で実行しているコンテナで各コンポーネントが動いているイメージです。

上の図のようにコンテナ内で各ノードを構成することで1つのホストマシン内でコントロールプレーン（マスターノード）とワーカーノード(node)を作成することができます。

• pv（PersistentVolume）

Pod内で使用するボリュームになります。Podが削除された後も、ボリューム内のデータは保持されます。永続ボリュームと記述されていることもあります。

• pvc（PersistentVolumevClime）

Podが要求している要件のボリュームをsc（storageclass）に申し込みます。

• sc（storageclass）

ボリュームを作成する際の設定やボリュームを作成するリソースを設定します。また、ボリュームの払い出しを行ってくれます。Pod内ではpvcを使用することでpvが利用可能になります。pvを使用する際に、scがpvcとpvの紐づけを行ってくれます。

• Deployment

ReplicaSetの作成、ローリングアップデート、ロールバックの役割を担う。

• ReplicaSet

Podのレプリカを作成して、指定した数のレプリカを維持するリソース。複数のPodが存在する場合はラベルでの紐づけを行うことでどのPodで何台複製するかを指定できます。レプリカと言いつつ「１」を指定することも可能です。

• オートヒーリング/セルフヒーリング

前述したReplicaSetを設定することでPodを削除した際に、必要なPod数を補充して新たなPodを作成することを指します。記事によってオートヒーリングとセルフヒーリングで記述が異なる可能性があります。

• オートスケーリング

自動的にリソースの増減を行う。リソースの増加をスケールアウト、リソースを減らすことをスケールイン。

• Cluster Autoscaler　

Kubernetesクラスタ単位のオートスケーリング機能のこと。

• Statefullset

replicasetと基本動作は一緒でPod削除後もデータが保持される

• Daemonset

ReplicaSetはPodがn個ずつ生成されるのに対してdaemonsetは１setごとに各Podをひとつずつ生成する。また、新規のノードにPodが追加された際に自動的に立ち上がるため、各ホストのログの出力をしたい際などに便利。

• ローリングアップデート

Podの設定更新機能。以下のような処理順になります。

1. Deploymentで新たにReplicaSetを作成
2. 設定更新に伴い、設定更新されたPodを新しいReplicaSetに配置
3. 古いReplicaSetから新しいReplicaSetに配置済みのPodを削除

※➀～➂を繰り返す

• Recreate

ローリングアップデートと同じくPodの設定更新機能。ローリングアップデートと異なるのは、全てのPodを削除してから新しいPodに配置します。

以下、処理順になります。

1. deploymentで新たにReplicaSetを作成。
2. 設定更新に伴い、古いReplicaSetから全Podを削除。
3. 設定更新されたPodを新しいReplicaSetに配置。

• configmap

単純なKey-Value値や設定ファイルを利用する際に使用。Pod上に設定ファイルの読み込みや環境変数を呼び出す際に使用します。

• sercret

configmapと同様に単純なKey-Value値を設定することができます。base64でエンコードし機密情報を利用する際に使用。
configmapとの使い分けは機密情報を管理するのか、それとも設定ファイルの内容を管理したいのかで使い分けるとよいと思います。

• ingress

L7レベル（アプリケーション層）のロードバランシングのリソースを提供する機能

• ingress controller

Kubernetesに登録されているingressリソースを操作可能にする。

• service

ingressと同様にL4レベル（トランスポート層）ロードバランシングのリソースを提供する機能。ingressとは異なり、kuberetやkubedns、kube proxyを使用してトラフィック経路を選定する。

以下、処理順になります。

1. ユーザーのリクエストをingressで受け取る
2. ingressからserviceへ転送
3. serviceから各Podへ転送

主なコンポーネント

• etcd

Kubernetesクラスタに登録されるすべてのデータが保存される。 kubenetesクラスタの変数もetcdに保存されるので、使用する場合は変数をetcdから呼び出して使用することが可能。

• kube-apiserver

Kubernetesの中核となるコンポーネントであり、他のすべてのコンポーネント（例: kube-controller-manager, kube-scheduler, kubelet）が動作するために必要.

• kube-controller-manager

Kubernetesのdeploymentやrepllicaset controller で 必要なpod数やrepllica数を監視して作成する。

• kube proxy

kube proxy は各ノード上で動作を行いクラスター内外でPodに対してトラフィックをどのように転送するかを決めることができる。

• kubelet

kubelet はノード上でDocker等（コンテナランタイム）を使用してPodを実行・管理するKubernetesのエージェント。

• CNI

CNIはコンテナネットワークのAPIインターフェースです。 Pod（コンテナ)間のネットワークを接続するインターフェースのことです。

以下のような種類があります。

• Calico: 高度なネットワークポリシー管理とセキュリティを提供。
• Flannel: シンプルで軽量なオーバーレイネットワーク。
• Weave Net: 分散型ネットワークを提供し、簡単にセットアップ可能。
• Cilium: eBPFを利用した高パフォーマンスのネットワークとセキュリティ。

Minikubeやkind(Kubernetes in docker)を用いたローカル環境では使用しないです。

• kubedns

kube-dnsは クラスター上でDNS PodとServiceをスケジュールし、DNSの名前解決をするために各コンテナに対してDNS ServiceのIPを使うようにKubeletを設定します。 このkubednsがあることで各Podに対して、resolve.confに自動でネームサーバーの指定とsearch {namespace名} .svc.cluster.localの設定を行います。

Kubernetes構成図

※上図中のDNSはkubednsを指します。

まとめ

あくまでも、これだけ理解しておけばドキュメントやブログ記事などを読んでもそれなりに理解できるようになりそうというものを個人的に抜粋して記事にしてみました。また、筆者もKubernetesを学んで間もないため図に書ききれていないところや誤りが多々あると思うのですが、誤り等あれば教えていただけるとありがたいです。Kubernetesをこれから学習しようと思っている方や初学者の方が少しでも理解を早めるお役に立てたらうれしいです。以上、ありがとうございました！！

参考リンク

・https://www.mordorintelligence.com/ja/industry-reports/kubernetes-market
・https://circleci.com/ja/blog/ci-tool/
・https://kubernetes.io/ja/docs/home/

参考にした技術書

・Kubernetes完全ガイド 第2版
・Kubernetesの知識地図 —— 現場での基礎から本番運用まで