Kubernetes でのネットワーキングのための Calico: 概要と少しの経験

この記事の目的は、Kubernetes でのネットワーキングとネットワーク ポリシーの管理の基本と、標準機能を拡張するサードパーティの Calico プラグインを読者に紹介することです。 その過程で、運用経験から得た実際の例を使用して、構成の容易さといくつかの機能をデモンストレーションします。

Kubernetes ネットワーク アプライアンスの簡単な紹介

Kubernetes クラスターはネットワークなしでは想像できません。 私たちはすでにその基本に関する資料を公開しています。Kubernetes のネットワーキングに関する図解ガイド"そして"セキュリティ専門家のための Kubernetes ネットワーク ポリシーの概要'。

この記事の文脈では、K8s 自体はコンテナーとノード間のネットワーク接続を担当しないことに注意することが重要です。このため、さまざまな CNI プラグイン (コンテナ ネットワーキング インターフェイス)。 このコンセプトについて詳しくは、 彼らも私に言いました.

たとえば、これらのプラグインの中で最も一般的なものは次のとおりです。 フランネル — 各ノードにブリッジを立ち上げ、それにサブネットを割り当てることにより、すべてのクラスター ノード間に完全なネットワーク接続を提供します。 ただし、完全で規制されていないアクセシビリティが常に有益であるとは限りません。 クラスター内で何らかの最小限の分離を提供するには、ファイアウォールの構成に介入する必要があります。 一般に、iptables は同じ CNI の制御下に置かれるため、サードパーティによる iptables への介入は誤って解釈されたり、完全に無視されたりする可能性があります。

また、Kubernetes クラスターでネットワーク ポリシー管理を組織化するための「すぐに使える」機能が提供されています。 ネットワークポリシーAPI。 選択された名前空間に分散されるこのリソースには、あるアプリケーションから別のアプリケーションへのアクセスを区別するルールが含まれる場合があります。 また、特定のポッド、環境 (名前空間)、または IP アドレスのブロック間のアクセスを構成することもできます。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

これは最も原始的な例ではありませんが、 公式ドキュメント これは、ネットワーク ポリシーがどのように機能するかのロジックを理解したいという欲求を完全に妨げる可能性があります。 ただし、ネットワーク ポリシーを使用してトラフィック フローを処理する基本原理と方法を理解しようと努めます...

論理的には、ポッドに入るトラフィック (イングレス) とポッドから発信されるトラフィック (イーグレス) の 2 種類のトラフィックが存在します。

実は政治は方向性によってこの２つに分けられます。

次に必須の属性はセレクターです。 ルールが適用される人。 これは、ポッド (またはポッドのグループ) または環境 (つまり、名前空間) です。 重要な詳細: これらのオブジェクトの両方のタイプにラベル (ラベル Kubernetes 用語で) - これらは政治家が操作するものです。

ある種のラベルで結合された有限数のセレクターに加えて、「すべてを許可/拒否/全員」のようなルールをさまざまなバリエーションで記述することができます。 この目的のために、フォームの構造が使用されます。

  podSelector: {}
  ingress: []
  policyTypes:
  - Ingress

— この例では、環境内のすべてのポッドが受信トラフィックからブロックされます。 逆の動作は、次の構成で実現できます。

  podSelector: {}
  ingress:
  - {}
  policyTypes:
  - Ingress

発信の場合も同様に:

  podSelector: {}
  policyTypes:
  - Egress

- オフにします。 含める内容は次のとおりです。

  podSelector: {}
  egress:
  - {}
  policyTypes:
  - Egress

クラスター用の CNI プラグインの選択に戻ると、次のことに注意してください。 すべてのネットワーク プラグインが NetworkPolicy をサポートしているわけではありません。 たとえば、前述の Flannel はネットワーク ポリシーの構成方法を知りません。 直接言われる 公式リポジトリにあります。 そこでは代替案、つまりオープンソースプロジェクトについても言及されています。 サラサこれにより、ネットワーク ポリシーの観点から Kubernetes API の標準セットが大幅に拡張されます。

Calico を知る: 理論

Calico プラグインは、Flannel (サブプロジェクト) と統合して使用できます。 運河)、または独立して、ネットワーク接続と可用性管理機能の両方をカバーします。

K8s の「ボックス化された」ソリューションと Calico の API セットを使用すると、どのような機会が得られますか?

NetworkPolicy に組み込まれているものは次のとおりです。

• 政治家は環境によって制限される。
• ポリシーはラベルでマークされたポッドに適用されます。
• ルールはポッド、環境、またはサブネットに適用できます。
• ルールには、プロトコル、名前付きポート仕様またはシンボリック ポート仕様を含めることができます。

Calico がこれらの関数を拡張する方法は次のとおりです。

• ポリシーは、ポッド、コンテナ、仮想マシン、インターフェイスなどの任意のオブジェクトに適用できます。
• ルールには特定のアクション (禁止、許可、ログ記録) を含めることができます。
• ルールのターゲットまたはソースには、ポート、ポートの範囲、プロトコル、HTTP または ICMP 属性、IP またはサブネット (第 4 世代または第 6 世代)、任意のセレクター (ノード、ホスト、環境) を指定できます。
• さらに、DNAT 設定とトラフィック転送ポリシーを使用して、トラフィックの通過を規制できます。

Calico リポジトリの GitHub への最初のコミットは 2016 年 XNUMX 月に遡り、その XNUMX 年後、プロジェクトは Kubernetes ネットワーク接続の組織化において主導的な地位を獲得しました。これは、たとえば、次の調査結果によって証明されています。 ニュースタックによる指揮:

K8 を使用した多くの大規模なマネージド ソリューション。 アマゾンEKS, Azure AKS, Google GKE などの人々がそれを使用することを推奨し始めました。

パフォーマンスに関しては、ここではすべてが素晴らしいです。 製品のテストにおいて、Calico 開発チームは、50000 秒あたり 500 コンテナの作成速度で 20 の物理ノード上で XNUMX を超えるコンテナを実行するという天文学的なパフォーマンスを実証しました。 スケーリングに関して問題は確認されませんでした。 このような結果 発表されました すでに最初のバージョンの発表の時点で。 スループットとリソース消費に焦点を当てた独立した調査でも、Calico のパフォーマンスが Flannel とほぼ同じであることが確認されています。 例えば:

プロジェクトは非常に迅速に開発されており、K8s、OpenShift、OpenStack で管理される一般的なソリューションでの作業をサポートしており、クラスターをデプロイするときに Calico を使用することが可能です。 キック、サービス メッシュ ネットワークの構築に関する参照があります (ここに例があります Istio と組み合わせて使用​​されます)。

キャリコと一緒に練習

バニラ Kubernetes を使用する一般的なケースでは、CNI のインストールは、ファイルを使用することになります。 calico.yaml, 公式ウェブサイトからダウンロードした、 с помощью kubectl apply -f.

原則として、プラグインの現在のバージョンは、Kubernetes の最新の 2 ～ 3 バージョンと互換性があります。古いバージョンでの動作はテストされておらず、保証されていません。 開発者によると、Calico は、iptables または IPVS 上で CentOS 3.10、Ubuntu 7、または Debian 16 を実行する 8 以降の Linux カーネル上で実行されます。

環境内での隔離

一般的な理解のために、Calico 表記のネットワーク ポリシーが標準のネットワーク ポリシーとどのように異なるのか、また、ルールを作成するアプローチによってルールの読みやすさと構成の柔軟性がどのように簡素化されるのかを理解するための簡単なケースを見てみましょう。

クラスターには 2 つの Web アプリケーション (Node.js と PHP) がデプロイされており、そのうちの XNUMX つは Redis を使用します。 Node.js との接続を維持しながら、PHP から Redis へのアクセスをブロックするには、次のポリシーを適用するだけです。

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-redis-nodejs
spec:
  podSelector:
    matchLabels:
      service: redis
  ingress:
  - from:
    - podSelector:
        matchLabels:
          service: nodejs
    ports:
    - protocol: TCP
      port: 6379

基本的に、Node.js から Redis ポートへの受信トラフィックを許可しました。 そして彼らは明らかに他に何も禁止していませんでした。 NetworkPolicy が表示されるとすぐに、特に指定されていない限り、その中で言及されているすべてのセレクターが分離され始めます。 ただし、分離ルールはセレクターでカバーされていない他のオブジェクトには適用されません。

例では、 apiVersion Kubernetes はすぐに使用できますが、使用を妨げるものはありません Calico 配信からの同じ名前のリソース。 ここの構文はより詳細であるため、上記の場合のルールを次の形式で書き直す必要があります。

apiVersion: crd.projectcalico.org/v1
kind: NetworkPolicy
metadata:
  name: allow-redis-nodejs
spec:
  selector: service == 'redis'
  ingress:
  - action: Allow
    protocol: TCP
    source:
      selector: service == 'nodejs'
    destination:
      ports:
      - 6379

通常の NetworkPolicy API を介したすべてのトラフィックを許可または拒否するための上記の構造には、理解したり覚えたりするのが難しい括弧を含む構造が含まれています。 Calico の場合、ファイアウォール ルールのロジックを逆に変更するには、次のように変更します。 action: Allow на action: Deny.

環境による隔離

ここで、アプリケーションが Prometheus で収集し、Grafana を使用してさらに分析するためのビジネス メトリクスを生成する状況を想像してください。 アップロードには機密データが含まれる場合がありますが、これもデフォルトで一般公開されます。 このデータを覗き見から隠しましょう:

Prometheus は、原則として、別のサービス環境に配置されます。この例では、次のような名前空間になります。

apiVersion: v1
kind: Namespace
metadata:
  labels:
    module: prometheus
  name: kube-prometheus

フィールド metadata.labels これは偶然ではありませんでした。 上記のように、 namespaceSelector （同様に podSelector) ラベルを使用して動作します。 したがって、特定のポート上のすべてのポッドからメトリクスを取得できるようにするには、何らかのラベルを追加して (または既存のラベルから取得して)、次のような構成を適用する必要があります。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-metrics-prom
spec:
  podSelector: {}
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          module: prometheus
    ports:
    - protocol: TCP
      port: 9100

Calico ポリシーを使用する場合、構文は次のようになります。

apiVersion: crd.projectcalico.org/v1
kind: NetworkPolicy
metadata:
  name: allow-metrics-prom
spec:
  ingress:
  - action: Allow
    protocol: TCP
    source:
      namespaceSelector: module == 'prometheus'
    destination:
      ports:
      - 9100

一般に、特定のニーズに合わせてこのような種類のポリシーを追加すると、クラスター内のアプリケーションの動作に対する悪意のある干渉または偶発的な干渉から保護できます。

Calico の作成者によると、ベスト プラクティスは「すべてをブロックし、必要なものを明示的に開く」アプローチです。 公式ドキュメント (他の人も同様のアプローチに従っています - 特に、 すでに言及した記事).

追加の Calico オブジェクトの使用

Calico API の拡張セットを通じて、ポッドに限定されないノードの可用性を調整できることを思い出してください。 次の例では、 GlobalNetworkPolicy クラスター内で ICMP リクエストを渡す機能は閉じられています (たとえば、ポッドからノード、ポッド間、またはノードから IP ポッドへの ping)。

apiVersion: crd.projectcalico.org/v1
kind: GlobalNetworkPolicy
metadata:
  name: block-icmp
spec:
  order: 200
  selector: all()
  types:
  - Ingress
  - Egress
  ingress:
  - action: Deny
    protocol: ICMP
  egress:
  - action: Deny
    protocol: ICMP

上記の場合でも、クラスター ノードが ICMP 経由で相互に「接続」することは可能です。 そしてこの問題は次のような方法で解決されます GlobalNetworkPolicy、エンティティに適用される HostEndpoint:

apiVersion: crd.projectcalico.org/v1
kind: GlobalNetworkPolicy
metadata:
  name: deny-icmp-kube-02
spec:
  selector: "role == 'k8s-node'"
  order: 0
  ingress:
  - action: Allow
    protocol: ICMP
  egress:
  - action: Allow
    protocol: ICMP
---
apiVersion: crd.projectcalico.org/v1
kind: HostEndpoint
metadata:
  name: kube-02-eth0
  labels:
    role: k8s-node
spec:
  interfaceName: eth0
  node: kube-02
  expectedIPs: ["192.168.2.2"]

VPN のケース

最後に、標準的なポリシー セットでは十分ではない場合に、クラスターに近い相互作用の場合に Calico 関数を使用する実際の例を示します。 Web アプリケーションにアクセスするために、クライアントは VPN トンネルを使用します。このアクセスは厳密に制御され、使用が許可されているサービスの特定のリストに制限されます。

クライアントは標準の UDP ポート 1194 経由で VPN に接続し、接続されると、ポッドとサービスのクラスター サブネットへのルートを受け取ります。 再起動やアドレス変更中にサービスが失われないように、サブネット全体がプッシュされます。

構成内のポートは標準であるため、アプリケーションを構成して Kubernetes クラスターに転送するプロセスに若干のニュアンスが生じます。 たとえば、同じ AWS で UDP 用の LoadBalancer が文字通り昨年末に限定されたリージョンのリストに登場しましたが、NodePort はすべてのクラスター ノードで転送するため使用できず、サーバー インスタンスの数をスケールすることは不可能です。耐障害性の目的。 さらに、デフォルトのポート範囲を変更する必要があります...

考えられる解決策を検討した結果、次のものが選択されました。

1. VPN を備えたポッドは、ノードごとにスケジュールされます。 hostNetworkつまり、実際の IP に送信されます。
2. サービスは次の方法で外部に掲示されます。 ClusterIP。 ポートはノードに物理的にインストールされており、マイナーな予約 (条件付きで実際の IP アドレスが存在する) を使用して外部からアクセスできます。
3. ポッドが上昇したノードを特定することは、この話の範囲を超えています。 十分な想像力がある人であれば、サービスをノードに配線することも、VPN サービスの現在の IP アドレスを監視し、クライアントに登録されている DNS レコードを編集する小さなサイドカー サービスを作成することもできるとだけ言っておきます。

ルーティングの観点から見ると、VPN サーバーによって発行された IP アドレスによって VPN クライアントを一意に識別できます。 以下は、上記の Redis で示されている、このようなクライアントのサービスへのアクセスを制限する基本的な例です。

apiVersion: crd.projectcalico.org/v1
kind: HostEndpoint
metadata:
  name: vpnclient-eth0
  labels:
    role: vpnclient
    environment: production
spec:
  interfaceName: "*"
  node: kube-02
  expectedIPs: ["172.176.176.2"]
---
apiVersion: crd.projectcalico.org/v1
kind: GlobalNetworkPolicy
metadata:
  name: vpn-rules
spec:
  selector: "role == 'vpnclient'"
  order: 0
  applyOnForward: true
  preDNAT: true
  ingress:
  - action: Deny
    protocol: TCP
    destination:
      ports: [6379]
  - action: Allow
    protocol: UDP
    destination:
      ports: [53, 67]

ここでは、ポート 6379 への接続は厳しく禁止されていますが、同時に DNS サービスの動作は維持され、ルールを作成する際にその機能が損なわれることがよくあります。 前述したように、セレクターが表示されると、特に指定しない限り、デフォルトの拒否ポリシーがセレクターに適用されるためです。

結果

したがって、Calico の高度な API を使用すると、クラスター内およびクラスター周辺のルーティングを柔軟に構成し、動的に変更できます。 一般に、その使用方法は大砲でスズメを撃つように見え、BGP および IP-IP トンネルを使用した L3 ネットワークの実装は、フラット ネットワーク上の単純な Kubernetes インストールでは巨大に見えます...しかし、それ以外の点では、このツールは非常に実行可能で便利に見えます。 。

セキュリティ要件を満たすためにクラスターを分離することは必ずしも実現可能であるとは限りません。この場合、Calico (または同様のソリューション) が役に立ちます。 この記事に記載されている例 (若干の変更を加えたもの) は、AWS のクライアントのいくつかのインストールで使用されています。

PS

私たちのブログもお読みください:

• «セキュリティ専門家のための Kubernetes ネットワーク ポリシーの概要";
• 「Kubernetes でのネットワークの図解ガイド」: パート 1 および 2 (ネットワーク モデル、オーバーレイ ネットワーク), パート 3 (サービスとトラフィック処理);
• «Container Networking Interface (CNI) - Linux コンテナのネットワーク インターフェイスおよび標準'。

出所： habr.com