Microservice Patterns in Kubernnetes

1. Goal
1.1. Build reference architecture for microservices for Kubernetes

2. Architecture Groupings

2.1. Basic building block architectures
2.1.1. Deployment Patterns
2.1.2. Runtime patterns


3. Building Blocks

3.1. Covers the initial concerns
3.1.1. Codebase
3.1.1.1. Code stored in source control
- Example: Git, Perforce
3.1.1.2. Container images stored in an image repository
- Example: Docker Hub, Artifactory

3.1.1.3. Codebase Workflow
3.1.1.3.1. Push code to your source control.
3.1.1.3.2. Automated build is kicked off to build and run tests against code.
3.1.1.3.3. Bild container image; push to image repository.

3.1.1.4. Image Repository
3.1.1.4.1. Stores your code in an image
3.1.1.4.2. Need to decide early on
3.1.1.4.3. Follow your company guidelines

3.1.2. Dependencies

3.1.2.1. Applications modeled in Kubernetes as Deployments and pods
3.1.2.2. Single pod can have many containers inside
3.1.2.3. Commonly seen in Kubernetes: sidecar pattern

3.1.3. Dev/staging/production parity

3.1.3.1. Dev versus Prod in Kubernetes
3.1.3.1.1. Common Kubernetes deployment patterns
- Small footprint: different namespaces with different credentials for dev, staging, and production

- Large footprint: unique Kubernetes installation for dev, staging, and production


3.1.4. Admin processes.

3.1.4.1. Admin process containers tagged in a similar way to the running application
3.1.4.2. Containers run as Kubernetes jobs/chron job
3.1.4.3. Also run as a separate deployment


4. Deployment Patterns


4.1 Patterns around aplication deployment
4.1.1. Application configurations
4.1.1.1. Applications always have associated configuration to make the application work as expected

4.1.1.2. Application Configuration in Kubernetes
4.1.1.2.1. Two ways to store configs
- configMaps: for generic information(example: metadata, version)
- Secrets: for sensitive data(example:passwords)

4.1.1.2.2. Loaded into the pod via
- Environment variables
- Files


4.1.1.2.3. A Word on Secrets
- Secrets are a good start, but depending on the use case, might need something more like ashiCoprp Vault

4.1.2. Build, release, run
- Tag containers at build time with explicit version
- Don't use latest ta for production containers

4.1.2.1. Running in Kubernetes
- High-level constructs to run containers
- Deployments, DaemonSets, ReplicaSets
- Package management provided by Helm
- Adds revision control


4.1.3. Processes
4.1.3.1. Processes and Port Bindings
4.1.3.1.1. Processes
- Keep application stateless
- Goal: Alllow request to go to any container or server by default

4.1.3.1.2. Statelessness in Kubernetes
- Translated to Deployments and pods
- Deployments comprised of ReplicaSets, which are a collection of one or more pods

4.1.3.1.3. Word on StatefulSets
- Typically used to create persistent storage systems like a MySQK shard

4.1.3.2. Port Bindings
- Containers are implemented in pods
- Communicate to each other via well-defined ports



5. Runtime Patterns
Associating Resources in Kubernetes
- Everything is treated as a service, and configurations are stored in a ConfigMap or Secret

Scenario: Replace a Link to a Database

1) Create new database; ensure it's online and ready to accept connections.
2) Update configuration stored in the ConfigMaps or Secrets.
3) Kill the pods that were communicating with the old database.

When Kubernetes starts up the new pods, the new pods automatically pick up the new configuration, and you'll be using the new service.

If a pod is taking too much load or is receiving a lot of requests, it's easy to scale the number of pods in Kubernetes by adding more to the replica set.

Scaling Kubernetes to handle more traffic is one of the strengths of the platform.



5.1. Patterns for live running systems
5.1.1. Backing services
5.1.2. Features around concurreny
5.1.3. Disposability
The abliity to maximize robustness with fast startup and graceful shutdown

Containers
- Start up fast and run efficiently
- Have all required tooling built inside of the container image

Containers to Pods to Replicas
- Kubernetes manages your containers in pods, which are managed with ReplicaSets
- If one of the pods goes offline, the ReplicaSet will automatically start up a new pod to take its place

Advantages to Users
- From a user perspective, the application will still function, and the user won't see any downtime

5.1.4. Log management

5.1.4.1. Logging
- Treat logs as streams: execution environment handles the logs
- Common to user a log router (Beats/Fluentd) to save the logs to a service(Elasticsearch/ Splunk)
- Kubernetes makes this process easy


6. Some Assembly Required

6.1 Basic Knowledge of Kubernetes required
6.2. Watch the Learning Kubernetes course in the library if needed