deployment is exposed to the network • ClusterIP – cluster internal IP 1. 內部東西向服務調用 2. kube-controller-manager 通過--service- cluster-ip-range 定義的地址段來給 Cluster IP Service 分配 VIP 3. kube-proxy 實現資料平面轉發 4. 和 CoreDNS 結合實現服務發現 NodePort – Exposes the service on each Node at a static port 1. 無法進行源位址透傳（ExternalTrafficPolicy） 2. L7 應用交付能力弱，會話保持能力弱 3. 負載演算法少，健康檢查能力弱 4. 安全性差 & 運維複雜度高 5. 性能與資料平面的穩定性差
your deployment is exposed to the network • NodePort – Exposes the service on each Node at a static port • LoadBalancer – provisions a loadbalancer for your service 1. F5 CIS 實現的 Load Balancer 可以 bypass kube-proxy(大多數實現都是 kube-proxy 結合 外部負載) 2. Load Balancer Service 需要結合 IPAM 控制器, 不同 Service 不同入口入口 3. Load Balancer Service 適合 4 層流量入口處理
對象 資料流程方向 說明 Cluster IP Service kube-proxy Service 東西向 內部 POD 和 Service 通信 Node Port Service kube-proxy Service 南北向 Load Balancer Service kube-proxy Service 南北向 F5 實現可 bypass kube- proxy Host Port kube-proxy POD 南北向 Host Network POD 南北向 DNS CoreDNS POD, Service 東西向，南北向 L3/L4 Security Policy(Network Policy) kube-proxy POD, Namespace 東西向，南北向 kube-proxy 是容器網路基本功能正常運行的關鍵元件: • 流量轉發 • 服務負載均衡 • 流量過濾
GETTING BACK TO OUR OPEN SOURCE ROOTS Earlier this year we launched NGINX Kubernetes Gateway, based on the Kubernetes Gateway API SIG’s reference architecture. This modernizes our product family and keeps us in line with the ongoing evolution of cloud native. The NGINX Kubernetes Gateway is also something of an olive branch we’re extending to the community. We realize it complicated matters when we created both a commercial and an open source Ingress controller for Kubernetes, both different from the community Ingress solution (also built on NGINX). The range of choices confused the community and put us in a bad position. It’s pretty clear that the Gateway API is going to take the place of the Ingress controller in the Kubernetes architecture. So we are changing our approach and will make the NGINX Kubernetes Gateway – which will be offered only as an open source product – the focal point of our Kubernetes networking efforts (in lockstep with the evolving standard). It will both integrate and extend into other NGINX products and optimize the developer experience on Kubernetes.
is Critical to Security Architecture- Part 1 HTTPS://COMMUNITY.F5.COM/T5/TECHNICAL-ARTICLES/WHY-K8S-EGRESS-TRAFFIC-POLICY-CONTROL-IS-CRITICAL-TO- SECURITY/TA-P/297887 Category Solutions or products Description Platform based Kubernetes Network policy Openshift EgressIP Openshift Egress Router pod Openshift Egress Firewall Openshift EgressNetworkPolicy A specific feature of a platform provider CNI based Calico Egress pod Calico Enhanced Network policy Cilium Enhanced Network policy Kube-ovn The capability of CNI Service Mesh NGINX Service Mesh Istio A function of Service Mesh Micro segmentation PrismaNeu Vector From ZTA perspective or use enforcer container to control egress Fusion F5 CES(Container Egress Service) Fortinet Use k8s native method to integrate exist security assets to k8s Others DNS interception Proxy pod Intercept coredns or use a proxy pod as forward proxy
is Critical to Security Architecture - Part 2 HTTPS://COMMUNITY.F5.COM/T5/TECHNICAL-ARTICLES/WHY-K8S-EGRESS-TRAFFIC-POLICY-CONTROL-IS-CRITICAL-TO- SECURITY/TA-P/297895
Mesh? Manages Internal Traffic (E/W) between pods: 1. Intercepts traffic using ‘sidecar proxy’ to gain control 2. Transparently provides security (mTLS), metrics and traces, and traffic control 3. Integrates with Ingress and Egress controllers for traffic to external services Kubernetes Cluster pod pod pod pod Service A pod pod pod pod Service B pod pod pod pod Service C Ingress Controllers Kubernetes API Traffic Policies Egress Controllers
Mesh (CGAM) work independently of each other solving similar but separate problems • There is no special integration between SPK and CGAM • Separate technology selection and buying decision by the SP Ingress/Egress vs Service Mesh Cloud Native vRAN Cloud Native DC Diameter SIP HTTP/2 TCP/UDP TCP TCP/SCTP AMF KUBERNETES CLUSTER Service Proxy Aspen Mesh Aspen Mesh Aspen Mesh http/2 Aspen Mesh AMF AMF SMF SMF AMF NRF NRF PCRF HSS SIP app app app PCF AUSF UDM N-S E-W E-W
of the service mesh https://buoyant.io/blog/ebpf-sidecars-and-the-future- of-the-service-mesh 綜上所述，我們得出一個結論：無論 是 eBPF 還是沒有 eBPF，服務網格 的可預見未來都是由在用戶空間中運 行的 sidecar 代理構建的。 How eBPF will solve Service Mesh – Goodbye Sidecars Per Node Proxy vs Sidecar Proxy
vs. Ingress Controller vs. Service Mesh https://www.nginx.com/blog/how-do-i-choose-api-gateway-vs-ingress-controller-vs-service-mesh/ North-South API Gateway Use Cases: Use an Ingress Controller East-West API Gateway Use Cases: Use a Service Mesh
A Cluster B c c c c N N N c c c c c c c c N N N 統一管理面或統一API 集群管理面 集群管理面 c c c c Cluster A Cluster B c c c c N N N c c c c c c c c N N N 集群管理面 集群管理面 網路互連，服務互通，Pod互通 以集群或集群控制面為切入思維 以互連多集群間網路及資源互訪為切入思維
A Cluster B c c c c N N N c c c c c c c c N N N 統一管理面或統一API 集群管理面 集群管理面 • Kubefed: K8s cluster federation project，獨立新控制面 • 採用gitops，通過CD工具來實現一致性管理， 無實際上層API抽象，將不同獨立集群以統一標準化方式管理 例如ArgoCD類工具 • 部分容器雲公司開發統一的管理介面，相容不同環境或類型 k8集群的管理，屬於多獨立集群的簡化管理思維，與gitops 思維類似，但圖形化更好，以及其它類如聚合指標，統一日誌 統一CI/CD流程做的更好 • 公有雲跨k8s集群管理模式: F5 Distributed Cloud ， Google Anthos, EKS anywhere， Azure Arc 根據應用部署模式的不同，可能需要額外的集群間網路資源互連互訪問題的考慮
Cloud Private Cloud F5 XC Global Network (ADN) Users & CDNs Nomadic Edge Physical Edge RE RE CE CE CE CE XC Console IPSec/SSL tunnels IPSec/SSL tunnels
marschen2007
oikon48
akhino
yahonda
endonanana
recruitengineers
jtakeda
ishikawa_satoru
persolserverworks
shumei_ito
tetsuya28
willnet
prog893
philnash
minecr
khoart
elsirapls
katiecoart
marcoroth
iamctodd
uxyall
geoffreycrofte
kevinliebholz
inesmontani
reverentgeek
