Using Class E IPv4 Address space to help GKE address IPv4 depletion problems. The need for private IPv4 addresses is growing along with the amount of services and apps hosted on Google Kubernetes Engine (GKE) (RFC 1918). The RFC1918 address space is becoming harder to come by for a lot of big businesses, which makes IP address depletion a problem that affects their application scalability.
This precise address depletion problem is resolved by IPv6, which offers a large number of addresses. But not every business or application is prepared for IPv6 just yet. You may continue to expand your company by entering the IPv4 address space (240.0.0.0/4), which can handle these problems.
Class E addresses (240.0.0.0/4) are set aside for future usage, as indicated in RFC 5735 and RFC 1112, as stated in Google VPC network acceptable IPv4 ranges; nevertheless, this does not preclude you from using them in certain situations today. Google will also provide tips for organizing and using GKE clusters with Class E.
Recognizing Class E addresses
IPv4 addresses
Some typical criticisms or misunderstandings about the use of Class E addresses are as follows:
- Other Google services do not function with class E addresses. This is untrue. Class E addresses are included in the acceptable address ranges for IPV4 that Google Cloud VPC offers. Furthermore, private connection techniques using Class E addresses provide access to a large number of Google controlled services.
- Communicating with services outside of Google (internet/on-premises/other clouds) is limited when using Class E addresses. False. You may use NAT or IP masquerading to convert Class E addresses to public or private IPv4 addresses in order to access destinations outside of Google Cloud, since Class E addresses are not routable and are not published over the internet or outside of Google Cloud. Furthermore,
a. Nowadays, a large number of operating systems support Class E addresses, with Microsoft Windows being the prominent exception.
b. Routing the addresses for usage in private DCs is supported by several on-premises suppliers (Cisco, Juniper, Arista).
- There are scale and performance restrictions on Class E addresses. This is untrue. Regarding performance, there is no difference between the addresses and other address ranges used by Google Cloud. Agents can grow to accommodate a high number of connections without sacrificing speed, even with NAT/IP Masquerade.
Therefore, you may utilize Class E addresses for private usage inside Google Cloud VPCs, for both Compute Engine instances and Kubernetes pods/services in GKE, even though they are reserved for future use, not routable over the internet, and shouldn’t be publicized over the public internet.
Class E IP Addresses Advantages
Despite these limitations, Class E addresses provide some benefits:
Large address space: Compared to standard RFC 1918 private addresses (around 17.9 million addresses vs. about 268.4 million addresses for it), Class E addresses provide a much bigger pool of IP addresses. Organizations experiencing IP address depletion will benefit from this abundance as it will enable them to expand their services and applications without being constrained by a finite amount of address space.
Growth and scalability: It addressing’s wide reach facilitates the simple scalability of services and apps on Google Cloud and GKE. IP address restrictions do not prevent you from deploying and growing your infrastructure, which promotes innovation and development even during times of high consumption.
Effective resource utilization: By using Class E addresses to enhance your IP address allocation procedures, you may reduce the possibility of address conflicts and contribute to the efficient use of IP resources. This results in reduced expenses and more efficient operations.
Future-proofing: Although it is not supported by all operating systems, its use is anticipated to rise in response to the growing need for IP addresses. You can future-proof your infrastructure scalability to enable company development for many years to come by adopting Class E early on.
Class E IP addresses
Things to be mindful of
Even though Class E IP addresses provide many advantages, there are a few crucial things to remember:
Compatibility with operating systems: At the moment, not all operating systems enable Class E addressing. Make sure your selected operating system and tools are compatible before putting Class E into practice.
Software and hardware for networking: Check to see whether your firewalls and routers (or any other third-party virtual appliance solutions running on Google Compute Engine) are capable of handling the addresses. Make sure any programs or software that use IP addresses are updated to support it as well.
Migration and transition: To ensure there are no interruptions while switching from RFC 1918 private addresses to it, meticulous preparation and execution are needed.
How Snap implemented Class E
Network IP management is becoming more difficult due to the growing use of microservices and containerization systems such as GKE, particularly by major clients like Snap. Snap’s finite supply of RFC1918 private IPv4 addresses was rapidly depleted with hundreds of thousands of pods deployed, impeding cluster scalability and necessitating a large amount of human work to release addresses.
Originally contemplating an IPv6 migration, Snap ultimately opted to deploy dual-stack GKE nodes and GKE pods (IPv6 + Class E IPv4) due to concerns over application readiness and compatibility. In addition to preventing IP fatigue, this approach gave Snap the scale of IP addresses it required for many years to accommodate future expansion and cut down on overhead. Furthermore, this technique was in line with Snap’s long-term plan to switch to IPv6.
Fresh clusters
Requirement
Construct native VPC clusters.
Steps
- Make a subnetwork with supplementary ranges for services and pods, if desired. It range (240.0.0.0/4) has CIDRs that may be used in the secondary ranges.
- When creating the cluster for the pod and services CIDR ranges, use the previously generated secondary ranges. This is an example of the user-managed secondary range assignment mechanism.
- Setup IP masquerading to source network address translation (SNAT) to map the IP address of the underlying node to the source network address.
Migrating clusters
Requirement
The clusters need to be native to the VPC.
Steps
- It is not possible to modify the cluster’s default pod IPv4 range. For more recent node pools that support Class E ranges, you may add pod ranges.
- Workloads from earlier node pools may potentially be moved to newer node pools.
IPv4 Vs IPv6
Making the switch from IPv4 to IPv6 Class E
For enterprises experiencing IP depletion, switching to dual-stack clusters with the IPv4 and IPv6 addresses now is a wise strategic step. By increasing the pool of IP addresses that are accessible, it offers instant relief and permits expansion and scalability inside Google Cloud and GKE. Furthermore, implementing dual-stack clusters is an essential first step toward a more seamless IPv6-only transition.
