Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

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

とことんDevOps

December 08, 2022
Tweet

More Decks by とことんDevOps

Other Decks in Technology

Transcript

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

    View Slide

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

    View Slide

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

    View Slide

  4. Kubernetesとは
    4

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  18. Kubernetesのしくみ
    18

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  23. 23
    kubec
    tl

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  28. Podのマニフェスト
    28

    View Slide

  29. 29

    View Slide

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

    View Slide

  31. ReplicaSetのマニフェスト
    31

    View Slide

  32. 32

    View Slide

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

    View Slide

  34. 34

    View Slide

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

    View Slide

  36. 36

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  40. Deploymentのマニフェスト
    40

    View Slide

  41. 41

    View Slide

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

    View Slide

  43. 43

    View Slide

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

    View Slide

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

    View Slide

  46. ロールバックもできる
    46

    View Slide

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

    View Slide

  48. ClusterIP
    48

    View Slide

  49. NodePort
    49

    View Slide

  50. Serviceのマニフェスト
    50

    View Slide

  51. 51

    View Slide

  52. 52

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

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

    View Slide

  57. 57

    View Slide

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

    View Slide

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

    View Slide

  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”.

    View Slide