Amazon VPC CNI plugin for KubernetesのソースコードリーディングでEKSのネットワーキングについて理解を深める #1

はじめに

この記事はAmazon EKS Advent Calendar 2019 11日目の記事です。

1. Amazon VPC CNI plugin for KubernetesのソースコードリーディングでEKSのネットワーキングについて理解を深める #1 （イマココ）
2. Amazon VPC CNI plugin for KubernetesのソースコードリーディングでEKSのネットワーキングについて理解を深める #2
3. Amazon VPC CNI plugin for KubernetesのソースコードリーディングでEKSのネットワーキングについて理解を深める #3

巷ではEKSにNodeGroupを作成するAPIが追加されたり、FargateがGAになったりと新機能が話題ですが、
今回はそんな新機能には全く触れず、原点に立ち返って、EKSのネットワークの特徴でもある、Amazon VPC CNIプラグイン(amazon-vpc-cni-k8s)について見ていきたいと思います。

自分は長らくEKSでKubernetesを触っていましたが、正直ネットワーク周りをあまり理解していませんでした。
ただKubernetesを触る以上そろそろネットワークのこともちゃんと知っておかないとと思い、改めてEKSのネットワーキングについてまとめたいと思います。

また先に謝らせていただくと、長くなったので実際にソースコードを見ていくのは#2で行います。
CNIプラグインのソースコードまで目を通してみると、Operator SDKや自前のコントローラーがあったり、RWMutexでインメモリデータストアが実装されていたりなど、ネットワークだけでなく色々と発見があって面白いです。

そんな感じでまとまるか少々不安ですが、少しでもどなたかのご参考になれば幸いです。

Amazon VPC CNI pluginの概要

まずはEKSのドキュメントから。

ポッドネットワーキング (CNI)
https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/pod-networking.html

Amazon EKS は、Amazon VPC CNI plugin for Kubernetes を経由してネイティブな VPC ネットワーキングをサポートします。この CNI プラグインを使用すると、Kubernetes ポッドは VPC ネットワーク上と同じ IP アドレスをポッド内に持つことができます。この CNI プラグインは、GitHub で管理されているオープンソースのプロジェクトです。

正式名称は「Amazon VPC CNI plugin for Kubernetes」。
Githubのリポジトリはこちら→　https://github.com/aws/amazon-vpc-cni-k8s

Amazon VPC CNIプラグインはEKSのデフォルトCNIプラグインですが、EKS以外にも利用することが可能です。

Creating a single control-plane cluster with kubeadm
https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#tabs-pod-install-1

AWS VPC CNI provides native AWS VPC networking to Kubernetes clusters.

自分も一度kubeadmで構築したことがあります。以前はバグに当たったりなどHard wayな印象でしたが、EKSのネットワークに興味ある人は是非。

ただ、そんなところに興味もなかった昔の自分は、

「ENIのセカンダリIPなるものがPodに割り振られるらしい。だからクラスタ外からもPodのIPに直接繋がるらしい。」

そんな程度の理解でした。

ENIのセカンダリIPについて

ところでENIって意外と何者かわからなくないでしょうか(少なくとも自分はわかりませんでした)

しかもENIのセカンダリIPについては、特にネット上の情報が少ない印象です。

複数の IP アドレス
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/MultipleIP.html

ENIはEC2等にアタッチ可能な仮想ネットワークインターフェースです。実態はよく分かりませんが、MACアドレスを動的に割り当てる仕組みなのでしょうか。

ENIには複数のIPアドレスを割り当てることが可能で、１つのプライマリIPと、複数のセカンダリIPを持つことができます。

このようなENIの特徴のうち、Amazon VPC CNIプラグインにとって重要なことは、「ENIのセカンダリIPはEC2内で割り振り直すことができる」ということです。これを利用することで、VPCネイティブなPodネットワーキングを実現しています。

セカンダリプライベート IPv4 アドレスを認識するようにインスタンスのオペレーティングシステムを設定する
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/MultipleIP.html

セカンダリプライベート IPv4 アドレスをインスタンスに割り当てたら、セカンダリプライベート IP アドレスを認識するようにインスタンスのオペレーティングシステムを設定する必要があります。
ネットワークインターフェイスに割り当てられているセカンダリプライベート IPv4 アドレスは、明示的に許可された場合、別のネットワークインターフェイスに割り当て直すことができます。

ENIやセカンダリIPはEC2インスタンスタイプごとに割り当て可能な量に違いがあります。そのためEKSのノードで動かせるPod数は、CPUやメモリといったリソースのほかに、IPアドレス数の制限を受けます。

CNIプラグインのコンポーネント

次にCNIプラグインがどのような構成なのか見ていきます。
先ほどのEKSのドキュメントの続きをみます。

https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/pod-networking.html

CNI プラグインは、Kubernetes ノードに VPC IP アドレスを割り当て、各ノードのポッドに必要なネットワークを設定します。​このプラグインは 2 つの主なコンポーネントで構成されています。

• L-IPAM デーモンは、インスタンスへの Elastic Network Interface の接続、Elastic Network Interface へのセカンダリ IP アドレスの割り当て、スケジュールされた際に Kubernetes ポッドに割り当てるために各ノードにおける IP アドレスの「ウォームプール」の維持を行います。

• CNI プラグインは、ホストネットワークの接続 (例: インターフェイスと仮想イーサネットペアの設定) とポッド名前空間への正しいインターフェイスの追加を行います。

L-IPAMデーモン(Local IP Address Manager Daemon、ipamdとの記載もあります)は、各ノードでaws-nodeというdaemonsetのPodで起動します。L-IPAMは内部にデータストアをもち、IPアドレスの管理やPodへのアサインを行っています。gRPCサーバの機能ももち、CNIプラグインからのPodの追加／削除リクエストに応えます。

CNIプラグインは、その名の通り、CNIの仕様に沿って実行されるモジュールで、gRPCでL-IPAMと通信してIPを取得し、ネットワーク設定を行います。以下、公式のイメージを引用します。

Inter-process communication between CNI-plugin and L-IPAM
https://github.com/aws/amazon-vpc-cni-k8s/blob/master/docs/cni-proposal.md#inter-process-communication--between-cni-plugin-and-l-ipam

(Officeでちょろっと作ったような図ですよね・・・笑)

そもそもCNIって・・・という方には以下の記事が参考になります。

CNCF CNI プラグイン
https://qiita.com/hichihara/items/54ff9aeff476bf463509

EKSクラスター作成時の状態

それでは実際にEKSの状態を見ていきましょう。

クラスターの状態

まずはkubectlでクラスターの状態から。

$ kubectl get nodes
NAME                                               STATUS   ROLES    AGE   VERSION
ip-10-110-10-171.ap-northeast-1.compute.internal   Ready    <none>   8h    v1.14.7-eks-1861c5
ip-10-110-10-233.ap-northeast-1.compute.internal   Ready    <none>   9d    v1.14.7-eks-1861c5
ip-10-110-20-254.ap-northeast-1.compute.internal   Ready    <none>   8d    v1.14.7-eks-1861c5

$ kubectl get all -n kube-system -l k8s-app=aws-node -o wide
NAME                 READY   STATUS    RESTARTS   AGE   IP              NODE                                               NOMINATED NODE   READINESS GATES
pod/aws-node-2gl8m   1/1     Running   0          16h   10.110.10.171   ip-10-110-10-171.ap-northeast-1.compute.internal   <none>           <none>
pod/aws-node-v8w76   1/1     Running   0          9d    10.110.10.233   ip-10-110-10-233.ap-northeast-1.compute.internal   <none>           <none>
pod/aws-node-xpqxv   1/1     Running   0          9d    10.110.20.254   ip-10-110-20-254.ap-northeast-1.compute.internal   <none>           <none>

NAME                      DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE   CONTAINERS   IMAGES                                                                    SELECTOR
daemonset.apps/aws-node   3         3         3       3            3           <none>          14d   aws-node     602401143452.dkr.ecr.ap-northeast-1.amazonaws.com/amazon-k8s-cni:v1.5.3   k8s-app=aws-node

$ kubectl describe daemonset.apps/aws-node -n kube-system
Name:           aws-node
Selector:       k8s-app=aws-node
Node-Selector:  <none>
Labels:         k8s-app=aws-node
Annotations:    deprecated.daemonset.template.generation: 1
                kubectl.kubernetes.io/last-applied-configuration:{}
Desired Number of Nodes Scheduled: 3
Current Number of Nodes Scheduled: 3
Number of Nodes Scheduled with Up-to-date Pods: 3
Number of Nodes Scheduled with Available Pods: 3
Number of Nodes Misscheduled: 0
Pods Status:  3 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
  Labels:           k8s-app=aws-node
  Service Account:  aws-node
  Containers:
   aws-node:
    Image:      602401143452.dkr.ecr.ap-northeast-1.amazonaws.com/amazon-k8s-cni:v1.5.3
    Port:       61678/TCP
    Host Port:  61678/TCP
    Requests:
      cpu:  10m
    Environment:
      AWS_VPC_K8S_CNI_LOGLEVEL:  DEBUG
      MY_NODE_NAME:               (v1:spec.nodeName)
    Mounts:
      /host/etc/cni/net.d from cni-net-dir (rw)
      /host/opt/cni/bin from cni-bin-dir (rw)
      /host/var/log from log-dir (rw)
      /var/run/docker.sock from dockersock (rw)
  Volumes:
   cni-bin-dir:
    Type:          HostPath (bare host directory volume)
    Path:          /opt/cni/bin
    HostPathType:  
   cni-net-dir:
    Type:          HostPath (bare host directory volume)
    Path:          /etc/cni/net.d
    HostPathType:  
   log-dir:
    Type:          HostPath (bare host directory volume)
    Path:          /var/log
    HostPathType:  
   dockersock:
    Type:          HostPath (bare host directory volume)
    Path:          /var/run/docker.sock
    HostPathType:  
Events:            <none>

aws-nodeというdaemonsetが起動します。いつも見るやつですね。
この中でL-IPAMが動いています。

このPodのIPは各ノードのプライマリIPとなっており、HostPathでいくつかホスト上のディレクトリをマウントしていることがわかります。

また、CRDが１つ作成されています。

$ kubectl api-resources # 抜粋
NAME                              SHORTNAMES   APIGROUP                       NAMESPACED   KIND
eniconfigs                                     crd.k8s.amazonaws.com          false        ENIConfig

これは、Podのネットワークに、同じVPC内にある別のセキュリティグループまたはサブネットを使用したい場合にオプションで利用します。
今回は詳しく触れませんので、公式ドキュメントを貼っておきます。

CNI カスタムネットワーク
https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/cni-custom-network.html

ノードの状態

ノードにログインして、先ほど確認した、aws-nodeにHostPathでマウントしているディレクトリを見ていきましょう。

cni-bin-dir:
cniで利用される実行ファイルが配置されたディレクトリです。kubeletの起動オプションで変えられた気がしますが、マウントされているのはデフォルトで利用されるディレクトリです。

EKSのドキュメントに記載のあったCNIプラグインがaws-cniというモジュールです。
CNIの仕様に沿って実行され、ipamdとgRPCで通信します。

$ ll /opt/cni/bin
合計 69688
-rwxr-xr-x 1 root root 15863452 11月 28 00:12 aws-cni <---------- これ
-rwxr-xr-x 1 root root     3110 11月 28 00:12 aws-cni-support.sh
-rwxr-xr-x 1 root root  4028260  3月 15  2019 bridge
-rwxr-xr-x 1 root root  2775211  8月 17  2017 cnitool
-rwxr-xr-x 1 root root 10232415  3月 15  2019 dhcp
-rwxr-xr-x 1 root root  2856252  3月 15  2019 flannel
-rwxr-xr-x 1 root root  3127363  3月 15  2019 host-device
-rwxr-xr-x 1 root root  3036768  3月 15  2019 host-local
-rwxr-xr-x 1 root root  3572685  3月 15  2019 ipvlan
-rwxr-xr-x 1 root root  3084347  3月 15  2019 loopback
-rwxr-xr-x 1 root root  3613497  3月 15  2019 macvlan
-rwxr-xr-x 1 root root  2606733  8月 17  2017 noop
-rwxr-xr-x 1 root root  3470464 11月 28 00:12 portmap
-rwxr-xr-x 1 root root  3993428  3月 15  2019 ptp
-rwxr-xr-x 1 root root  2641877  3月 15  2019 sample
-rwxr-xr-x 1 root root  2850029  3月 15  2019 tuning
-rwxr-xr-x 1 root root  3568537  3月 15  2019 vlan

なお、aws-cni-support.shはデバッグ用の情報収集ツールです。Githubにほんの少しドキュメントがあります。

Troubleshooting Tips
https://github.com/aws/amazon-vpc-cni-k8s/blob/master/docs/troubleshooting.md

collecting node level tech-support bundle for offline troubleshooting
[root@ip-192-168-188-7 aws-routed-eni]# /opt/cni/bin/aws-cni-support.sh

// download
/var/log/aws-routed-eni/aws-cni-support.tar.gz

cni-net-dir:
CNIの設定を記載したConfigファイルを配置するディレクトリです。
このディレクトリにConfigファイルを配置することで、NodeStatus が Ready になります。

中身には、先ほどのaws-cniをCNIプラグインとして使うことなどが記載されています。

$ ll /etc/cni/net.d
合計 4
-rw-r--r-- 1 root root 235 11月 28 00:12 10-aws.conflist
$ cat /etc/cni/net.d/10-aws.conflist
{
  "name": "aws-cni",
  "plugins": [
    {
      "name": "aws-cni",
      "type": "aws-cni",
      "vethPrefix": "eni"
    },
    {
      "type": "portmap",
      "capabilities": {"portMappings": true},
      "snat": true
    }
  ]
}

log-dir:
ipamdやCNIプラグインのログが出力されています。
1時間ごと1日24ファイルも作っているんですね・・・

$ ll /var/log/aws-routed-eni/
合計 14992
-rw-r--r-- 1 root root 628617 12月  7 00:59 ipamd.log.2019-12-07-00
-rw-r--r-- 1 root root 629027 12月  7 01:59 ipamd.log.2019-12-07-01
-rw-r--r-- 1 root root 629018 12月  7 02:59 ipamd.log.2019-12-07-02
-rw-r--r-- 1 root root 629020 12月  7 03:59 ipamd.log.2019-12-07-03
-rw-r--r-- 1 root root 628943 12月  7 04:59 ipamd.log.2019-12-07-04
-rw-r--r-- 1 root root 629025 12月  7 05:59 ipamd.log.2019-12-07-05
-rw-r--r-- 1 root root 629041 12月  7 06:59 ipamd.log.2019-12-07-06
-rw-r--r-- 1 root root 628617 12月  7 07:59 ipamd.log.2019-12-07-07
-rw-r--r-- 1 root root 629048 12月  7 08:59 ipamd.log.2019-12-07-08
-rw-r--r-- 1 root root 629023 12月  7 09:59 ipamd.log.2019-12-07-09
-rw-r--r-- 1 root root 629024 12月  7 10:59 ipamd.log.2019-12-07-10
-rw-r--r-- 1 root root 628920 12月  7 11:59 ipamd.log.2019-12-07-11
-rw-r--r-- 1 root root 629033 12月  7 12:59 ipamd.log.2019-12-07-12
-rw-r--r-- 1 root root 629013 12月  7 13:59 ipamd.log.2019-12-07-13
-rw-r--r-- 1 root root 628607 12月  7 14:59 ipamd.log.2019-12-07-14
-rw-r--r-- 1 root root 629030 12月  7 15:59 ipamd.log.2019-12-07-15
-rw-r--r-- 1 root root 181262 12月  7 16:17 ipamd.log.2019-12-07-16
-rw-r--r-- 1 root root   1718 11月 28 00:21 plugin.log.2019-11-28-00
-rw-r--r-- 1 root root   4585 11月 28 04:32 plugin.log.2019-11-28-04
-rw-r--r-- 1 root root   3253 12月  5 01:13 plugin.log.2019-12-05-01

dockersock:
Dockerのsocketですね。

ENIを通してPodが繋がる仕組み

EC2内でどのようなルーティング設定を行っているのかは、Githubにドキュメントがあります。

Proposal: CNI plugin for Kubernetes networking over AWS VPC
https://github.com/aws/amazon-vpc-cni-k8s/blob/master/docs/cni-proposal.md

Pod to Pod Communication
https://github.com/aws/amazon-vpc-cni-k8s/blob/master/docs/cni-proposal.md#pod-to-pod-communication

ホスト側でvethを作成し、Podのネットワーク名前空間のeth0に紐づけています。

そしてPodに割り当てたENIのセカンダリIPにきた通信が、vethに流れるようにルーティングテーブルを設定することで、Podに繋がるようになっています。

Life of a Pod to Pod Ping Packet
https://github.com/aws/amazon-vpc-cni-k8s/blob/master/docs/cni-proposal.md#life-of-a-pod-to-external-packet

Podから外への通信は、Podのネットワーク名前空間のデフォルトゲートウェイからvethに流れるようにして実現しているようです。

Pod起動時の状態

実際にPodを起動してノードの中身を見てみます。
何度目の引用かわかりませんが、実際のネットワーク設定が書いてある貴重なドキュメントなので、これに沿って見ていきます。

Pod to Pod Communication
inside-a-pod
https://github.com/aws/amazon-vpc-cni-k8s/blob/master/docs/cni-proposal.md#inside-a-pod

on-host-side
https://github.com/aws/amazon-vpc-cni-k8s/blob/master/docs/cni-proposal.md#on-host-side

Podとしてnetshootを起動しました。PodのIPは 10.110.10.109 です。

nicolaka/netshoot
https://github.com/nicolaka/netshoot

$ kubectl get po tmp-shell -o wide 
NAME        READY   STATUS    RESTARTS   AGE   IP              NODE                                               NOMINATED NODE   READINESS GATES
tmp-shell   1/1     Running   0          13h   10.110.10.109   ip-10-110-10-171.ap-northeast-1.compute.internal   <none>           <none>

ノードにログインして動いているdockerコンテナを確認します。

このノードで動いているのは、kube-proxyとaws-nodeと各pauseコンテナをのぞいて、netshootのコンテナだけです。
（pauseコンテナは、Podのネットワーク名前空間を保持するコンテナです。仮にアプリのコンテナが再起動してもネットワーク名前空間が再利用できるよう存在します。）

[ec2-user@ip-10-110-10-171 ~]$ sudo docker ps
CONTAINER ID        IMAGE                                                                   COMMAND                  CREATED             STATUS              PORTS               NAMES
e49972815e64        932520758690.dkr.ecr.ap-northeast-1.amazonaws.com/nicolaka/netshoot     "tail -f /dev/null"      13 hours ago        Up 13 hours                             k8s_tmp-shell_tmp-shell_kube-system_de9cb72e-1a90-11ea-a80c-0efdaea6eca6_0 <---------- これと
373b7e98b5a1        602401143452.dkr.ecr.ap-northeast-1.amazonaws.com/eks/pause-amd64:3.1   "/pause"                 13 hours ago        Up 13 hours                             k8s_POD_tmp-shell_kube-system_de9cb72e-1a90-11ea-a80c-0efdaea6eca6_0 <---------- これ
13e3eed03049        602401143452.dkr.ecr.ap-northeast-1.amazonaws.com/amazon-k8s-cni        "/bin/sh -c /app/ins…"   3 days ago          Up 3 days                               k8s_aws-node_aws-node-2gl8m_kube-system_b0160f05-1806-11ea-b040-0adab48a968a_0
9fec891354e8        602401143452.dkr.ecr.ap-northeast-1.amazonaws.com/eks/kube-proxy        "kube-proxy --v=2 --…"   3 days ago          Up 3 days                               k8s_kube-proxy_kube-proxy-6wjkw_kube-system_b0169b30-1806-11ea-b040-0adab48a968a_0
4bfccfc27c3d        602401143452.dkr.ecr.ap-northeast-1.amazonaws.com/eks/pause-amd64:3.1   "/pause"                 3 days ago          Up 3 days                               k8s_POD_aws-node-2gl8m_kube-system_b0160f05-1806-11ea-b040-0adab48a968a_0
0b6435826e81        602401143452.dkr.ecr.ap-northeast-1.amazonaws.com/eks/pause-amd64:3.1   "/pause"                 3 days ago          Up 3 days                               k8s_POD_kube-proxy-6wjkw_kube-system_b0169b30-1806-11ea-b040-0adab48a968a_0
[ec2-user@ip-10-110-10-171 ~]$ 

このノードにはENIが２つアタッチされていました。
一番最後のネットワークインターフェースがPod用のvethです。

[ec2-user@ip-10-110-10-171 ~]$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 06:a3:0c:9d:99:5e brd ff:ff:ff:ff:ff:ff
4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 06:ed:bb:fd:5a:d8 brd ff:ff:ff:ff:ff:ff
6: enie5da25cfd1a@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc noqueue state UP mode DEFAULT group default <---------- Podのveth
    link/ether 02:5b:59:7b:c9:f7 brd ff:ff:ff:ff:ff:ff link-netnsid 0

[ec2-user@ip-10-110-10-171 ~]$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
    link/ether 06:a3:0c:9d:99:5e brd ff:ff:ff:ff:ff:ff
    inet 10.110.10.171/24 brd 10.110.10.255 scope global dynamic eth0 <---------- ENI(eth0)プライマリIP
       valid_lft 3339sec preferred_lft 3339sec
    inet6 fe80::4a3:cff:fe9d:995e/64 scope link 
       valid_lft forever preferred_lft forever
4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
    link/ether 06:ed:bb:fd:5a:d8 brd ff:ff:ff:ff:ff:ff
    inet 10.110.10.167/24 brd 10.110.10.255 scope global eth1 <---------- ENI(eth1)のプライマリIP
       valid_lft forever preferred_lft forever
    inet6 fe80::4ed:bbff:fefd:5ad8/64 scope link 
       valid_lft forever preferred_lft forever
6: enie5da25cfd1a@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc noqueue state UP group default
    link/ether 02:5b:59:7b:c9:f7 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::5b:59ff:fe7b:c9f7/64 scope link 
       valid_lft forever preferred_lft forever

次にルーティング設定を見てみます。
ルールを確認すると、10.110.10.109への通信はmainルートテーブルを見なさいとあります。

[ec2-user@ip-10-110-10-171 ~]$ ip rule
0:      from all lookup local 
512:    from all to 10.110.10.109 lookup main 
1024:   from all fwmark 0x80/0x80 lookup main 
32766:  from all lookup main 
32767:  from all lookup default 

mainルートテーブルをみます。
10.110.10.109はenie5da25cfd1aを使いなさいとあります。
これがPodのvethですね。その他の通信はeth0を使うようになっています。

[ec2-user@ip-10-110-10-171 ~]$ ip route show table main
default via 10.110.10.1 dev eth0 
10.110.10.0/24 dev eth0 proto kernel scope link src 10.110.10.171 
10.110.10.109 dev enie5da25cfd1a scope link 
169.254.169.254 dev eth0

先ほどのネットワークインタフェースを見るとvethのMACアドレスが02:5b:59:7b:c9:f7とあります。

[ec2-user@ip-10-110-10-171 ~]$ ip link
〜〜
6: enie5da25cfd1a@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc noqueue state UP mode DEFAULT group default 
    link/ether 02:5b:59:7b:c9:f7 brd ff:ff:ff:ff:ff:ff link-netnsid 0

それでは次にコンテナ内のネットワーク設定をみてみます。
コンテナのネットワーク名前空間内のeth0のipアドレスが、10.110.10.109になっていることがわかります。

[ec2-user@ip-10-110-10-171 ~]$ sudo docker exec e49972815e64 ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
3: eth0@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc noqueue state UP group default 
    link/ether 62:18:cc:40:63:a8 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.110.10.109/32 brd 10.110.10.109 scope global eth0

コンテナ内のルーティングテーブルは169.254.1.1がデフォルトゲートウェイになっています。

[ec2-user@ip-10-110-10-171 ~]$ sudo docker exec e49972815e64 ip route
default via 169.254.1.1 dev eth0 
169.254.1.1 dev eth0 scope link 

最後に、arpテーブルを見ると、169.254.1.1がホスト側のvethのMACアドレス02:5b:59:7b:c9:f7に紐づいていることがわかります。

[ec2-user@ip-10-110-10-171 ~]$ sudo docker exec e49972815e64 ip neigh
169.254.1.1 dev eth0 lladdr 02:5b:59:7b:c9:f7 PERMANENT

最後に

ひとまず今回はドキュメントや実際のクラスターの状態から、ネットワークの基本的な内容を整理しました。

次回はCNIプラグインのソースコードを見ていきますが、ネットワーク周りだけでなくGoの面白そうなところをピックアップしていきたいと思います。