What is virtualization?
It is the emulation of a physical computer.
What is bare metal hypervisor?
It is a piece of software that runs on top of bare metal hardware. It doesn’t rely on the host operating system and can achieve better performance. However the hardware it runs on is more expensive.
What are the benefits of virtual machines?
They are cheaper to run. Many of them share the same hardware and they allow much higher resource utilization. They are easy to scale too. There is some migration software even moving one VM from one host to another without even shutting down the VM.
What are the downsides of virtual machines?
They could be vulnerable to the noisy neighbor problem. When our own application is sharing the host machine with a resource hog of a neighbor, our own application performance could suffer. Also vms that are sharing the same host share the same physical cores. They are vulnerable to attacks that take advantage of the design flaws in modern micro processors. Side channel attacks like Meltdown and Spektre some well known examples.
What is containerization?
It is considered to be a lightweight version of virtualization. We have hardware and the host operating system. But instead of virtualizing the underlying hardware, we virtualize the host operating system with a special software called Container Engine. On top of the container engine, there are many containers running, each have their own application environment isolated from each other.
What are the advantages of containers?
The container engine provides even faster resource provisioning, and all the resources that needed to run an application are packaged together so applications can run anywhere. Containers are scalable and portable. They are lightweight and require less hardware resources to run than virtual machines. A bare metal can run significantly more containers than virtual machines. Each container runs as a native process of the host operating system, they are much faster to start and this makes it even easier to deploy and maintain at scale. Only with a container engine software.
What are the downsides of containers?
Containers are less secure. They share the same underlying operating system and isolation lies on the OS level primitives. This means containers are exposed to a wider class of security vulnerabilities at the OS level. One way is to run containers in different VMs to reduce the attack surface. This is a tradeoff between flexibility and security.
What comes after containers?
Serverless and edge computing come to mind. They make the developer productivity and deployment stories even more compelling.
What are the virtualization layers?
Hardware
Host Operating System
Hypervisor
Then in each virtual machine, there is a guest os and on top of every operating system, runs an application for a tenant.
What is bare metal hardware?
A bare metal software is a physical computer that is single tenant only. It has hardware, host OS and many applications on top of it. Once upn a time all servers were bare metal. It gives us complete control on the hardware resources and the software stack to run\ for software applications that require the ablolute highest performance from the hardware, this could be a good way. Bare metal servers are physically isolated so they are not affected by the noisy neighbor problem. Second the isolation provides the highest level of security. Not afected by side-channel attacks. A malicious neighbor can steal secrets from its tenants. When an application needs the most strict isolation and security compliance and regulatory requirements, the bare metal could be sometimes the only way to go.
What are the downsides of bare metal?
Is expensive, hard to manage and hard to scale. acquiring new hardware takes time, and a competent team to manage it well.
What’s a hypervisor software?
A hypervisor, also known as a virtual machine monitor (VMM), is software that creates and runs virtual machines (VMs) by separating the physical hardware from the operating systems of the VMs. There are two types of hypervisors: Type 1 (or bare-metal), which runs directly on the hardware, like VMware ESXi, Microsoft Hyper-V, and Xen, and Type 2 (or hosted), which operates on top of a host operating system, like VMware Workstation and Oracle VirtualBox. Hypervisors allow multiple VMs, each with its own OS, to run concurrently on a single physical machine, effectively maximizing resource utilization and providing environment isolation.
What is Kubernetes, and what are some of its main features and benefits?
Kubernetes is an open-source platform designed to automate the deployment, scaling, and operation of application containers across clusters of hosts, providing container-centric infrastructure. Here are some of its main features and benefits:
- Orchestration and Management: Kubernetes efficiently manages clusters of containers, handling the deployment and ensuring that the state of containers matches user configurations.
- Scaling: It allows for manual or automatic scaling of applications based on demand, ensuring efficient use of resources.
- Load Balancing: Kubernetes can distribute network traffic so that deployments are stable and performant, automatically finding the best container instance for each request.
- Self-healing: It automatically restarts containers that fail, replaces and reschedules containers when nodes die, and kills containers that don’t respond to user-defined health checks.
- Automated Rollouts and Rollbacks: Kubernetes rolls out changes to the application or its configuration while monitoring application health to ensure it doesn’t kill all your instances at the same time.
- Service Discovery and Load Balancing: Kubernetes groups sets of containers into Pods for easy management and discovery, and provides them with IP addresses and a single DNS name, making it easy to set up load balancing.
- Secret and Configuration Management: Kubernetes can manage sensitive information like passwords and API keys using secrets, and it can deploy and update configuration settings without rebuilding container images.
- Storage Orchestration: It automatically mounts the storage system of your choice, whether from local storage, public cloud providers, or network storage systems.
- Resource Usage Monitoring: Kubernetes allows you to monitor the resource usage of applications through built-in tools like Kubernetes Dashboard or external solutions like Prometheus.
- Extensibility and Flexibility: It supports multiple container runtimes and provides extensive APIs, making it highly extensible and able to integrate with existing infrastructure.
These features make Kubernetes a powerful tool for modern application deployment and management in the cloud-native ecosystem.
What are the components of a Kubernetes cluster, and how do they interact with each other?
A Kubernetes cluster consists of several components that interact to manage the state of the cluster and run applications efficiently:
- Control Plane (Master Node): This central component manages the state of the Kubernetes cluster, making decisions about the cluster (e.g., scheduling) and reacting to cluster events (e.g., starting up a new container when one fails).
- etcd: A consistent and highly-available key value store used as Kubernetes’ backing store for all cluster data. It stores the configuration and state of the cluster, ensuring that data is always available to the control plane components.
- API Server (kube-apiserver): The API server is a component of the Kubernetes control plane that exposes the Kubernetes API. It serves as the front end for the Kubernetes control plane, allowing interaction, management, and configuration through API calls.
- Scheduler (kube-scheduler): The Kubernetes scheduler is a control plane process which assigns Pods to Nodes. It watches for newly created Pods that have no assigned node, and selects a node for them to run on based on resource availability, policy, affinity specifications, and other criteria.
- Controller Manager (kube-controller-manager): This component runs controller processes which regulate the state of the cluster, managing the lifecycle of different resources like nodes, jobs, endpoints, etc.
- Node (Worker Node): Nodes are the workers that run application containers. Each node has the services necessary to run Pods and is managed by the master components.
- Kubelet: Running on nodes, the kubelet is the primary node agent. It watches for tasks sent from the API Server, executes the container tasks, reports back to the master, and ensures that the containers running on the node are healthy.
- Kube-Proxy: This component runs on each node to maintain network rules that allow network communication to your Pods from network sessions inside or outside of your cluster.
- Container Runtime: The underlying software that is used to run containers. Kubernetes is compatible with various container runtimes such as Docker, containerd, and CRI-O.
- Add-ons: These provide cluster features like DNS, which gives a DNS service for the cluster, handling DNS resolution for Kubernetes services, or the Kubernetes Dashboard, a general-purpose, web-based UI for Kubernetes clusters.
These components interact through the Kubernetes API, which is exposed by the API Server, ensuring that the cluster maintains the desired state and responds appropriately to changes and failures.
How can you interact with Kubernetes API?
- kubectl
- directly accessing the rest api (kubectl proxy –port=8080 &then curl http://localhost:8080/api/)
- programmatic access to the api for go python java dotnet etc
https://kubernetes.io/docs/reference/using-api/client-libraries/
Explain these commands:
k create, k get, k describe, k delete, k apply, k logs, k exec, scale, rollout
Here’s an explanation of each of these Kubernetes kubectl commands:
kubectl create: This command is used to create a resource in your Kubernetes cluster. You can specify the resource type and provide a YAML or JSON file for the resource configuration. For example,kubectl create -f mypod.yamlcreates a pod as defined in themypod.yamlfile.kubectl get: This command retrieves information about one or more resources in your Kubernetes cluster. It can list various resources like pods, services, deployments, etc., and can be used to see their current state. For example,kubectl get podslists all pods in the current namespace.kubectl describe: This command shows detailed information about a specific resource or group of resources. It includes status, readiness, and other important metadata and is more verbose thankubectl get. For instance,kubectl describe pod mypodgives detailed information about the pod named “mypod”.kubectl delete: This command removes resources from the cluster. You can delete pods, services, deployments, and more, either by specifying the resource type and name or by using a file. For example,kubectl delete -f deploy.yamldeletes the resources defined in thedeploy.yamlfile.kubectl apply: This command is used to apply a configuration to a resource created from a file or stdin. It is commonly used for updating existing resources or creating resources if they do not already exist. For example,kubectl apply -f mydeployment.yamlupdates or creates the deployment as specified.kubectl logs: This command fetches the logs from a container in a pod. If a pod has multiple containers, you specify which container’s logs you want to view. For example,kubectl logs mypod -c mycontainerfetches logs from “mycontainer” within “mypod”.kubectl exec: This command executes a command in a container within a pod. It is often used for diagnostic purposes, such as checking the current environment or running interactive shells. For example,kubectl exec mypod -- ls /appruns thels /appcommand inside “mypod”.kubectl scale: This command changes the number of replicas of a specified deployment or other scalable resource. It’s used for manually scaling the number of pods in a deployment, for example,kubectl scale deployment mydeployment --replicas=4scales “mydeployment” to 4 replicas.kubectl rollout: This command manages a deployment’s rollout process. It can be used to start a new rollout, undo a deployment, or pause/resume an ongoing rollout. For instance,kubectl rollout restart deployment/mydeploymentrestarts the rollout of “mydeployment”.
These commands form the backbone of most interactions with Kubernetes clusters, providing the tools needed to manage and maintain your applications and their environments.
How do you create a Kubernetes deployment, and what are some best practices to follow when defining deployments?
Certainly! When defining Kubernetes deployments, here are some key best practices to follow for better efficiency, reliability, and security:
- Use Descriptive Labels: Employ meaningful labels with clear key-value pairs to help organize and manage Kubernetes objects more effectively. Labels are crucial for selecting and filtering resources during deployment operations.
- Define Resource Requests and Limits: It’s important to specify the amount of CPU and memory each container should use. Setting these parameters ensures that containers have the resources they need to operate effectively without monopolizing cluster resources, which helps maintain overall cluster health.
- Implement Health Checks: Integrate liveness and readiness probes into your container configurations. These checks allow Kubernetes to better manage container lifecycle events like restarts and traffic routing, based on the actual state of your application.
- Use an Appropriate Update Strategy: Choose a suitable strategy for updating applications, with the most common being
RollingUpdate. This strategy minimizes downtime by incrementally updating pods rather than recreating all pods simultaneously, which is crucial for maintaining service availability. - Secure Your Applications: Ensure that containers pull images from trusted and secure registries. Specify policies that define how and when images are pulled, and utilize security contexts to enforce privilege and access controls on running containers.
Following these practices helps ensure that Kubernetes deployments are not only stable and performant but also secure and easy to manage.
What is an ImagePullPolicy and what values can this parameter hold?
In Kubernetes, the imagePullPolicy is a field within a container’s configuration that determines how the kubelet (the agent running on each node) handles pulling images from the container registry. This policy controls whether or not an image should be pulled prior to starting the container, and it can be crucial for both development and production environments to ensure that the correct image version is being used.
The imagePullPolicy can take one of three values:
Always: This setting forces the kubelet to always pull the image from the registry before starting the container, regardless of whether it is already present on the node. This policy is useful in environments where you continuously update images with the same tag (likelatest) and need to ensure that the most up-to-date version is always used.IfNotPresent: With this policy, the kubelet pulls the image only if it is not already present on the local node. If the image already exists, regardless of its freshness or version, it won’t be pulled again. This policy is efficient for stable production environments where images don’t change frequently, or for minimizing bandwidth usage.Never: This setting tells the kubelet to never pull the image. It will always use an existing image on the node. If the image is not present, the container will not start. This policy can be useful in tightly controlled environments where you want to strictly manage what images are available on a node or in an offline environment.
Choosing the right imagePullPolicy is essential for controlling how updates to your container images are handled across your Kubernetes cluster.
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx-container
image: nginx:1.19.0
ports:
- containerPort: 80
imagePullPolicy: Always # Ensures the image is always pulled before starting the container
What is a Kubernetes port forward? Why do you use that? What’s the command to perform that?
Kubernetes port forwarding allows you to create a temporary direct connection from a local port to a port on a Kubernetes pod, facilitating secure access to applications running in the cluster without public exposure. This feature is particularly useful for debugging, accessing internal services, or during development phases when immediate access is required without the need for external routing configurations.
kubectl port-forward pod/myapp-pod 8080:80
NodePort vs LoadBalancer?
In Kubernetes, NodePort and LoadBalancer are two types of services that expose your applications to external traffic in different ways.
-NodePort service makes your application accessible on a specific port of every node in your cluster, which then routes traffic to the appropriate pods, typically useful for development environments or limited production use.
-LoadBalancer service integrates with a cloud provider’s load balancer to distribute incoming traffic efficiently across all nodes, offering a single access point to clients and is suitable for production environments.
While NodePort allocates a port from a defined range and can be accessed using any node’s IP and the designated port, LoadBalancer simplifies service discovery by providing a stable IP address or hostname. Overall, LoadBalancer is preferred for larger, distributed applications due to its inherent capability to handle more traffic and provide failover solutions.
Explain node affinity, node taints, node selectors, and pod priority
Node Affinity
Node affinity in Kubernetes allows you to specify rules that limit which nodes your pod can be scheduled on, based on labels on nodes. It offers more expressive options than simple node selectors, such as soft preferences (preferredDuringSchedulingIgnoredDuringExecution) and hard requirements (requiredDuringSchedulingIgnoredDuringExecution). This feature enhances the scheduler’s ability to allocate pods to suitable nodes according to specific needs, like co-location or spreading.
Node Taints
Node taints are a mechanism to repel a set of pods from a node unless those pods explicitly tolerate the taint. Taints are added to nodes and consist of a key, value, and effect (such as NoSchedule, which prevents pod scheduling unless tolerated). This mechanism is useful for reserving specific nodes for particular workloads based on their requirements or managing node usage policies.
Node Selectors
Node selectors are the simplest form of node selection constraint in Kubernetes; they allow you to restrict pod placement to specific nodes by using labels. A node selector is specified in a pod specification and matches pods to nodes with specific labels. This approach is straightforward but less flexible than node affinity, offering only the capability to enforce placement on labeled nodes.
Pod Priority
Pod priority determines the scheduling importance of a pod relative to other pods, using PriorityClasses. Pods with higher priority values are scheduled before pods with lower priority values, which is crucial when resources are limited. Pod priority can influence scheduling decisions and, in overload situations, can lead to preemption where lower-priority pods are evicted to make room for higher-priority ones.
Explain the Pod lifecycle
The Pod lifecycle in Kubernetes describes the sequence of states a Pod goes through from its initiation to its termination in a Kubernetes cluster. It begins when a Pod is created and moves to the Pending state, where it waits for all of its containers to be scheduled and all prerequisites to be satisfied. Once scheduled on a node and all containers start running, it transitions to the Running state. During its operation, a Pod might experience failures, and Kubernetes’ self-healing mechanisms, such as restarts (handled by restart policies), play a role to maintain service continuity. Finally, a Pod reaches the Succeeded or Failed state (if all containers in the Pod terminate successfully or unsuccessfully, respectively), or it can be manually or automatically terminated, leading to the Terminated state where it is removed from the cluster.
What is the CrashLoopBackOff state?
The CrashLoopBackOff state in Kubernetes is an error condition that indicates a pod is repeatedly crashing and failing to stay running. This happens when a pod starts up but then crashes or fails shortly after. Kubernetes automatically tries to restart the pod each time it crashes, following its restart policy (usually the default setting is to always try to restart). However, if the pod continues to fail and crash after each restart attempt, Kubernetes applies an exponential backoff delay between restart attempts to prevent overloading the system with continuous failures.
The CrashLoopBackOff state signals that there is a problem with the application running inside the pod that requires investigation. Common causes might include misconfigurations, failing to connect to dependencies, missing environment variables, or errors in the application code itself. The pod will remain in this state until the issue causing the crash is resolved.
When is a Pod evicted?
- A Pod in Kubernetes may be evicted under several circumstances, primarily related to resource management and node stability. Pods are evicted when a node experiences resource shortages like insufficient memory or disk space, which triggers the kubelet’s eviction policy to reclaim resources and prevent node failure.
- Kubernetes also evicts pods when performing node maintenance, scaling down operations, or upgrading cluster components, requiring pods to be moved or restarted on different nodes.
- Additionally, if a Pod has a lower priority and the node is under resource strain, higher-priority Pods may cause lower-priority Pods to be preempted and evicted.
- Lastly, administrators can manually evict Pods to manage the cluster workload distribution or to troubleshoot issues within specific nodes or Pods.
