KCNA Flashcards
Idea of Cloud Native Architecture
Optimize software for cost efficiency and reliability
Definition of Cloud Native
Build and run scalable applications in modern and dynamic environments
Reason for Cloud Native
Come away from the monolithic approach
Characteristics of Cloud Native Applications
- High level of automation
- Self healing
- Scalable
- (Cost-) Efficient
- Easy to maintain
- Secure by default
Autoscaling
- vertical scaling
- add more CPU & RAM to the VM so it can handle more
- horizontal scaling
- add more servers / racks to the underlying infrastructure so loadbalancing can kick in
Serverless
- servers are still ofc required
- developers don’t have to deal with things like network, Vms, operating systems etc..
- Function as a Service (FaaS) by cloud vendors
Open Standards
- OCI Spec: image, runtime and distribution specification on how to run, build and distribute containers
- Container Network Interface (CNI): Networking for Containers
- Container Runtime Interface (CRI): Runtimes in Container Orchestration Systems
- Container Storage Interface (CSI): Storage in Container Orchestration Systems
- Service Mesh Interface (SMI)
Use of Containers
- running applications more efficiently
- manage dependencies the application needs easily
Container basics
- originates from the “chroot” command
- nowadays, namespaces and cgroups are used
- share kernel of host machine
- are only isolated processes
4 Cs (outter to inner)
- Cloud
- Cluster
- Container
- Code
Security with Containers
- don’t rely on the isolation properties for security
- containers share kernel with host → risk
- containers can have kernel capabilities which increase the risk
- execution of processes with too many privileges such as root or admin
- use of public images is also a risk
Container Orchestration Fundamentals
- schedule multiple containers to servers in an efficient way
- allocate resources to containers
- Manage availability of containers
- Scale containers if load increases
- provide networking to connect containers
- provision storage for persistent container data
Networking within Containers
- Microservice has interface implemented that can be called for a request
- Network namespaces allow own unique IP adresses and (same) port allocations
- container ports can be mapped to a host ports for accessability
Service Discovery
DNS:
- modern DNS servers with API to register new services
Key-Value-Store:
- database to store information about services, f.e. etcd, Consul or Apache Zookeeper
Service Mesh
- adds a proxy server to every container in your architecture
- this can modify and/or filter network traffic between server and client
- nginx, haproxy and envoy are techs for this
Storage
- containers are ephemeral, read-only, consist of layers
- since a lot of applications need to write files, a read-write layer is put on top of the container image
- to persist data, you need to write it to a disk
- volumes can be used for this
Kubernetes Architecture
- used as a cluster, spanned across multiple servers, works ondifferent tasks and distributes load
- high horizontal scalability
- consists of Control plane and Worker nodes
K8s Control plane
kube-apiserver:
- centerpiece of k8s. All the other components interact with it
etcd:
- the database which holds the state of the cluster
kube-scheduler:
- chooses the worker node that could fit a workload that should be scheduled based on properties like CPU and RAM
kube-controller-manager:
- contains non-terminating control loops that manage the state of the cluster. F.e. this checks if a desired number of your application is available at all times
cloud-controller-manager (optional):
- can be used to interact with the API of cloud providers, to create external resources like load balancers, storage or security groups
K8s Worker node
container runtime:
- responsible for running containers on the worker node, f.e. docker or containerd
kubelet:
- small agent that runs on every worker node. Talks to the api-server and container runtime to handle the starting of containers
kube-proxy:
- a network proxy that handles inside and outside communication of the cluster. Tries to rely on the networking capabilitiesof the underlying operating system
K8s API
- responsible for communication with the cluster
- Authentication
- Authorization
- Admission Control
Containers in K8s
- pods are the smallest compute unit
containerd:
- lightweight and performant implementation to run containers
- most popular container runtime atm
- used by all major cloud providers for Kubernetes As A Service producs
CRI-O
- created by Red Hat, similar to podman and buildah
Docker
- long time standard, but never really made for container orchestration
- usage of docker will be deprecated in Kubernetes 1.23
Networking in K8s
- Container-to-Container communications
- This can be solved by the Pod concept
- Pod-to-Pod communications
- This can be solved with an overlay network
- Pod-to-Service communications
- Implemented by the kube-proxy and the packet filter on the node
- External-to-Service communications
- Implemented by the kube-proxy and the packet filter on the node
- Every Pod gets own IP
- core-dns for name resolution and service discovery
K8s scheduling
- process of choosing the right worker node to run a containerized workload on
- kube-scheduler make the scheduling decisions, but is not responsible for starting it
- scheduling starts when a new Pod is created
- users have to give information about application requirements
- if multiple nodes fit equally, K8s will schedule on the node with the least amount of pods
K8s objects
- apiVersion: Each object can be versioned, so the data structure of the object can change between versions
- kind: the kind of object that should be created
- metadata: used to identify the object like name
- spec: the specification of the object
Workload Objects in K8s
ReplicaSet
- controller Object that makes sure a desired number of pods are running at any given time
- used to scale applications and improve their availability
- they do this by starting multiple copies of a pod definition
Deployment
- most feature-rich object in K8s
- can be used to describe complete application lifecycle
- perfect to run stateless applications in K8s
StatefulSet
- can be used to run stateful applications like databases in K8s
- try to retain IP addresses of pods and give them a stable name, persistent storage and more graceful handling of scaling
DaemonSet
- ensures that a copy of a Pod runs on all (or some) nodes of your cluster
- perfect to run infrastructure-related workload like monitoring or logging
Job
- creates one or more pods that execute a specific task and terminate afterwards
- perfect to run one-shot skripts like database migrations or administrative tasks
CronJob
- add a time-based configuration to jobs, that allows Jobs to run periodically like every hour
Networking Objects in K8s
Services
- can be used to expose a set of pods as a network service
- there are 4 Service Types:
ClusterIP
- most common service type
- is a virtual IP inside K8s that can be used as a single endpoint for a set of pods
- can be used as a round-robin load balancer
NodePort
- extens the ClusterIP by adding simple routing rules
- opens a port between 30000-32767 on every node in the cluster and maps it to the ClusterIP
- allows routing external traffic to the cluster
LoadBalancer
- extends the NodePort by deploying an external LoadBalancer instance
- will only work if your environment has an API to configure a LoadBalancer instance (f.e. on Hetzner, AWS…)
ExternalName
- special service type that has no routing
- uses k8s internal DNS server to create a DNS alias
- useful if you want to reach external resources from your Kubernetes cluster
Ingress Object
- exposes HTTP and HTTPs routes from outside the cluster for a service inside the cluster
- configures routing rules a user can set and implement with an ingress controller
Volumes & Storage Objects in K8s
- k8s made volumes part of a pod
- volumes allow sharing data between multiple containers in the same pod
- prevents data loss when Pod crashes and is restarted on the same node
- only data stored to a volume will be saved
PersistentVolumes (PV):
- abstract description for a slice of storage
- object configuration holds type of volume, volume size, access mode and information on how to mount it
PersistentVolumeClaims (PVC):
- request for storage by a user
- if cluster has multiple volumes, user can create PVC which will reserve a PV according to his needs
Configuration Objects in K8s
- applications often have config files or need connections strings to other services
- in K8s the configuration from the pods is decoupled with a ConfigMap
- ConfigMaps can be used to store whole configuration files or variables as key-value pairs
- you can mount a ConfigMap as volume in a pod or map variables from the ConfigMap to environment variables of a Pod
- secrets for sensitive data
Autoscaling Objects in K8s
Horizontal Pod Autoscaler (HPA)
- most used autoscaler in K8s
- watches Deployments or ReplicaSets and increases number of Replicas is threshold is reached
Cluster Autoscaler
- can add new worker nodes to the cluster if the demand increases
- works great in tandem with the HPA
Vertical Pod Autoscaler
- relatively new
- allows Pods to increase resource requests and limits dynamically
- is limited by the node capacity
Application Delivery Fundamentals
- every applications lifecycle starts with code that is written
- best way to manage source code is a version control system (Git)
- next step is building the application (this includes docker images)
- last step is delivering the application to the platform it should run on
CI/CD
Continuous Integration
- first part of the process
- described permanent building and testing of the written code
Continuous Delivery
- second part of the process
- automates deployment of the pre-built software
- software is often deployed to Development or Staging environments before it gets released
Pipelines are used for whole automation of this workflow:
- build code
- run tests
- deploy to servers
- perform security and compliance checks
GitOps
- Infrastructure as Code
- merge requests to manage infrastructure changes
Push-based:
- pipeline runs tools that make changes in the platform
- changes can be triggered by commit or merge requested
Pull-based
- agent watches git repository for changes and compares it to the actual running state
- applies changes to the infrastructure when changes were detected
- K8s is well suited for GitOps because of its API
Observability
- often used synonymously with monitoring
- is the system stable?
- is the system sensitive to change?
- do certain metrics exceed their limits?
- why does a request to the system fail?
- are there any bottlenecks?
Telemetry
- distance (tele) measuring (metry)
- each and every application should have build in tools that generate information data
- information data should be collected and transferred in a centralized system
Logs
- messages emitted from an application when errors, warnings or debug information should be represented
Metrics
- quantitive measurments taken over time
- f.e. a number of requests or an error rate
Traces
- track progression of a request while it’s passing through the system
- provides information of when a request was processed by which service and how long it took
Logging
- many frameworks come with logging tools built-in
Linux programs provide three I/O streams:
- standard input (stdin): Input to a program e.g. via keyboard
- standard output (stdout): The output of a program
- standard error (stderr): Errors of a program
Node-level logging
- most efficient way to collect logs
- admin configures a log shipping tool that collects logs and ships them to a central system
Logging via sidecar container
- application has a sidecar container that collects and ships logs
Application-level logging
- the application itself pushes the logs directly to the central store
Prometheus
- open source monitoring system
collects four core metrics:
- Counter: value that increases, like request or error count
- Gauge: values that increase or decrease, like memory size
- Histogram: sample of observations, like request duration or response size
- Summary: similar to histogram, but also provides total count of observations
To expose those metrics, applications can expose an HTTP endpoint under /metrics.
Tracing
- used to understand how a request is processed in a microservice architecture
- consists of multiple units of work
- each application can contribute a span to a trace which can include start and finish time, name, tags or a log message
Cost Management
- cloud providers don’t offer “pro-bono”
- analyze what is really needed and automate the scheduling of resources needed
Identify wasted and unused resources
- with good monitoring its easy to find unused resources
- autoscaling helps to shut down instances that are not needed
Right-Sizing
- when starting out, it can be a good idea to choose servers with lot more power than actually needed
- good monitoring give good indications over time how much actually is needed
- ongoing process to always adapt to the load you actually need
Reserved Instances
- On-demand pricing models are great if you really need resources on-demand
- if not, you’re paying a lot for “on-demand” service
- you can reserve resources and pay them upfront if you can estimate the resources you will need
Spot Instances
- use spot instances for heavy batch of jobs or load for a short amount of time
- you get unused resources that have been over-provisioned by the cloud vendor for very low prices
- spot instances can be terminated since these are not reserved for you but for the one who paid the full price
