Skip to content

DNET_Kubernetes

Jump to bottom
nishi_74322014 edited this page Sep 11, 2026 · 1 revision

Kubernetes

概要

  • ネットワークインフラなどの自動展開やスケーリングといったコンテナの運用を自動化するための、
    フリーソフトウェアによって構成されるコンテナ・オーケストレーション・プラットフォーム。

  • Open PaaSと比較されることが多いが、
    ジャンルとしては、PaaSではなく、CaaS（新設）らしい。

呼称

  • クバネティス / クバネテス / クーべネティス
  • ギリシャ語で航海長またはパイロットを意味する。
  • K8sと略記される。

経緯

  • 当初、Googleが開発していた。
    Google の Borg という 15 年にわたるプロジェクトに基づいている。

  • オープンソースソフトウェアとして公開したことで、
    MicrosoftやRed Hatといった多くのIT企業が開発に参加表明。

2014年

Google、Kubernetes発表（6月）

2015年

  • 2月
    OpenShift V3、DockerとKubernetesをコアとすると発表。

  • 7月

    • バージョン1.0に達する
    • CNCFが設立され開発主体がこの団体へ移動。

2016年

Swarm（Dockerの該当節を参照） 対 Kubernetesの状態

  • 10月
    Kubernetesが独自コンテナランタイム（cri-o）開発を表明

2017年

コンテナ・オーケストレーションのデファクトになった。

  • 初頭に、Kubernetesをサポートする
    Public Cloud は Google Cloud Platformのみだった。

  • 2月
    Microsoft AzureがKubernetesの公式サポートを表明、
    クラウド業界は次第にKubernetesにシフトするようになった。

    • オラクルやVMwareといった企業もCNCFに参加を表明
    • GoogleやMicrosoftとは競合関係にあるAWSも参加

  • 10月に、DockerがKubernetesサポートすることを発表。

2018年

  • 1月時点でLinux Foundationの傘下にある
    CNCFが管理するオープンソースプロジェクトになった。

標準化の動向（概要）

標準化の動向を参照。

アーキテクチャ

  • ネットワークで接続された複数のLinux上にクラスタを構築することで動作する。

  • クラスタは主に複数のマスター (master) とノード (node) から構成される。

    • マスターがクラスターの管理を行い、
    • 各ノード上にコンテナがデプロイされる。

  • マスターやノードを構成するコンポーネントは下記のようになっている。

  • マスターとノードのコンポーネントは同一のマシン上に存在してもよく、
    最小の構成では1台からなるKubernetesクラスタが構築出来る。

マスター

制御プレーンとも。

kube-apiserver

Kubernetes APIを外部に公開するためのコンポーネント。

etcd

Kubernetesクラスタの情報を保存する分散キーバリューストア。

kube-scheduler

ポッドをどのノードに対してデプロイするかを選択するコンポーネント。

kube-controller-manager

Kubernetesクラスタの各種コントローラを実行するコンポーネント。

cloud-controller-manager

  • Kubernetesとプラットフォームとなっている
    クラウドプロバイダとの相互作用を担うコンポーネント。
  • 各クラウドプロバイダに特化した機能を提供し、パフォーマンスを向上する。

その他アドオン

アドオンを参照。

ノード

実行ノードとも。

kubelet

  • ノード上に常駐し、ノードの生存をクラスタに対して通知する。

  • 自身に対するポッドの割り当てが行われたかどうかを監視して

    • ボリュームのマウント、
    • コンテナのダウンロード/デプロイ、
    • ポッドの生存確認

などを行い、クラスタに通知する機能も担う。

kube-proxy

外部やapiserverからのアクセスを、
ノード上の各ポッドに対して転送し、
ポッドへのアクセスを抽象化するコンポーネント。

コンテナ・ランタイム

Docker

Docker

containerd

containerd

CRI-O

cri-o

アドオン

DNS

  • 環境内の他のDNSサーバ

  • 以下のDNSレコードを提供するDNSサーバ

    • 環境内の他のDNSサーバ
    • Kubernetesサービスの

ダッシュボード

コンテナリソース監視

  • supervisord

  • kubeletとDockerが正しく動作
    し続けるように監視及び管理するコンポーネント。

クラスターレベルログ

  • fluentd
  • クラスタレベルでのロギングを補助する。

コントローラ

マスター上のkube-controller-manager上で実行される。

Deployments

下位要素は、ReplicaSet

  • CLIを使用したり、yaml や JSON で定義をコントローラに渡したりして展開できる。
  • ポッドだけでなくサービスの定義や、各種要素の詳細な設定を定義して一括で適用できる。

ReplicaSet

下位要素は、ポッド

  • 負荷分散や、SLAの維持のためレプリカ数のポッドが利用可能であることを保証する。
  • ポッドがどのノードで動くかは、kube-schedulerによって決定される。

DaemonSet

下位要素は、ポッド

  • ノードが単一のポッドのコピーを稼働させることを保証する。

  • 全ノードや特定のノード群に対してある機能を実行しておきたい場合に使う。

  • 具体的な利用シーンとしては、ログ収集のエージェントなどがある。

StatefulSet

下位要素は、ポッド

  • データベースなどステートフルなポッドが必要な場合はStatefulSetを使って展開。

  • Deploymentでは、全てのポッドで1個のPVをマウントするが、
    StatefulSetで作成されたポッドは、それぞれ単一のPVをマウントする。

  • StatefulSetを使うとストレージやネットワーク名などが保持される。

  • データベースなど、データの永続化の用途で利用される。

ポッド

概要（ポッド）

  • いくつかのコンテナをグループ化したもの。
  • ポッド単位で作成、開始、停止、削除といった操作を行う。
  • １つのコンテナを作成したいときも「コンテナが１つ含まれるポッド」を作成する。

特徴

以下の特徴がある。

  • ポッド内のコンテナは、同一ホスト上に配備される。

  • ポッド内のコンテナは、仮想NICやプロセステーブルを共有する。
    → つまり、同じIPを使えたり、互いのプロセスが見えたりする。

    • 各ポッドには固有のIPアドレスがあり、ポートスペース全体を所有している。
    • ポッド内のコンテナはストレージを共有できる。

  • ポッドには、ポッドをグループするための1つ以上のラベルを指定できる。

  • 一般的には、サーバと、そのサーバと共に実行する補助サービスを含める。

    • Webサーバ
    • APサーバ
    • DBサーバ
    • KVSサーバ

ボリューム

  • 抽象化されたポッドと疎結合なリソースで、ポッドに紐づく。
  • ポッド内のコンテナがデータを読み書きできるディスク領域。
  • 様々な種類が提供されている。

種類や用途

ボリュームには様々な種類や用途がある。

  • 一時領域

    • CONFIG

  • データ共有

    • 永続領域

    • 高可用性

      • DBの高可用性オプションによるもの
      • ReplicaSetによるもの

ボリューム・タイプ

  • emptyDir

    • ポッド用の一時的なディスク領域
    • ポッドが terminate されると削除される。

  • hostPath
    ノード(ホスト）の任意の領域をマウントできる。

  • PersistentVolume(PV)
    永続化領域として確保されるボリューム。

サービス

ネットワーク機能を提供するコンポーネント

用途

  • ポッドに対して通信をルーティングする。
  • ポッドに対する通信を維持する（SLA、負荷分散）

サービス・タイプ

以下の種類がある。

  • Node Port
  • Cluster IP
  • Load Balancer
  • , etc.

※ 詳しくはService。

リソースで分類

以下に分類される。リソースを定義するYAMLの記述方法の詳細はAPIドキュメントを参照ください。

Workloads

Kubernetesを構成する基本的なリソース

Deployment

Deployments

ReplicaSet（リソース）

ReplicaSet

Pod

ポッド

DaemonSet（リソース）

DaemonSet

StatefulSet（リソース）

StatefulSet

Job/CronJob

  • Job
    バッチ処理が終わったらPodが(正常)終了。
  • CronJob
    Jobをスケジュール実行する。

Discovery & LB

基本的なリソースに対して、外部から参照する口を提供するもの

Service

  • L4のロードバランシングを実現する。

  • Serviceは、既定で利用可能。

  • 種別
    以下のような種別がある。

    • Node Port

      • <Node IP>:<Node Port> にアクセスを提供する。
      • <Node IP> は、マスタのIPで、サービスの全Nodeを公開

    • Cluster IP
      サービスの特定のNodeを公開（内部通信用）

    • External IP
      サービスの特定のNodeを公開（外部通信用）

    • Headless
      DNS ラウンドロビンによる転送先PodのIPアドレス取得

    • Endpoint(selector 指定無し)

負荷分散

  • Load balancer

    • L4ロード・バランシングを実現する。
    • Cluster IPに負荷分散機能を加えている。

  • Ingress

    • L7ロード・バランシングを実現する。
    • IngressリソースにはIngressコントローラーが必要。

Outbound

  • External Name

    • 外部のドメイン宛のCNAMEを返す機能を提供する。
    • 例えば、Podから外部のexample.comへアクセスする場合。

  • None-Selector
    外部のサービスに対してロード・バランシング

Config & Storage

Config Map

Key-Valueで構成され、アプリケーションの設定値を管理するリソース。

Secret

パスワードなどの機密情報を管理するリソース。

Volume

Podのデータを永続化するための仕組み。

  • PersistentVolumeClaim (PVC)
    PodにVolumeやPersistentVolume (PV)を間接的に指定。

    • PV の要求を行うリソース。

    • PVC は要求された内容(容量、ラベル)から
      適切な PV を探し、ボリュームを割り当てる。

    • プロビジョニングの方法として以下の2つの方法がある。

      • Static : 予め PV を作成
      • Dynamic : PVC が作成した際に動的に PV を作成

Cluster

  • Node

  • Namespace
    分離 / 独立した環境を準備する。

  • PersistentVolume (PV)

  • RBAC (Role Based Access Control)

    • Role
    • ClusterRole
    • RoleBinding
    • ClusterRoleBinding

Metadata

  • Resource Quota

    • resource.request
      NamespaceおよびPodに割り当てるリソース量を定義

    • resource.limit
      NamespaceおよびPodに割り当てるリソースの上限を定義

    • LimitRange
      最小 / 最大・デフォルト値を定義

      • リソースタイプ
        Pod / Container / PersistentVolumeClaim
      • マシンリソース
        CPU / メモリ
      • 設定値
        最大値 / 最小値 / デフォルト / resource.limitとresource.requestの比率

  • QoS Classes
    マシンリソースを超えたリソースの割当を行う場合、
    どのPodに優先 / 削除する必要があるかを決定する。

    • Guaranteed
      CPU/メモリ共にresource.limit/requestが設定＆limit=request
    • Burstable
      CPU/メモリのいずれかがresource.limit/requestが設定
    • BestEffort
      上記条件に当てはまらない

  • HorizontalPodAutoscaler(HPA)

    • Pod数を増減
    • 動的な水平スケーリングを実現
    • Webサーバなど永続化データを持たないサーバが対象

  • VerticalPodAutoscaler(VPA)

    • Podに割り当てるCPU / メモリ量を増減
    • 動的な垂直スケーリングを実現
    • DBサーバなど永続化データを持つサーバが対象

エコシステム

kubectl

kubectl

kubectlコマンド

kubectlの該当節を参照。

kube configファイル

kubectlの該当節を参照。

サブシステム

Compose on Kubernetes

Compose on Kubernetes

Komposeと同じだが、開発元が別の会社。

Kompose

Kompose

Docker Compose ファイルを Kubernetes オブジェクトに変換できる。

Helm Charts

Helm Charts

Kubernetes の charts を利用するための簡単なツール

Rancher Charts

Rancher Charts

Helmのウワモノ。

ツール類

構築ツール類

Kubernetesの構築

運用ツール類

Kubernetesの運用

監視ツール類

Kubernetesの監視

トレンド

コンテナの標準仕様

コンテナの標準仕様

CRI（Container Runtime Interface）

コンテナの標準仕様の該当節を参照。

→ コンテナ・ランタイム

OCI（Open Container Initiative）

コンテナの標準仕様の該当節を参照。

CSI（Container Storage Interface）

コンテナの標準仕様の該当節を参照。

CNI（Container Network Interface）

コンテナの標準仕様の該当節を参照。

標準化の動向

2015年（標準化）

OCI（Open Container Initiative）

  • コンテナ・ランタイムとコンテナ・イメージの標準
  • 6月にDocker社などの複数の企業によりイニシアチブ（組織）が設立された。

2016年（標準化）

CRI（Container Runtime Interface）

  • Docker以外のコンテナ・ランタイムを組み込み易くするI/F標準。
  • 12月にkubeletとコンテナランタイムの通信規格として規定された

2017年（標準化）

  • OCI（Open Container Initiative）
    7月に「OCI v1.0」が策定、以下がリリースされている。

    • コンテナランタイムの標準仕様である「Runtime Specification」
    • コンテナイメージの標準仕様である「Image Format Specification」

  • CRI（Container Runtime Interface）

    • 「cri-o」も1.0に到達
    • kubeletとコンテナランタイム間のAPIのI/Fも「CRI」準拠のものとなった。

2018年（標準化）

  • OCI（Open Container Initiative）
    4月にはコンテナイメージ配布の標準仕様を策定する、
    「Distribution Specification」プロジェクトへの着手が発表。

  • CSI（Container Storage Interface）
    11月にコンテナ・オーケストレーション・ツールと
    ストレージ間のI/Fの標準仕様として、v1.0に到達した。

Dockerとの関係

昨今、開発寄りなのかも知れない。

  • アプリケーションの開発フェーズにおいてDockerが使われる。
  • 今後は、コンテナ・ランタイムの多様化が起きると言われている。

containerd

デファクト・スタンダードのコンテナ・ランタイム

  • 2016年

    • 6-8月
      Swarm（Dockerの該当節を参照） と
      Kubernetesのコンテナ・オーケストレーション・ツールの主導権争い。

    • 10月
      Kubernetesが独自コンテナランタイム（cri-o）開発を表明

    • 12月
      中立的なコンテナ・ランタイムのため、Dockerからcontainerdが分離された。

cri-o

Dockerに依存しない軽量コンテナ・ランタイム

  • 2017年

    • 1.0が2017/10/17にリリースされた。
    • ランタイムのみなので、Dockerコマンドのような機能は備えていない。

参考

Qiita

Publickey

CRI

OCI

IT Search+

【連載】Kubernetes入門

Kubernetes

Concepts

https://kubernetes.io/docs/concepts/

  • Overview
  • Cluster Architecture
  • Workloads
  • Services, Load Balancing, and Networking
  • Storage
  • Configuration
  • Security
  • Policies
  • Scheduling
  • Cluster Administration
  • Extending Kubernetes

Kubectl

github.com

マイクロソフト系技術情報 Wiki

Docker Desktop for Windows

Docker Desktop for Windows

Azure Kubernetes Service (AKS)

Azure Kubernetes Service (AKS)

移行メモ

  • 「リソースで分類」の冒頭「に分類されます。」は主語が欠けていたため 「以下に分類される。」と補った。
  • 「マシンリソースを超えたリソースを割当を行う場合」は 「マシンリソースを超えたリソースの割当を行う場合」に、 「[Kompose]と同じだが、開発元が社」は「開発元が別の会社。」に正した。
  • マイクロソフト系技術情報 Wiki（techinfoofmicrosofttech.osscons.jp）への リンクは、移行済みの MS_DockerDesktopForWindows / MS_AKS に張り替えた。

Tags: 移行, Kubernetes, K8s, コンテナ, オーケストレーション, Docker, CRI, OCI

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally