#contents
*Rancher/Kubernetes の概要 [#jd3d060a]
#ref(Rancher-Kubernetes.png)
-Rancher (牧場主) は、Kubernetes (k8s) の管理アプリ
--https://rancher.com/
--k8s のほとんどの機能を Web GUI から操作できる
--Rancher 自体も Docker 上で動く
--Version 1 では、独自の Docker コンテナ管理基盤を持っていたが、Version 2 から k8s の管理に特化 → 'Kubernetes-as-a-Service.'
-Kubernets (k8s)
--https://kubernetes.io/
--Docker コンテナのオーケストレーション基盤
--サービスを実行しているコンテナは、IA サーバのクラスタ上のどっかで動く
--外部への公開は、Ingress を通して行う
---Ingress は、内部的には Nginx の Reverse Proxy
---Reverse Proxy の物理的な接続先は k8s が勝手に管理してくれる
---外部に見せる URL と接続先のサービス (Docker コンテナ) との対応は、k8s に設定する必要がある。この設定は Rancher から行うことができる
-Docker コンテナ永続化領域は、Rancher が "Volume" から切り出す
--"Volume" には、NFS の他 Amazon EBS、iSCSI などを設定できる
*Kubernetesの概要 [#gfe1c864]
-Kubernetes の設定は、Rancher の Web GUI からできるとしても、Kubernetes の概要を知らないと何を設定していいのかもわからん
-ということで、登場人物だけ整理
#ref(Kubernetes.png)
**ハードウェア [#j7318cbc]
|Kubernetes Cluster|Kubernetes システム|
|Master Node |管理ノード。ここが死ぬとKubernetes全体が死ぬので、本番システムでは3台以上で冗長化する|
|Node |計算ノード|
**Kubernetes全体の管理 [#sfcd5210]
|kubectl|管理コマンド。RancherではWebから実行できる|
|kube apiserver|kuberctlからの処理依頼を受付|
|kube scheduler|Nodeを管理して、どの Node で Pod を動かすかを制御|
|kube control management|Kubernetes の資産を管理|
|etcd|分散KVS。Kubernetes自体の設定内容を格納|
**アプリコンテナ [#yff3d38f]
|namespace|Podの論理的な管理単位。初期設定で Default が作られている|
|Pod |Containerの論理的な単位。Nodeをまたぐことはない|
|Service |Pod (内の Container 上で動くアプリ) 同士で通信する場合に、パケットのルーティングを行う|
**Podの構成 [#c1bb64ea]
--ネットワーク
---Podに内部ネットワークのIPアドレスが振られる
---ただしIPアドレスは起動するごとに変わるので、内部ネットワークのIPアドレスはアプリやユーザは使わない
--Podは、Dockerが動いている仮想マシンと考えるとわかりやすい
+--------------+
| Pod |
| | 172.17.0.3
| Nginx(80)----+-8080----
| Container |
| | |
| | (5432) |
| Postgis |
| Container |
+--------------+
Port変換で、Container上で動いているアプリが listen している Port を Pod 外に公開する
**Service [#d39ab536]
|Cluster IP Serice |Pod間で通信をするための Service。通常 Service と言ったら Cluster IP Service|
|Node Port IP Service |あるノード(物理マシン)の Port 経由で Pod にアクセスするための Service|
|External Name Service|Pod から namespace 外のサービスを呼び出すための Serivce|
|Load Balancer Service|大規模 Kubernetes で、物理 Load Balancer と連携するための Service の総称。AWS とか Google Cloud Platform のうらで動いている Service|
-冗長化
|Replica Set|同一構成のPodの組。並列性能の向上、障害対応のために用いる|
|Deployment |本番サービスでは Deployment でアプリを管理。過去の Replica Set をもっていて、Replica Set に対してダウンタイムがないようにバージョンアップやロールバックを行える|
-Podへの外部からのアクセスは Service (L4 Switch相当) が振り分ける
--Pod はそれぞれラベルを持っていて、ラベルに従ってパケットを振り分ける。（そういうふうに Service を設定する)
--Replica Set 内の Pod はすべて同じラベルを持っていて、Service はそのことを知っているので、負荷分散がおこなわれる&br;
こんなかんじ
|IN Port |Label |h
|4848ポートに来たパケットは |"本番環境の管理アプリ" ラベルのPodにルーティング|
|8080ポートに来たパケットは |"本番環境" ラベルのPodにルーティング|
|14848ポートに来たパケットは |"テスト環境の管理アプリ" ラベルのPodにルーティング|
|18080ポートに来たパケットは |"テスト環境" ラベルのPodにルーティング|
---"本番環境"ラベルのPodが3つあったら順繰りに呼ばれる。
---パケット単位なんでアプリのセッションごとに振り分け先 Pod を固定するなんてことはできない → Ingress を使う
**Ingress [#abeaecb2]
-クラスタ全体の HTTP Reverse Poxy (L7 Switch相当)
-内部的には、外部からの HTTP Request を受け付けて、Service (Cluster IP Serice) 経由で Pod に HTTP パケットを投げなおしている
-中身は Nginx
**永続化領域 [#xf087301]
#ref(PersistentVolume.png)
-Pod 内で動く Docker Container の データ永続化領域（Volume）をどう確保するか
|PV (Persistent Volume)| Kubernetes 上で動くアプリケーションのデータを格納する領域。まとめて確保して PVC に切り出す|
|PVC (Persistent Volume Claim)| Pod が必要とするデータ領域のスペックと容量の要求(Claim)。Claim をもとに自動的に適切な PV が選ばれて PVC のデータ領域が作られる。通常は Volume Container が作られる|
|Pod| Pod では、PVC の name とアプリケーションからのマウントポイントを決める|
-PVCの例
#code(plain){{{
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mysql-data
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 8Gi
storageClassName: ssd
}}}
-PVの例
#code(plain){{{
apiVersion: v1
kind: PersistentVolume
metadata:
name: nfs001
spec:
capacity:
storage: 500Gi
accessModes:
- ReadWriteMany
persistentVolumeReclaimPolicy: Recycle
storageClassName: ssd
mountOptions:
- hard
nfs:
path: /opt/nfs
server: ai-chan.local
}}}
-accessMode
|ReadWriteOnce|1つのPodから読み書きできる|
|ReadOnlyMany |複数のPodから読み取りができる|
|ReadWriteMany|複数のPodから読み書きができる|
-persistentVolumeReclaimPolicy
|Retain |PVCが削除されても、データ領域(Volume Container)を残す|
|Recycle|PVCが削除されたら、データ領域(Volume Container)の中身を削除する|
|Delete |PVCが削除されたら、データ領域(Volume Container)を削除する|
-storageClassName
--任意に設定可能。Rancher ではデフォルトで何も登録されていない
*今回の実行環境 [#adaee6b5]
-[[DeepLearning 計算機調達]]
-[[DeepLearning XUbuntuインストール]]
-[[DeepLearning nvidia-docker2]]
-結局欲しいのは、Computing Node
--"--runtime=nvidia --shm-size=1g --ulimit memlock=-1 --ulimit stack=67108864" オプション付きで動かし、GPUを使った計算ができるノード
--こいつに macOS 上で動く PyCharm PRO (開発環境) をリモート接続する
-データを格納するために elastic search がほしい
-計算ノードの Dockerfile 及び Docker image を管理するために Gitlab が必要
*Rancherのインストール [#g4ad5bcd]
+Rancher を起動する。
$ sudo docker run -d --restart=unless-stopped -p 10080:80 -p 10443:443 rancher/rancher:latest
--明示的に docker stop されない限り再起動する
--公開するIPアドレスは 10080/10433。Kubernetes の Ingress が 80/433 を使うのでずらす
+https://ai-chan.local:10433 にアクセスする。証明書が (Rancherの) 自己証明書なのでアクセスを許可する必要がある
#ref(rancher-0.png)
+adminのパスワードを決める
#ref(rancher-1.png)
+Rancherのアドレスは https://ai-chan.local:10433 ですよ
#ref(rancher-2.png)
--ちなみに https://ai-chan.local だと *.local はダメだよと怒られる
*Kubernetes のインストール [#d89c7461]
+Add Cluster
#ref(rancher-3.png)
+種別は CUSTOM
#ref(rancher-4.png)
+適当にクラスタの名前をつける
#ref(rancher-5.png)
+一台構成なので、etcd Control Worker 全てにチェックをつける。インストールスクリプトが提示されるので、ターミナルで実行する
#ref(rancher-6.png)
+Done
#ref(rancher-7.png)
+しばらく待ちます
#ref(rancher-8.png)
+クラスタができた
#ref(rancher-9.png)
+Kubernetes が動いている。ここまで 5 分
#ref(rancher-10.png)
*PV (Persistent Volume) の作成 [#z5d2a5d7]
#ref(pv-0.png)
#ref(pv-1.png)
#ref(pv-2.png)
----
[[Deep Learning]]
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
