Kubernetes

Kubernetes

| Docker |

link

link

• コンテナ化されたアプリケーションのデプロイ、スケーリングなどの管理を自動化するプラットフォーム（コンテナオーケストレーションエンジン)
• https://knowledge.sakura.ad.jp/20955/
• 信頼性が高くスケーラブルな分散システムを上手に構築してデプロイするために必要なソフトウェアを提供
• 分散システムとは、異なるマシンで動作するAPIを実装する部品の集まり
• マネージドKubernetesサービス(KaaS:Kubernates-as-a-Service)
  • Microsoft:Azure Container Service
  • Google:Google Kubernetes Engine

宣言的なコードによる管理

• YAMLやJSONの宣言的なマニフェストで、コンテナやリソースを管理できる

スケーリング/オートスケーリング

• コンテナクラスタを形成して、複数のKubernetes Nodeを管理できる

スケジューリング

• コンテナを Kubernetes Nodeにデプロイする際に、どのNodeに配置するかを決定するスケジューリングというステップがある
• コンテナのワークロードの特徴、Kubernetes Nodeの性能差を意識してスケジューリングを行うことができる

リソース管理

• コンテナ配置に特別指定がない場合、自動スケジューリングが行われるため、管理する必要がない
• オートスケール機能により、Kubernetesクラスタの、Kubernetes Nodeの増減も自動で行われる

セルフヒーリング

• 標準でコンテナのプロセス管理を行っており、プロセス停止を検知すると、再度コンテナのスケジュールを行うことで自動的にコンテナを再デプロイする
• プロセス監視以外にも、HTTP・TCPや、シェルスクリプトによるヘルスチェックも可能

サービスディスカバリーとロードバランシング

• ロードバランシング機能（Service)を持っており、事前に指定した条件に合致するコンテナ群に対してルーティングを行う機能を提供する
• コンテナスケール時や、障害時のサービスへの追加、切り離しも自動で行うため、エンドポイント管理をKubernetesに任せることが可能
• コンテナを使用したシステム構築では、マイクロサービスアーキテクチャ採用が一般的、マイクロサービスが相互参照するために、サービスディスカバリー機能が有用
• マイクロサービスを定義されたマニフェストを元にシステム全体を連携させることが可能

データ管理

• バックエンドのデータ管理にetcdを利用している

基礎

• Kubernetes は、Kubernetes Master と Kubernetes Node の２種類のノードからから成り立っている
• Kubernetes Master は、APIエンドポイントの提供コンテナのスケジューリング、コンテナのスケーリングなどを担う
• Kubernetes Node は、Docker ホストに相当し実際にコンテナが稼働するノード
• Kubernetes クラスタを操作するには、kubectl と YAML か JSON 形式のマニフェストファイルを用いて、Kuebrnetes Masterにリソースの登録を行う
• kubectlは、マニフェストファイルの情報を元にKubernetes MasterのAPIにリクエストを送り、Kubernetesの操作を行う
• Kubernetes の API は一般的な RESTful API として実装されている

Kubernetes とリソース

• Kubernetesでは、リソースを登録することで、コンテナの実行やロードバランサの作成が非同期に行われる

Workloadsリソース

• クラスタ上にコンテナを起動するために利用する
• 内部的に利用されているものをのぞき、直接操作するものとしては、以下のリソースがある
  • Pod
  • ReplicationController
  • ReplicaSet
  • Deployment
  • DaemonSet
  • StatefulSet
  • Job
  • CronJob

Pod

• Workloadsリソースの最小単位
• 一つ以上のコンテナから構成され、ネットワーク的に隔離されておらず、IPアドレスを共有する
• 2つのコンテナが入ったPoｄを作成した場合、同一IPアドレスを持ち、お互い、localhostで通信できる
• 多くの場合は、1つのPodに1つのコンテナを含めるが、補助するサブコンテナを複数含めることもある

Discovery ＆ LBリソース

• コンテナサービスディスカバリやクラスタの外部からもアクセス可能なエンドポイントなどを提供する
• 利用者が直接利用するものとしては、Service と Ingress があり、Serviceは複数タイプが用意されている
• Service
  • ClusterIP
  • ExternalIP （ClusterIPの一種)
  • NodePort
  • LoadBalancer
  • Headless （None)
  • ExternalName
  • None-Selector
• Ingress

Config & Storage リソース

• 設定や機密データをコンテナに埋め込んだり、永続ボリュームを提供する
• Secret と ConfigMap は Key-Value のデータ構造を持ち保存データが機密か一般化によって使い分ける
• Secret
• ConfigMap
• PersistentVolumeClaim

Cluster リソース

• クラスタ自体の振る舞いを定義
• Node
• Namespace
• PersistentVolume
• ResourceQuote
• ServiceAccount
• Role
• ClusterRole
• RoleBinding
• ClusterRoleBinding
• NetworkPolicy

Metadataリソース

• クラスタ内の他のリソースの動作を制御する
• LimitRange
• HorizontalPodAutoscaler
• PodDisruptionBudget
• CustomResourceDefinition

Kubectl

チートシート

• 公式なクライアントは、kubectl
• kubectlを使用してクラスターと対話できるようになります
• Kubernetes APIと連携するコマンドラインツール
• minikube から利用する場合

> minikube kubectl version

kubectlコマンド

• Kubernetesでは、クラスタの操作は全て、Kubernetes Masterの APIを介して行われる
• 手動で操作する場合には、CLIツールの kubectl を利用するのが一般的
• Kubectl が　Kubernetes Master と通信するには、接続先サーバー情報や認証情報が必要となる
• デフォルトでは、~/.kube/config に書かれている情報を使用して接続を行う

kubectlインストール

$ curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl
$ sudo chmod +x ./kubectl
$ sudo install kubectl /usr/local/bin

設定

• 設定を行う箇所は、clusters,contexts,users
• YAML もしくは JSONフォーマット
• 直接編集するだけでなく、kubectlから変更も可能
• https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#pod-v1-core

apiVersion: v1
clusters:
- cluster:
    certificate-authority: /home/piroto/.minikube/ca.crt
    server: https://192.168.39.214:8443
  name: minikube
contexts:
- context:
    cluster: minikube
    user: minikube
  name: minikube
current-context: minikube
kind: Config
preferences: {}
users:
- name: minikube
  user:
    client-certificate: /home/piroto/.minikube/profiles/minikube/client.crt
    client-key: /home/piroto/.minikube/profiles/minikube/client.key

マニフェストとリソースの作成

• sample-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
spec:
  containers:
    - name: nginx-container
      image: nginx:1.12

実行

• apply　コマンドを利用すると、存在しなければ生成、更新があれば更新、変更なければ何もしないという挙動

$ kubectl create -f sample-pod.yaml  
pod/sample-pod created

• 確認

$ kubectl get pod
NAME         READY   STATUS    RESTARTS   AGE
sample-pod   1/1     Running   0          42s

$ kubectl apply -f sample-pod.yaml 
pod/sample-pod configured

アノテーションとラベル

• 各リソースに対してアノテーションとラベルというメタデータを付与することができる

名称	概要
アノテーション	システムコンポーネントが使用するメタデータ.アノテーションを元に処理するシステムコンポーネントが存在しない場合は単なるメモ
ラベル	リソース管理に利用するメターデータ.リソースを分別するための情報

• ユーザーがアノテーションを付与せず作成したリソースでも、下記のように様々なアノテーションが付与される

$ kubectl get deployments -o yaml hello-minikube
apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "1"
  creationTimestamp: "2020-08-22T08:02:54Z"
         :

• アノテーションとラベルをマニフェストに追記

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
  annotations:
    annotation1: val1 
    annotation2: val2
  labels:
    label1: lab1
    label2: lab2
spec:
  containers:
    - name: nginx-container
      image: nginx:1.19

• 表示の拡張

$ kubectl get pod --output wide
NAME         READY   STATUS    RESTARTS   AGE   IP           NODE       NOMINATED NODE   READINESS GATES
sample-pod   1/1     Running   2          24h   172.17.0.3   minikube   <none>           <none>

• ダッシュボードに表示された

2つのコンテナを内包したPod

• マニフェスト sample-2pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: sample-2pod
spec:
  containers:
    - name: nginx-container
      image: nginx:1.19
    - name: radis-container
      image: redis:6.0.7

• 適用

$ kubectl apply -f sample-2pod.yaml 
pod/sample-2pod created

• 結果確認

$ kubectl get pod --output wide
NAME          READY   STATUS    RESTARTS   AGE     IP           NODE       NOMINATED NODE   READINESS GATES
sample-2pod   2/2     Running   0          7m40s   172.17.0.6   minikube   <none>           <none>
sample-pod    1/1     Running   2          2d      172.17.0.3   minikube   <none>           <none>

Pod

• 同じ実行環境上で動くアプリケーションコンテナとストレージボリュームの集まりのこと
• Kubernetesクラスタ上では、コンテナではなくPodがデプロイの最小単位
• 1つのPodないのコンテナは全て同じマシン上に配置される
• 同じPod内のアプリケーションは、ネイティブなプロセス間通信チャネルで通信できるが、異なるPodのアプリケーションからは分離されている

Pod単位で考える

• WordPressとMySQLを同じPodに入れれば良いと考えるのはアンチパターンの1つ
• それぞれ別マシンで通信できればよく、WordPressとDBが同じ単位としてスケールする可能性も低い
• WordPress自体はステートレスなため、負荷が増大した場合、WordPressのPodを増やしてスケールさせれば良い
• 通常は、Podを作る際に、コンテナが異なるマシンに配置されても正常に動作するかという点が判断基準

Docker

Dockerデーモンの再利用によるローカルイメージの使用

• Dockerデーモンの再利用によるローカルイメージの使用
• Mac/LinuxのホストでDockerデーモンを操作できるようにするには、minikube docker-envを実行
• MinikubeのVM内のDockerデーモンと通信しているホストのMac/LinuxマシンのコマンドラインでDockerを使用できるようになる

$ minikube docker-env
export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://192.168.39.214:2376"
export DOCKER_CERT_PATH="/home/piroto/.minikube/certs"
export MINIKUBE_ACTIVE_DOCKERD="minikube"

# To point your shell to minikube's docker-daemon, run:
# eval $(minikube -p minikube docker-env)

$ docker ps
Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get http://%2Fvar%2Frun%2Fdocker.sock/v1.40/containers/json: dial unix /var/run/docker.sock: connect: permission denied

• https://tech.librastudio.co.jp/entry/index.php/2018/07/14/post-1924/

$ sudo groupadd docker
$ sudo gpasswd -a `id -un` docker
$ sudo chgrp docker /var/run/docker.sock 

$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

https://hub.docker.com/