SAP C_KYMD_01 SAP Certified Development Associate - Side-by-Side Extensibility based on SAP BTP Kyma runtime Exam Practice Test

 A service mesh in Kyma typically consists of two components: the data plane and the control plane12. The data plane is responsible for handling the communication between the microservices in the cluster. It consists of a set of sidecar proxies (Envoy) that are injected into each pod and intercept the traffic. The control plane is responsible for managing the configuration and policies of the data plane. It consists of a set of components (Istio) that provide features like service discovery, security, traffic management, observability, and more12. References: Discovering the Service Mesh, SAP BTP – KYMA – SERVICE MESH | SAP Blogs

The kube-scheduler is a control plane process that assigns pods to nodes based on scheduling principles, such as resource requirements, affinity, anti-affinity, and more. The kube-scheduler watches for newly created pods that have no node assigned and selects an optimal node for each pod to run on. The kube-scheduler does not start pods, scale nodes, or schedule Cron Jobs. These are the responsibilities of other components, such as the kubelet, the cluster autoscaler, and the kube-controller-manager. References: Kubernetes Scheduler, kube-scheduler

 Kubernetes pods are the smallest and most basic unit of an application in Kubernetes. They are ephemeral and can be created and destroyed at any time. Pods managed by deployments are not meant to be accessed directly, but rather through services that provide load balancing and service discovery. To ensure that pods managed by deployments are unique and identifiable, they are assigned a random hash suffix as part oftheir name. For example, a pod named nginx-deployment-6dd86d77d-ztqvs belongs to a deployment named nginx-deployment and has a hash suffix of 6dd86d77d-ztqvs12. References: Deployments | Kubernetes, Kubernetes Administrator: Managing Pods & Deployments

The Kubernetes cluster master node is responsible for running the Kubernetes control plane, which manages the entire cluster. The control plane consists of several components, such as the API server, etcd, controller manager, and scheduler. The etcd is a distributed key-value store that holds the cluster state and configuration. The scheduler is responsible for assigning workloads to the available worker nodes, based on the resources andconstraints. The master node does not run deployed applications, nor does it maintain network rules between applications. Those tasks are handled by the worker nodes and the kube-proxy component. References: Nodes | Kubernetes, Kubernetes master and worker nodes, Kubernetes Nodes - The Complete Guide - Komodor

A zero downtime deployment is a technique that allows updating an application without interrupting its availability or functionality. It usually involves creating a separate environment for the new version and switching the traffic to it once it is ready. This way, the users do not experience any disruption or errors during the deployment process. A zero downtime deployment can be achieved by using different strategies, such as blue-green deployments, canary deployments, or rolling updates123. References: Zero Downtime Deployment Techniques: Rolling Update, Zero Downtime Deployment Techniques - Blue-Green Deployments, 5 Effective Deployment Strategies To Release Applications In 2021

• Use kubectl apply to create or update resources from a file or stdin. This command does a three-way diff between the previous configuration, the input configuration, and the current configuration of the resource, and then applies the changes.
• Use kubectl patch to update Kubernetes API objects in place. Do a strategic merge patch or a JSON merge patch.
• Use kubectl replace to delete and re-create the resource. You can use this command to update immutable fields of a resource, such as its kind or name.

References:

• Manage Kubernetes Objects
• Command line tool (kubectl)
• kubectl Quick Reference

When you create an API Rule for a service, the API Gateway Controller creates an Istio Virtual Service for you behind the kyma-gateway. The Istio Virtual Service defines the rules that control how requests for a service are routed within an Istio service mesh. By creating an API Rule, you have a higher-level abstraction of Istio VirtualServices and Oathkeeper Access Rules that allows you to provision services quickly and securely. References: Using the API Gateway to Expose Services, Exposing a Service in Kyma with API Rules

 Kubernetes is an open source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation1. Kubernetes enables the operation of an elastic web server framework for cloud applications, as well as the orchestration of microservices, batch processing, machine learning, and more2. Kubernetes is not a tool for governance of applications, management of virtual machines, or registration of services, although it can integrate with other tools or frameworks that provide these functionalities. References: 1(https://kubernetes.io/docs/concepts/overview/),  2(https://en.wikipedia.org/wiki/Kubernetes)

Kyma Eventing simplifies the process of publishing and subscribing to events in the cluster. Publishing events means sending information about a change in the state of the application or the system to the Eventing backend. Subscribing to events means registering interest for a specific event type from a specific source. Kyma Eventing allows users to publish events by sending HTTP requests to the Event Publisher Proxy component, which validates and forwards the events to the NATS backend. Kyma Eventing also allows users to subscribe to events by creating Subscription custom resources that specify the event source, type, and the HTTP endpoint of the service that will receive the events. Kyma Eventing handles the delivery of the events from the NATS backend to the subscribers with the help of the Eventing Controller and the Eventing Dispatcher components. References: https://kyma-project.io/

https://blogs.sap.com/2021/06/15/in-cluster-eventing-in-sap-btp-kyma-runtime/

 The service mesh solution in SAP BTP, Kyma runtime is based on Istio, which is one of the most popular service mesh solutions. Istio uses the Sidecar proxy pattern, which means that a proxy is deployed as a sidecar container next to each service. This way, the proxy can intercept and manage the traffic between the services, without requiring any changes in the application code. The proxy also communicates with the Istio control plane, whichprovides configuration and policies for the service mesh. The other options are not valid proxy patterns for the service mesh solution in SAP BTP, Kyma runtime. References: Discovering the Service Mesh - SAP Learning, Istio Documentation - What is Istio?

 A one off/non parallel job is a workload type that runs a single task to completion and then terminates. This is suitable for running a database migration on SAP BTP, Kyma runtime, as it does not require scaling, persistence, or parallelism. A parallel job, on the other hand, is a workload type that runs multiple tasks in parallel and then terminates. This is useful for batch processing or data analysis, but not for database migration. A StatefulSet is a workload type that runs one or more pods that maintain a stable identity and persistent storage. This is useful for stateful applications such as databases or message brokers, but not for database migration. A DaemonSet is a workload type that runs one pod on each node in the cluster. This is useful for providing node-level services such as logging or monitoring, but not for database migration. References: Workload Concepts, Kubernetes Workloads

When you delete a pod managed by a Replica Set, the Replica Set will schedule a new pod to replace the deleted one. This is because the Replica Set’s purpose is to maintain a stable set of replica pods running at any given time. As such, it is often used to guarantee the availability of a specified number of identical pods1. The Replica Set controller monitors the number of pods it owns and creates or deletes pods as needed to reach the desired number. The Replica Set identifies its pods by using a selector that matches the pods’ labels2. Therefore, deleting a pod will reduce the number of pods that match the selector, and trigger the Replica Set to create a new pod with the same pod template3.

References:

• 1: ReplicaSet | Kubernetes
• 2: Labels and Selectors | Kubernetes
• 3: Pods, Deployments and Replica Sets: Kubernetes Resources Explained

 Grafana and Prometheus Web UI are the open-source projects that provide data visualization in the kyma-system Namespace. Grafana is a visualization and analysis tool that can create dashboards from various data sources, such as Prometheus and Loki. Prometheus Web UI is a web interface that allows users to query and visualize the metrics collected by Prometheus. Both Grafana and Prometheus Web UI can be accessed from the Kyma Dashboard by selecting the namespace kyma-system and choosing the menu option Configuration -> Tools. References: Describing Observability in Kyma, Accessing the built-in observability tools of Kyma runtime, Using the Kyma Dashboard

Namespaces are used to isolate groups of resources in a Kubernetes cluster1. Namespaces provide a logical scope for resources, such as pods, services, deployments, and secrets. Namespaces can be used to separate different environments, teams, projects, or applications within the same cluster. Namespaces also enable resource quota management, access control, and service discovery within the cluster2. Namespaces are not the same as organizations and spaces, which are concepts used in Cloud Foundry to manage applications and services3. Semantic versioning is a convention for assigning version numbers to software releases, not a method for isolating resources. Object groups are not a native Kubernetes concept, but a term used in some tools or frameworks to group related resources. References: 1(https://learn.microsoft.com/en-us/azure/aks/operator-best-practices-cluster-isolation),  2(https://stackoverflow.com/questions/68314160/kubernetes-how-best-to-isolate-resources-based-on-environment-labels-and-sele),  3(https://packetpushers.net/4-methods-of-kubernetes-isolation/), ,

Stateless workloads are workloads that do not store any data or application state on the host that serves the requests. Instead, they rely on the information provided by the client or an external service, such as a database, to process each request independently. Stateless workloads do not keep any references to past transactions or interactions, and they can be handled by any available server. Stateless workloads are more scalable, fault-tolerant, and easier to manage than stateful workloads, which require persistent storage and session management. Some examples of stateless workloads are web servers, print servers, or microservices. References: Stateful vs stateless - Red Hat, Create stateless workloads | Google Distributed Cloud Hosted - Google Cloud, Stateless vs Stateful Kubernetes - WEKA

kubectl is a command-line tool that allows you to run commands against Kubernetes clusters1. You can use kubectl in SAP BTP, Kyma runtime for the following purposes:

• To run interactive commands. kubectl supports various commands that let you interact with your cluster resources, such as creating, updating, deleting, describing, or executing them. For example, you can use kubectl create to create a resource from a file or kubectl exec to run a command in a container2.
• To view pod logs. kubectl allows you to view the logs of a pod or a container in a pod using the kubectl logs command. This can help you troubleshoot issues or monitor the pod activity3.
• To forward ports from remote machines to pods. kubectl enables you to forward one or more local ports to a pod using the kubectl port-forward command. This can allow you to access a pod from your local machine for debugging or testing purposes4.

References:

• 1: Kubernetes / Overview of kubectl
• 2: Kubernetes / kubectl Cheat Sheet
• 3: Kubernetes / Viewing logs
• 4: Kubernetes / Use Port Forwarding to Access Applications in a Cluster

A Kubernetes cluster consists of two types of components: the control plane and the worker nodes. The control plane is responsible for managing the cluster state and orchestrating the containerized applications. The worker nodes are the machines that run the applications in pods. Some of the components of the architecture of a Kubernetes cluster are:

• kubelet: The kubelet is an agent that runs on each worker node and communicates with the control plane. The kubelet ensures that the pods and containers are running as expected, and reports the node status and resource usage to the control plane1.
• kube-proxy: The kube-proxy is a network proxy that runs on each worker node and enables the service abstraction. The kube-proxy maintains the network rules on the nodes, and allows the pods to communicate with each other and with external services2.
• etcd: The etcd is a distributed key-value store that stores the cluster configuration and state. The etcd is the source of truth for the cluster, and is accessed by the control plane components. The etcd is designed to be consistent, reliable, and secure3.

References:

• 1: Kubernetes Components | Kubernetes
• 2: Services, Load Balancing, and Networking | Kubernetes
• 3: etcd | Kubernetes

The command kubectl get pods -n  lists the pods in a specific namespace. This command uses the -n flag to specify the namespace and the get pods subcommand to retrieve the pod resources. The output shows the name, status, restarts, and age of each pod in the namespace1. You can also use the -o wide flag to show more details, such as the node where the pod is running2. References:

• 1: Get a Shell to a Running Container
• 2: List pods per namespace in kubernetes