kubestronautへの道 ~CKAD編 その3~

tech article

本記事の内容

前回に引き続いてUdemyのKubernetes Certified Application Developer (CKAD) with Testsというコースを受講していた中で気になったところをメモしていきます。

今回は以下のセクションに基づいています

#7 Service & Networking

service

Service
KubernetesにおけるServiceとは、 クラスター内で1つ以上のPodとして実行されているネットワークアプリケーションを公開する方法です。 Kubernetesでは、なじみのないサービスディスカバリーのメカニズムを使用するためにユーザーがアプリケーションの修正をする必要はありません。 KubernetesはP...
kubernetes.io

service自体が仮想IPを持っている。そのIPはサービスのClusterIPと呼ばれている。

serviceにはいくつかのタイプがあるが、メインとなる2つを紹介する。

ClusterIP

  • pod同士の通信のためのインターフェースとなる。
  • タイプを指定しない場合、serviceはClusterIPタイプとなる。

NodePort

  • クラスタ外からのトラフィックをpodに流すためのインターフェースとなる。
  • ワーカーノードのIP(パブリックなIP) とポート番号の組み合わせを、ClusterIP(プライベートなIP)とマッピングさせる。
    • https://<workerNode-ip>:<port>とserviceを紐づけているという感じ。

他にはLoadBalancerタイプ、ExternalNameタイプが存在する。

全てのServiceは以下の形式でDNSエントリを持つ。

<service-name>.<namespace-name>.svc.cluster.local

ingress

クラスター内のServiceに対する外部からのアクセス(主にHTTP)を管理するAPIオブジェクト。Ingressは負荷分散、SSL終端、名前ベースの仮想ホスティングの機能を提供する。

クラスターにデフォルトでは組み込まれていないので、ingress用のコントローラーを立てる必要がある

  • ingressコントローラ
    • deploymentとして定義される
    • ingressリソースを参照して、実際にトラフィックをルーティングする
    • ALBそのもの(を作り出すリソース？)みたいなもん
  • ingressリソース
    • ingressコントローラが参照するルール
    • ALBのリスナールールみたいなもん

ちなみに、namespaceを跨いでserviceにルーティングすることは可能であるが、ExternalNameタイプのserviceを使わなければならず大変なので、namespaceごとにingressを立てるのが良いとされている。（ingressリソースをapplyすれば勝手にロードバランサーが立つのかな？）

デフォルトのバックエンド

Ingress
FEATURE STATE: Kubernetes v1.19 クラスター内のServiceに対する外部からのアクセス(主にHTTP)を管理するAPIオブジェクトです。 Ingressは負荷分散、SSL終端、名前ベースの仮想ホスティングの機能を提供します。 用語 簡単のために、このガイドでは次の用語を定義します。 ノー...
kubernetes.io
  • 一致するルールがないトラフィックは単一のデフォルトのバックエンドに転送される。
    • .spec.defaultBackendに対象となるバックエンドを記述する。
  • kubectl describe ingress <-n namaspece>でdefault backendが<default>なら、ingress controllerで詳細を調べる。
  • defaultBackendは、Ingressコントローラーのオプション設定であり、Ingressリソースでは指定されていない。.spec.rulesを設定しない場合、.spec.defaultBackendの設定は必須。
    • defaultBackendが設定されていない場合、どのルールにもマッチしないリクエストの処理は、使用するIngressコントローラごとに異なる。

annotations

Ingressコントローラーに依存しているいくつかのオプションの設定をするためのフィールド。ingressリソースのマニフェストファイルに記述する。Ingressコントローラーの種類が異なれば、使用できるアノテーションも異なる。

例：rewrite-targetアノテーション
特定のパスをリライトするアノテーション。クライアントのリクエストパスを別のパスに変更し、バックエンドサービスが期待する形式でリクエストを受け取れるようにする。この機能は、パスの統一、パスの隠蔽、簡単なルーティングを実現するのに便利便利万歳。

以下の例では/testpathを/に変換してバックエンドに流している。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: minimal-ingress
#アノテーション
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx-example
  rules:
  - http:
      paths:
      - path: /testpath
        pathType: Prefix
        backend:
          service:
            name: test
            port:
              number: 80

network policy

ネットワークポリシー
IPアドレスまたはポートのレベル(OSI参照モデルのレイヤー3または4)でトラフィックフローを制御したい場合、クラスター内の特定のアプリケーションにKubernetesのネットワークポリシーを使用することを検討してください。ネットワークポリシーはアプリケーション中心の構造であり、Podがネットワークを介して多様な「エン...
kubernetes.io

network policyは、podが通信できるエンティティを制御するためのリソース。
デフォルト（＝network policyが適用されていないpod）はクラスター内の全てのpodと通信することが可能。

ingressのfromセクション, egressのtoセクション

離れていて少しわかりづらいが、from配列 + ports配列, もしくはto配列 + ports配列ひとかたまりで、ひとまとまりのポリシーとして扱う。
例えば、name=payrollのpodに対して8080ポートで、name=mysqlのpodに対して3306でアクセスできるようにしたいときは、以下のように設定する。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: internal-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
     name: internal
  policyTypes:
  - Egress
  egress:
  - to:
    - podSelector:
        matchLabels:
          name: payroll
    ports:
    - protocol: TCP
      port: 8080
  - to:
    - podSelector:
        matchLabels:
          name: mysql
    ports:
    - protocol: TCP
      port: 3306

ちなみにyamlの記法について。

  • ハイフンは配列の要素を示す
  • 連想配列はキーの後にコロンをつけ、コロンの後にスペースを入力するか、改行して行頭からキーまでのスペースの半角スペース+半角スペース2つ分開けて値を入力する
  • 同じ階層の要素を兄弟要素と呼ぶ（親子要素との対比で使う言葉？）

曖昧なまま使っていたが、特に2個目が全然わかってなかった。つまり、

example:
  key1: value1
  key2: value2

と

example:
  key1:
    value1
  key2:
    value2

は同じ意味ということ。

タイトルとURLをコピーしました