Kubernetis メモ

Kubernetis 勉強会メモ

2023/02/23

  • 構成要素

  • ノード

    • application を実行しているマシン
      • 物理サーバーやマシン
    • 種類は以下二種
      • ワーカーノード
        • この中にコンテナがある
      • マスターノード
        • ワーカーノードを管理する役割

  • クラスター

    • マスターノードとワーカーノードを束ねているもの
    • 高可用性と負荷分散を実現するための構成
    • 高可用性
      • コンテナが壊れたら自動で再起動させたりする
    • 負荷分散
      • 特定ノードに処理が集中しないようにノード間で負荷分散する

  • コンポーネント

    • ノードの配下でははたらく特定の役割をするものくらいの認識(?)
      • etcd とか kubuapiserver が代表例

  • マスターノード

    • クラスタ内の ワーカーノード と Pod を管理する
    • マスターコンポーネント(マスタノードの中にあるコンポーネント)には以下のようなものがある。詳細は後述。
      • kube-apiserver
      • etcd
      • scheduler
      • Controller Manager
      • Cloud Controller Manager
    • それぞれのコンポーネントを別々のノードで起動させることもできる。
      • ただ可用性の観点からは少なくともメインのマスターコンポーネントは１個にまとめるのがベストプラクティス
    • kube-apiserver
      • クラスタ内のすべての操作の窓口になるマスターコンポネント。API機能のフロントエンド部分。
      • セキュリティの観点から外部からAPI呼べて大丈夫？
        • apiserverを経由する際に、認証認可の役割も備えている
        • かつ入力制御(?)の役割も担う
          • 具体例は？
        • 以上の認証認可、入力制御を突破しないと操作はできないのでOK
    • etcd
    • scheduler
      • Podの配置決めを行うコンポーネント
      • どのPodをどのノードに配置するか決める部分のみを担当する 
        * 実際のPod作成はこいつがするわけではない
      • 配置の決め方の例　-> 1つのPodに3つのノードを配置するとすると...
        • 配置方法は以下2種類
          • フィルタリング
            • そもそも要件を満たさないノードを除外する
            • 例: 4CPU のノードに 5CPUのPodを配置しようする
          • スコアリング
            • Podをノードに配置した時の残るリソース量が大きいものを優先する評価方式
    • Controller Manager
      • コンポーネントの状態を監視し、必要な対応を実行する
      • 例: ノードコントローラー *
      • 監視制御を全部まとめて管理するためのもの
    • Cloud Controller Manager
  • ワーカーノード
    • 実際に Pod を動作させるためのノード
    • Pod と ノードコンポーネントで構成される
    • ノードコンポーネント
      • kubelet, kube proxy など
    • kubelet
      • エージェントの役割をもつコンポーネント.Podの起動や管理を担う
        • 例:
          • ワーカノード自体の監視
          • ワーカノード内のPodの監視
          • コンテナランタイムの操作
        • ワーカーノード内部のリソースの監視や操作の窓口的な役割(?)
        • apiserver から指示をうけとって、結果のレポートを apiserver に返しているっぽい
    • kube proxy
      • ネットワーキングと負荷分散をサポートするコンポーネント
      • 内部的には iptables (Linuxの機能でファイやウォールやNAT機能をもっているもの)
    • コンテナランタイム
      • ワーカーノードでコンテナのイメージ取得から実行を行うもの
      • 2層に別れる
        • 高レベルランタイム
          • コンテナのイメージを取得し実行するコンテナ環境の設定をファイルの作成を行う
          • kubelet から呼び出される
        • 低レベルランタイム
          • 設定ファイルをもとに、コンテナ環境の作成
      • 様々な種類のソフトウェアがあり、それぞれ特徴がある
  • Ingress
    • クラスタ外部からクラスタ内に通信するためのURLを提供し、Serviceにロードバランシングするオブジェクト
      • 負荷分散, SSL/TLSの終端になる機能
    • 外部通信を制御する Ingress のおかげで外部クライアントは内部のことを気にせず、単一のURLをつかってサービスを利用できる
    • どこに配置されるものなのかはよくわからん。。。要調査
  • Manifest
    • リソース構成やコンテナイメージを yaml で形式で記述する
    • IaC を実際書く部分

  • Kubernetes の中で働くリソース

    • 特徴ごとに分類...
      • コンピュート
      • ストレージ
      • ネットワーク
      • アクセス制御
      • Pod設定
      • クラスタ設定

  • ラベルとセレクター

    • リソース数が増えれば増えるほど管理が大変になるのでそれを補助する機能がある
    • ラベル
      • Podなどのリソースをグループ化する
    • セレクター
      • グループ化された特定のリソースを使用する際に指定

  • Namespace

    • リソースを分離.独立しお互いの干渉を防ぐための linuxカーネル機能
    • 複数のワーカーノードを横断して kubernetes リソースの分離と独立が制御できる
    • デフォルトで以下３つの Namesapce が作成されている
      • defaut:
      • kubu-system:
      • kube-public:
    • 特に kubu-system は重要

  • Pod

    • kubernetes は各ノードに直接コンテナを起動するのではなく、Podという単位でコンテナを実行していく
    • 使い方の注意点
      • 1Pod1コンテナ 構成が一般的
      • ただ同一のボリュームをコンテナ間で共有したい場合は 1Podの中に複数のコンテナを起動させる

  • Replica Set

    • ノードやPodに障害が発生しても、Podをほかのノードに自動で配置しなおすことができる
      • セルフヒーリングという
    • セルフヒーリングの機能の一つ
    • 指定したPod数になっているかを監視する役割(?) 現状だとこれくらいの機能に見える
    • 後から指定したPod数の変更ができる

  • Deployment

    • Replica Set を管理して ローリングアップデートやロールバックを実現する
    • ちなみに管理している階層構造を整理すると
      • Depoyment が ReplicaSet を管理
      • ReplicaSet が Pod を管理
    • ローリングアップデート時に新しいレプリカセットも作成している
      • old用とnew用のレプリカセットを作って徐々

  • Service

    • クラスタ内外からのPodあての通信を仮想IPアドレスで振り分けてくれる
    • Serviceディスカバリー機能
      • Podが再配置しても通信の振り分け先のPodを検索判別してくれる昨日
      • DNSで名前解決したりする。ほかにも種類はある
    • 要はロードバランサーでどのPodに振り分けてるか管理してくれる
      • 背後のPodが死んでもServiceが一回受けてくれることで、背後のPodが死んで(オートヒーリングで復活して)IPが変わったとしても通信が継続できる
    • ターゲットとなる Pod は Service で定義するラベルとセレクターにより決められる
  • PVとPVC
  • configMap
    • Podの実行時に必要な環境変数、ぽーど番号などの構成要素をConfigMapから分離して保守するためのリソース
    • 上記の各種設定ファイルを保存する