ç Kubernetes基礎 NTT Tech Conference#4 @yosshi_

● 吉村 翔太 ● NTTコミュニケーションズ所属 ● データサイエンスチーム ● インフラエンジニア/データエンジニアリング ● Kubernetes 、Prometheus　 etc ● 登壇 CNDT “Kubernetes Logging入門” etc ● コミュニティ活動 “Cloud Native Developers JP” @yosshi_ 自己紹介 “Prometheus Meetup Tokyo”

今日話す内容 • Kubernetesの全体像 – Cluster – kubectl • 基本的な構成要素 – Workload – Configuration – Discovery & LB – Metadata • kubectlによるオペレーション – Manifestを中心にしたオペレーション – よく使うkubectl

Kubernetesの全体像

Kuberntes(k8s)の全体像 k8s Cluster node master API Server etcd cluster Controller Manager Scheduler etcd Kubelet Kube-proxy Container runtime コンテナ node Kubelet Kube-proxy Container runtime コンテナ Kubectl これを 今から説明します API Server経由でetcdの操作を行い、etcdの状態に応じてアクションする

Infrastructure components • Master – k8sを管理するコンポーネントが配置されるサーバ群 • Node – コンテナが配置されるサーバ群 • etcd cluster – コンテナが配置されるサーバ群高信頼性KVS、k8sのデータが保存される

Master components • API Server – etcdへのwrite、readを行うAPIサーバ – 複数台配置して冗長化構成をとることができる • Controller Manager – デプロイするコンテナの個数等を管理する – 複数台配置できるがリーダは1つだけ • Scheduler – コンテナをどのNodeにデプロイするか決める – 複数台配置できるがリーダは1つだけ

Node components • Container runtime – 文字通りコンテナのランタイム – Docker以外を使用することもできる • Kubelet – Node上に配置されるエージェント – コンテナの起動停止等を行う • Kube-proxy – コンテナとの接続を保証するためにNodeのNWを管理する

kubectl • kubectl – ユーザがk8sを操作する際に使う – 詳細は後述

参考：MasterとControl Plane componentsの違い API Server Scheduler Controller Manager Kubelet Kube-proxy API Server Scheduler Controller Manager 参照 < https://kubernetes.io/docs/concepts/architecture/master-node-communication/ > こんなニュアンスが多そうだか その限りでもなさそうで困る Master to Clusterの通信とかなんだよ・・ • Control Plane components – k8sを管理するコンポーネントが配置されるサーバ群 • Master – k8sを管理するコンポーネントが配置されるサーバ群

参考：Master Nodeの中身 Controller Manager Kubelet Container runtime API Server Scheduler Master Control Planeもコンテナだったりする

Kubeadmで構築時のMaster $ systemctl status docker ● docker.service - Docker Application Container Engine Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled) Active: active (running) since Sun 2019-03-24 01:04:19 UTC; 23h ago Docs: https://docs.docker.com Main PID: 1229 (dockerd) Tasks: 211 Memory: 874.2M CPU: 39min 29.172s CGroup: /system.slice/docker.service ├─1229 /usr/bin/dockerd -H fd:// ├─1254 docker-containerd --config /var/run/docker/containerd/containerd.toml ├─2820 docker-containerd-shim -namespace moby -workdir /var/lib/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/808fb・・・ ├─2822 docker-containerd-shim -namespace moby -workdir /var/lib/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/2f33b・・・ $ systemctl status kubelet ● kubelet.service - kubelet: The Kubernetes Node Agent Loaded: loaded (/lib/systemd/system/kubelet.service; enabled; vendor preset: enabled) Drop-In: /etc/systemd/system/kubelet.service.d └─10-kubeadm.conf Active: active (running) since Sun 2019-03-24 01:05:58 UTC; 23h ago Docs: https://kubernetes.io/docs/home/ Main PID: 2691 (kubelet) Tasks: 17 Memory: 75.0M CPU: 48min 37.605s CGroup: /system.slice/kubelet.service └─2691 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubel・・・ API Server Controller Manager Scheduler ①Dockerの起動 ②Kubeletの起動 ③ Control Plane componentsが 　 コンテナとして起動

参考：systemctlで“kubelet”を確認する (1/4) $ systemctl status kubelet • kubelet.service - kubelet: The Kubernetes Node Agent Loaded: loaded (/lib/systemd/system/kubelet.service; enabled; vendor preset: enabled) Drop-In: /etc/systemd/system/kubelet.service.d └─10-kubeadm.conf Active: active (running) since Sun 2019-07-21 03:13:41 UTC; 2 days ago Docs: https://kubernetes.io/docs/home/ Main PID: 17633 (kubelet) Tasks: 18 (limit: 4915) CGroup: /system.slice/kubelet.service └─17633 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf 　　　　　　　　　　　　　　--kubeconfig=/etc/kubernetes/kubelet.conf 　　　　　　　　　　　　　　 --config=/var/lib/kubelet/config.yaml --cgroup-driv 起動時にこのconfigを読んでる

参考：systemctlで“kubelet”を確認する (2/4) $ cat /var/lib/kubelet/config.yaml address: 0.0.0.0 apiVersion: kubelet.config.k8s.io/v1beta1 authentication: anonymous: enabled: false : : serializeImagePulls: true staticPodPath: /etc/kubernetes/manifests streamingConnectionIdleTimeout: 4h0m0s syncFrequency: 1m0s volumeStatsAggPeriod: 1m0s 参考< https://kubernetes.io/docs/tasks/administer-cluster/static-pod/ > Static Pods機能を使うと 起動時に指定したmanifestに書かれたPodを 起動することができる

参考：systemctlで“kubelet”を確認する (3/4) $ ls /etc/kubernetes/manifests etcd.yaml kube-apiserver.yaml kube-controller-manager.yaml kube-scheduler.yaml kubelet起動時にStaticPodsで指定した Control Plane ComponentsのPodが立つことでKubernetesとして機能している 参考< https://kubernetes.io/docs/tasks/administer-cluster/static-pod/ >

参考systemctlで“kubelet”を確認する (4/4) $ cat /etc/kubernetes/manifests/kube-apiserver.yaml apiVersion: v1 kind: Pod metadata: creationTimestamp: null labels: component: kube-apiserver tier: control-plane name: kube-apiserver namespace: kube-system spec: containers: : : 中身は普通のyaml

Kuberntes(k8s)の全体像 k8s Cluster node master API Server etcd cluster Controller Manager Scheduler etcd Kubelet Kube-proxy Container runtime コンテナ node Kubelet Kube-proxy Container runtime コンテナ Kubectl API Server経由でetcdの操作を行い、etcdの状態に一致するようにk8sが変更される

参考：API Serverからetcdにいかない例外の4パターン • “/proxy” – API Serverとの間にproxyをはる • “/exec” – コンテナでコマンドで実行 • “/attach” – コンテナにattach • “/logs” – コンテナのログを取得 “logs”の場合の通信 Mnaging Kubernetes

Kuberntes(k8s)の全体像 k8s Cluster node master API Server etcd cluster Controller Manager Scheduler etcd Kubelet Kube-proxy Container runtime コンテナ node Kubelet Kube-proxy Container runtime コンテナ Kubectl マネージドサービスを使うと 　　　　だけ考えれば良いことが多い オンプレミスだとこれら全てを理解して保証する必要がある

基本的な構成要素

構成要素の全体像 Resources mgt Network / exposition Configuration Storage IAM Pod generator Creates References Kubernetes Ressources Map 参考< https://github.com/kubernetes/community/tree/master/icons > ：今日話す範囲

構成要素の全体像 Resources mgt Network / exposition Configuration Storage IAM Pod generator Creates References Kubernetes Ressources Map 参考< https://github.com/kubernetes/community/tree/master/icons > ：今日話す範囲 ① コンテナの制御 ② コンテナのConfig ③ NW ④ 仮想ク ラスタ 権限制御 ストレージ リソース制限

Workload Configuration Discovery & LB Deployment ReplicaSet Pod Service Secret ConfigMap k8s Cluster Namespace 今日話す基本的な構成要素の全体図

Workload

Workload Configuration Discovery & LB Deployment ReplicaSet Pod Service Secret ConfigMap k8s Cluster Namespace 今日話す基本的な構成要素の全体図

Workloadの一覧 名前 略称 説明 Pod - コンテナのデプロイの最小単位 ReplicaSet rs デプロイしたPod数を維持するリソース Deployment deploy RollingUpdateするためにReplicaSetを管理するリソース DaemonSet ds 各Nodeに1個ずつPodをデプロイするリソース StatefulSet sts Statefulなコンテナのデプロイに対応したリソース Job - Job用のコンテナをデプロイするリソース CronJob - Jobをcron実行するリソース ：今日話す範囲

Pod(po) • コンテナのデプロイの最小単位 – 1個のPodに複数のコンテナを定義できる(Sidecar) – 定義された複数のコンテナは必ず同一のNodeにデプロイされる – 複数のコンテナは同一のIPアドレスを共有 node Kubelet Kube-proxy node Kubelet Kube-proxy コンテナB コンテナA Pod 必ずPod単位でNodeにデプロイされる

Pod(po) コンテナB コンテナA Pod $ kubectl get po –o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nginx-deployment-756bf884bf-gr6qt 2/2 Running 0 10s 10.244.1.2 worker01 spec: containers: - name: nginx1 image: nginx:1.7.9 - name: nginx2 image: nginx:1.7.9 Podの定義 k8s Clusterの状態 NIC Podの中にコンテナが 2個あることが分かる Pod単位にNICが1個ある Podをデプロイすると

ReplicaSet(rs) コンテナA Pod app: nginx 1個のPodにLabelを複数付与できるので、目的の違う PodのLabelの組み合わせが被らないように設計しよう コンテナA Pod app: nginx コンテナA Pod app: nginx ReplicaSet “replicas: 3” Label Selector ”app: nginx” Podが死んだ場合でも 個数が3になるように管理する • デプロイしたPod数を維持するリソース – Podに付与されているlabelを意識してReplicaSetが制御する

ReplicaSet(rs) kubectl get rs,po -o wide NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR replicaset.extensions/nginx-deployment-76fbb7bd7b 3 3 3 6s nginx1 nginx:1.7.9 app=nginx,pod-template-hash=76fbb7bd7b NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod/nginx-deployment-76fbb7bd7b-9rhdr 1/1 Running 0 6s 10.244.2.9 worker02 pod/nginx-deployment-76fbb7bd7b-kdsfl 1/1 Running 0 6s 10.244.3.9 worker03 pod/nginx-deployment-76fbb7bd7b-x566n 1/1 Running 0 6s 10.244.1.9 worker01 spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx1 image: nginx:1.7.9 ReplicaSetの定義 k8s Clusterの状態 同一のreplicasetの管理下で あることが分かる ReplicaSetをデプロイすると ReplicaSetで管理するPodのLabel Podに付与するLabel ReplicaSetのLabel Selector

Deployment(deploy) コンテナA Pod ReplicaSet 旧 コンテナA Pod コンテナA’ Pod ReplicaSet 新 コンテナA’ Pod Deployment 新しいReplicaSetが作られて Podも順次作られる 旧のReplicaSetのreplicas の数が減って Podも順次削除される • RollingUpdateするためにReplicaSetを管理するリソース

Deployment(deploy) kubectl get deploy,rs,po -o wide NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR deployment.extensions/nginx-deployment 3/3 3 3 118m nginx1 nginx:1.12 app=nginx NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR replicaset.extensions/nginx-deployment-5fbf59df75 2 2 1 3s nginx1 nginx:1.12 app=nginx,pod-template-hash=5fbf59df75 replicaset.extensions/nginx-deployment-76fbb7bd7b 2 2 2 114m nginx1 nginx:1.7.9 app=nginx,pod-template-hash=76fbb7bd7b NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod/nginx-deployment-5fbf59df75-55j5b 0/1 ContainerCreating 0 1s worker03 pod/nginx-deployment-5fbf59df75-fwqpn 1/1 Running 0 3s 10.244.1.10 worker01 pod/nginx-deployment-76fbb7bd7b-9rhdr 1/1 Running 0 114m 10.244.2.9 worker02 pod/nginx-deployment-76fbb7bd7b-kdsfl 1/1 Running 0 114m 10.244.3.9 worker03 pod/nginx-deployment-76fbb7bd7b-x566n 1/1 Terminating 0 114m 10.244.1.9 worker01 k8s Clusterの状態 Podの削除と新規作成が 順次行われる imageを変更してデプロイ “1.7.9” -> “1.12” spec: containers: - name: nginx1 image: nginx:1.12 新しいReplicaSetが作られる Deploymentの定義

Workloadの一覧 名前 略称 説明 Pod - コンテナのデプロイの最小単位 ReplicaSet rs デプロイしたPod数を維持するリソース Deployment deploy RollingUpdateするためにReplicaSetを管理するリソース DaemonSet ds 各Nodeに1個ずつPodをデプロイするリソース StatefulSet sts Statefulなコンテナのデプロイに対応したリソース Job - Job用のコンテナをデプロイするリソース CronJob - Jobをcron実行するリソース ：今日話す範囲

参考：WorkLoadのリソースの関係 Deployment CronJob ReplicaSet StatefulSet Pod DaemonSet Job Pod Pod Pod StatefulSetがReplicaSetを操作してたりするわけじゃない Kuberntes完全ガイド

Configuration

Workload Configuration Discovery & LB Deployment ReplicaSet Pod Service Secret ConfigMap k8s Cluster Namespace 今日話す基本的な構成要素の全体図

Configurationの一覧 名前 説明 Configmap 設定情報をkey-valueの形式で保持するリソース Sercret 機密情報を保持するリソース

ConfigMap • 設定情報をkey-valueの形式で保持するリソース • 作り方 – Manifestを書く – ファイルから作る (–frome-file,kustomize:configMapGenerator) • 使い方 – 環境変数とする – Volumeとしてマウントする apiVersion: v1 kind: Pod metadata: name: dapi-test-pod spec: containers: - name: test-container image: k8s.gcr.io/busybox command: [ "/bin/sh", "-c", "env" ] env: - name: SPECIAL_LEVEL_KEY valueFrom: configMapKeyRef: name: special-config key: special.how apiVersion: v1 kind: ConfigMap metadata: name: special-config namespace: default data: special.how: very ConfigMapの定義 Podの定義

Sercretの一覧 種類 説明 opaque Key-valueで機密情報を保持する kubernetes.io/service-account-token サービスアカウント用の機密情報を保持する kubernetes.io/dockerconfigjson Dockerレジストリ用の機密情報を保持する kubernetes.io/basic-auth Basic認証用の機密情報を保持する kubernetes.io/ssh-auth SSH用の機密情報を保持する kubernetes.io/tls TLS用の機密情報を保持する 参考< https://docs.koki.io/short/resources/secret/ > ：今日話す範囲

Sercret”Type:Opaque”について • Key-valueの形式で機密情報を保持する – 扱い方はConfigmap • Configmapと違い – 値がBASE64エンコードされる – ディスクではなく、tmpfsに配置される – リソースタイプがConfigmapではなくSecret

Sercret”Type:Opaque”について • 使う目的 – ID,Password等を格納する (例えばDBのアクセス用のとか) • 使い方 – secretに対して特定のユーザを除き”Get”、”List”の権限を与えない – Gitで管理するときにConfigmapとは管理方法を分ける Configmapとは別のリソースタイプなのでそれぞれ別の権限管理を 行えることに意味がある。 名前から受ける印象じゃなくて 仕様を理解して使うことが大事

Discovery & LB

Workload Configuration Discovery & LB Deployment ReplicaSet Pod Service Secret ConfigMap k8s Cluster Namespace 今日話す基本的な構成要素の全体図

ClusterIP コンテナ B Pod ClusterIP コンテナA Pod コンテナ B Pod コンテナ B Pod LBされる 10.244.1.10 10.244.1.10 Service名で アクセスする 10.244.2.10 10.244.3.10 アプリがDBにアクセスするときもよく使う • クラスタ内のアクセスを保証する – クラスタ内のPodへアクセスをLBする – Service名で名前解決してクラスタ内のPodへアクセスする LabelとSelectorの仕組みにより IPアドレスの管理から解放される

NodePort • クラスタ外からクラスタのPortを指定してアクセスする – クラスタの全てのNodeの特定のPortへのアクセスをPodへ保証する

Serviceのデプロイ kubectl get svc,po -o wide NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR service/svc-sample NodePort 10.110.100.22 8080:31706/TCP 17s app=nginx NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod/nginx-deployment-5fbf59df75-55j5b 1/1 Running 0 83m 10.244.3.10 worker03 pod/nginx-deployment-5fbf59df75-6hnbq 1/1 Running 0 83m 10.244.2.10 worker02 pod/nginx-deployment-5fbf59df75-fwqpn 1/1 Running 0 83m 10.244.1.10 worker01 NodePortをデプロイする apiVersion: v1 kind: Servicemetadata: name: svc-sample spec: type: NodePort ports: - name: "http-port“ protocol: "TCP“ port: 8080 targetPort: 80 selector: app: nginx NodePortが確認できる NodePortでも ClusterIPが付与される

Describeで、より詳細を見てみる kubectl describe svc svc-sample Name: svc-sample Namespace: default Labels: Annotations: kubectl.kubernetes.io/last-applied-configuration: {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"name":"svc-sample","namespace":"defaultSelector: app=nginxType: NodePortIP: 10.110.100.22 Port: http-port 8080/TCP TargetPort: 80/TCP NodePort: http-port 31706/TCP Endpoints: 10.244.1.10:80,10.244.2.10:80,10.244.3.10:80 Session Affinity: None External Traffic Policy: Cluster Events: k8s Clusterの状態 ServiceとPodが対応してることがわかる kubectl get po -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod/nginx-deployment-5fbf59df75-55j5b 1/1 Running 0 83m 10.244.3.10 worker03 pod/nginx-deployment-5fbf59df75-6hnbq 1/1 Running 0 83m 10.244.2.10 worker02 pod/nginx-deployment-5fbf59df75-fwqpn 1/1 Running 0 83m 10.244.1.10 worker01 NodePortが確認できる

kubeadm config view kubeadm config view apiServer: extraArgs: authorization-mode: Node,RBAC timeoutForControlPlane: 4m0s apiVersion: kubeadm.k8s.io/v1beta1 certificatesDir: /etc/kubernetes/pki clusterName: kubernetescontrolPlane Endpoint: "“ controllerManager: {} dns: type: CoreDNSetcd: local: dataDir: /var/lib/etcdimageRepository: k8s.gcr.io kind: ClusterConfiguration kubernetesVersion: v1.13.4 networking: dnsDomain: cluster.local podSubnet: 10.244.0.0/16 serviceSubnet: 10.96.0.0/12 scheduler: {} k8s Clusterの状態 PodとServiceはNWが別

Metadata

Workload Configuration Discovery & LB Deployment ReplicaSet Pod Service Secret ConfigMap k8s Cluster Namespace 今日話す基本的な構成要素の全体図

Namespace • 1つのクラスタの中を仮想のクラスタで分けることができる • 使い方 – 商用、検証、開発環境で1つのクラスタの中で分ける – 開発チーム単位で分ける – あるプロダクト単位で分ける – etc Namespace単位で分けてもクラスタ全体に対する障害については影響を受ける 爆発半径はクラスタ単位で分けた方が小さいが、クラスタ管理コストが増える傾向にある

Workload Configuration Discovery & LB Deployment ReplicaSet Pod Service Secret ConfigMap k8s Cluster Namespace 今日話す基本的な構成要素の全体図(復習)

kubectl

Manifestを中心にしたオペレーション apiVersion: v1 kind: Servicemetadata: name: svc-sample spec: type: NodePort ports: - name: "http-port“ protocol: "TCP“ port: 8080 targetPort: 80 selector: app: nginx Kubectl API Server k8s Cluster • 基本的にManifestを作成してk8sを操作する – 他のやり方も可能だが状態が観測できなくなる – git等でManifestを管理することでk8sの状態を把握しやすくなる

よく使うkubectlコマンド 種類 説明 kubectl apply リソースを作成する kubectl delete リソースを削除する kubectl get Node pod などのリソースの情報を取得 kubectl describe リソースの詳細情報を取得 kubectl logs コンテナのログを確認する kubectl exec コンテナでコマンドを実行する

参考：書籍 しくみがわかるKuberntes Kubernetes実践入門 Mnaging Kubernetes Kuberntes完全ガイド