「.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とプラットフォームとなっている
クラウドプロバイダとの相互作用を担うコンポーネント。
- 各クラウドプロバイダに特化した機能を提供し、パフォーマンスを向上する。
その他アドオン †
- Kubernetesクラスタ内での名前解決を行うDNSサーバ
- 各種Web UIやクラスタ単位でロギングを行うコンポーネント(fluentd, etc.)
- , etc.
ノード †
実行ノードとも。
kubelet †
- ノード上に常駐し、ノードの生存をクラスタに対して通知する。
- 自身に対するポッドの割り当てが行われたかどうかを監視して
- ボリュームのマウント、
- コンテナのダウンロード/デプロイ、
- ポッドの生存確認
などを行い、クラスタに通知する機能も担う。
kube-proxy †
外部やapiserverからのアクセスを、
ノード上の各ポッドに対して転送し、
ポッドへのアクセスを抽象化するコンポーネント。
supervisord †
kubeletとdockerが正しく動作し続けるように監視及び管理するコンポーネント。
fluentd †
クラスタレベルでのロギングを補助する。
Docker †
実際にコンテナを動作させるバックエンドに利用される。
コントローラ †
マスター上のkube-controller-manager上で実行される。
Deployments †
- 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:特定のポート）に転送
その他（？） †
kube configファイル †
.kube/config †
のパスにある。
内部の情報 †
中身は、コンテキスト毎、以下の情報が含まれる。
- クラスタ情報
- コンテキスト名
- 権限情報
- Master APIのURL
コンテキスト †
認証 / 認可 / アクセス制御 †
Bearer Tokenなので、OAuth2的。
- 認証
- 既定では、ユーザ管理機能はないので、機能なし。
- 拡張で、ユーザ管理機能と連携させることが出来る。
- 認可
- トークンを検証して権限情報を認可する。
- 既定では、「クラスタ管理者」と「クラスタ・ユーザ」の権限しか無い。
（そして、「クラスタ・ユーザ」権限もかなり高い権限を持っている）
- アクセス制御
認可された権限情報を用いて、アクセス制御を行う。
エコシステム？ †
Kubernetes の charts を利用するための簡単なツール
Minikube †
VirtualBox? 上で実行されるために作られた、とてもシンプルなツール
k3s、MicroK8s †
Minikubeのような仮想マシンを
利用せずにKubernetesを動かすことができる。
- Rancher Labs社：k3s
- 様々な機能が削られている。
- MasterとNodeで分散稼働する。
- EgdeコンピューティングやARMバイナリで動く
- IoTなどのスモールデバイス向き。
- Canonical社：MicroK8s
- ワンコマンドでKubernetesが実行環境を作ることができることを売りにしている
- MasterとNodeという分散動作せず、冗長性はない。
- 開発向けのシングルKubernetesを動かすことに特化。
Docker Compose ファイルを Kubernetes オブジェクトに変換できる。
Komposeと同じだが、開発元が社
トレンド †
標準化の動向 †
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コマンドのような機能は備えていない。
参考 †
Publickey †
CRI †
OCI †
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]")
