序文
何かをするのは難しいことではありません。難しいのは継続することです。しばらく続けることは難しくありませんが、難しいのは最後まで続けることです。
記事タグの色の説明:
- 黄色:重要标题
- 赤: 結論を示すために使用されます
- 緑: 引数をマークするために使用されます
- 青: 引数をマークするために使用されます
最新のコンテナ化アプリケーションの世界では、コンテナ オーケストレーション プラットフォーム Kubernetes が標準になっています。 Kubernetes は分散システムであり、複雑なアプリケーションとマイクロサービス アーキテクチャをサポートするために、ネットワークは Kubernetes クラスターの不可欠な部分です。
コンテナ化されたアプリケーションを管理および調整できます。監視は、ユーザーがクラスターの健全性、パフォーマンス、可用性を理解するのに非常に重要な側面です。
この記事では、Kubernetesネットワークプラグインの「Antrea」プラグインについて詳しく紹介します。
この記事があなたに何かを得るだけでなく、楽しく学んでいただければ幸いです。ご提案がございましたら、メッセージを残してご連絡ください。
コラム紹介
これは、この記事が掲載されているコラムです。購読を歓迎します:【k8s の詳細な分析】コラム
このコラムの内容を簡単に紹介しましょう。
- 主に、誰もが k8s を完全にマスターできるように、各知識ポイントを詳細に分析します。
- これはカラム紹介記事のアドレスです:[K8S カラム紹介の詳細な分析]
1 基本的な紹介
Kubernetes では、ネットワーク プラグインはコンテナ ネットワーク インターフェイス (CNI) プラグインとも呼ばれ、コンテナ間の通信とネットワーク接続を実装するために使用されます。一般的な Kubernetes ネットワーク プラグインをいくつか示します。
Flannel: Flannel は、仮想ネットワーク オーバーレイ テクノロジ (オーバーレイ ネットワーク) を使用して、異なるノード上のコンテナを接続する一般的な CNI プラグインです。 Flannel は、VXLAN、UDP、Host-GW などのさまざまなバックエンド ドライバーをサポートしています。
Calico: Calico は、BGP プロトコルを使用してコンテナ間のルーティングを実装するオープンソース ネットワークおよびセキュリティ ソリューションです。 Calico は柔軟なネットワーク ポリシーとセキュリティ ルールをサポートしており、大規模な展開に使用できます。
Weave Net: Weave Net は、仮想ネットワーク デバイスとネットワーク プロキシを作成して、異なるノード上のコンテナを接続する軽量の CNI プラグインです。 Weave Net はオーバーレイ モードと直接接続モードをサポートし、柔軟性を提供します。
Cilium: Cilium は、Kubernetes 用の高性能ネットワークおよびセキュリティ ソリューションであり、eBPF (Extended Berkeley Packet Filter) テクノロジーを使用して、高速なコンテナ間通信とネットワーク ポリシーの実装を提供します。
Canal: Canal は、Calico と Flannel の機能を組み合わせた包括的な CNI プラグインです。 Calico のネットワーク ポリシーとセキュリティ機能を使用しながら、Flannel を使用してオーバーレイ ネットワークを提供できます。
Antrea: Antrea は、Open vSwitch に基づく CNI プラグインで、Kubernetes ネットワーキングとセキュリティ向けに設計されています。高性能のネットワーク接続とネットワーク ポリシー機能を提供します。
kube-router: kube-router は、ネットワーク プロキシ機能とサービス プロキシ機能を組み合わせたオープン ソース CNI プラグインです。 BGP および IPIP プロトコルをサポートし、負荷分散機能を備えています。
これらは Kubernetes ネットワーク プラグイン間で一般的なオプションの一部であり、それぞれに固有の利点と適用可能なシナリオがあります。適切なネットワーク プラグインの選択は、ニーズ、ネットワーク トポロジ、パフォーマンス要件などの要因によって異なります。
同時に、Kubernetes コミュニティは常に進化しており、変化するニーズに対応するために新しいネットワーク プラグインをリリースしています。
2 アントレアの紹介
Antrea は、高性能、ネットワーク ポリシー、可観測性の利点を備えた強力な K8s ネットワーク プラグインで、さまざまなサイズとニーズの K8s クラスターに適しています。
Antrea の中心となる概念、利点と欠点、使用シナリオ、インストール手順を深く理解することで、Antrea をより適切に活用して、コンテナ化されたアプリケーションを管理および保護できます。
2.1 概念の紹介
Antrea はオープンソースの K8s ネットワーク プラグインで、高性能、安全かつスケーラブルなネットワーク接続とネットワーク ポリシーを提供することを目的としています。 。 Antrea の中心となる概念は次のとおりです。
CNI プラグイン: Antrea はCNI (コンテナ ネットワーク インターフェイス) プラグインです。これは、K8s ネットワーク インターフェイスとクラスター内のコンテナーの通信の管理を担当します。 K8s ネットワーク モデルを実装し、コンテナが透過的に相互に通信できるようにします。
Open vSwitch (OVS): Antrea はOVS をデータ プレーンとして使用します。 -パフォーマンス ネットワーク データ パケットの転送を処理するために使用される仮想スイッチ。 OVS は、Antrea が高度なネットワーク機能を実装できるようにするプログラム可能なデータ プレーンを提供します。
ネットワーク ポリシー: Antrea は K8s ネットワーク ポリシーをサポートしており、管理者はどのコンテナと対話できるかを定義できます。他のコンテナが通信する内容、およびセキュリティがどのように実装されるか。これは、クラスター内のネットワークのセキュリティと分離を確保するのに役立ちます。
サービス プロキシ: Antrea は、K8s サービスが透過的に通信できるようにするサービス プロキシ機能も提供します。バックエンド Pod 通信では、Pod の IP アドレスを公開する必要はありません。
2.2 メリットとデメリット
アドバンテージ:
- 軽量: Antrea は非常に軽量になるように設計されており、占有リソースが少なく、システム パフォーマンスにほとんど影響を与えません。
- 設定が簡単: Antrea は、ユーザーがすぐに使い始めることができるように、シンプルで使いやすい設定ファイルを提供します。
- 高パフォーマンス: Antrea は効率的なデータ構造とアルゴリズムを使用して、優れたパフォーマンスを保証します。
- 複数のプロトコルをサポート: Antrea は、さまざまなシナリオのニーズを満たすために、TCP や UDP などの複数のプロトコルをサポートします。
- スケーラビリティ: Antrea は、ユーザーの二次開発とカスタマイズを容易にする豊富な API を提供します。
- 可観測性: Calico に基づいた Antrea は、管理者がネットワーク状態をよりよく理解できるように、豊富なネットワーク可観測性を提供します。
欠点:
- 機能が制限されている: 他の成熟した k8s ネットワーク プラグインと比較すると、Antrea の機能は比較的少なく、一部の複雑なシナリオのニーズを満たせない場合があります。
- 限定的なコミュニティ サポート : Antrea は比較的新しいため、コミュニティ サポートとドキュメントが他の成熟したプラグインほど充実していない可能性があります。
複雑さ: Antrea は、特に高度なネットワーク戦略が必要な場合、初心者にとってセットアップと構成がやや複雑になる可能性があります。
OVS の依存関係: Antrea はデータ プレーンとして OVS に依存しているため、環境によってはさらに複雑になる可能性があります。
2.3 使用シナリオ
Antrea は次のシナリオに適しています。
- マイクロサービス アーキテクチャ: マイクロサービス アーキテクチャでは、サービス間の通信と負荷分散が非常に重要です。 Antrea は、サービスの自動検出と負荷分散を実現し、システムの拡張性と可用性を向上させるのに役立ちます。
- コンテナ化された展開: コンテナ化された展開のシナリオでは、ネットワーク プラグインは不可欠なコンポーネントです。 Antrea は、コンテナーが相互に通信し、外部ネットワークに接続するのに役立ちます。
- エッジ コンピューティング: エッジ コンピューティングのシナリオでは、サービスが広範囲に分散されているため、効率的な通信と負荷分散が必要です。 Antrea はこれらのニーズを満たし、エッジ ノードの使用率を向上させることができます。
大規模クラスタ:大規模な K8s クラスタで高性能のコンテナ通信を実現する必要がある場合、Antrea は最適です。選択。
ネットワーク ポリシー要件:正確なネットワーク ポリシー制御、セキュリティ、分離が必要なマルチテナント環境では、Antrea のネットワーク ポリシー機能が非常に役立ちます。 。
オブザーバビリティ要件:詳細な場合トラブルシューティングの目的とパフォーマンスの最適化のためにネットワークの監視とログが必要< /span>、Antrea はこれらの機能を提供します。
3 インストールと使用方法
Antrea プラグインをインストールするには、次の手順に従います。
Antrea YAML ファイルをダウンロード
YAMLファイルを編集する
YAMLファイルを適用する
インストールが完了するまで待ちます
ネットワークポリシーを構成する
テスト
3.1: Antrea YAML ファイルをダウンロードする
K8s クラスター内のマシンで次のコマンドを実行して、Antrea の YAML ファイルをダウンロードします。 YAML ファイルの最新バージョンは、Antrea の GitHub リポジトリから入手できます。
curl -O https://raw.githubusercontent.com/vmware-tanzu/antrea/main/build/yamls/antrea.yml
3.2: YAML ファイルの編集
ダウンロードした Antrea YAML ファイル (通常は
antrea.yml
という名前) を開き、クラスタの要件に従って編集します。このファイルはテキスト エディターを使用して開き、必要に応じて構成できます。以下に例を示します。
apiVersion: operator.antrea.io/v1alpha1
kind: AntreaCluster
metadata:
name: antrea-cluster
spec:
defaultAntreaAgent: {}
controller:
# Antrea控制器的配置选项
service:
type: LoadBalancer # 选择适合您集群的Service类型
networkPolicy:
enable: true # 启用网络策略
agent:
# Antrea代理的配置选项
logLevel: info # 设置日志级别
ovs:
bridgeName: br-int # 指定OVS的网桥名称
podCIDR: 192.168.0.0/16 # 指定Pod的CIDR范围
ファイル内の構成が K8s クラスター トポロジおよびネットワーク ポリシー要件と一致していることを確認してください。ファイルを保存して閉じます。
3.3: YAML ファイルを適用する
kubectl またはその他の K8s クラスター管理ツールを使用して、編集した YAML ファイルを K8s クラスターに適用します。次のコマンドを実行します。
kubectl apply -f antrea.yml
これにより、Antrea プラグインのインストールと構成プロセスが開始されます。
3.4: インストールが完了するまで待ちます
Antrea プラグインが自動的にインストールされ、K8s クラスターに設定されるまで、しばらく待ちます。次のコマンドを使用して、Antrea 関連の Pod が実行されているかどうかを確認できます。
kubectl get pods -n kube-system | grep antrea
関連するすべての Antrea Pod が「実行中」状態になると、インストールは完了です。
antrea-agent-74d2s 1/1 Running 4m
antrea-controller-9x6z2 1/1 Running 4m
3.5: ネットワークポリシーの構成
特定のニーズに基づいて、K8s ネットワーク ポリシーを使用してコンテナ間の通信ルールを定義します。ネットワーク ポリシー オブジェクトを作成および適用して、コンテナ間のトラフィックを制御できます。
3.6: テスト
最後に、K8s クラスター内のコンテナーがセキュリティと分離の要件を満たしながら、ネットワーク ポリシーに従って通信できることを確認します。いくつかのテスト アプリケーションを展開し、それらが定義されたネットワーク ポリシーに準拠していることを確認できます。
この例では、Nginx コンテナーをテスト アプリケーションとして使用し、それらの間の通信を制限します。
ステップ 1: ネームスペースを作成する
まず、テスト アプリケーションを分離するための新しい名前空間を作成します。
kubectl create namespace test-namespace
ステップ 2: 2 つの Nginx ポッドをデプロイする
2 つの Nginx ポッドを作成し、作成した名前空間にデプロイします。
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment-1
namespace: test-namespace
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment-2
namespace: test-namespace
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
上記の YAML ファイルを
nginx-deployment.yaml
として保存し、次のコマンドを使用してデプロイします。
kubectl apply -f nginx-deployment.yaml
ステップ 3: ネットワーク ポリシーを定義する
別のポッドからのトラフィックを制限するネットワーク ポリシーを作成します。
この例では、
nginx-deployment-1
のポッドがnginx-deployment-2
のポッドと通信できないようにします。
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-nginx-communication
namespace: test-namespace
spec:
podSelector:
matchLabels:
app: nginx
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
app: nginx
上記の YAML ファイルを
network-policy.yaml
として保存し、次のコマンドを使用してネットワーク ポリシーを作成します。
kubectl apply -f network-policy.yaml
ステップ 4: ネットワーク ポリシーをテストする
これで、
nginx-deployment-1
の Pod がnginx-deployment-2
の Pod と通信しないようにするネットワーク ポリシーを定義しました。これをテストするには、nginx-deployment-1
のポッドで次のコマンドを実行します。
# 创建一个临时Pod,用于测试通信
kubectl run -i --tty --rm debug --image=nginx --namespace=test-namespace
# 在临时Pod中尝试访问另一个Pod的IP地址
curl <IP_OF_NGINX_DEPLOYMENT_2_POD>
ネットワーク ポリシーが有効な場合、
nginx-deployment-1
のポッドがnginx-deployment-2
。
curl: (7) Failed to connect to <IP_OF_NGINX_DEPLOYMENT_2_POD> port 80: Connection timed out
この例を通じて、Kubernetes ネットワーク ポリシーを使用して、コンテナ間の通信がセキュリティと分離の要件を確実に満たすようにする方法を確認できます。
実際のニーズに応じて、特定のアプリケーションとセキュリティの要件を満たすために、より複雑なネットワーク ポリシーを定義できます。