「.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からのアクセスを、
ノード上の各ポッドに対して転送し、
ポッドへのアクセスを抽象化するコンポーネント。
コンテナ・ランタイム †
- 実際にコンテナを動作させるバックエンドに利用される。
- 全て Kubernetes CRI (Container Runtime Interface) 実装
昨今、開発寄りなのかも知れない。
デファクト・スタンダードのコンテナ・ランタイム
アドオン †
DNS †
- 以下のDNSレコードを提供するDNSサーバ
- 環境内の他のDNSサーバ
- Kubernetesサービスの
ダッシュボード †
コンテナリソース監視 †
- kubeletとDockerが正しく動作
し続けるように監視及び管理するコンポーネント。
クラスターレベルログ †
- fluentd
- クラスタレベルでのロギングを補助する。
コントローラ †
マスター上のkube-controller-manager上で実行される。
Deployments †
下位要素は、ReplicaSet
- CLIを使用したり、yaml や JSON で定義をコントローラに渡したりして展開できる。
- ポッドだけでなくサービスの定義や、各種要素の詳細な設定を定義して一括で適用できる。
ReplicaSet? †
下位要素は、ポッド
- 負荷分散や、SLAの維持のためレプリカ数のポッドが利用可能であることを保証する。
- ポッドがどのノードで動くかはスケジューラーによって決定される。
DaemonSet? †
- ノードが単一のポッドのコピーを稼働させることを保証する。
- 全ノードや特定のノード群に対してある機能を実行しておきたい場合に使う。
StatefulSet? †
- データベースなどステートフルなポッドが必要な場合はステートフルセットを使って展開。
- ステートフルセットを使うとストレージやネットワーク名などが保持される。
ポッド †
概要 †
- いくつかのコンテナをグループ化したもの。
- ポッド単位で作成、開始、停止、削除といった操作を行う。
- １つのコンテナを作成したいときも「コンテナが１つ含まれるポッド」を作成する。
特徴 †
以下の特徴がある。
- ポッド内のコンテナは、同一ホスト上に配備される。
- ポッド内のコンテナは、仮想NICやプロセステーブルを共有する。
→ つまり、同じIPを使えたり、互いのプロセスが見えたりする。
- 各ポッドには固有のIPアドレスがあり、ポートスペース全体を所有している。
- ポッド内のコンテナはストレージを共有できる。
- ポッドには、ポッドをグループするための1つ以上のラベルを指定できる。
- 一般的には、サーバと、そのサーバと共に実行する補助サービスを含める。
- Webサーバ
- APサーバ
- DBサーバ
- KVSサーバ
ボリューム †
- 抽象化されたポッドと疎結合なリソースで、ポッドに紐づく。
- ポッド内のコンテナがデータを読み書きできるディスク領域。
- 様々な種類が提供されている。
種類や用途 †
ボリュームには様々な種類や用途がある。
ボリューム・タイプ †
- emptyDir
- ポッド用の一時的なディスク領域
- ポッドが terminate されると削除される。
- hostPath
ノード(ホスト）の任意の領域をマウントできる。
- PersistentVolume?(PV)
- 永続化領域として確保されるボリューム。
- PVは個別にリソースを作成して利用する必要がある。
- 後述する PersistentVolumeClaim?(PVC)経由で利用する。
- PersistentVolumeClaim?(PVC)
- PV の要求を行うリソース。
- PVC は要求された内容(容量、ラベル)から
適切な PV を探し、ボリュームを割り当てる。
- プロビジョニングの方法として以下の２つの方法がある。
- Static : 予め PV を作成
- Dynamic : PVC が作成した際に動的に PV を作成
サービス †
ネットワーク機能を提供するコンポーネント
用途 †
- ポッドに対して通信をルーティングする。
- ポッドに対する通信を維持する（SLA、負荷分散）
サービス・タイプ †
以下の種類がある。
- ExternalName?
特定の DNS エントリを作成
- NodePort?
「ノードのIP:特定のポート」を特定のサービス（ClusterIP:特定のポート）に転送
エコシステム †
サブシステム †
Kubernetes の charts を利用するための簡単なツール
Helmのウワモノ。
Docker Compose ファイルを Kubernetes オブジェクトに変換できる。
Komposeと同じだが、開発元が社
トレンド †
CRI（Container Runtime Interface） †
→ コンテナ・ランタイム
OCI（Open Container Initiative） †
CSI（Container Storage Interface） †
CNI（Container Network Interface） †
- Flannel
- Calico
- Canal
- NSX-T Container Plugin (NCP)
標準化の動向 †
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が使われる。
- 今後は、コンテナ・ランタイムの多様化が起きると言われている。
containerd †
- 6-8月
Swarm と Kubernetesのコンテナ・オーケストレーション・ツールの主導権争い。
- 10月
Kubernetesが独自コンテナランタイム（cri-o）開発を表明
- 12月
中立的なコンテナ・ランタイムのため、Dockerからcontainerdが分離された。
cri-o †
Dockerに依存しない軽量コンテナ・ランタイム
- 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 †
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
