【IBM Cloud k8s検証メモ】Kuberetesクラスタ構成について資料リンク集


Bluemix の k8s を利用するにあたって、必要な知識を得るために、必要なリンクと要約集を作ってみました。 と言っても殆ど自分用なんですけどね。この図は、Bluemixのk8sのマニュアル https://console.bluemix.net/docs/containers/cs_ov.html#cs_ov_architecture の図をVPN接続とネームスペースの関係を削除して、再グループ化したものです。

![スクリーンショット 2017-09-06 17.07.35.png](https://qiita-image-store.s3.amazonaws.com/0/42829/e1a699af-d079-6a34-1e04-7b500596d331.png "スクリーンショット 2017-09-06 17.07.35.png")



# Master

## kube-apiserver

Kubernetes APIサーバーは、ポッド、サービス、レプリケーションコントローラなどを含むapiオブジェクトのデータを検証し、構成します。 APIサーバーはREST操作を処理し、他のすべてのコンポーネントが相互作用するクラスタの共有状態にフロントエンドを提供します。
https://kubernetes.io/docs/admin/kube-apiserver/


## kube-controller-manager

'Kubernetes controller manager'は、Kubernetesに同梱されているコアのコントロールループを組み込んだデーモンです。 ロボット工学および自動化のアプリケーションでは、制御ループはシステムの状態を調整する終了しないループです。 Kubernetesで、コントローラは、`apiserver`を介してクラスタの共有状態を監視し、現在の状態を目的の状態に向かって移行しようとする変更を行う制御ループです。 今日、Kubernetesと共に出荷されるコントローラーの例には、`replication controller`, `endpoints controller`, `namespace controller`, and `serviceaccounts controller`があります。
https://kubernetes.io/docs/admin/kube-controller-manager/


## kube-scheduler

Kubernetesスケジューラは、可用性、パフォーマンス、および容量に大きな影響を与える「ポリシーリッチな」「トポロジを意識した」「ワークロード固有の」機能です。 スケジューラは、個別および集合的なリソース要件、サービス品質要件、ハードウェアやソフトウェアのポリシー制約、親和性および非親和性の指定、データ局所性、相互ワークロードの干渉、デッドラインなどが含まれます。 必要に応じて、「ワークロード固有の要件」がAPIを通じて公開されます。
https://kubernetes.io/docs/admin/kube-scheduler/


## etcd

etcdは分散システムの最も重要なデータに対する信頼性の高いキーストアです。
  * シンプル：ユーザー定義の明確なAPI（gRPC）
  * セキュア：オプションのクライアント証明書認証による自動TLS
  * 速さ：ベンチマーク10,000回/秒
  * 信頼性：ラフトを使用して適切に配布

etcdはGoで書かれ、Raftコンセンサスアルゴリズムを使用して、高可用性の複製ログを管理します。
https://github.com/coreos/etcd

Raftについて https://gist.github.com/sile/ad435262c17eb79f133d

## OpenVPNサーバー

IBM Bluemix の Kubernetesの実装に採用されている OSSのVPNサーバーです。 k8sのマスターは、IBM管理となっており、ワーカーと呼ばれるノードに相当する部分は、ユーザーの仮想サーバーとなっています。 このIBM管理のマスターとユーザーの仮想サーバーは、Private LANを相互に接続して連携できないので、Public LAN を経由して安全に通信するために、マスターにOpenVPNサーバー、ワーカーにOpenVPNクライアントがデプロイされています。
https://www.openvpn.jp/introduction/




# Worker (グーグルの呼び方では Node)


## kubelet

kubeletは、各ノードで動作する主要な「ノードエージェント」です。 kubeletは「PodSpecの用語」で機能します。

PodSpecは、ポッドを記述するYAMLまたはJSONオブジェクトです。 kubeletは、さまざまなメカニズム（主にapiserverを介して）によって提供される一連のPodSpecを受け取り、それらのPodSpecに記述されているコンテナが実行中で健全であることを保証します。 kubeletは、Kubernetesによって作成されなかったコンテナを管理しません。


apiserverからのPodSpec以外に、コンテナマニフェストをKubeletに提供する3つの方法があります。

* File：コマンドラインでフラグとして渡されるパス。このパスの下にあるファイルは定期的に更新されます。監視期間はデフォルトで20秒で、フラグを使用して設定できます。
* HTTPエンドポイント：コマンドラインでパラメータとして渡されるHTTPエンドポイント。このエンドポイントは20秒ごとにチェックされます（フラグでも設定可能）。
* HTTPサーバ：kubeletはHTTPをリッスンし、新しいマニフェストを送信する簡単なAPI（現時点では未指定）にも応答することができます。

https://kubernetes.io/docs/admin/kubelet/


PodSpecの仕様 https://kubernetes.io/docs/api-reference/v1.6/#pod-v1-core


## kube-proxy

Kubernetesネットワークプロキシは、各ノードで実行されます。これは、各ノード上のKubernetes APIで定義されているサービスを反映し、単純なTCP、UDPストリーム転送、またはラウンドロビンTCP、バックエンドセット全体のUDP転送を行うことができます。 サービスクラスタのIPとポートは現在、サービスプロキシによって開かれたポートを指定するDocker-link-compatible環境変数によって検出されます。これらのクラスタIPにクラスタDNSを提供するオプションのアドオンがあります。 プロキシを設定するには、apiserver APIを使用してサービスを作成する必要があります。
https://kubernetes.io/docs/admin/kube-proxy/


## Addons

### Web UI (Dashboard)

DashboardはWebベースのKubernetesユーザーインターフェイスです。 Dashboardを使用して、コンテナ化されたアプリケーションをKubernetesクラスタに展開し、コンテナ化されたアプリケーションのトラブルシューティングを行い、付随するリソースと共にクラスタ自体を管理できます。 Dashboardを使用すると、クラスタ上で実行されているアプリケーションの概要や、個々のKubernetesリソース（デプロイメント、ジョブ、デーモンセットなど）の作成または変更を行うことができます。 たとえば、デプロイメントを拡張したり、「ローリング・アップデート」を開始したり、「ポッドを再起動する」、または「デプロイ・ウィザードを使用して新しいアプリケーションをデプロイする」ことができます。

ダッシュボードには、クラスタ内のKubernetesリソースの状態や発生した可能性のあるエラーに関する情報も表示されます。

https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/


### kueb-dns

オプションの（ただし強く推奨される）クラスタアドオンはDNSサーバーです。 DNSサーバーはKubernetes APIで新しいサービスを監視し、それぞれに対して一連のDNSレコードを作成します。 DNSがクラスタ全体で有効になっている場合、すべてのポッドはサービスの名前解決を自動的に行うことができます。

たとえば、Kubernetesネームスペース "my-ns"に "my-service"というサービスがある場合、 "my-service.my-ns"のDNSレコードが作成されます。 "my-ns"名前空間に存在するポッドは、単に "my-service"の名前検索を行うだけで見つけることができます。 他のネームスペースに存在するポッドは、その名前を "my-service.my-ns"として修飾する必要があります。 これらの名前検索の結果はクラスタIPです。

https://kubernetes.io/docs/concepts/services-networking/service/#dns


## Calico for Kubernetes

Calicoは、クラウド全体でKubernetesクラスタのネットワークとネットワークポリシーを可能にします。 Calicoはすべての主要なパブリッククラウドプロバイダーとプライベートクラウドでどこでも動作します。

Calicoは純粋なIPネットワーキング・ファブリックを使用して高性能ネットワーキングを提供し、そのバトルテストを受けたポリシー・エンジンは、ハイレベルな意図に焦点を当てたネットワーク・ポリシーを実施します。 CalicoとKubernetesは、インフラストラクチャを何十万ものワークロードに拡張できる安全なクラウドネイティブのプラットフォームを提供します。
https://docs.projectcalico.org/v2.0/getting-started/kubernetes/


## Bluemix Container Service ワーカー・ノードのネットワークポリシー

> Kubernetes クラスターはそれぞれ、Calico と呼ばれるネットワーク・プラグインを使用してセットアップされます。各ワーカー・ノードのパブリック・ネットワーク・インターフェースを保護するために、デフォルトのネットワーク・ポリシーがセットアップされます。 固有のセキュリティー要件があるときには、Calico および Kubernetes のネイティブ機能を使用してクラスター用のネットワーク・ポリシーをさらに構成できます。 これらのネットワーク・ポリシーは、クラスター内のポッドを出入りするネットワーク・トラフィックのどれを許可し、どれをブロックするかを指定します。
> Calico と Kubernetes のネイティブ機能のいずれかを選んで、ご使用のクラスター用のネットワーク・ポリシーを作成することができます。 手始めには Kubernetes のネットワーク・ポリシーを使用することができますが、より堅牢な機能が必要であれば Calico のネットワーク・ポリシーを使用してください。

https://console.bluemix.net/docs/containers/cs_security.html#cs_security_network_policies




### calico-policy-controller

ポリシーコントローラは、主に環境変数によって構成されます。 ポリシーコントローラをKubernetesポッドとして実行する場合、これはポッドマニフェストのenvセクションで行います。
https://docs.projectcalico.org/v2.0/reference/policy-controller/configuration



### calico-ipam

IPAMとは、IP Address Management の略で、ある範囲のIPアドレスを管理することを指します。 コンテナの作成時にユーザーが特定のIPアドレスを選択できるように指定するものです。
https://docs.projectcalico.org/v2.0/getting-started/docker/tutorials/ipam



### calico-cni
Calico CNIプラグインは、標準のCNIを通じて構成されます。
Container Networking Interface Specification https://github.com/containernetworking/cni/blob/master/SPEC.md#network-configuration



### calico-node
calico-nodeコンテナは、主に環境変数によって構成されます。
https://docs.projectcalico.org/v2.5/reference/node/configuration




## Heapster

ヒープスターは、コンテナクラスタ監視とパフォーマンス分析を可能にします。Heapsterは現在、KubernetesとCoreOSをネイティブにサポートしています。 Heapsterはv1.0.6以降のkubernetesバージョンと互換性があります

https://github.com/kubernetes/heapster