Thank you for being here today to talk about a complex topic, which is kubernetes. My goal is to provide clarity about the principles and the concepts of kubernetes and compare them to the virtualization world that you might be familiar with. So hopefully by the end of this presentation you have a better grasp of kubernetes and you'll be able to start using it as well. So let's begin. My name is Julia and I'm a global technologist at VIM. And as the name indicates, we started providing services backups mainly for virtual machines. But nowadays we've expanded and we provide backup for most environments like cloud SAS, including kubernetes as well. But we're not here to talk about that today. We're here to explain and clarify kubernetes in an easier way for virtualization admins. So we traced the evolution of infrastructure through four significant stages. Initially, applications ran directly on dedicated physical servers, limiting resource utilization and scalability. But with the advent of virtualization, we introduced vms, enabling multiple virtual instances on a single physical server. Each VM included a complete guest operating system alongside the application, reducing hardware costs and simplifying management. Then with cloud computing, we elevated virtualization by offering vms as a service, so facilitating on demand provisioning and scalability, and removing the burden of physical infrastructure management. So this was really amazing. But then with the latest evolution containers we optimized resource usage by sharing the host OS. Kernel containers encapsulate only essential components necessary for running applications, enhancing efficiency and portability across diverse environments. Virtual machines and containers differ in several ways, but the primary difference is that containers provide a way to virtualize an OS so that multiple workloads can run on a single OS instance, whereas with vms the hardware is being virtualized to run multiple OS instances. As organizations seek for future ready infrastructure solutions, the integration of kubernetes and virtualization in hybrid environments will emerge as a compelling strategy. That's why it's so important to understand kubernetes, so we can all start using kubernetes as well. Similar to how shipping containers encapsulate goods, software containers similar to how shipping containers encapsulate goods, software containers encapsulate applications and all their dependencies, making them highly portable and consistent across different environments. This portability enables developers to build applications once and deploy them anywhere. Also, just as shipping containers enhance security by sealing goods from external elements, software containers enhance security by isolating applications from the underlying infrastructure, ensuring that they run consistently and securely regardless of the hosting environment, containers at their core share the host operating system's kernel with other containers. The shared OS components are red only, resulting in remarkable lightweight properties. This means you can deploy multiple containers on a single server or virtual machine, eliminating the need to dedicate an entire server to a single application. This not only optimize resource utilization, but also reduces the overhead of maintaining multiple operating systems. Scaling up becomes effortless, requiring no additional server space. Containerization also addresses various other challenges in software development and deployment. It provides a robust solution for mass deployment, as showncased in the deployment layer at the top of this image and here we focus on how to efficiently deploy and manage numerous containers beneath. On the bottom lies the nodes layer, encompassing the hardware and the runtime environment necessary to execute these tasks. The nodes play a crucial role in supporting containerized applications and ensuring they are seamless operation and we'll talk about both the deployment layer and the nodes layer in a little bit. Kubernetes represents nothing short of a revolution in infrastructure management. It has fundamentally reshaped the way we orchestrate, deploy, and scale applications in today's dynamic it landscape. Now let's explore the architecture of Kubernetes and compare its key components to familiar concepts in virtualization. At the heart of Kubernetes is the Kube API server, which acts as the central control point. Think of it as similar to the vcentering virtualization. It exposes the Kubernetes API, allowing users to interact with the cluster, the ETCD. It's a database that behind the scene is basically a distributed key value store. So let me go back here and it serves as the Kubernetes memory storing configurations, states and other essential information, and also in virtualization. The vcenter also relies on a database to store configuration data, so we can compare both to the vcenter. Then the Kubernetes, like we said, is API driven, offering both a command line interface and a programmatic API for interaction. This is like how we interact with Vcenter through tools like vsphere client and ESX cloud. Also in Kubernetes, pods are fundamental units that host our containers. They are like the equivalent of vms in the virtualization world, providing a layer of abstraction for running application. Then, just as virtualization platforms use hypervisor or container runtimes to manage resources, Kubernetes here employs a container runtime like Docker or containerd to oversee the execution of containers. And finally, the control plane that we'll explain more in a few slides further encompasses components like Kube, API, server, etcd, etc. To regulate the cluster's behavior. Similar to how virtualization has a control plane responsible for orchestrating the vms. Kubernetes, like we said, is the go to container orchestrator for provisioning, managing, and scaling applications. Beyond containers, kubernetes also take care of additional resources like volumes, networks, and secrets. This ensures that your apps have what they need to connect to databases, interact with firewall backends and safeguard keys. Kubernetes also operates on a declarative model, so you specify the desire state and Kubernetes takes care of the rest. If you need like five instances, for instance, you don't need to manually start them, you just tell kubernetes and it ensures your desired state is maintained. Even if something goes wrong, kubernetes will repair that and maintain that desired state. A Kubernetes cluster is essentially a collection of nodes where each node can be either a physical machine or a virtual machine. The cluster thrives on the synergy between a master and worker nodes, where the master node orchestrate and directs and the worker nodes execute and perform. This collaboration forms the bedrock of modern containerized applications deployment now talking a little bit more about the worker nodes at the foundation, a node comprises the physical hardware serving as the infrastructure backbone. Then installed on top of the hardware is the operating system, acting as the base software layer for resource management and application execution, similar to a hypervisor or a host OS in virtualization. Then to execute containers, a container runtime like docker, container Id, crio or others is installed. This software is responsible for launching and managing the containers. The Kubelet service acts as an agency on every node within the cluster. It takes commands from the master controller, and you can also think of Kubelet as a nodes coordinator, which ensures that containers run as directed. And finally, the worker node also has a cube proxy, which is another critical components residing on each node. It plays a pivotal role in proxying connections to the pods from another components known as services. This is like how a load balancer or network proxy directs traffic to various virtual machines in virtualization setups. Now the master node let's talk about the master node, which is also called a control plane. Again, this control plane is responsible for orchestrating and managing the cluster's operation. Within the control plane, the controller manages services. When you submit tasks or requests to Kubernetes, the controller reads them via the API and orchestrates their execution across the worker nodes. Then there is also another components called the scheduler, similar to configuring resource allocation in virtualization, like specifying resources for a new vm in VSphere, the scheduler that determines where to run containerized services, which are represented as pods within the cluster, it selects a suitable worker node for deploying pods, optimizing resource allocation. Now, in Kubernetes, pods serve as the lowest form of deployment. They are configured using YAML, following a declarative approach where you specify resources, container details, and more. Like creating a vm with power CLI, you define the pod's name, container location, prepackaged services, and any necessary arguments. Additionally, you can introduce a persistent devalue claim known as PVC to request storage for a non ethermoral date. Kubernetes, being an orchestration layer, manages the storage requirements specified in the PVC, creating what is known as a persistent volume, or pv. This is reminiscent of managing data stores or NFS exports in virtualization, with pvcs resembling the VM's data disk. Now, while pods are the fundamental building blocks, deployments are like the orchestration conductors that simplify the management of these pods. Think of deployments in Kubernetes as orchestration conductors for the pods. They serve as blueprints defining your application's desired state, including replica counts, container images, storage secrets, and config maps. Config maps they store configuration data as key value pairs, allowing containers to customize behavior without altering the image. For instance, environments, variable, and settings can be stored in config maps, simplifying multiple environment setups. Secrets, on the other hand, securely hold sensitive information like password or keys. They enable your application to access vital security related data without exposing it in container image or configurations. So Kubernetes continuously monitors and enforces this desired state, providing seamless updates. So whether you're changing container images or configuration in config maps or managing secrets, kubernetes handles the rollout while maintaining high availability deployments. They simplify the application management, including config maps and secrets, streamlining configuration changes, and scaling to meet evolving requirements. They are really a powerful tool for orchestrating containerized applications in a Kubernetes cluster. Now let's talk about stateful sets. The biggest myth in the Kubernetes world, and even in the virtualization operations infrastructure world, is that Kubernetes is only for stateless applications. Stateful sets empower Kubernetes to orchestrate stateful workloads and data services with efficiency and reliability. In a typical Kubernetes setup, attaching storage to a pod guarantees data persistency even if the pod is restarted. However, there is a caveat. The pod's identity remains ephemeral. So after a restart, it might reappear with a different hostname or identifier, a characteristic that doesn't align with the requirements of stateful applications. But stateful sets ensure that each pod maintains a steadfast and predictable identity, irrespective of whether it's terminated or rescheduled. So let's say, for instance, envision a scenario where a stateful set oversees three database nodes. If one of these nodes undergoes termination, it doesn't reappear as an entirely new entity. Instead, it will retain its identity and seamlessly reconnect to the same underlying storage construct, and will preserve the vital role within the cluster. So this feature, stateful sets, proves indispensable for stateful applications that require both high availability and data consistency. Now another important components with Kubernetes is services. They play a crucial role in managing communication and ensuring the availability of containerized applications. Imagine another scenario where you have multiple instances of a service running for high availability. You need an efficient way to communicate with them. And now think of services as a traffic coordinator within your cluster. When external traffic comes in, you can create an ingress layer which acts like a load balancer, directing requests to the appropriate destination. Each destination is represented by a pod, and these pods, they can be independent and dynamically managed, spun up, spun down, or updated as needed. So like, let's say, let's consider a WordPress application. In a traditional setup, everything might run on a single virtual machine, making it challenging to scale individual components. But with containerization and kubernetes, you can have individual pods for each service, such as authentication, content and more. This modular approach allows you to scale each service independently. So if your WordPress site experiences a surge in traffic, you can add another service layer, acting as a load balancer to distribute the load efficiently. Kubernetes services, they simplify the management of communication and scalability in your containerized application. Now finally, network policies in Kubernetes are application centric rules that determine how pods can communicate with different network entities. Essentially, they control the flow of traffic at the IP address or port level, operating at OSI layers three and four. So by default, in the absence of specific policies in a namespace, all inbound and outbound traffic is permitted for pods within that name within that namespace. These policies are a vital tool for fine tuning and securing network communication within your Kubernetes environment, allowing to define precisely how your pods interact within the network. Now, just to finish this, let's recap about how Kubernetes reflects in the virtualization world. Kubernetes excels in managing modern cloud native workloads, offering dynamic scaling and efficient resource virtualization, while virtualization still remains a robust choice for legacy applications. But understanding the right tool for your workload is crucial because as all organizations seek future ready infrastructure solutions, there will be an integration between Kubernetes and virtualization in hybrid environments and it will be a very powerful strategy. So this approach bridges the gap between traditional workloads and cloud native applications. Additionally, I just want to mention that solutions like Kasten by Vim simplified the migration process from virtualization to kubernetes, ensuring a seamless transition and providing data management capabilities for crucial for modern workloads. So if you have more questions and if you're interested about that, feel free to check out Castin IO or reach out to me on social media. I would be glad to answer any questions that you have on this presentation or on Kubernetes or even on virtualization. I hope this presentation was helpful and thank you for watching it. Bye.