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

目次

概要

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

呼称

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

経緯

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

2014年

Google、Kubernetes発表(6月)

2015年

  • 2月
    OpenShift V3、DockerとKubernetesをコアとすると発表。
  • 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?

  • データベースなどステートフルなポッドが必要な場合はステートフルセットを使って展開。
  • ステートフルセットを使うとストレージやネットワーク名などが保持される。

ポッド

概要

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

特徴

以下の特徴がある。

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

ボリューム

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

種類や用途

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

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

ボリューム・タイプ

  • emptyDir
    • ポッド用の一時的なディスク領域
    • ポッドが terminate されると削除される。
  • hostPath
    ノード(ホスト)の任意の領域をマウントできる。
  • PersistentVolume?(PV)
    • 永続化領域として確保されるボリューム。
    • PVは個別にリソースを作成して利用する必要がある。
    • 後述する PersistentVolumeClaim?(PVC)経由で利用する。
  • PersistentVolumeClaim?(PVC)
    • PV の要求を行うリソース。
    • PVC は要求された内容(容量、ラベル)から
      適切な PV を探し、ボリュームを割り当てる。
    • プロビジョニングの方法として以下の2つの方法がある。
      • Static : 予め PV を作成
      • Dynamic : PVC が作成した際に動的に PV を作成

サービス

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

用途

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

サービス・タイプ

以下の種類がある。

  • ClusterIP
    クラスタの内部IP
  • LoadBalancer?
    クラスタの外部IP
  • ExternalName?
    特定の DNS エントリを作成
  • NodePort?
    「ノードのIP:特定のポート」を特定のサービス(ClusterIP:特定のポート)に転送

その他(?)

kube configファイル

.kube/config

のパスにある。

内部の情報

中身は、コンテキスト毎、以下の情報が含まれる。

  • クラスタ情報
    • コンテキスト名
    • 権限情報
    • Master APIのURL

コンテキスト

  • コンテキストには、コンテキスト名と対応するクラスタ名と認証情報がある。
    $ kubectl config get-contexts
  • コンテキストによって、接続先やクレデンシャル情報を変更できる。
    $ kubectl config use-context <コンテキスト名>
  • コンテキスト毎に、ファイルを分割する。
    $ kubectl config --kubeconfig=<ファイル名>  use-context <コンテキスト名>

認証 / 認可 / アクセス制御

Bearer Tokenなので、OAuth2的。

  • 認証
    • 既定では、ユーザ管理機能はないので、機能なし。
    • 拡張で、ユーザ管理機能と連携させることが出来る。
  • 認可
    • トークンを検証して権限情報を認可する。
    • 既定では、「クラスタ管理者」と「クラスタ・ユーザ」の権限しか無い。
      (そして、「クラスタ・ユーザ」権限もかなり高い権限を持っている)
  • アクセス制御
    認可された権限情報を用いて、アクセス制御を行う。

トレンド

コンテナの標準仕様

標準化の動向

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 と Kubernetesのコンテナ・オーケストレーション・ツールの主導権争い。
  • 10月
    Kubernetesが独自コンテナランタイム(cri-o)開発を表明
  • 12月
    中立的なコンテナ・ランタイムのため、Dockerからcontainerdが分離された。

cri-o

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

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

PaaSの上モノ部分

OpenShiftの「s2i」に相当するものが色々出ており、
(microsoftの「draft」やGoogleの「Skaffold」など)
玉石混合で、なにがベストプラクティスなのか固まっていない。

Helm

Kompose

Compose on Kubernetes

参考

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

サブシステム

Helm Charts

Compose on Kubernetes

Kompose

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

Docker Desktop for Windows

Azure Kubernetes Service (AKS)


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