Kubernetes and Docker Concepts: A Comprehensive Guide
Control Plane
The Control Plane is the component of Kubernetes responsible for managing the state of the cluster. It includes the API server, scheduler, controller manager, and etcd.
Deployments
Deployments are Kubernetes objects that manage the deployment and scaling of a set of identical Pods. They ensure a specified number of Pods are running and update them as needed.
Desired State Management
Desired State Management is the process by which Kubernetes continuously monitors and maintains the desired state of the system as specified by the user, ensuring the actual state matches the declared state.
Cluster
A Kubernetes cluster has at least one master node, which runs a container Pod, and a control plane that manages the cluster. When you deploy Kubernetes, you are essentially running a Kubernetes cluster.
Pods
Pods are the smallest deployable units in Kubernetes, representing a single instance of a running process in a cluster. They can contain one or more containers.
Services
Services are Kubernetes resources that provide a stable IP address and DNS name to access a set of Pods, enabling communication within the cluster.
Worker Nodes
Worker Nodes are nodes in a Kubernetes cluster that run containerized applications. They host the Pods and provide the runtime environments.
Bind Mounts
Bind Mounts are a way to map directories on the host machine to directories in a Docker Container. Unlike Docker Volumes, bind mounts have a direct relationship with the host filesystem.
Docker Volumes
Docker Volumes are storage mechanisms for persisting data generated and used by Docker containers. Volumes are managed by Docker and can be shared among containers.
Docker Compose
Docker Compose is a tool for defining and running multi-container Docker applications using a docker-compose.yml file. It simplifies managing applications with multiple interconnected services.
Container
A Container is a lightweight, standalone, and executable software package that includes everything needed to run a piece of software: code, runtime, system tools, libraries, and settings.
Image
An Image is a read-only template used to create Docker containers. Images contain the application code and dependencies, system libraries, tools, and settings.
Network
Networks are mechanisms for enabling communication between Docker Containers, either on the same host or across different hosts. Docker provides several network drivers such as bridge, overlay, and host.
Cloud Native
Cloud Native is an approach to building and running applications that fully exploit the advantages of the cloud computing delivery model. This involves using microservices, containers, CI/CD pipelines, and DevOps practices.
FaaS
FaaS is a type of serverless computing where users deploy individual functions rather than entire applications, with the cloud provider handling the execution.
Microservices
Microservices is an architectural style that structures an application as a collection of small, independently deployable services, each running in its own process and communicating via lightweight mechanisms like HTTP.
Monolithic
Monolithic is a software architecture in which all components of an application are packaged and deployed together as a single unit.
Serverless
Serverless is a cloud computing execution model where the cloud provider dynamically manages the allocation and provisioning of servers. Users write functions that are executed without needing to manage infrastructure.
Service-Oriented-Architecture
Service-Oriented-Architecture is an architectural pattern where applications are composed of discrete services that communicate over a network, each responsible for a specific business function.
Distributed Systems
Distributed Systems are systems where components located on networked computers communicate and coordinate their actions by passing messages to achieve a common goal.
Patterns towards Resilience
Retry
Automatically retrying failed operations.
Fallback
Providing an alternative response when a service fails.
Timeout
Limiting the time spent waiting for a response from a service.
Load Balancer
Distributing incoming network traffic across multiple servers.
Circuit Breaker
Temporarily blocking requests to a failing service to prevent overload.
Monitoring
Continuously observing system performance and health.
Resilience
Resilience is the ability of a system to handle and recover from failures gracefully without significant disruption of service.
Problems in Distributed Systems
Challenges such as network latency, partitioning, consistency, data replication, and fault tolerance.
12-Faktor
- Codebase: A codebase managed in a version control system, with many deployments.
- Dependencies: Explicitly declare and isolate dependencies.
- Configuration: Store configuration in environment variables.
- Supporting services: Treat supporting services as attached resources.
- Build, release, run: Strictly separate build and run phases.
- Processes: Run the app as one or more processes.
- Port binding: Export services by binding to ports.
- Concurrency: Scale using the process model.
- Disposability: Be robust with fast startup and graceful shutdown.
- Dev-Prod-Parity: Keep development, staging, and production as similar as possible.
- Logs: Treat logs as a stream of events.
- Admin processes: Treat admin/management tasks as one-off processes.
CAP Theorem
A principle that states it is impossible for a distributed data store to simultaneously provide more than two out of three guarantees: Consistency, Availability, and Partition Tolerance.
Conway’s Law
The design of systems is constrained by the communication structures of the organizations that produce them.
Fallacies of Distributed Computing
- The Network is reliable.
- Latency is ZERO.
- Bandwidth is infinite.
- The network is secure.
- Topology doesn’t change.
- There is only one administrator.
- Transport costs are negligible.
- The network is homogeneous.
Polyglot
The practice of using multiple programming languages, frameworks, or tools within a single project or across projects to take advantage of the strengths of each technology.
REST Idempotent
An operation that produces the same result no matter how many times it is performed. In REST, HTTP methods like GET, PUT, and DELETE are idempotent.
Richardson Maturity Model
The RMM categorizes Web APIs into four levels (0 to 3), with each higher level representing a more complete adherence to REST principles. Each level also encompasses the characteristics of the previous level.
Level 0: The Swamp of POX
Web APIs with a single URI (typically POST over HTTP) that accepts all supported operations of the service. Resources are not well-defined. Typical of RPC POX and many SOAP services.
Level 1: Resources
Introduction of resources and individual URIs for different actions (still mostly POST). The API resources are more generic, but it is possible to identify their scope.
Level 2: HTTP Verbs
Utilization of HTTP verbs to further specialize resources and separate functionalities. GET requests only retrieve data, POST/PUT requests add new data or update existing data, and DELETE requests remove data.
Level 3: Hypermedia Controls
Introduction of hypermedia elements into the response messages of resources (HATEOAS). These elements enable the establishment of a relationship between the data entities returned by and passed to the APIs.