calicoネットワークモデルにおけるルーティング原理

7179 ワード

calicoの導入
1、ダウンロードテンプレートwget https://docs.projectcalico.org/v3.1/getting-started/kubernetes/installation/hosted/kubeadm/1.7/calico.yamlcalicoの公式提供v 3を得ることができます.1バージョンcalicoの配置テンプレート(kubeadmベース).もちろん中にはコミュニティのミラーが入っています.ローカルミラーに置き換えることができます.網易雲の光景センターにダウンロードすることをお勧めします.他の多くの国内の鏡像倉庫はメンテナンスをしません.
2、ip-ipのオン/オフ
現在、公式に提供されているテンプレートでは、デフォルトでip-ip機能が開き、nodeにデバイス:tunl 0が作成され、コンテナのネットワークデータがデバイスをカプセル化してipヘッダに転送されます.ここ、calico.yamlでcalico-nodeの環境変数を変更する:CALICO_IPV4POOL_IPIPはipip機能を実現するためのスイッチです:デフォルトはAlwaysで、オンを表します;Offはipipをオフにすることを示します.cross-subnetは、クロスサブネットを開いてサポートすることを示しており、現在はこのタイプは使用されていません.sed -i "s#Always#Off#g" calico.yaml
3、配置:
注意:配備前に、calico-nodeコンポーネントがnodeのIPを識別できるようにパラメータを構成するには、nodeに複数のNICがある可能性があります.公式に提供されたyamlファイルでは、ip識別ポリシー(IPDETECTMETHOD)が構成されていません.つまり、デフォルトはfirst-foundであり、ネットワーク異常なipがnodeIPとして登録され、node-to-node meshに影響を与えます.can-reachのポリシーに変更して、ReadyのnodeのIPに接続して、正しいIPを選択することができます.
便宜上、次のスクリプトでは、いずれかのnodeのipアドレスをreachアドレスとします.

connective_ip=`kubectl get node -o wide |grep Ready |head -n1 |awk '{print $6}'`
sed -i  -rn 'p;/name: IP/,/autodetect/H;/autodetect/{g;s/^
//;p}' calico.yaml 
sed -i '1,/name: IP/{s/name: IP/name: IP_AUTODETECTION_METHOD/}' calico.yaml
sed -i '1,/\"autodetect\"/{s/\"autodetect\"/can-reach=__ONE_CONNECTIVE_ENDPOINT__/}' calico.yaml
sed -i "s#__ONE_CONNECTIVE_ENDPOINT__#$connective_ip#g" calico.yaml

実行:kubectl apply -f calico.yaml4、calico使用中のその他の点

calicoがipipモードで配備されると、nodeにはtunl 0のNICデバイスがあります.これはipipがトンネルパッケージ用です.ノードをオフラインにすると、calicoコンテナが停止した後も、このデバイスはまだ存在し、rmmod ipipipコマンドを実行して削除できます(calico-nodeがまだ実行されている場合は、自動的に新しいものを再構築します)

calicoの導入が完了すると、calico-etcdコンテナ実行ノードの/var/etcd/calico-dataディレクトリにデータが記録され、クラスタ内のetcdデータを完全にクリーンアップするには、ディレクトリを削除する必要があります.

calicoはkubernetesをストレージバックエンドとしてサポートしています.このように配置すると、calicoはetcdを追加的に配置する必要はありません.データをCRDでk 8 sに保存します.calicoのコンポーネントはkubeconfigに依存してk 8 sと対話する.このモードでは、calicoの導入には

が必要です.

wget https://docs.projectcalico.org/v3.1/getting-started/kubernetes/installation/hosted/kubernetes-datastore/calico-networking/1.7/calico.yaml
wget https://docs.projectcalico.org/v3.1/getting-started/kubernetes/installation/hosted/rbac-kdd.yaml
kubectl apply -f rbac-kdd.yaml
kubectl apply -f calico.yaml

     calico.yaml               ipip、ip pool     。

calico bgpネットワーク
bgp方式でcalicoを導入した後、クラスタにいくつかのpodを作成します.

root@k8s-calico1:~# pods 
NAMESPACE     NAME                                       READY     STATUS    RESTARTS   AGE       IP                NODE
huang1        huangtest-69d9fddd97-cbzbm                 1/1       Running   0          20m       192.168.211.1     k8s-calico4
huang1        huangtest-69d9fddd97-pbvvw                 1/1       Running   0          3m        192.168.210.194   k8s-calico3
huang2        hhh-6897d64fcd-4zph4                       1/1       Running   0          1d        192.168.97.2      k8s-calico2

k 8 s-calico 2というnodeで見てみましょう.ip rを実行し、このnodeのルーティングでは、次の点に注目する必要があります.

192.168.97.2 dev calic285cddbb40 scope link 
blackhole 192.168.97.0/26 proto bird 
192.168.210.192/26 via 10.173.32.26 dev eth0 proto bird 
192.168.211.0/26 via 10.173.32.25 dev eth0 proto bird

192.168.97.2 dev calic285cddbb40 scope linkこのルーティングは、コンテナipへのリクエストをveth:calic 285 cddbb 40に導き、さらにリクエストをコンテナ内のネットワークカードに直通させる.blackhole 192.168.97.0/26 proto birdは、192.168.97.0/26セグメントに送信されたメッセージが破棄され、ソースに返信されないことを示す.このルーティングを構成する理由は、このマシン上のcalicoネットワークに割り当てられるcidrが192.168.97.0/26であり、コンテナ内で同じセグメントの他のIPにアクセスする場合、メッセージが外部に送信されないようにルーティングを構成するためである.最後の2つは,calicoネットワークのあるセグメントにアクセスするには,対応するnode IPをゲートウェイとしてeth 0パケットを通過する必要があることをそれぞれ記録している.すなわち,この2つのルーティングにより,一部のネットワークセグメント(宛先IP)のパケットをeth 0を介して正しい場所に送信することができる.
pod hhh-6897d64fcd-4zph4のping huangtest-69d9fddd97-pbvvwの場合、流量はこのように移動します.
0、パケットのパッケージが完成し、src ip:192.168.97.2、destip:192.168.210.1941、コンテナにはeth 0ネットワークカードしかなく、コンテナにip rが見えるのはdefault **** dev eth0なので、流量はコンテナのeth 0を通じて送信される.2、容器カードの配置はvethpairによって作られている.つまり、容器の中でネットカードが発行したバッグは、ホストコンピュータ上でcalic285cddbb40デバイスに発行される.3、第2のステップを通じて、ネットワークメッセージはホストのネットワークの中で、ホストのルーティングの影響を受けて、192.168.210.192/26 via 10.173.32.26 dev eth0 proto birdこのルーティングはeth 0からデータを転送して、ルーティングの中で記録したゲートウェイに送ります:10.173.32.26(このip、pod huangtest-69d9fddd97-pbvvwの所在するnode:k 8 s-calico 3のip)4、10.173.32.26はnode:k 8 s-calico 3のeth 0のipで、パケットを受け取った後、機械自身のルーティングテーブルで合理的なルーティングを探していますが、もちろんこの場所にもルーティングがあります:192.168.210.194 dev calif6874dae1d2 scope link、そこでパケットは順調に対端に受信されます
calico ipipネットワーク
ip-ipモードでcalicoを導入し、既存のpodをすべて削除して再構築します.以下のようにします.

root@k8s-calico1:~# pods 
NAMESPACE     NAME                                       READY     STATUS             RESTARTS   AGE       IP                NODE
huang1        huangtest-69d9fddd97-2b8hr                 1/1       Running            0          1m        192.168.97.1      k8s-calico2
huang1        huangtest-69d9fddd97-npwzw                 1/1       Running            0          1m        192.168.210.65    k8s-calico4
huang2        hhh-6897d64fcd-kqsj4                       1/1       Running            0          10s       192.168.210.129   k8s-calico3

k 8 s-calico 2というnode上のルーティングを見てみましょう.同じように私たちが注目しなければならないルーティングは次のいくつかあります.

root@k8s-calico2:~# ip r  |grep bird
192.168.97.1 dev cali3683f65394b scope link
blackhole 192.168.97.0/26 proto bird 
192.168.110.64/26 via 10.173.32.24 dev tunl0 proto bird onlink 
192.168.210.64/26 via 10.173.32.25 dev tunl0 proto bird onlink 
192.168.210.128/26 via 10.173.32.26 dev tunl0 proto bird onlink

前の2つはもう言うまでもなく、私たちは最後の3つのルートを見て、実は彼らが説明した論理はBGPの2つと差がなくて、ネットカードがtunl 0に変わっただけです.
一例で説明するとpod huangtest-69d9fddd97-2b8hr ping hhh-6897d64fcd-kqsj40、パッケージメッセージ、SRCIP:192.168.97.1 DESTIP:192.168.210.1291、コンテナにはeth 0ネットワークカードしかなく、コンテナにip rが見えるのはdefault **** dev eth0なので、トラフィックはコンテナのeth 0を通じて送信されます.2、容器カードの配置はvethpairによって作られている.つまり、容器の中でネットカードが発行したバッグは、ホストコンピュータ上でcalic285cddbb40デバイスに発行される.3、第2のステップを通じて、ネットワークメッセージはホストのネットワークの中にあり、ホストのルーティングの影響を受けて、192.168.210.128/26 via 10.173.32.26 dev tunl0 proto bird onlink は一致する対端IPを識別し、メッセージをtunl 0から10.173.32.26に送信する.ここで、tunl 0はメッセージをカプセル化し、既存のipメッセージの上にipヘッダをカプセル化し、新しいヘッダでは、src ipはホスト自身のip:10.173.32.23、destipは対端のipアドレス:10.173.32.26である.tcpdumpパッケージをキャプチャすることで、この手順を見ることができます.パッケージの前に:
パッケージング後(出力内容の末尾にipip-proto-4があることに注意):
4、シンクホストにはethの物理マシンネットワークカードが1つしかないため、トラフィックは結局eth 0から10.173.32.26まで外部に送信される.10.173.32.26このノードのeth 0ネットワークカードは、メッセージを受け取った後、ipipipプロトコルのタグ(第3ステップでtcpdumpパケットで見たipip-proto-4)が付いていることを発見し、ipipヘッダを解き、実際のメッセージに処理した.5、シンクホスト上の192.168.210.129 dev cali5ce61eb6bc2 scope linkというルーティングはvethpairにパケットを送信し、コンテナ内のeth 0によって受信される.6、icmp応答パケットの向きは、上述した向きと論理的に同じである.
保留中:ipipとbgpの使用シーンを補充します.およびcalicoのBGPルーティング構成方法(AS,node-mesh)

標準IOとlinuxシステムIOのバッファ問題

kubernetes yamlファイル解析