Kubernetesの基礎.pdf

Transcript

1. ç Kubernetes基礎 NTT Tech Conference#4 @yosshi_

2. • 吉村 翔太 • NTTコミュニケーションズ所属 • データサイエンスチーム • インフラエンジニア/データエンジニアリング •

   Kubernetes 、Prometheus　 etc • 登壇 CNDT “Kubernetes Logging入門” etc • コミュニティ活動 “Cloud Native Developers JP” @yosshi_ 自己紹介 “Prometheus Meetup Tokyo”

3. 今日話す内容 • Kubernetesの全体像 – Cluster – kubectl • 基本的な構成要素 –

   Workload – Configuration – Discovery & LB – Metadata • kubectlによるオペレーション – Manifestを中心にしたオペレーション – よく使うkubectl

4. Kubernetesの全体像

5. 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の状態に応じてアクションする

6. Infrastructure components • Master – k8sを管理するコンポーネントが配置されるサーバ群 • Node – コンテナが配置されるサーバ群

   • etcd cluster – コンテナが配置されるサーバ群高信頼性KVS、k8sのデータが保存される

7. Master components • API Server – etcdへのwrite、readを行うAPIサーバ – 複数台配置して冗長化構成をとることができる •

   Controller Manager – デプロイするコンテナの個数等を管理する – 複数台配置できるがリーダは1つだけ • Scheduler – コンテナをどのNodeにデプロイするか決める – 複数台配置できるがリーダは1つだけ

8. Node components • Container runtime – 文字通りコンテナのランタイム – Docker以外を使用することもできる •

   Kubelet – Node上に配置されるエージェント – コンテナの起動停止等を行う • Kube-proxy – コンテナとの接続を保証するためにNodeのNWを管理する

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

10. 参考：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を管理するコンポーネントが配置されるサーバ群

11. 参考：Master Nodeの中身 Controller Manager Kubelet Container runtime API Server Scheduler

    Master Control Planeもコンテナだったりする

12. 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が 　 コンテナとして起動

13. 参考：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を読んでる

14. 参考：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を 起動することができる

15. 参考：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/ >

16. 参考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

17. 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が変更される

18. 参考：API Serverからetcdにいかない例外の4パターン • “/proxy” – API Serverとの間にproxyをはる • “/exec” –

    コンテナでコマンドで実行 • “/attach” – コンテナにattach • “/logs” – コンテナのログを取得 “logs”の場合の通信 Mnaging Kubernetes

19. 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 マネージドサービスを使うと 　　　　だけ考えれば良いことが多い オンプレミスだとこれら全てを理解して保証する必要がある

20. 基本的な構成要素

21. 構成要素の全体像 Resources mgt Network / exposition Configuration Storage IAM Pod

    generator Creates References Kubernetes Ressources Map 参考< https://github.com/kubernetes/community/tree/master/icons > ：今日話す範囲

22. 構成要素の全体像 Resources mgt Network / exposition Configuration Storage IAM Pod

    generator Creates References Kubernetes Ressources Map 参考< https://github.com/kubernetes/community/tree/master/icons > ：今日話す範囲 ① コンテナの制御 ② コンテナのConfig ③ NW ④ 仮想ク ラスタ 権限制御 ストレージ リソース制限

23. Workload Configuration Discovery & LB Deployment ReplicaSet Pod Service Secret

    ConfigMap k8s Cluster Namespace 今日話す基本的な構成要素の全体図

24. Workload

25. Workload Configuration Discovery & LB Deployment ReplicaSet Pod Service Secret

    ConfigMap k8s Cluster Namespace 今日話す基本的な構成要素の全体図

26. Workloadの一覧 名前 略称 説明 Pod - コンテナのデプロイの最小単位 ReplicaSet rs デプロイしたPod数を維持するリソース

    Deployment deploy RollingUpdateするためにReplicaSetを管理するリソース DaemonSet ds 各Nodeに1個ずつPodをデプロイするリソース StatefulSet sts Statefulなコンテナのデプロイに対応したリソース Job - Job用のコンテナをデプロイするリソース CronJob - Jobをcron実行するリソース ：今日話す範囲

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

    Kubelet Kube-proxy node Kubelet Kube-proxy コンテナB コンテナA Pod 必ずPod単位でNodeにデプロイされる

28. 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 <none> <none> 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をデプロイすると

29. 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が制御する

30. 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 <none> <none> pod/nginx-deployment-76fbb7bd7b-kdsfl 1/1 Running 0 6s 10.244.3.9 worker03 <none> <none> pod/nginx-deployment-76fbb7bd7b-x566n 1/1 Running 0 6s 10.244.1.9 worker01 <none> <none> 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

31. Deployment(deploy) コンテナA Pod ReplicaSet 旧 コンテナA Pod コンテナA’ Pod ReplicaSet

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

32. 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 <none> worker03 <none> <none> pod/nginx-deployment-5fbf59df75-fwqpn 1/1 Running 0 3s 10.244.1.10 worker01 <none> <none> pod/nginx-deployment-76fbb7bd7b-9rhdr 1/1 Running 0 114m 10.244.2.9 worker02 <none> <none> pod/nginx-deployment-76fbb7bd7b-kdsfl 1/1 Running 0 114m 10.244.3.9 worker03 <none> <none> pod/nginx-deployment-76fbb7bd7b-x566n 1/1 Terminating 0 114m 10.244.1.9 worker01 <none> <none> k8s Clusterの状態 Podの削除と新規作成が 順次行われる imageを変更してデプロイ “1.7.9” -> “1.12” spec: containers: - name: nginx1 image: nginx:1.12 新しいReplicaSetが作られる Deploymentの定義

33. Workloadの一覧 名前 略称 説明 Pod - コンテナのデプロイの最小単位 ReplicaSet rs デプロイしたPod数を維持するリソース

    Deployment deploy RollingUpdateするためにReplicaSetを管理するリソース DaemonSet ds 各Nodeに1個ずつPodをデプロイするリソース StatefulSet sts Statefulなコンテナのデプロイに対応したリソース Job - Job用のコンテナをデプロイするリソース CronJob - Jobをcron実行するリソース ：今日話す範囲

34. 参考：WorkLoadのリソースの関係 Deployment CronJob ReplicaSet StatefulSet Pod DaemonSet Job Pod Pod

    Pod StatefulSetがReplicaSetを操作してたりするわけじゃない Kuberntes完全ガイド

35. Configuration

36. Workload Configuration Discovery & LB Deployment ReplicaSet Pod Service Secret

    ConfigMap k8s Cluster Namespace 今日話す基本的な構成要素の全体図

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

38. 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の定義

39. 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/ > ：今日話す範囲

40. Sercret”Type:Opaque”について • Key-valueの形式で機密情報を保持する – 扱い方はConfigmap • Configmapと違い – 値がBASE64エンコードされる –

    ディスクではなく、tmpfsに配置される – リソースタイプがConfigmapではなくSecret

41. Sercret”Type:Opaque”について • 使う目的 – ID,Password等を格納する (例えばDBのアクセス用のとか) • 使い方 – secretに対して特定のユーザを除き”Get”、”List”の権限を与えない

    – Gitで管理するときにConfigmapとは管理方法を分ける Configmapとは別のリソースタイプなのでそれぞれ別の権限管理を 行えることに意味がある。 名前から受ける印象じゃなくて 仕様を理解して使うことが大事

42. Discovery & LB

43. Workload Configuration Discovery & LB Deployment ReplicaSet Pod Service Secret

    ConfigMap k8s Cluster Namespace 今日話す基本的な構成要素の全体図

44. 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アドレスの管理から解放される

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

46. 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 <none> 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 <none> <none> pod/nginx-deployment-5fbf59df75-6hnbq 1/1 Running 0 83m 10.244.2.10 worker02 <none> <none> pod/nginx-deployment-5fbf59df75-fwqpn 1/1 Running 0 83m 10.244.1.10 worker01 <none> <none> 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が付与される

47. Describeで、より詳細を見てみる kubectl describe svc svc-sample Name: svc-sample Namespace: default Labels:

    <none> 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: <none> 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 <none> <none> pod/nginx-deployment-5fbf59df75-6hnbq 1/1 Running 0 83m 10.244.2.10 worker02 <none> <none> pod/nginx-deployment-5fbf59df75-fwqpn 1/1 Running 0 83m 10.244.1.10 worker01 <none> <none> NodePortが確認できる

48. 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が別

49. Metadata

50. Workload Configuration Discovery & LB Deployment ReplicaSet Pod Service Secret

    ConfigMap k8s Cluster Namespace 今日話す基本的な構成要素の全体図

51. Namespace • 1つのクラスタの中を仮想のクラスタで分けることができる • 使い方 – 商用、検証、開発環境で1つのクラスタの中で分ける – 開発チーム単位で分ける –

    あるプロダクト単位で分ける – etc Namespace単位で分けてもクラスタ全体に対する障害については影響を受ける 爆発半径はクラスタ単位で分けた方が小さいが、クラスタ管理コストが増える傾向にある

52. Workload Configuration Discovery & LB Deployment ReplicaSet Pod Service Secret

    ConfigMap k8s Cluster Namespace 今日話す基本的な構成要素の全体図(復習)

53. kubectl

54. 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の状態を把握しやすくなる

55. よく使うkubectlコマンド 種類 説明 kubectl apply リソースを作成する kubectl delete リソースを削除する kubectl

    get Node pod などのリソースの情報を取得 kubectl describe リソースの詳細情報を取得 kubectl logs コンテナのログを確認する kubectl exec コンテナでコマンドを実行する

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