預設 EKS cluster 使用 VPC CNI Plugin 作為 CNI。本文將探討「為什麼 EKS cluster 知道預設 CNI Plugin 為 VPC CNI plugin」，希望理解 EKS CNI plugin 設定過程。

接續前一篇，我們了解了 EKS node group 定義，並知道了 EKS worker node 使用了 EKS optimized Amazon Linux AMI 內預先設置好的 bootstrap 設定 container runtime、kubelet 等設定。 Kubernetes 為確保 Control Plane 及 worker node 溝通安全性，於 Kubernetes 1.4 導入了 certificate request 及 signing API 機制 [https://github.com/kubernetes/kubernetes/pull/20439/files]

如果是一個自建的 Kubernetes cluster，我們會需要使用 Certificate Authority 憑證給予 Kubernetes Components [https://kubernetes.io/docs/concepts/overview/components/#node-components] [1] 所使用，如 Kubernetes The Hard Way [https://github.com/kelseyhightower/kubernetes-the-hard-way/blob/master/docs/04-certificate-authority.md] [2] 或是以下 kubeadm join [https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-join/] [3] 命令則可以使 Kubernetes node

本文將探討這兩個問題「為什麼原生的 kubectl 可以直接訪問 EKS cluster」以及「為什麼 AWS CLI 權限與訪問 EKS cluster」，希望理解在 kubectl 如何與 IAM 權限整合允許訪問 EKS cluster。