「.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からのアクセスを、
ノード上の各ポッドに対して転送し、
ポッドへのアクセスを抽象化するコンポーネント。
コンテナ・ランタイム †
アドオン †
DNS †
- 以下のDNSレコードを提供するDNSサーバ
- 環境内の他のDNSサーバ
- Kubernetesサービスの
ダッシュボード †
コンテナリソース監視 †
- kubeletとDockerが正しく動作
し続けるように監視及び管理するコンポーネント。
クラスターレベルログ †
- fluentd
- クラスタレベルでのロギングを補助する。
コントローラ †
マスター上のkube-controller-manager上で実行される。
Deployments †
下位要素は、ReplicaSet
- CLIを使用したり、yaml や JSON で定義をコントローラに渡したりして展開できる。
- ポッドだけでなくサービスの定義や、各種要素の詳細な設定を定義して一括で適用できる。
ReplicaSet? †
下位要素は、ポッド
DaemonSet? †
下位要素は、ポッド
- 全ノードや特定のノード群に対してある機能を実行しておきたい場合に使う。
- 具体的な利用シーンとしては、ログ収集のエージェントなどがある。
StatefulSet? †
下位要素は、ポッド
- データベースなど、データの永続化の用途で利用される。
ポッド †
概要 †
- いくつかのコンテナをグループ化したもの。
- ポッド単位で作成、開始、停止、削除といった操作を行う。
- １つのコンテナを作成したいときも「コンテナが１つ含まれるポッド」を作成する。
特徴 †
以下の特徴がある。
- ポッド内のコンテナは、同一ホスト上に配備される。
- ポッド内のコンテナは、仮想NICやプロセステーブルを共有する。
→ つまり、同じIPを使えたり、互いのプロセスが見えたりする。
- 各ポッドには固有のIPアドレスがあり、ポートスペース全体を所有している。
- ポッド内のコンテナはストレージを共有できる。
- ポッドには、ポッドをグループするための1つ以上のラベルを指定できる。
- 一般的には、サーバと、そのサーバと共に実行する補助サービスを含める。
- Webサーバ
- APサーバ
- DBサーバ
- KVSサーバ
ボリューム †
- 抽象化されたポッドと疎結合なリソースで、ポッドに紐づく。
- ポッド内のコンテナがデータを読み書きできるディスク領域。
- 様々な種類が提供されている。
種類や用途 †
ボリュームには様々な種類や用途がある。
ボリューム・タイプ †
- emptyDir
- ポッド用の一時的なディスク領域
- ポッドが terminate されると削除される。
- hostPath
ノード(ホスト）の任意の領域をマウントできる。
サービス †
ネットワーク機能を提供するコンポーネント
用途 †
- ポッドに対して通信をルーティングする。
- ポッドに対する通信を維持する（SLA、負荷分散）
サービス・タイプ †
以下の種類がある。
- Node Port
- Cluster IP
- Load Balancer
- , etc.
※ 詳しくはコチラ。
リソースで分類 †
に分類されます。リソースを定義するYAMLの記述方法の詳細はAPIドキュメントを参照ください。
Workloads †
Kubernetesを構成する基本的なリソース
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アドレス取得
負荷分散 †
- 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
分離 / 独立した環境を準備する。
- RBAC (Role Based Access Control)
- Role
- ClusterRole?
- RoleBinding?
- ClusterRoleBinding?
Metadata †
- 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サーバなど永続化データを持つサーバが対象
エコシステム †
サブシステム †
Komposeと同じだが、開発元が社
Docker Compose ファイルを Kubernetes オブジェクトに変換できる。
Kubernetes の charts を利用するための簡単なツール
Helmのウワモノ。
トレンド †
→ コンテナ・ランタイム
標準化の動向 †
2015年 †
OCI（Open Container Initiative）
- コンテナ・ランタイムとコンテナ・イメージの標準
- 6月にDocker社などの複数の企業によりイニシアチブ（組織）が設立された。
2016年 †
CRI（Container Runtime Interface）
- Docker以外のコンテナ・ランタイムを組み込み易くするI/F標準。
- 12月にkubeletとコンテナランタイムの通信規格として規定された
2017年 †
2018年 †
昨今、開発寄りなのかも知れない。
- アプリケーションの開発フェーズにおいてDockerが使われる。
- 今後は、コンテナ・ランタイムの多様化が起きると言われている。
containerd †
デファクト・スタンダードのコンテナ・ランタイム
- 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のリソースタイプを体系的に学ぶ
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]")
