將 ipv4 路由到 ipv6 作為機制來克服在前提 k8s 上不擁有 ipv4 塊以實現負載平衡（無 aws/gcp）

這不是關於隧道的問題，儘管這可能是解決方案的一部分。

對於公共雲提供商，由於提供商擁有大型 A/B/C 類公共 IPv4 塊，因此請求負載均衡器是微不足道的。然而，雖然擁有一個 ipv6 塊是微不足道的，但發布負載均衡器地址並非易事，因為您不能假設傳入流量支持 ipv6。如何彌合這一差距？

嘗試實現：給定有限的 ipv4 公共地址 (4)，而是生成第 7 層 http 負載均衡器 A 記錄，這些記錄映射到 ipv4 地址。這些 ip4 地址然後路由到集群內 ipv6 集群地址。也許這裡需要 SNI？

約束：不能假設 Ingres 流量支持 ipv6，因此（如果可能）需要 SNAT 來重寫 ipv6 -> ipv6 並再次返回（這可能嗎？）、iptables 和 conntrack 以進行連接跟踪？

E.g ingress
Load balancer A records   Public ipv4 address  <mapping (not tunnelling)>  Public ipv6 address range  
lb[1-n].example.com  ------>  192.0.2.0/24         ---->   2001:DB8::/32

E.g. egress
ipv6 address range        Public ipv4 address
2001:DB8::/32             ----->  192.0.2.0/24        ----> source ip ipv4 or ipv6

https://sookocheff.com/post/kubernetes/understanding-kubernetes-networking-model/ https://kubernetes.io/docs/concepts/services-networking/dual-stack/ netfilter https://metallb.universe.tf / https://linux.die.net/man/8/ip6tables https://community.hetzner.com/tutorials/install-kubernetes-cluster

在眾所周知的埠上執行服務，IP 元組的伺服器部分大部分是不變的。比如曾經流行的 https over 443/tcp。第 4 層負載均衡器將需要每個服務的 IP 地址，這在 IPv4 耗盡時不實用。

基於名稱的虛擬主機來救援。可能是 http 主機頭或 SNI。

不，不需要 SNAT。

基於代理的負載均衡器應該能夠終止一個 IP 連接並建立一個新的連接，可能使用不同的地址族。例如，兩者 a.example.net都有b.example.net負載均衡器的 A 記錄，位於203.0.113.69。虛擬主機 A 的後端可能是2001:db8:26:74::aB 的後端2001:db8:26:83::b。如果所有流量都通過負載均衡器，則後端不需要 IPv4 地址。

或者，讓 v4 和 v6 相互通信可以在第 4 層完成，而無需應用程序代理或狀態防火牆。SIIT 是一種無狀態的翻譯方式。但是，這並不能解決許多服務需要多個 v4 地址的問題，您的一個 IPv4 會在後端映射到一個 IPv6。因此，這很可能不會取代應用層虛擬主機。如果您只想在數據中心使用 v6 並僅在需要時提供 v4，這仍然很有用。

這些代理或翻譯實際上都不是路由。IPv4 和 IPv6 是不同的協議，它們不能原封不動地轉發。

真正彌合差距的將是 v6 端到端。大部分網際網路還沒有。

引用自：https://serverfault.com/questions/1059990