Kubernetes Certified Native Associate (KCNA) Notes

https://www.cncf.io/certification/kcna/

Kubernetes Certified Native Associate (KCNA) Notes

Table of Contents

• Exam
  • Outline
  • Changes
• Preparation
  • Study Resources
  • Practice
• Kubernetes Fundamentals
  • Pods
  • ReplicaSets
  • Deployments
  • ReplicaSet vs Deployment
  • Kubernetes Namespaces
  • Imperative vs Declarative
  • Scheduling
  • Labels and Selectors
  • Taints and Tolerations
  • Node Selectors
  • Node Affinity
  • Requests and Limits
  • DaemonSets
  • Static Pods
  • Multiple Schedulers
  • Authentication
  • Authorization
  • API Groups
  • Role-Based Access Control (RBAC)
  • Service Accounts
• Container Orchestration
  • Cluster Networking
  • Pod Networking
  • CNI
  • DNS
  • Ingress
  • Services
  • Sidecars
  • Envoy
  • Storage
• Cloud Native Architecture
  • Autoscaling
  • Kubernetes KEPs and SIGs
• Cloud Native Application Delivery
  • GitOps
    • GitOps Principles

Exam

Outline

https://github.com/cncf/curriculum/blob/master/KCNA_Curriculum.pdf

Changes

Preparation

Study Resources

https://learn.kodekloud.com/user/courses/kubernetes-and-cloud-native-associate-kcna https://amazon.com/KCNA-Book-Kubernetes-Native-Associate/dp/1916585035

Practice

https://learn.kodekloud.com/user/courses/kubernetes-and-cloud-native-associate-kcna https://tutorialsdojo.com/kubernetes-and-cloud-native-associate-kcna-sample-exam-questions/

Kubernetes Fundamentals

Pods

• A pod is the smallest deployable unit in Kubernetes. A Pod represents a single instance of a running process in your cluster.
• Pods deploy a container image on a Kubernetes cluster as a running instance of an application.
• A pod can contain more than one container.
  • An example use case would be a pod that contains a web server and a sidecar container that collects logs for the web server container.
• A pod can be deployed by using kubectl or by creating a YAML manifest:
  • Kubectl example:

  kubectl run my-pod --image=my-image
  

  • YAML manifest example:

  apiVersion: v1
  kind: Pod
  metadata:
    name: my-pod
  spec:
  - containers:
    - name: my-container
      image: my-image
  

• You can view pods running in a cluster by using the following command:

  kubectl get pods
  

  • You can view detailed information about a pod by using the following command:

  kubectl describe pod my-pod
  

ReplicaSets

• A ReplicaSet ensures that a specified number of pod replicas are running at any given time.
• A ReplicaSet is defined by a YAML manifest that specifies the number of replicas to maintain.
• A ReplicaSet can be deployed by creating a YAML manifest:
  • Kubectl example:

  kubectl create -f my-replicaset.yaml
  

• Replication Controllers are an older version of ReplicaSets and are being replaced.
• You can view ReplicaSets running in a cluster by using the following command:

  kubectl get replicaset
  

  • You can view detailed information about a ReplicaSet by using the following command:

  kubectl describe replicaset my-replicaset
  

Deployments:

• A Deployment is a higher-level concept that manages ReplicaSets and provides declarative updates to Pods along with a lot of other useful features.
• A Deployment is defined by a YAML manifest that specifies the desired state of the deployment.
• A Deployment can be deployed by creating a YAML manifest or imperatively using kubectl:
  • YAML example:

  kubectl create -f my-deployment.yaml
  

• You can view Deployments running in a cluster by using the following command:

  kubectl get deployments
  

• You can view detailed information about a Deployment by using the following command:

  kubectl describe deployment my-deployment
  

• Rolling updates can be performed on a Deployment by updating the Deployment’s YAML manifest and applying the changes:

ReplicaSet vs Deployment:

• ReplicaSets are a lower-level concept that manages Pods and ensures a specified number of pod replicas are running at any given time.
• Deployments are a higher-level concept that manage ReplicaSets and provide declarative updates to Pods along with a lot of other useful features.

Kubernetes Namespaces

• Namespaces are a way to divide cluster resources between multiple users.
• Namespaces can be used to organize resources and provide a way to scope resources.
• Namespaces can be used to create resource quotas and limit the amount of resources a user can consume.
• Namespaces can be used to create network policies and limit the network traffic between pods.
• Namespaces can be used to create role-based access control (RBAC) policies and limit the permissions of users.

Imperative vs Declarative

• Imperative:
  • Imperative commands are used to perform a specific task.
  • An example of an imperative command would be to create a pod using kubectl run.
  • Imperative commands are useful for quick tasks and testing.
• Declarative:
  • Declarative commands are used to define the desired state of a resource.
  • An example of a declarative command would be to create a pod using a YAML manifest.
  • Declarative commands are useful for managing resources in a production environment.

Scheduling

• Scheduling is the process of assigning pods to nodes in a Kubernetes cluster.
• The Kubernetes scheduler is responsible for scheduling pods to nodes based on resource requirements and constraints.
• The scheduler uses a set of policies to determine where to place pods in the cluster.
• The scheduler can be configured to use different scheduling algorithms and policies.
• The scheduler can be extended with custom scheduling plugins.
• To schedule a pod, the scheduler evaluates the pod’s resource requirements, affinity and anti-affinity rules, taints and tolerations, and other constraints. It then selects a node that meets the requirements and assigns the pod to that node by updating the spec.nodeName field in the pod’s manifest.

Labels and Selectors

• Labels are key-value pairs that are attached to objects in Kubernetes.
• Labels can be used to organize and select objects in Kubernetes.
• Labels can be used to filter and group objects in Kubernetes.
• Labels can be used to create selectors that match objects based on their labels.
• Selectors are used to select objects in Kubernetes based on their labels.
• Selectors can be used to filter objects based on their labels.
• Selectors can be used to group objects based on their labels.
• Selectors can be used to create sets of objects that match a specific label query.

Taints and Tolerations

• Taints are used to repel pods from nodes in a Kubernetes cluster.
• We apply a taint to a node (as a key-value pair). Any pods that do not have a toleration for that taint will not be scheduled on that node.

Node Selectors

• Node selectors are used to constrain which nodes a pod is eligible to be scheduled based on labels on the node.
• Node selectors are used to filter nodes based on their labels.
• To use a node selector, you add a nodeSelector field to the pod’s spec that specifies a set of key-value pairs that must match the labels on the node.
• Example:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
  nodeSelector:
    disktype: ssd

Node Affinity

• Node affinity is a way to constrain which nodes a pod is eligible to be scheduled based on labels on the node.
• Node affinity is similar to node selectors but provides more control over how pods are scheduled.
• Node affinity can be used to specify required and preferred rules for node selection.
• Node affinity can be used to specify rules that match or do not match nodes based on their labels.
• Node affinity can be used to specify rules that match or do not match nodes based on their topology.
• Example:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: disktype
            operator: In
            values:
            - ssd

Requests and Limits

• Requests and limits are used to specify the amount of resources a pod requires and the maximum amount of resources a pod can consume.
• Requests are used to specify the amount of resources a pod requires to run.
• Limits are used to specify the maximum amount of resources a pod can consume.
• Requests and limits can be specified for CPU and memory resources.
• Requests and limits can be specified in the pod’s spec.
• Example:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

DaemonSets

• DaemonSets are used to run a copy of a pod on all nodes in a Kubernetes cluster.
• DaemonSets are used to run system daemons and other background tasks on all nodes.
• DaemonSets are defined by a YAML manifest that specifies the pod template to use.
• DaemonSets can be deployed by creating a YAML manifest:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: my-daemonset
spec:
  selector:
    matchLabels:
      app: my-daemonset
  template:
    metadata:
      labels:
        app: my-daemonset
    spec:
      containers:
      - name: my-container
        image: my-image

Static Pods

• Static Pods are pods that are managed by the kubelet on a node.
• Static Pods are defined by a file on the node’s filesystem.
• Static Pods are not managed by the Kubernetes API server.
• Static Pods are useful for running system daemons and other background tasks on a node.
• Static Pods are defined by a file in the /etc/kubernetes/manifests directory on the node.
• Static Pods are created and managed by the kubelet on the node.

Multiple Schedulers

• Kubernetes supports multiple schedulers that can be used to schedule pods in a cluster.
• You can even create your own schedule and use it to schedule pods in a cluster.

Authentication

• Authentication is the process of verifying the identity of a user or system.
• Kubernetes supports multiple authentication methods, including:
  • X.509 client certificates
  • Static tokens
  • Service accounts
  • OpenID Connect tokens
  • Webhook tokens

authorization

• Authorization is the process of determining what actions a user or system is allowed to perform.
• Kubernetes supports multiple authorization methods, including:
  • Role-based access control (RBAC)
  • Attribute-based access control (ABAC)

API Groups

• API groups are used to organize resources in Kubernetes.
• API groups are used to group related resources together.
• API groups that you will commonly use:
  • core: Contains core resources like pods, services, and namespaces.
  • apps: Contains higher-level resources like deployments, replica sets, and stateful sets.
  • batch: Contains resources like jobs and cron jobs.
  • extensions: Contains deprecated resources like replica sets and daemon sets.
  • networking.k8s.io: Contains resources like network policies and ingresses.
  • storage.k8s.io: Contains resources like storage classes and persistent volume claims.
  • rbac.authorization.k8s.io: Contains resources like roles and role bindings.
  • metrics.k8s.io: Contains resources like pod metrics.
  • autoscaling: Contains resources like horizontal pod autoscalers.
  • admissionregistration.k8s.io: Contains resources like mutating webhooks and validating webhooks.
• Example:

curl -k https://<master-ip>:6443/apis/apps/v1

Role Based Access Control (RBAC)

• Role-based access control (RBAC) is a method of restricting access to resources based on the roles of users or systems.

Service Accounts

• Service Accounts are created and managed by the Kubernetes API and can be used for machine authentication
• To create a service account: kubectl create serviceaccount <account name>
• Service accounts are namespaced
• When a service account is created, it has a token created automatically. The token is stored as a secret object.
• You can also use the base64 encoded token to communicate with the Kube API Server: curl https://172.16.0.1:6443/api -insecure --header "Authorization: Bearer <token value>"
• You can grant service accounts permission to the cluster itself by binding it to a role with a rolebinding. If a pod needs access to the cluster where it is hosted, you you configure the automountServiceAccountToken boolean parameter on the pod and assign it a service account that has the appropriate permissions to the cluster. The token will be mounted to the pods file system, where the value can then be accessed by the pod. The secret is mounted at /var/run/secrets/kubernetes.io/serviceaccount/token.
• A service account named ‘default’ is automatically created in every namespace
• As of kubernetes 1.22, tokens are automatically mounted to pods by an admission controller as a projected volume.
  • https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md
• As of Kubernetes 1.24, when you create a service account, a secret is no longer created automatically for the token. Now you must run kubectl create token <service account name> to create the token.
  • https://github.com/kubernetes/enhancements/issues/2799

Container Orchestration

Cluster Networking

• A kubernetes cluster consists of master and worker nodes. Each node must have a network interface with a valid IP address configured. Each host must be connected to a network.
• Certain TCP/UDP ports are required to be open:
  • 6443/tcp
  • 10250/tcp
  • 10251/tcp
  • 10252/tcp
  • 2379/tcp
  • 2380/tcp
  • 30000-32767/tcp

Pod Networking

• Every requires an IP address
• Every pod in the cluster should be able to reach every other pod without using NAT

CNI

• Container Network Interface
• Container Network Interface (CNI) is a framework for dynamically configuring networking resources. It uses a group of libraries and specifications written in Go. The plugin specification defines an interface for configuring the network, provisioning IP addresses, and maintaining connectivity with multiple hosts.

DNS

• Domain Name Service
• Used to resolve names to IP addresses
• CoreDNS is the default DNS service used in Kubernetes

Ingress

Services

• Services are like a load balancer. They load balance traffic to backend pods (referred to as endpoints)
• There are 3 types of services in Kubernetes
  • ClusterIP
    • the default
    • The service IP address is only available inside the cluster
  • NodePort
    • Makes the service accessible on a predefined port on all nodes in the cluster
  • LoadBalancer
    • Provisions a load balancer in a cloud environment to make the service accessible

Sidecars

• Sidecars are a secondary container running inside our pod that provide a service for the primary pod
• An example is a container in our pod that ships logs to an external service for the business-logic container

Envoy

Storage

Cloud Native Architecture

Autoscaling

• Horizontal Pod Autoscaler (HPA)
  • Automatically scales the number of pods in a deployment based on CPU utilization or custom metrics
• Vertical Pod Autoscaler (VPA)
  • Automatically adjusts the CPU and memory requests and limits for a pod based on its usage
• Cluster Autoscaler
  • Automatically adjusts the number of nodes in a cluster based on resource demands

Kubernetes KEPs and SIGs

• Kubernetes Enhancement Proposals (KEPs) are used to propose and track major changes to Kubernetes
• Special Interest Groups (SIGs) are used to organize contributors around specific areas of the project

Cloud Native Application Delivery

GitOps

• What is GitOps

• GitOps Principles
  • Declarative - The entire system must be described desclaritively
  • Versioned/Immutable -
  • Pulled Automatically - Changes must be applied automatically
  • Continuously Reconciled - Monitor desired state vs. actual state and reconcile if needed

Observability

Prometheus

• Prometheus is an open-source monitoring and alerting system
• Prometheus scrapes metrics from instrumented jobs and stores them in a time-series database
• Prometheus provides a query language (PromQL) to query and visualize the collected metrics
• Prometheus can be integrated with Grafana for visualization
• Prometheus can be used to monitor Kubernetes clusters and applications running on Kubernetes
• Prometheus is designed to collect numeric database, not logs.
• Exporters run on the nodes and expose metrics to Prometheus
• Prometheus scrapes the metrics from the exporters