[GitOps]🧐 What is Reconciliation?

Hello! This is the fourth installment of our GitOps series. Today, we’re going to delve deep into the ‘Reconciliation Model,’ a core mechanism of GitOps operations and a topic many engineers ponder.

Shall we master the differences between the Pull method and the Push method, the first choices you encounter when implementing GitOps, in just 10 minutes? 🚀

Before we dive in, let’s clarify the meaning of ‘reconciliation.’ In GitOps, reconciliation refers to the process of comparing the ‘Desired State stored in Git’ with the ‘Actual State of the real environment,’ and if there’s a difference, taking a series of steps to make them consistent.

This process is divided into Push and Pull depending on who initiates it. ⚖️

---

1. Push Method: Traditional Power 💨

The Push method is used by traditional CI/CD tools like Jenkins, GitHub Actions, and GitLab CI, which we commonly use.

✅ How it Works

1. A developer commits source code to Git.
2. The CI pipeline is triggered to perform builds and tests.
3. In the final stage of the pipeline, commands are directly issued to the operating environment (e.g., Kubernetes cluster) to perform updates. (e.g., kubectl apply -f …)

👍 Advantages

• Familiarity: Many existing CI tools follow this method, resulting in a low learning curve.
• Flexibility: Since control is external to the cluster, various commands can be executed freely without being dependent on a specific cluster.

👎 Disadvantages and Limitations

• Security Vulnerability: The CI tool must have administrator privileges (Kubeconfig, etc.) for the operating environment. If the CI tool is hacked, the entire operating server becomes vulnerable.
• Inability to Detect State Drift: The CI tool’s mission ends with sending commands. If someone later manually changes server settings, the CI tool cannot detect this.

---

2. Pull Method: The True Essence of GitOps ⚓

The Pull method is the model recommended by the creators of GitOps, and dedicated tools like Argo CD and Flux use this approach.

✅ How it Works

1. A

   ‘GitOps operator (agent)’

   is installed inside the operating environment (e.g., Kubernetes cluster).

2. This operator periodically monitors the Git repository (Polling).
3. When changes occur in Git, the operator itself ‘pulls’ these changes and updates its state.

👍 Advantages

• Strong Security: Authentication information for the operating environment does not leave the cluster. External entities cannot see inside, and only internal entities look outwards (to Git).
• Self-healing: If someone manually changes settings, the resident operator inside immediately detects this and reverts the state to match Git.
• Reliability: The deployment process is less sensitive to network conditions or temporary CI tool errors.

👎 Disadvantages and Limitations

• Implementation Complexity: Managing an operator for each cluster can make initial setup somewhat complex.
• Visibility: Since the deployment process occurs within the cluster, additional configuration is required to monitor deployment progress in real-time from an external CI dashboard.

---

📊 Push vs Pull: A Quick Comparison

Comparison Item	Push Method	Pull Method
—	—	—
Initiator	External CI tool (e.g., GitHub Actions)	Internal operator (e.g., Argo CD)
Security	Authentication info exposed externally	Authentication info managed internally
State Maintenance	Command delivery then termination (one-time)	Continuous monitoring and reconciliation (continuous)
Self-healing	Not possible (requires re-execution)	Possible (automatic recovery)
Key Tools	Jenkins, GitLab CI, CircleCI	Argo CD, Flux CD

—

🤔 Which method should you choose?

To conclude, if security and operational stability are important, we strongly recommend the ‘Pull method’.

• Push in these cases: Suitable for small-scale projects, deployments to non-Kubernetes environments, or environments where it’s difficult to significantly change existing CI pipelines.
• Pull in these cases: Suitable for Kubernetes-based cloud-native environments, or enterprise systems that need to manage multiple environments (Dev/Prod) safely and consistently.

---

🏁 Wrapping Up

The true beauty of GitOps ultimately lies in ‘continuous reconciliation via the Pull method.’ A system that autonomously maintains its latest state and recovers from failures without manual intervention is every operator’s dream. ✨

A clear understanding of the differences between the two methods we’ve explored today will greatly assist your team in establishing an optimized deployment strategy.