---
# System prepended metadata

title: 1. from monolith to microservice

---

# 1. from monolith to microservice

## monolith to microservice
## refactoring
* big-bang
* cause change from monolith to microservice
* which componets  to separate?
* decouple the databases from the application to separate data complexity from appllication logic
* check microservices
    * test
    * dependencies
* refactoring is hard but advantage
## challenges  
* laguages
    * cobal or Assembler
        * give up
        * re-build it
* after refactoring
    * suitable tools
        * keep alive all the decoupled modules
* choosing runtmes
    * lib conflict 
* containerised application
    * higher utilization
    * individual module scalabillty
    * easy integration with automation tools
## sucess stories
* AppDirect
* box - a cloud storage solutions provicer
* Crowdfire
* GolfNow
* Pinterest

# Chapter 2. Container Orchestration
## learning Objective
* Define the concept of container orchestration.
* Explain the benefits of using container orchestration.
* Discuss different container orchestration options.
* Discuss different container orchestration deployment options.

## what are containers?
* best suited to deliver microservices
* containers encapsulate microservices
* do not run them directly
* containers run container images

## what are container Orchestration?
* development environments need to:
    * fault-tolerance
    * on-demand scalability
    * Optimal resource usage
    * Auto-discovery to automatically discover and communicate with each other
    * Accessibility from the outside world
    * Seamless updates/rollbacks without any downtime.
    
## container orchestrators
* Amazon Elastic container Service
* Azure Container Instances
* Azure Service Fabric
* Kubernetes
* Marathon
* Nomad
* Docker Swarm

## why use container orchestrators?
* Group hosts together while creating a cluster
* Shedule containers to run on hosts in the cluster based on resources availability
* Enable containers in a cluster to communicate with each other regardless of the host they are deployed to in the cluster
* Bind containers and storage resources
* Group sets of similar containers and bind them to **load-balancing** constructs to simplify access to containerized applications by creating a level of abstraction between the containers and the user
* Manage and optimize resource usage
* Allow for implementation of policies to secure access to applications running inside containers.

# Chapter 3. Kubernetes
## Learning Objectives
* Define Kubernetes.
* Explain the resons for using Kubernetes.
* Discuss the features  of Kubernetes.
* Discuss the evolution of Kubernetes from Borg.
* Explain the role of the Cloud Native Computing Foundation.

## What is Kubernetes?
Kubernetes is an open-source system for automating deployment, scaling, and management of containerized applications.

## From Brog to Kubernetes
[Large-scale cluster management at Google with Borg](https://research.google/pubs/pub43438/)
* kubernetes learned from it:
    * API servers
    * Pods
    * IP-per-Pod
    * Services
    * Labels

## Kubernetes Features
* Automatic bin packing
    * schedules containers based on resource needs
* Self-healing
* Horizontal scaling
* Service discovery and load balancing
* Automated rollouts and rollbacks
    * seamlessly
        * deploy app
        * configuration
* Secret and configuration management
* Storage orchestration
* Batch execution

## Why Use Kubernetes?
* extensible
* modular
* pluggable
* community

## Cloud Native Computing Foundation (CNCF)

## CNCF and Kubernetes
For Kubernetes, the Cloud Native Computing Foundation:

# Chapter 4. Kubernetes Architecture
* kubernetes architecture
* control plan
* master 
* worker node
* Container Network Interface

## Learning Objectives
* Discuss the Kubernetes architecture.
* Explain the different componets for master and worker nodes.
* Discuss about cluster state management with etcd.
* Review the Kubernetes network setup requiremetments.

## Kubernetes Architecture
* One or more **master nodes**, partof the **control plane**
* One or more **worker nodes**.

## Master Node Overview
* user use
    * cli
    * web ui
    * API
* etcd: a distributed key-value

## master node components
* components
    * API Server
    * Scheduler
    * Controller Managers
    * Data Store
* master runs
    * Container Runtime
    * Node Agent
    * Proxy

## API Server
* API server intercepts RESTful calls from users, operators, agents
* read state from etcd
* only component to talk to etcd
* highly configurable
* customizable

## sheculer
* role
    * assign new workload
        * pods
        * node
* obtains from etcd (via API)
* recives requirements (from API)
* through sheduling policies, plugins
    * configurable
    * customization

## controler managers
* kube-controller-manager
* cloud-controller-manager
    * load balancing
    
## data store
* etcd
    * strongly consistent
    * key-value
    * only API server is able to communicate with etcd
* etcdctl
    * backup
    * snapshot (take photo)
    * restore capabilities
* kubeadm provision 
    * stacked etcd master node
    * externel etcd master node
        * reducing the chances of an etcd failure
* master and follower
    * any node can be treated as a master
* besides store cluster state
    * subnets
    * ConfigMaps
    * Secrets
## node overview
* applications are encapsulated in Pods
* controlled by cluster control plane
* pod is the smallest scheduling unit
* network is handled by worker node

## Worker Node components
* container runtime
* node Agent - kubelet
* proxy - kube-proxy
* Addons for DNS, Dashboard user interface, cluster-level monitoring and logging

## container runtime
* docker
* CRI-O
* containerd
* frakti

## node Agent - kubelet
![](https://cl.ly/3I2p0D1V0T26/Image%202016-12-19%20at%2017.13.16.png)
* CRI: container runtime interface
* kubelet <-> shim <-> container runtime
* kubelet: grpc client
* CRI implements two services
    * ImageService
        * image related
    * RuntimeService
        * pod and container related
        
## CRI shim
* dockershim
![](https://lh6.googleusercontent.com/4NGAPzwhkL0GTNjkAEFN9iWX_Wc0ZE-AZxAxEw4E5aOntuGmv764b3ZYQUyapSnP9BrlUs2rUyo5kiCrj5QuiMHw3-dz2vPUDma029Qt3tej9QABEHFSsOBsq6LjLfFhTBgMhAAc)
    * docker uses containerd to manage containers
* cri-containerd
* CRI-O
* frakti

## proxy - kube-proxy
* network agent
    * TCP
    * UDP
    * SCTP
* implements forwarding rules defined by users through Service API objects

## Addons
third-party pod and service
* DNS
* Dashboard
* Monitoring
* logging

## networking challenges
all these networking challenges must be addresses before deploying a kubernetes cluster
* container
    * communication inside pods
* pod-to-pod
* pod-to-Service
    * within the same namespace
    * across cluster namespaces
* External-toService
    * clients to access application in a cluster
    
## container-to-Container communication inside pods
* special **pause** container

## Pod-to-Pod Communicaion Across Nodes
* pods are expected to be able to communicate with all other pods in the cluster
* without NAT
* IP-per-Pod
    * ensures pod-to-pod
* through CNI(Container Network Interface)
    * supported by CNI plugins

## Pod-toExternal World Communication
* shrough Services
* stored in iptables 
* implemented by kube-proxy agents

# Kubernetes Building Blocks
## Pods
![]()
* smallest and simplest
* one **or more** containers
    * schceduledd togeter on the same host with the pod
    * Share the same network namespace(share a single IP address)
    * Access to mount the same external storage(volumes)
    
```yaml=
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.15.11
    ports:
    - containerPort: 80
```

## Labels
Labels are **key-value pairs** attachd to Kubernetes objects (e.g. Pods, ReplicaSets, Nodes, Namespaces, Persistent Volumes)
* select a subset of objects
* do not provide uniqueness to objects
* one objects can have muitiple objects

## Label Selectors
* ```env == dev```, ```env != dev```
* ```env in (dev, qa)```
* ```!app```

## ReplicationControllers
* no longer a recommended controller
The default recommended controller is the Deployment which configures a ReplicaSet controller to  manage Pods' lifecycle

## ReplicaSets
* next-generation ReplicationController
* replication
* self-healing

## Deployment
* rollouts rollback
* manages ReplicaSets for app scaling
* roll back 
    * to a prior Revision

## namespace
partition the cluster into virtual sub-cluster using Namespaces

# Chapter 9. Authentication, Authorization, Admission Control

## Overview
to access a API endpoint on API server. Each access request goes through the following access control stages:
* Authentication
* Authorization
* Admission Control

## Authentication
two kinds of users: 
* Normal Users
* Servicd Accounts
    * via the API server
    * manually
[authenticaion modules](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#authentication-strategies)

## Authorization
users can send the API requests to perform different poerations. Here these API requests get **authorized** by Kubernetes.