{Kubernetes}

- Developer 101 -
How to transition from ECS to K8s & Gitops

Florian Dambrine - Principal Engineer

From ECS to K8s - What has changed ?

CI/CD

1.

Changes in CI/CD
GitOps workflow

2.

Container Platform

Container Platform
Deployment Anatomy
Load balancing

3.

Tooling

CLI and Tools
ArgoCD
Logging

# Agenda

CI/CD Changes

Legacy Vs New Pipeline

GitOps Workflow

Kubernetes CI/CD Workflow

# Legacy ECS

CI - Build the application JAR and run checkstyle & unit tests

Deployment Api & Router - Active ECS deployment using ecs-cli (tight coupling)

Notification - Developer feedback on Slack

CD - Docker image build and registry push

# New K8s

CI - Build the application JAR and run checkstyle & unit tests

Deployment Api & Router - Auto Versioning + GitOps Workflow (passive / decoupled)

Notification - Developer feedback on Slack

CD - Docker image build and registry push

Principles

Ensure separation of concerns by decoupling the application code from its platform deployment (make use of two git repos)
Ensure propagation of a change to the live infrastructure in an automated fashion (eg. new docker image pushed to registry)

1. Auto versioning

2. GitOps

Principles

#1 The entire system is described declaratively

#2 The canonical desired system state versioned in git

#3 Approved changes that can be automatically applied to the system

#4 Software agents ensure correctness and alert on divergence

# Key concepts

# GitOps Workflow

Push

Push

2/ Kubernetes App repository (verity-k8s-ops)

K8s Templates Repo

CI / CD

GitOps Repo

Push

Publish

1/ App repository (verity-api)

image:vX.Y.Z

Application Repo

CI / CD

Container Registry

Sync

Source of truth

Deploy Operator

K8s Cluster

image:vX.Y.Z

# K8s CI/CD Workflow

Canonical Desired States

verity-api--production

verity-api--staging

myapp:staging

myapp:v1.0.0

#1 The entire system is described declaratively

staging.yaml

production.yaml

verity-k8s-ops

Collection of templates

Rendering

# K8s CI/CD Workflow

verity-api--production

verity-api--staging

Canonical Desired States

#2 The canonical desired system state versioned in git

verity-api--production
└── monochart
    └── templates
        └── deployment.yaml

verity-api--staging
└── monochart
    └── templates
        └── deployment.yaml

git://va-verity-eks-stage-gitops

git://va-verity-eks-prod-gitops

# K8s CI/CD Workflow

#4 Software agents ensure correctness

verity-api--production
└── monochart
    └── templates
        └── deployment.yaml

verity-api--staging
└── monochart
    └── templates
        └── deployment.yaml

ArgoCD

Sync

?

Container Platform

K8s Deployment Anatomy

# Container Platform

Service Discovery

EC2

EC2

EC2

EC2

ECS

 K8s workers

EKS Control Plane (Master)

ECS World

K8s World

# Container Platform

ECS World

K8s World

 Task

 Task definition

 Service

 ReplicaSet

 Deployment

Pod

Kubernetes is a lot more than a simple container scheduler, it can be seen as an automation platform to define multiple pieces of configuration or infra using YAML objects (It's a big REST API)

ECS is a fairly simple scheduler that gets the job done. It is much more lightweight in term of capabilities and requires additional work to bridge all the components together (Prometheus monitoring / Service discovery / ...)