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

コンテナを利用したシステムでKubernetesを使用することが非常に多くなっています。しかし、他のシステムでも使ってたから使っている、標準だから使っているという人も少なくないと思います。

今回の勉強会では、そのような方に向けて、Kubernetesを使用する理由はなんなのか、どのような機能があるのか、どのような仕組みなのかといったKubernetes活用の土台となる部分を解説したいと思います。今までなんとなくで使っていたレベルからステップアップして、Kubernetes活用するための基礎知識を身につけましょう。

Transcript

1. Kubernetes再⼊⾨ - K8s活⽤するならこれだけは知っておきたいこと - 日本仮想化技術株式会社 ttanaka@VirtualTech.jp 2022/12/7 1
2. ⾃⼰紹介 • 名前：⽥中智明（たなか ともあき） • 出⾝：北海道 • 仕事： • Ops案件 • 技術検証 • 技術ブログ執筆 https://tech.virtualtech.jp/ https://devops-blog.virtualtech.jp/ • 勉強会登壇 2 はてなID: tnktmak
3. アジェンダ • Kubernetesとは • どういうツール？ • どうして使うの？ • Kubernetesのしくみ • コンポーネント • コンテナの管理 3
4. Kubernetesとは 4
5. どういうツール？ • 「クバネティス」「クーベネティス」「クバネテス」と読む • 省略して「K8s」と書く • Kubernetesの先頭の“K”と末尾の“s”の間が8⽂字(ubernete)で“K + 8⽂字 + s” • 読みは「ケーエイツ」「ケーエイトエス」「クバネティス」 • コンテナの運⽤を⽀援してくれるコンテナオーケストレーションツール • オーケストレーションは運⽤管理の⾃動化 • 2013年にGoogleのエンジニアによって設計開発を開始 • Googleが社内で⻑年使っていたBorgの機能をOSS化するため • Borgから⼤きな影響を受けている 5
6. どういうツール？ • 2014年にオープンソース化 • 2015年にはLinux FoundationとGoogleでCloud Native Computing Foundation(CNCF)を設 ⽴しKubernetesを寄贈 • Google, Microsoft, AWS, Red Hatなどが⽀援 • コンテナオーケストレーションのデファクトスタンダード 6
7. どうして使うの？ 過去を振り返ってKubernetesの何がいいのかを考える 7
8. 8 https://kubernetes.io/ja/docs/concepts/overview/what-is-kubernetes/ より
9. 仮想化ができる前の時代におけるデプロイ (Traditional deployment) • 物理サーバー上で複数のアプリケーションを直接実⾏していた • リソースの割当に問題があった • 1つのアプリケーションがリソースの⼤半を消費した時に、他のアプリケーションに も影響が出てしまう • 解決策としては、それぞれのアプリケーションを別々のサーバーで稼働させる • リソースを⼗分に活⽤できない • 物理サーバーを調達するには時間がかかる • 物理サーバーを増やすと費⽤がかかる 9
10. 仮想化を使ったデプロイ (Virtualized deployment) • 1台の物理サーバーで複数の仮想マシン(VM)を実⾏する • 仮想化によってアプリケーションはVM毎に隔離される • 他アプリケーションからの影響を受けづらい • 物理サーバー内のリソース使⽤率が向上した • 空きリソースがあればアプリケーションをデプロイできる • アプリケーション追加が容易になった • VM毎に完全なOSを起動している • リソース消費が多い 10
11. コンテナを使ったデプロイ (Container deployment) • コンテナランタイム上で実⾏する • コンテナはホストマシンとKernelを共有している • コンテナイメージにKernelを含める必要がないのでイメージが軽量 • コンテナ実⾏時にOSのプロビジョニングがないので起動がはやい • OSの設定が不要なので、開発者はアプリケーションに集中できる • コード、ライブラリ、フレームワークなど、依存関係のあるものをパッケージング • ローカルや本番で同じように動作 • デプロイが容易になる 11
12. コンテナ化だけでは解決しない課題 • 本番のように⾼可⽤性を求められる環境では様々な要求がでてくる • 複数サーバーで複数のコンテナをダウンタイムなしに管理 • コンテナ毎にリソース割り当てを制御 • 複数コンテナへの負荷分散、⾃動的なスケールイン、アウト • コンテナがダウンした時の⾃動リカバリー • ワークフローの複雑さからコンテナを運⽤するためのツールが必要になる 12
13. コンテナ化だけでは解決しない課題 • 本番のように⾼可⽤性を求められる環境では様々な要求がでてくる • 複数サーバーで複数のコンテナをダウンタイムなしに管理 • コンテナ毎にリソース割り当てを制御 • 複数コンテナへの負荷分散、⾃動的なスケールイン、アウト • コンテナがダウンした時の⾃動リカバリー • ワークフローの複雑さからコンテナを運⽤するためのツールが必要になる • これらを⾃動化してくれるのがKubernetes 13
14. Kubernetesが提供できるもの • サービスディスカバリーと負荷分散 Kubernetesは、DNS名または独⾃のIPアドレスを使ってコンテナを公開することができま す。コンテナへのトラフィックが多い場合は、Kubernetesは負荷分散し、ネットワークトラフ ィックを振り分けることができるため、デプロイが安定します。 • ストレージ オーケストレーション Kubernetesは、ローカルストレージやパブリッククラウドプロバイダーなど、選択したスト レージシステムを⾃動でマウントすることができます。 • ⾃動化されたロールアウトとロールバック Kubernetesを使うとデプロイしたコンテナのあるべき状態を記述することができ、制御され たスピードで実際の状態をあるべき状態に変更することができます。例えば、アプリケーショ ンのデプロイのために、新しいコンテナの作成や既存コンテナの削除、新しいコンテナにあら ゆるリソースを適⽤する作業を、Kubernetesで⾃動化できます。 14 https://kubernetes.io/ja/docs/concepts/overview/what-is-kubernetes/ より
15. Kubernetesが提供できるもの • ⾃動ビンパッキング コンテナ化されたタスクを実⾏するノードのクラスターをKubernetesへ提供します。 各コンテナがどれくらいCPUやメモリー(RAM)を必要とするのかをKubernetesに宣⾔す ることができます。Kubernetesはコンテナをノードにあわせて調整することができ、リ ソースを最⼤限に活⽤してくれます。 • ⾃⼰修復 Kubernetesは、処理が失敗したコンテナを再起動し、コンテナを⼊れ替え、定義した ヘルスチェックに応答しないコンテナを強制終了します。処理の準備ができるまでは、ク ライアントに通知しません。 15 https://kubernetes.io/ja/docs/concepts/overview/what-is-kubernetes/ より
16. Kubernetesが提供できるもの • 機密情報と構成管理 Kubernetesは、パスワードやOAuthトークン、SSHキーのよう機密の情報を保持し、管 理することができます。機密情報をデプロイし、コンテナイメージを再作成することなく アプリケーションの構成情報を更新することができます。スタック構成の中で機密情報を 晒してしまうこともありません。Kubernetesは、パスワードやOAuthトークン、SSHキー のよう機密の情報を保持し、管理することができます。機密情報をデプロイし、コンテナ イメージを再作成することなくアプリケーションの構成情報を更新することができます。 スタック構成の中で機密情報を晒してしまうこともありません。 16
17. ここまでのまとめ • コンテナ技術は⼗分優れていて、軽量でデリバリーは⾼速、OSのプロビジョニングもな いので起動もはやい、ポータビリティにも優れている • コンテナ化だけでは運⽤は楽にならない • ⾼可⽤性を求められる環境では要求められるワークフローが多く、複雑 • ⼈間の⼿には負えないのでKubernetesを使う 17
18. Kubernetesのしくみ 18
19. Kubernetesコンポーネント 19 https://kubernetes.io/ja/docs/concepts/overview/components/ より
20. コントロールプレーンコンポーネント • kube-apiserver • クラスタを操作するためのAPIを提供 • etcd • クラスター情報の保存場所 • kube-scheduler • Podがノードに割り当てられているか監視 • Podを稼働させるノードを選択 20
21. コントロールプレーンコンポーネント • kube-controller-manager • 複数のコントローラープロセスを実⾏ • ノードのダウンを検知 • 正しい数のPodが稼働しているか • ネットワークの設定 • デフォルトアカウント • APIアクセストークンの作成 • cloud-controller-manager • Kubernetesとクラウドの架け橋 21
22. ノードコンポーネント • kubelet • 各コンテナがPodで実⾏されていることを保証 • kube-proxy • ネットワークプロキシ • Podを公開する時に通信経路を確保 • コンテナランタイム • コンテナの実⾏を担当するソフトウェア • Docker, containerd, CRI-O • K8s v1.20からDockerランタイムは⾮推奨 • K8s v1.24でDockershimが削除された 22
23. 23 kubec tl
24. コンテナの管理 • Kubernetesオブジェクトで⾏う • YAMLフォーマットで表現されている • クラスターの今の状態を表している • どのようなアプリケーションが、どのノードで稼働しているか • それらのアプリケーションから利⽤可能なリソース • アプリケーションがどのように振る舞うか • オブジェクトの操作はCLIクライアントの「kubectl」かクライアントライブラリから • YAMLフォーマットのマニフェストファイルを使⽤することもできる • ファイルに保存するとdiffを取れるので便利 • ファイルが残っていればシェルのヒストリーが⾶んでも再現可能 24
25. Kubernetesオブジェクト • オブジェクトには⾊々な種類がある • 基本的なKubernetesオブジェクト • Pod • Service • Volume • Namespace • Kubernetesのコントローラーに依存 • Deployment • DaemonSet • StatefulSet • ReplicaSet • Job • ちょっと特殊なカスタムリソース 25
26. Kubernetesオブジェクト • オブジェクトには⾊々な種類がある • 基本的なKubernetesオブジェクト • Pod • Service • Volume • Namespace • Kubernetesのコントローラーに依存 • Deployment • DaemonSet • StatefulSet • ReplicaSet • Job • ちょっと特殊なカスタムリソース 26
27. Pod • KubernetesではPodが最⼩のデプロイ単位 • 1つ、または複数のコンテナやストレージボリュームの集まり • コンテナの実⾏⽅法を指定 • 同じPodに含まれるコンテナは同じマシンで動く • Podを分けた場合はそれぞれ別マシンで動く可能性を考慮する 27
28. Podのマニフェスト 28
30. ReplicaSet • 指定されたレプリカ数のPodを稼働させる • template内に情報を元にPodを稼働させる • ReplicaSetを直接使うよりDeploymentを推奨 30
31. ReplicaSetのマニフェスト 31
33. コンテナバージョンを変えてみる 33
35. レプリカ数を変更してみる 35
37. spec.templateを変更するだけではだめ • ReplicaSetはspec.templateの変更を検知しない • replicasを変更するとspec.templateを元にPodを起動する • 既存のコンテナとイメージバージョンが違ってもお構いなし • ReqplicaSetはPod数は管理してくれるけど、Podの状態までは管理してくれない 37
38. ⼿動でロールアウトするしかない 38
39. Deployment • ReplicaSetを管理 • Podの状態を更新するにはReplicaSetを作り直す必要がある • Deploymentはspec.templateを更新するとReplicaSetをロールアウトしてくれる 39
40. Deploymentのマニフェスト 40
42. コンテナバージョンを変えてみる 42
44. spec.templateを変更するとReplicaSetがロールアウトされた • DeploymentはPodの新しい状態を宣⾔することでReplicaSetをロールアウトする • 古いReplicaSetが残っているので、ロールバックも可能 44
45. ロールアウトのヒストリーにも残る 45
46. ロールバックもできる 46
47. Service • Podをネットワークサービスとして公開 • 公開⽅法は3つ • ClusterIP • クラスター内部のIPでServiceを公開 • クラスター内部からのみ疎通可能 • NodePort • 各NodeのIPで静的なNodePortで公開 • NodePortの転送先のClusterIPは⾃動的に作られる • LoadBalancer • クラウドプロバイダーのロードバランサーを使って公開 • LoadBalancerの転送先のNodePort、ClusterIPは⾃動的に作られる 47
48. ClusterIP 48
49. NodePort 49
50. Serviceのマニフェスト 50
53. ログを⾒ると交互にアクセスしてるのがわかる 53
54. ここまでのまとめ • Kubernetesは、1つ、または複数のControl Planeと複数のNodeの集まり • Kubernetesオブジェクトを作成することでコンテナを稼働させ、オブジェクトを参照す ることで現在のクラスターの状態を把握できる • 通信経路もKubernetesオブジェクトで管理されている • ReplicaSetを直接使うより、DeploymentでReplicaSetを管理するのがよい 54
55. 参考資料 • 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
56. ご清聴ありがとうございました 56
58. ⽇本仮想化技術株式会社 概要 • 社名：⽇本仮想化技術株式会社 • 英語名：VirtualTech Japan Inc. • 設⽴：2006年12⽉ • 資本⾦：3,000万円 • 本社：東京都渋⾕区渋⾕1-8-1 • 取締役：宮原 徹（代表取締役社⻑兼CEO）、伊藤 宏通（取締役CTO） • スタッフ：11名（うち、8名が仮想化技術専⾨エンジニアです） • URL：http://VirtualTech.jp/ • 仮想化技術に関する研究および開発 • 仮想化技術に関する各種調査 • 仮想化技術に関連したソフトウェアの開発 • 仮想化技術を導⼊したシステムの構築 • OpenStackの導⼊⽀援・新規機能開発 58 ベンダーニュートラルな 独⽴系仮想化技術の エキスパート集団 会社概要
59. OpenStackへの取り組み • 通信事業社でのOpenStack基盤の検討⽀援および構築・運⽤ • NTTドコモ (2011年から技術評価を⽀援、商⽤利⽤に向けた検討・構 築・運⽤を実施) • NTT⻄⽇本 (商⽤利⽤に向けた評価・検討の⽀援、プロジェクトマネ ージメント⽀援) • ⼤⼿通信事業社 (NFV基盤についての検証・評価⽀援) • ベアメタルOpenStackの開発 • 仮想環境と物理環境をOpenStackで⼀括管理 • 単⼀のイメージで仮想マシンと物理マシンの双⽅を起動可能 • 2013年4⽉リリースのGrizzlyで本体にマージ 59 会社概要
60. 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”.