當數位化轉型開啟時，大多數企業都採用傳統模式創立和部署應用（通常是單體應用），並由獨立的開發和運營團隊分別對這兩個功能負責。 隨著企業轉向更現代化的模式，他們開始創立基於微服務的應用並使用DevOps理念來部署應用，這使得傳統孤島之間的界限變得日益模糊。
雖然 DevOps 團隊和應用擁有者現在能夠更直接地控制應用的部署、管理和交付方式，但打破壁壘通常並不能一蹴而就，而且我們認為也沒有必要。 相反，我們觀察到職責的邏輯劃分仍然適用：
- 網路與安全團隊仍然關注企業基礎架構的整體安全性、性能和可用性。 他們最關心的是全域服務，而這些服務通常部署在企業基礎架構的“入口”。
這些團隊依賴 F5 BIG-IP 部署全域負載均衡 （GSLB）、DNS 解析、複雜的負載均衡等用例。 對於NetOps 團隊，BIGIQ 和 NGINX Controller 能夠提供最佳的指標參數和警報資訊以滿足需求。 而對於SecOps 團隊，這兩款產品也能提供可視化和安全控制用以保護企業資產並滿足行業法規的監管要求。
- 運營團隊（側重於運營的DevOps）根據相關業務的需求創立和管理各個應用。 他們最關心自動化和 CI/CD 流水線等服務，這些服務可以幫助他們更快地反覆運算和更新功能;此類服務通常部署在距離應用“更近”的位置，例如部署在 Kubernetes 環境中。
這些團隊依賴 NGINX 產品（例如 NGINX Plus、NGINX App Protect、NGINX Ingress Controller 和NGINX Service Mesh）對託管在多個環境（包括 Kubernetes 集群）中的分散式微服務應用進行負載均衡和流量整形。 用例包括 TLS 終止、基於主機的路由、URI 重寫、JWT 身份驗證、會話持久化、速率限制、健康檢查、安全性（使用 NGINX App Protect 作為整合式 WAF）等等。
Kubernetes 環境中的 NetOps 和 DevOps
NetOps 和 DevOps 團隊的關注點有所不同，主要反映在他們在 Kubernetes 環境中所扮演的角色以及所使用的工具上。 簡單來說，NetOps 團隊主要關注 Kubernetes 集群外部的基礎架構和網路功能，而 DevOps 團隊則主要關注 Kubernetes 集群內部的功能。
為了將流量引導到 Kubernetes 集群，NetOps 團隊可以將 BIGIP 用作外部負載均衡器，為他們熟悉的功能和Overlay網路提供支援。 但就 BIGIP 本身而言，它無法跟蹤 Kubernetes 集群內 Pods 的變化（例如 Pods 的數量或其 IP 位址的變化）。 為了解決這個問題，我們將 F5 Container Ingress Services （CIS） 部署為集群內部的操作員（operator）。 CIS 會監視 Pods 的變化，並相應地自動修改 BIGIP 系統負載均衡池中的位址。 它還會查找新創立的 Ingress、Route 和自定義資源，並相應地更新 BIGIP 配置。
雖然您可以將 BIGIP 和 CIS 結合使用，直接將流量負載均衡到應用的 Pods 上;但實際上，當應用發生動態變化，從而需要Pods和工作負載做出相應調整時，NGINX Ingress Controller 才是發現並應對這些變化的理想解決方案（例如：當需要橫向擴展 Application Pods以滿足需求的變化時）。
部署 NGINX Ingress Controller 的另一個優勢是它將應用負載均衡的控制權轉移給了負責應用本身的 DevOps 團隊。 它的高性能控制平面和以 DevOps 為中心的設計使其能夠為快速變化的 DevOps 用例提供強大支援（例如：對多個命名空間中的 Kubernetes 服務進行就地重新配置和滾動更新）。同時，NGINX Ingress Controller 使用原生 Kubernetes API 來發現哪些Pod已經被擴展了。
BIG-IP 和 NGINX Ingress Controller 如何協同工作
如您所知，BIGIP 和 NGINX Ingress Controller 最初是由兩個獨立的公司（分別為 F5 和 NGINX）打造的。 自 F5 收購 NGINX 之後，客戶表示提高這兩個工具之間的互操作性將簡化基礎架構的管理。為此，我們開發了一個新的 Kubernetes 資源：IngressLink。
IngressLink 是一個簡潔的增強功能，它使用 Kubernetes CustomResourceDefinition（CRD）來“連接”NGINX Ingress Controller 和 BIGIP。 簡而言之，它能夠讓 CIS 在 NGINX Ingress Controller Pod 發生變化時“告訴”BIGIP。 有了這個資訊，BIGIP 可以靈活地改變相應的負載均衡策略與之匹配。
當使用 BIGIP 對 Kubernetes 集群實施負載均衡，並使用 NGINX Ingress Controller 處理進出流量，流量的流向將會是這樣的：
- BIGIP 將外部流量定向到 NGINX Ingress Controller 實例。
- NGINX Ingress Controller 將流量分發到集群內相應的服務。
- 由於 NGINX Ingress Controller 非常高效，一組穩定的實例集就可以處理大量頻繁變化的Application Pods。 但是，當 NGINX Ingress Controller 本身需要橫向擴展或縮減（為了應對流量激增或驟降）時，CIS 會通知 BIGIP 相關的變化（通過 IngressLink 資源），從而讓 BIGIP 快速進行調整。
作者：Micheál Kingston
職位：F5解決方案架構師