Crossplane v2 Upgrade Successfully Completed in Production

Ganesh Pawar — Mon, 26 Oct 2026 08:39:27 +0000

Recently, I had the opportunity to do a major Crossplane upgrade from v1.20.0 to v2.0.2 on a live production environment.
For those unfamiliar with Crossplane, it is an open-source platform engineering framework that extends Kubernetes into a universal control plane, enabling teams to manage cloud infrastructure using Kubernetes APIs. Through Compositions, developers can provision complex infrastructure services with a single custom resource instead of managing individual components such as VPCs, subnets, security groups, IAM roles, and databases separately.
While the upgrade itself sounds straightforward, anyone who has worked with Crossplane knows that major version upgrades can be challenging. The biggest concern is ensuring that managed resources remain correctly mapped and are not accidentally recreated, orphaned, or disrupted.

Key areas we validated before the upgrade:
✅ Composition migration to Pipeline mode
✅ Safe managed resource mapping to prevent resource recreation
✅ Removal of deprecated features (ControllerConfig, native patch/transform, external secrets)
✅ Provider compatibility with Crossplane v2 and updated image references

One of the most important findings during the assessment was that the upgrade sequence mattered. We first upgraded Compositions, then Providers, and only after that proceeded with the Crossplane control plane upgrade itself.
We followed a phased approach through Development → Integration → Production, applying lessons learned at each stage to reduce risk and improve the rollout process.
The upgrade impacted 700+ managed resources in a live production environment. I won't deny that there were a few moments when my heartbeat definitely increased, but careful planning, validation, and testing paid off.
✅ Zero downtime
✅ No managed resource recreation
✅ No infrastructure impact
✅ Successfully running on Crossplane v2.0.2

A great reminder that complex platform upgrades are less about the upgrade itself and more about understanding dependencies, validating assumptions, and executing in the right sequence.
Happy to share experiences and lessons learned with anyone planning a similar Crossplane migration.

CIDR and Subnet Mask

Ganesh Pawar — Sun, 11 Oct 2026 09:29:33 +0000

Hello All,

I would like to share something I learned while preparing for the AWS Certified Advanced Networking - Specialty (ANS-C01) certification.

One of the topics that took me some time to fully understand was:

Decimal-to-binary conversion
How CIDR notation works
How to determine the network and broadcast address of a subnet

This may be a topic that others have already covered, but I thought it would still be helpful to share my learning journey.

Decimal to Binary

Computers do not understand decimal numbers like 192.168.31.1
Computers work with bits (0s and 1s), so the IP address must first be converted into binary before subnet calculations can be performed.
Rules:
If the remaining number is >= column value → write 1
If the remaining number is < column value → write 0

Each octet contains 8 bits.

The place values for an octet are: 128 64 32 16 8 4 2 1

Each position can be either:
1 = include the value
0 = do not include the value

Example : Convert 192 to Binary
Value Compare Bit Remaining
128 192 ≥ 128 1 64
64 64 ≥ 64 1 0
32 0 < 32 0 0
16 0 < 16 0 0
8 0 < 8 0 0
4 0 < 4 0 0
2 0 < 2 0 0
1 0 < 1 0 0
Result:11000000

CIDR: 192.168.31.1/18
Let's try to fetch IP range for above CIDR.

A /18 mask uses the first 18 bits for the network portion.
In the third octet, the mask is 192 (11000000 in binary).
This creates subnet blocks of 64 in the third octet:
0-63
64-127
128-191
192-255

Since the third octet is 31, it falls within the 0-63 block.

Conceptual Steps:

Convert IP address to a 32-bit binary number.

E.g. 192.168.31.1/18 Binary is 11000000.10101000.00011111.00000001

Create the subnet mask from the CIDR prefix. o For example, /18 means first 18 bits are 1, rest 14 bits are 0. 11111111.11111111.11000000.00000000
Perform a bitwise AND operation between the IP and the subnet mask.

Subnet mask in binary: 11111111.11111111.11000000.00000000
IP address in binary: 11000000.10101000.00011111.00000001
AND bitwise Operator results: 11000000.10101000.0000000.0000000
This zeroes out the host bits, leaving only the network bits.

The bitwise AND operator is used to compare two binary numbers bit by bit. For each bit, the result is 1 if both bits are 1, and 0 if at least one of the bits is 0.

Convert the result back to the dotted decimal format. o This is the network address. which is 11000000.10101000.0000000.0000000 (128+64).(128+32+8).0.0=192.168.0.0 for 192.168.31.1/18
Set Host Bits to 1 to Find the Broadcast Address: • The broadcast address is the last address in the subnet, which is obtained by setting all the host bits (bits corresponding to the 0s in the subnet mask) to 1. • Since /18 leaves the last 14 bits for hosts, set those 14 host bits to 1 in the network address: Network Address (Binary): 11000000.10101000.00000000.00000000 Set the host bits (the last 14 bits) to 1: 11000000.10101000.00111111.11111111 This binary value converts back to: 192.168.63.255

Therefore:

Network address: 192.168.0.0/18
Broadcast address: 192.168.63.255
Usable host range: 192.168.0.1 to 192.168.63.254

For AWS VPC networking, there is one important difference from traditional networking:

For the subnet 192.168.0.0/18:

Type IP AddressNetwork Address 192.168.0.0
Broadcast Address (traditional networks) 192.168.63.255
Traditional Usable Range 192.168.0.1 - 192.168.63.254

However, in AWS VPCs, AWS reserves 5 IP addresses per subnet:

Reserved Address Purpose
192.168.0.0 Network address
192.168.0.1 VPC router
192.168.0.2 Amazon DNS
192.168.0.3 Reserved by AWS
192.168.63.255 Network broadcast address (reserved by AWS, even though AWS does not support broadcast traffic)

DEV Community: Ganesh Pawar

Crossplane v2 Upgrade Successfully Completed in Production

CIDR and Subnet Mask