Skip to content

EN_Kubernetes

Jump to bottom
somaz edited this page Jan 29, 2024 · 41 revisions

1. Why should I use Kubernetes?

While using Kubernetes, you might be wondering, “Why should I use Kubernetes?” I've never thought much about the question. So, let’s find out why you should use Kubernetes.

Kubernetes is an open source platform designed to automate the deployment, scaling, and operation of application containers. It was developed by Google and is currently maintained by the Cloud Native Computing Foundation.

The main advantages are as follows:

  • Container Orchestration
    • Kubernetes efficiently manages the lifecycle of containers, handling deployment, scaling, and termination across machine clusters. This simplifies the process of running applications in containers that are isolated and bundle their own dependencies.
  • Scalability
    • Kubernetes allows you to automatically scale your applications up and down using simple commands or UI, or automatically based on CPU usage.
  • Load Balancing
    • Kubernetes can distribute network traffic to ensure stable deployment. This means you don't have to worry about a single point of failure in your application.
  • High Availability
    • Kubernetes ensures the availability of applications by providing features such as automatic bean packing, self-healing (automatically restarting unresponsive containers), replication, and horizontal scaling (automatically scaling applications as needed).
  • Automated Rollouts and Rollbacks
    • Kubernetes allows you to describe a desired state for deployed containers and change the actual state to the desired state at a controlled rate. For example, you can automate Kubernetes to create new containers for deployment, remove existing containers, and replace all resources with the new containers.
  • Service Discovery and Load Balancing
    • Kubernetes can expose containers using DNS names or their own IP addresses. When traffic to containers is high, Kubernetes can load balance and distribute network traffic to ensure that deployments are stable.
  • Storage Orchestration
    • Kubernetes allows you to automatically mount any storage system you want, including local storage and public cloud providers.
  • Secret and Configuration Management
    • Kubernetes can manage sensitive information such as passwords, OAuth tokens, and SSH keys. You can deploy and update secrets and application configuration without rebuilding the container image or exposing the secret to the stack configuration.

2. What are Kubernetes components?

Kubernetes is a system for managing containerized applications across clusters of machines. It uses a variety of resources and components to handle various aspects of application deployment and management. Within Kubernetes, the kube-system namespace contains several important system Pods that play important roles in a Kubernetes cluster.

Control Plane Components

kube-apiserver
  • Responsible for central control of the entire Kubernetes cluster.
  • It provides Kubernetes APIs for use by internal system components as well as external users.
  • When a Pod is created, kube-apiserver processes requests and stores Pod information in the etcd database.
etcd
  • A consistent, highly available key-value store that serves as Kubernetes' backing store for all cluster data.
  • When a Pod is created, its configuration and state are stored in etcd, so the cluster state is maintained and can be recovered in the event of a failure.
kube-scheduler
  • It watches for newly created Pods that do not have assigned nodes and selects which nodes to run based on various scheduling criteria, including resource requirements, affinity specifications, data locality, and workload-to-workload.
  • After a Pod is created, kube-scheduler assigns it to the appropriate node.
kube-controller-manager
  • Runs a controller process with background threads that handle routine tasks in the cluster.
  • When creating a Pod, the relevant controller in kube-controller-manager checks whether the actual state of the Pod matches the desired state specified by the user.

Node component

kubelet
  • The kubelet running on each node in the cluster is responsible for ensuring that containers are running in Pods.
  • When a Pod is scheduled on a node, the kubelet on that node receives a request from kube-apiserver and starts the container specified in the Pod.
kube-proxy
  • It runs on each node and is a network proxy, maintaining network rules that allow network communication to Pods from network sessions inside or outside the cluster.
  • When a Pod is created, kube-proxy updates the node's network rules to allow IP forwarding to the Pod's IP address.
DNS service (ex: CoreDNS)
  • Provides a DNS service for your Kubernetes cluster, translating service and pod names into IP addresses.
  • When a Pod is created, it gets an IP address and DNS name. CoreDNS updates records to make Pods accessible via their DNS names within the cluster.
Container Runtime
  • Container runtime is software responsible for running containers.
  • Supports container runtimes such as Containerd and CRI.
Addon
  • Addon implements cluster functions using Kubernetes resources (daemonset, deployment, etc.).
  • Because it provides cluster-level functionality, the namespace resource for the add-on belongs to the kube-system namespace.

3. Kubernetes Pod creation method

  1. The user asks Kubernetes to create a deployment using kubectl as shown below. The process works as follows:

    • kubectl apply -f k8s-deployment.yml

  2. kubectl converts the yaml resource to JSON and sends it to the master node or API server in the control plane.

  3. The API Server receives the request and maintains the deployment details or Object definition in the database.

  4. etcd is a highly available key-value store used to store data in Kubernetes, and is an important component of Kubernetes by storing configuration specifications and the overall state of running workloads.

  5. Once the deployment resources are stored in the etcd repository, the Controller Manager is notified and creates enough Pod resources to match the replica.

    • At that point, the deployment status of etcd is pending.

  6. Scheduler checks queue status, checks infrastructure status, and performs node filtering and ranking. Then, it determines where to reserve the Pod and executes the business logic. The nodeName field of the Pod specification contains the name of the node that can be reserved, and maintains the reserved Pod object in etcd in a reserved state.

    • At that point, the Pod has not yet been created and the object has been created, updated, and stored in etcd.

  7. Each worker node has a kubelet that is responsible for communicating with the master node or control plane. Provides an interface between the Kubernetes control plane and the container runtime on each server in the cluster. Therefore, the kubelet checks whether the container is running in the Pod, and when the control plane needs to do something on the node, the kubelet executes the task.

  8. If the deployment is instructed to create three replicas, each task will be marked as scheduled in etcd.

  9. The kubelet searches for templates for Pods and delegates container creation to the CRI Daemon.

  10. Once the CRI Daemon completes its work, the kubelet checks the readiness and active probes, and the pod is finally marked as running.

4. Kubernetes API Group & RBAC (Role Based Access Control)

API Group

The Kubernetes API Group is a way to organize Kubernetes API resources. API groups categorize related resources and allow for efficient version management.

Kubernetes API is broadly divided into Core Group and Named Group.

1. Core Group

The Core Group contains basic Kubernetes resources and is identified with an empty string ("") as the API group name. This group includes essential Kubernetes resources like Pods, Services, ReplicationControllers, Nodes, and Namespaces.

For example, to set permissions for the pods resource in the Core Group, use:

apiGroups: [""]
resources: ["pods"]
2. Named Group

The Named Group consists of API groups with specific names other than the Core Group. This group includes resources related to applications, security, configuration, and various extensions. Examples of Named Groups are extensions, apps, networking.k8s.io, rbac.authorization.k8s.io, etc.

For instance, to set permissions for the deployments resource in the apps API group, use:

apiGroups: ["apps"]
resources: ["deployments"]

RBAC (Role Based Access Control)

Kubernetes RBAC (Role-Based Access Control) is a security mechanism that provides access to resources in a Kubernetes cluster to users or groups. RBAC ensures secure protection of cluster resources by assigning minimal necessary permissions to specific users.

In Kubernetes, RBAC is implemented using four elements: Role, ClusterRole, RoleBinding, and ClusterRoleBinding.

1. Role

A Role defines access rights to resources within a specific namespace in Kubernetes. It specifies the types of resources to set permissions for and the operations (e.g., get, list, create, update, etc.) included in those permissions.

Example Role definition:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: gitlab-runner-role
rules:
  - apiGroups: ["extensions", "apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
  - apiGroups: [""]
    resources: ["pods", "services", "secrets", "pods/exec", "serviceaccounts"]
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

Permissions for the deployments resource in the extensions and apps API groups include operations like get, list, watch, create, update, patch, and delete. For resources in the core API group, similar operations are granted, including pods/exec for executing commands in containers within a pod.

2. RoleBinding

RoleBinding links the permissions defined in a Role to a user, group, or service account. It essentially assigns the permissions of a Role to specific users or groups. RoleBinding is namespace-specific.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: gitlab-runner-role-binding
subjects:
- kind: ServiceAccount
  name: default
roleRef:
  kind: Role
  name: gitlab-runner-role
  apiGroup: rbac.authorization.k8s.io

5. Kubernetes Secret

Kubernetes secrets are utilized to securely store sensitive data like passwords, API keys, tokens, or certificates within a Kubernetes cluster. They aid in isolating sensitive information from application code and configuration files. Secrets can be mounted as files or environment variables for use by pods and containers in your cluster.

The resources that can be stored as Kubernetes Secrets include:

  • Opaque Secrets
  • Service account token Secrets
  • Docker config Secrets
  • Basic authentication Secret
  • SSH authentication secrets
  • TLS secrets
  • External Secrets

6. Kubernetes Service Type & ExternalTrafficPolicy

Kubernetes Service Type

In Kubernetes, a Service is an abstraction that defines a logical set of Pods and a policy by which to access them. The Service Type specifies how the Service is exposed to the network.

The main Service Types include:

  • ClusterIP: This default service type provides a service only accessible within the cluster.
  • NodePort: Exposes the service on each Node's IP at a static port. You can contact the NodePort service from outside the cluster by requesting <NodeIP>:<NodePort>.
  • LoadBalancer: Creates an external load balancer in the current cloud (if supported) and assigns a fixed, external IP to the service.
  • ExternalName: Maps the service to the contents of the externalName field (e.g., foo.bar.example.com), by returning a CNAME record with its value.

ExternalTrafficPolicy

externalTrafficPolicy is an option of a Service of type LoadBalancer or NodePort that controls how the incoming traffic is routed. It can have two values: Cluster or Local.

  • Cluster: The traffic is routed to any node, and if that node doesn't have a pod for the service, the traffic is forwarded to a node that does. This can cause an extra hop and might obscure the source IP address.
  • Local: The traffic is only routed to the nodes that have the pod for the service. If the traffic hits a node without a pod, it's dropped, not forwarded. This preserves the original source IP address but can lead to uneven distribution of traffic across the pods.

Korean

CS & Architecture

Infrastructure

English

CS & Architecture

Infrastructure

Clone this wiki locally