Kubernetes再入門 - K8s活用するならこれだけは知っておきたいこと -

by とことんDevOps

Slide 1

Slide 1 text

Kubernetes再⼊⾨ - K8s活⽤するならこれだけは知っておきたいこと - 日本仮想化技術株式会社 [email protected] 2022/12/7 1

Slide 2

Slide 2 text

⾃⼰紹介 • 名前：⽥中智明（たなかともあき） • 出⾝：北海道 • 仕事： • Ops案件 • 技術検証 • 技術ブログ執筆 https://tech.virtualtech.jp/ https://devops-blog.virtualtech.jp/ • 勉強会登壇 2 はてなID: tnktmak

Slide 3

Slide 3 text

アジェンダ • Kubernetesとは • どういうツール？ • どうして使うの？ • Kubernetesのしくみ • コンポーネント • コンテナの管理 3

Slide 4

Slide 4 text

Kubernetesとは 4

Slide 5

Slide 5 text

どういうツール？ • 「クバネティス」「クーベネティス」「クバネテス」と読む • 省略して「K8s」と書く • Kubernetesの先頭の“K”と末尾の“s”の間が8⽂字(ubernete)で“K + 8⽂字 + s” • 読みは「ケーエイツ」「ケーエイトエス」「クバネティス」 • コンテナの運⽤を⽀援してくれるコンテナオーケストレーションツール • オーケストレーションは運⽤管理の⾃動化 • 2013年にGoogleのエンジニアによって設計開発を開始 • Googleが社内で⻑年使っていたBorgの機能をOSS化するため • Borgから⼤きな影響を受けている 5

Slide 6

Slide 6 text

どういうツール？ • 2014年にオープンソース化 • 2015年にはLinux FoundationとGoogleでCloud Native Computing Foundation(CNCF)を設⽴しKubernetesを寄贈 • Google, Microsoft, AWS, Red Hatなどが⽀援 • コンテナオーケストレーションのデファクトスタンダード 6

Slide 7

Slide 7 text

どうして使うの？過去を振り返ってKubernetesの何がいいのかを考える 7

Slide 8

Slide 8 text

8 https://kubernetes.io/ja/docs/concepts/overview/what-is-kubernetes/ より

Slide 9

Slide 9 text

仮想化ができる前の時代におけるデプロイ (Traditional deployment) • 物理サーバー上で複数のアプリケーションを直接実⾏していた • リソースの割当に問題があった • 1つのアプリケーションがリソースの⼤半を消費した時に、他のアプリケーションにも影響が出てしまう • 解決策としては、それぞれのアプリケーションを別々のサーバーで稼働させる • リソースを⼗分に活⽤できない • 物理サーバーを調達するには時間がかかる • 物理サーバーを増やすと費⽤がかかる 9

Slide 10

Slide 10 text

仮想化を使ったデプロイ (Virtualized deployment) • 1台の物理サーバーで複数の仮想マシン(VM)を実⾏する • 仮想化によってアプリケーションはVM毎に隔離される • 他アプリケーションからの影響を受けづらい • 物理サーバー内のリソース使⽤率が向上した • 空きリソースがあればアプリケーションをデプロイできる • アプリケーション追加が容易になった • VM毎に完全なOSを起動している • リソース消費が多い 10

Slide 11

Slide 11 text

コンテナを使ったデプロイ (Container deployment) • コンテナランタイム上で実⾏する • コンテナはホストマシンとKernelを共有している • コンテナイメージにKernelを含める必要がないのでイメージが軽量 • コンテナ実⾏時にOSのプロビジョニングがないので起動がはやい • OSの設定が不要なので、開発者はアプリケーションに集中できる • コード、ライブラリ、フレームワークなど、依存関係のあるものをパッケージング • ローカルや本番で同じように動作 • デプロイが容易になる 11

Slide 12

Slide 12 text

コンテナ化だけでは解決しない課題 • 本番のように⾼可⽤性を求められる環境では様々な要求がでてくる • 複数サーバーで複数のコンテナをダウンタイムなしに管理 • コンテナ毎にリソース割り当てを制御 • 複数コンテナへの負荷分散、⾃動的なスケールイン、アウト • コンテナがダウンした時の⾃動リカバリー • ワークフローの複雑さからコンテナを運⽤するためのツールが必要になる 12

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Kubernetesが提供できるもの • サービスディスカバリーと負荷分散 Kubernetesは、DNS名または独⾃のIPアドレスを使ってコンテナを公開することができます。コンテナへのトラフィックが多い場合は、Kubernetesは負荷分散し、ネットワークトラフィックを振り分けることができるため、デプロイが安定します。 • ストレージオーケストレーション Kubernetesは、ローカルストレージやパブリッククラウドプロバイダーなど、選択したストレージシステムを⾃動でマウントすることができます。 • ⾃動化されたロールアウトとロールバック Kubernetesを使うとデプロイしたコンテナのあるべき状態を記述することができ、制御されたスピードで実際の状態をあるべき状態に変更することができます。例えば、アプリケーションのデプロイのために、新しいコンテナの作成や既存コンテナの削除、新しいコンテナにあらゆるリソースを適⽤する作業を、Kubernetesで⾃動化できます。 14 https://kubernetes.io/ja/docs/concepts/overview/what-is-kubernetes/ より

Slide 15

Slide 15 text

Kubernetesが提供できるもの • ⾃動ビンパッキングコンテナ化されたタスクを実⾏するノードのクラスターをKubernetesへ提供します。各コンテナがどれくらいCPUやメモリー(RAM)を必要とするのかをKubernetesに宣⾔することができます。Kubernetesはコンテナをノードにあわせて調整することができ、リソースを最⼤限に活⽤してくれます。 • ⾃⼰修復 Kubernetesは、処理が失敗したコンテナを再起動し、コンテナを⼊れ替え、定義したヘルスチェックに応答しないコンテナを強制終了します。処理の準備ができるまでは、クライアントに通知しません。 15 https://kubernetes.io/ja/docs/concepts/overview/what-is-kubernetes/ より

Slide 16

Slide 16 text

Kubernetesが提供できるもの • 機密情報と構成管理 Kubernetesは、パスワードやOAuthトークン、SSHキーのよう機密の情報を保持し、管理することができます。機密情報をデプロイし、コンテナイメージを再作成することなくアプリケーションの構成情報を更新することができます。スタック構成の中で機密情報を晒してしまうこともありません。Kubernetesは、パスワードやOAuthトークン、SSHキーのよう機密の情報を保持し、管理することができます。機密情報をデプロイし、コンテナイメージを再作成することなくアプリケーションの構成情報を更新することができます。スタック構成の中で機密情報を晒してしまうこともありません。 16

Slide 17

Slide 17 text

ここまでのまとめ • コンテナ技術は⼗分優れていて、軽量でデリバリーは⾼速、OSのプロビジョニングもないので起動もはやい、ポータビリティにも優れている • コンテナ化だけでは運⽤は楽にならない • ⾼可⽤性を求められる環境では要求められるワークフローが多く、複雑 • ⼈間の⼿には負えないのでKubernetesを使う 17

Slide 18

Slide 18 text

Kubernetesのしくみ 18

Slide 19

Slide 19 text

Kubernetesコンポーネント 19 https://kubernetes.io/ja/docs/concepts/overview/components/ より

Slide 20

Slide 20 text

コントロールプレーンコンポーネント • kube-apiserver • クラスタを操作するためのAPIを提供 • etcd • クラスター情報の保存場所 • kube-scheduler • Podがノードに割り当てられているか監視 • Podを稼働させるノードを選択 20

Slide 21

Slide 21 text

コントロールプレーンコンポーネント • kube-controller-manager • 複数のコントローラープロセスを実⾏ • ノードのダウンを検知 • 正しい数のPodが稼働しているか • ネットワークの設定 • デフォルトアカウント • APIアクセストークンの作成 • cloud-controller-manager • Kubernetesとクラウドの架け橋 21

Slide 22

Slide 22 text

ノードコンポーネント • kubelet • 各コンテナがPodで実⾏されていることを保証 • kube-proxy • ネットワークプロキシ • Podを公開する時に通信経路を確保 • コンテナランタイム • コンテナの実⾏を担当するソフトウェア • Docker, containerd, CRI-O • K8s v1.20からDockerランタイムは⾮推奨 • K8s v1.24でDockershimが削除された 22

Slide 23

Slide 23 text

23 kubec tl

Slide 24

Slide 24 text

コンテナの管理 • Kubernetesオブジェクトで⾏う • YAMLフォーマットで表現されている • クラスターの今の状態を表している • どのようなアプリケーションが、どのノードで稼働しているか • それらのアプリケーションから利⽤可能なリソース • アプリケーションがどのように振る舞うか • オブジェクトの操作はCLIクライアントの「kubectl」かクライアントライブラリから • YAMLフォーマットのマニフェストファイルを使⽤することもできる • ファイルに保存するとdiffを取れるので便利 • ファイルが残っていればシェルのヒストリーが⾶んでも再現可能 24

Slide 25

Slide 25 text

Kubernetesオブジェクト • オブジェクトには⾊々な種類がある • 基本的なKubernetesオブジェクト • Pod • Service • Volume • Namespace • Kubernetesのコントローラーに依存 • Deployment • DaemonSet • StatefulSet • ReplicaSet • Job • ちょっと特殊なカスタムリソース 25

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Pod • KubernetesではPodが最⼩のデプロイ単位 • 1つ、または複数のコンテナやストレージボリュームの集まり • コンテナの実⾏⽅法を指定 • 同じPodに含まれるコンテナは同じマシンで動く • Podを分けた場合はそれぞれ別マシンで動く可能性を考慮する 27

Slide 28

Slide 28 text

Podのマニフェスト 28

Slide 29

Slide 29 text

Slide 30

Slide 30 text

ReplicaSet • 指定されたレプリカ数のPodを稼働させる • template内に情報を元にPodを稼働させる • ReplicaSetを直接使うよりDeploymentを推奨 30

Slide 31

Slide 31 text

ReplicaSetのマニフェスト 31

Slide 32

Slide 32 text

Slide 33

Slide 33 text

コンテナバージョンを変えてみる 33

Slide 34

Slide 34 text

Slide 35

Slide 35 text

レプリカ数を変更してみる 35

Slide 36

Slide 36 text

Slide 37

Slide 37 text

spec.templateを変更するだけではだめ • ReplicaSetはspec.templateの変更を検知しない • replicasを変更するとspec.templateを元にPodを起動する • 既存のコンテナとイメージバージョンが違ってもお構いなし • ReqplicaSetはPod数は管理してくれるけど、Podの状態までは管理してくれない 37

Slide 38

Slide 38 text

⼿動でロールアウトするしかない 38

Slide 39

Slide 39 text

Deployment • ReplicaSetを管理 • Podの状態を更新するにはReplicaSetを作り直す必要がある • Deploymentはspec.templateを更新するとReplicaSetをロールアウトしてくれる 39

Slide 40

Slide 40 text

Deploymentのマニフェスト 40

Slide 41

Slide 41 text

Slide 42

Slide 42 text

コンテナバージョンを変えてみる 42

Slide 43

Slide 43 text

Slide 44

Slide 44 text

spec.templateを変更するとReplicaSetがロールアウトされた • DeploymentはPodの新しい状態を宣⾔することでReplicaSetをロールアウトする • 古いReplicaSetが残っているので、ロールバックも可能 44

Slide 45

Slide 45 text

ロールアウトのヒストリーにも残る 45

Slide 46

Slide 46 text

ロールバックもできる 46

Slide 47

Slide 47 text

Service • Podをネットワークサービスとして公開 • 公開⽅法は3つ • ClusterIP • クラスター内部のIPでServiceを公開 • クラスター内部からのみ疎通可能 • NodePort • 各NodeのIPで静的なNodePortで公開 • NodePortの転送先のClusterIPは⾃動的に作られる • LoadBalancer • クラウドプロバイダーのロードバランサーを使って公開 • LoadBalancerの転送先のNodePort、ClusterIPは⾃動的に作られる 47

Slide 48

Slide 48 text

ClusterIP 48

Slide 49

Slide 49 text

NodePort 49

Slide 50

Slide 50 text

Serviceのマニフェスト 50

Slide 51

Slide 51 text

Slide 52

Slide 52 text

Slide 53

Slide 53 text

ログを⾒ると交互にアクセスしてるのがわかる 53

Slide 54

Slide 54 text

ここまでのまとめ • Kubernetesは、1つ、または複数のControl Planeと複数のNodeの集まり • Kubernetesオブジェクトを作成することでコンテナを稼働させ、オブジェクトを参照することで現在のクラスターの状態を把握できる • 通信経路もKubernetesオブジェクトで管理されている • ReplicaSetを直接使うより、DeploymentでReplicaSetを管理するのがよい 54

Slide 55

Slide 55 text

参考資料 • Kubernetesの概要 https://kubernetes.io/ja/docs/concepts/overview/ • ⼊⾨ Kubernetes https://www.oreilly.co.jp/books/9784873118406/ • Kubernetes 誕⽣の物語 https://cloudplatform-jp.googleblog.com/2016/08/google-kubernetes.html • Kubernetes: The Documentary https://youtu.be/BE77h7dmoQU https://youtu.be/318elIq37PE 55

Slide 56

Slide 56 text

ご清聴ありがとうございました 56

Slide 57

Slide 57 text

Slide 58

Slide 58 text

⽇本仮想化技術株式会社概要 • 社名：⽇本仮想化技術株式会社 • 英語名：VirtualTech Japan Inc. • 設⽴：2006年12⽉ • 資本⾦：3,000万円 • 本社：東京都渋⾕区渋⾕1-8-1 • 取締役：宮原徹（代表取締役社⻑兼CEO）、伊藤宏通（取締役CTO） • スタッフ：11名（うち、8名が仮想化技術専⾨エンジニアです） • URL：http://VirtualTech.jp/ • 仮想化技術に関する研究および開発 • 仮想化技術に関する各種調査 • 仮想化技術に関連したソフトウェアの開発 • 仮想化技術を導⼊したシステムの構築 • OpenStackの導⼊⽀援・新規機能開発 58 ベンダーニュートラルな独⽴系仮想化技術のエキスパート集団会社概要

Slide 59

Slide 59 text

OpenStackへの取り組み • 通信事業社でのOpenStack基盤の検討⽀援および構築・運⽤ • NTTドコモ (2011年から技術評価を⽀援、商⽤利⽤に向けた検討・構築・運⽤を実施) • NTT⻄⽇本 (商⽤利⽤に向けた評価・検討の⽀援、プロジェクトマネージメント⽀援) • ⼤⼿通信事業社 (NFV基盤についての検証・評価⽀援) • ベアメタルOpenStackの開発 • 仮想環境と物理環境をOpenStackで⼀括管理 • 単⼀のイメージで仮想マシンと物理マシンの双⽅を起動可能 • 2013年4⽉リリースのGrizzlyで本体にマージ 59 会社概要

Slide 60

Slide 60 text

OpenStack Summitでの発表実績 60 2014/11 OpenStack Summit Paris We spoke the knowledge and tips when building and operating OpenStack Cloud on 100 Physical Servers. (Neutron HA, VXLAN performance,,,) 会社概要 2015/10 OpenStack Summit Tokyo We (NTT West, Canonical and VTJ) spoke ”Requirements for Providing Telecom Services on OpenStack-based Infrastructure”.