KubeCon EU 2019 Highlights: Config Changes, Server‑Side Apply, GitOps, Canary Rollouts

Introduction

KubeCon EU 2019 in Barcelona showcased a series of practical lessons from the Alibaba Cloud team on scaling Kubernetes clusters for internet‑scale workloads. Deng Hongchao, a former CoreOS engineer and core author of the K8s Operator project, highlighted four major topics: Config changes, Server‑side Apply, GitOps, and Automated Canary Rollout.

The Config Changed

In Kubernetes, applications typically store configuration in ConfigMap objects that are mounted into Pods. When a ConfigMap is updated, only the files inside the Pod are refreshed, which works for hot‑reloading services like Nginx but not for most applications that require a full gray‑scale release.

Gray‑scale upgrades embody immutable infrastructure: a new version is deployed, validated, and the old version is destroyed, enabling easy rollback. Tools such as Wave (by Pusher) and Reloader automate this pattern by watching the ConfigMaps/Secrets referenced by a Deployment, hashing their contents, and annotating the PodTemplate to trigger a Deployment rollout when the hash changes. Reloader additionally lets users specify which ConfigMaps/Secrets to monitor.

Server‑Side Apply

Kubernetes is a declarative system where users define the desired state and apply it with kubectl apply. The original client‑side apply stored the last applied configuration in annotations and performed a three‑way merge, but it could not prevent different actors from overwriting each other’s fields and offered limited conflict feedback.

Server‑side apply moves the diff and merge logic to the API server, introducing the ManagedFields API that records which actor manages each field. Conflicts now return errors to non‑admin users, improving safety and reliability. Although still in Alpha, server‑side apply is expected to replace client‑side apply soon.

GitOps

GitOps treats Git repositories as the single source of truth for both code and configuration. All changes go through pull‑requests, providing audit trails, peer review, and easy rollback. This democratizes deployment processes, making them more transparent and professional.

The approach also enhances security and stability because deployments are versioned, reviewed, and can be audited. Teams can trace who deployed what and when, and roll back simply by reverting the Git commit.

Automated Canary Rollout

Canary rollout gradually shifts a small portion of traffic to a new version, validates metrics such as success rate and p99 latency, and then either promotes the new version or rolls back. Engineers from Amadeus and Datadog demonstrated a CRD‑based workflow that uses Kubernetes, Operators, Istio, and Prometheus to automate this process.

Deploy the new version (Deployment + Service).

Modify the Istio VirtualService to route a fraction of traffic to the new version.

Check Istio metrics to ensure success criteria are met.

If criteria are satisfied, promote the full rollout; otherwise, roll back.

The open‑source tool Flagger (by Weave) further automates canary progression by incrementally increasing traffic (e.g., 5% steps) until the new version is fully promoted.

Conclusion

The four highlighted techniques—config‑driven gray‑scale upgrades, server‑side apply, GitOps, and automated canary rollouts—illustrate how cloud‑native standards and CRD abstractions simplify complex operational workflows, improve reliability, and lower the barrier for developers to adopt best‑practice deployment patterns on Kubernetes.