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

目次

概要

  • ネットワークインフラなどの自動展開やスケーリングといったコンテナの運用を自動化するための、
    フリーソフトウェアによって構成されるコンテナ・オーケストレーション・プラットフォーム。
  • Open PaaSと比較されることが多いが、ジャンルとしては、PaaSではなく、CaaS(新設)らしい。

呼称

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

経緯

  • 当初、Googleが開発していた。
    Google の Borg という 15 年にわたるプロジェクトに基づいている。
  • オープンソースソフトウェアとして公開したことで、
    MicrosoftやRed Hatといった多くのIT企業が開発に参加表明。

2014年

Google、Kubernetes発表(6月)

2015年

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

2016年

Swarm 対 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

containerd

CRI-O

アドオン

DNS

  • 環境内の他のDNSサーバ
  • 以下のDNSレコードを提供するDNSサーバ
    • 環境内の他のDNSサーバ
    • Kubernetesサービスの

ダッシュボード

コンテナリソース監視

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

クラスターレベルログ

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

コントローラ

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

Deployments

下位要素は、ReplicaSet

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

ReplicaSet?

下位要素は、ポッド

DaemonSet?

下位要素は、ポッド

  • ノードや特定のノード群に対してある機能を実行しておきたい場合に使う。
  • 具体的な利用シーンとしては、ログ収集のエージェントなどがある。

StatefulSet?

下位要素は、ポッド

  • データベースなどステートフルなポッドが必要な場合はStatefulSetを使って展開。
  • StatefulSetを使うとストレージやネットワーク名などが保持される。
  • データベースなど、データの永続化の用途で利用される。

ポッド

概要

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

特徴

以下の特徴がある。

  • ポッド内のコンテナは、同一ホスト上に配備される。
  • ポッド内のコンテナは、仮想NICやプロセステーブルを共有する。
    → つまり、同じIPを使えたり、互いのプロセスが見えたりする。
    • 各ポッドには固有のIPアドレスがあり、ポートスペース全体を所有している。
    • ポッド内のコンテナはストレージを共有できる。
  • ポッドには、ポッドをグループするための1つ以上のラベルを指定できる。
  • 一般的には、サーバと、そのサーバと共に実行する補助サービスを含める。
    • Webサーバ
    • APサーバ
    • DBサーバ
    • KVSサーバ

ボリューム

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

種類や用途

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

  • 一時領域
    • CONFIG
  • データ共有
    • 永続領域
    • 高可用性
      • DBの高可用性オプションによるもの
      • ReplicaSetによるもの

ボリューム・タイプ

  • emptyDir
    • ポッド用の一時的なディスク領域
    • ポッドが terminate されると削除される。
  • hostPath
    ノード(ホスト)の任意の領域をマウントできる。

サービス

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

用途

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

サービス・タイプ

以下の種類がある。

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

※ 詳しくはコチラ

リソースで分類

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

Workloads

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

Deployment

ReplicaSet

Pod

DaemonSet

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のデータを永続化するための仕組み。

  • PV の要求を行うリソース。
  • PVC は要求された内容(容量、ラベル)から
    適切な PV を探し、ボリュームを割り当てる。
  • プロビジョニングの方法として以下の2つの方法がある。
    • Static : 予め PV を作成
    • Dynamic : PVC が作成した際に動的に PV を作成

Cluster

  • 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コマンド

kube configファイル

サブシステム

Compose on Kubernetes

Komposeと同じだが、開発元が社

Kompose

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

Helm Charts

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

Rancher Charts

Helmのウワモノ。

ツール類

構築ツール類

運用ツール類

監視ツール類

トレンド

コンテナの標準仕様

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」

2018年

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

Dockerとの関係

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

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

containerd

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

  • 2016年
  • 6-8月
    Swarm と 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のリソースタイプを体系的に学ぶ
  • DevOps?

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

Azure Kubernetes Service (AKS)


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2021-03-03 (水) 13:56:16 (48d)