Kubernetes

コンテナ化されたアプリケーションのデプロイ、スケーリングなどの管理を自動化するプラットフォーム（コンテナオーケストレーションエンジン)
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/

MyMemoWiki

Kubernetes

目次

Kubernetes

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

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

スケジューリング

リソース管理

セルフヒーリング

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

データ管理

基礎

Kubernetes とリソース

Workloadsリソース

Pod

Discovery ＆ LBリソース

Config & Storage リソース

Cluster リソース

Metadataリソース

Kubectl

kubectlコマンド

kubectlインストール

設定

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

実行

アノテーションとラベル

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

Pod

Pod単位で考える

Docker

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

案内メニュー

検索