Cloud Native Computing Foundation / Kubernetes Community Days Bangalore 2022

There is a presumption in the industry that with the advent of cloud and agile processes , having a solution architecture practice is sometimes a hindrance. The prevalent idea is - we can just use the tools provided , and call them one by one , no need for architecture design . I want to focus the talk on how NFRs help in designing a Cloud native solution , and the important role the Solution Architect plays within an enterprise .
At the end of the talk , I want every developer/cloud engineer/k8 operator to understand , that no matter , what role they play within the enterprise , it still pays to think about architecture. I also want to focus on how having a central architecture / CCOE team , that deploys best practices , patterns , and principles across the enterprise , can help , and how to setup such a team in an organization .

Developers and operators should be able to interact with Kubernetes clusters in a collaborative manner. Teams often collaborate in a chat application like Slack/Teams and this is how the idea of BotKube was born. BotKube is a bot for your Kubernetes cluster - you can talk to Kubernetes clusters using the same Kubectl commands. BotKube also comes built with plugins and extensions which inform you of critical problems in the cluster. The extensible architecture allows you to plug any external tool which can give one useful information about the cluster. This talk will demo BotKube interacting with a Kubernetes cluster and a developer trying to fix a failed deployment in the cluster using BotKube. And hopefully, the developer succeeds in his endeavor!

Supply Chain Security issues are on the rise. Supply Chain Security tools will ensure that whatever you are downloading from container registries is not tampered with. But the granularity of these tools is way too coarse. They work at the container image level. How do you ensure the continuous security of the apps shipped inside the container image? How do you secure the app against attacks where an attacker gains access to the container and replaces the app binaries? There are various ways supported in the k8s land, but they give you all or nothing solutions. How do you actively thwart someone from executing anything that is not shipped inside the image? This talk will showcase novel ideas using Linux Kernel technologies to implement solutions to block untrusted binary execution.

Cluster API is a Kubernetes sigs projects that provides a declarative way to create and manage Kubernetes clusters on many providers like Azure, AWS, GCP etc. In this talk, we will help understand how Cluster API is a consistent API across providers which not only enables broader use cases like hybrid and multi-cloud, but it also provides standardised tooling that can talk to this interface by providing blueprint of it’s components on top of which the provider components are built-up. They will touch upon the various involved controllers in cluster API and how the cross communication happens with the hooked in provider controllers in order to provision a Kubernetes cluster with a demo.
The audience should walk away with a good understanding of Cluster API projects, it's involved apis, machinery and how infrastructure provider gets integrated with Cluster API. This talk should be different that other existing Cluster API talks as it talks mostly around the APIs and how different involved controllers communicate and perform various tasks.

This talk/demo will show how Dapr decouples observability (i.e. distributed tracing, metrics, logging & health) from the application development. There’s no need to reference libraries or implement custom instrumentation code. Dapr allows the developer to focus on building business logic instead of observability plumbing. We will see how easy it is to move the app to a different monitoring platform using Dapr.

The session will focus on design choices and tradeoffs we made to reach the scale of ingesting 1mn events/s to an open source observability tool (SigNoz) Key points to be covered: - Horizontally scaling OpenTelemetry collector in Kubernetes - Designing hierarchy of OpenTelemetry collectors (cluster level/node level/sidecar level) - Extracting metrics from traces using spans2metrics processor - Getting application metrics and infrastructure metrics in the same UI - Why distributed columnar database is efficient for storing telemetry data

With dockershim removal scheduled in v1.24 release of Kubernetes, there have been a lot of confusion regarding this. In this talk, I will majorly discuss the "why dockershim removal" was necessary and discuss how the "shim" and container runtime are quite unrelated will further focus on the container ecosystem and the readily available options.
The talk will also focus on how CRI makes it easier for Kubernetes to use different container runtimes. It will include adequate links to available resources to help people understand the migration and make necessary changes.

The existing Test Framework is intrinsically baked into Kubernetes source code repository with organically grown assumptions over the years that shape how tests are created and executed. This, however has presented some shortcomings including: Difficulty of consuming existing test framework packages from outside of the Kubernetes project, Misaligned framework design can cause dependencies on unnecessary resources, the requirements to use Ginkgo as a way to write tests.
To resolve these difficulties we have come up with a new framework called e2e-framework which is now residing under https://github.com/kubernetes-sigs e2e-framework provides ways that make it easy to express test functions that can programmatically test components running on a cluster. The two overall goals of this framework are to allow developers to quickly and easily assemble end-to-end tests and to provide a collection of support packages to help with interacting with the API-server. It provides a uniform API to work with typed and untyped Kubernetes API objects.

Cause I am in tier-3 college many people don’t know about open source projects, how the world is impacting with technologies. How can we contribute to it? Then I realized why don”t I start a community and engage people about technology. Then, I attended kubecon 2020. It was my first ever huge conference i attended and it helped me a lot in finding new people from various places who are willing to learn about devops and has a passion for technologies. And I resolved to make kubernetes easy to understand by the students in a lame way. The talk will be very begginerly, understanding kubernetes from its origin to how it's now ruling the tech industries.

This talk is intended for why it is important to start in-house (within company) kubernetes community activities. Why developer engagement through kubernetes community is important , so insight and approach how one can develope and push within company. How to keep the engagement on and What benefits such community at the end can bring on the table.

In all open source projects like Cluster API and its providers we initially start with alpha releases, however, eventually, most of these projects will need to move to a more stable API and that's why they made multiple releases and introduced some changes in the existing APIs. Since now we support different versions, and users can request either version, so we need to define a way to convert between our versions. These API changes can include addition, deletion and renaming of some existing and new fields in the existing CRDs, but while introducing these changes we need to make sure we should not break and continue the support for older versions. So to attain this stability we need to write some conversion functions and to understand the logic behind these, we first need to understand Hubs, Spokes and other wheel metaphors that are heavily used in writing those conversion functions.
A simple approach to defining conversion might be to define conversion functions to convert between each of our versions. Then, whenever we need to convert, we’d look up the appropriate function, and call it to run the conversion. This approach works fine when we just have two versions, but what if we had 4 types? 8 types? That’d be a lot of conversion functions. So to understand this problem and unblock all the new contributors, we want to present this talk where we can brief the concepts used to write the conversion function and also give a demonstration of how you can update any API and extend the support for older versions.

Certificates are an integral part of a secure Kubernetes cluster deployment. They are mainly used to secure the Kubernetes API server using TLS, but certificates (and keys) are also used for other cluster functions such as client authentication, and encryption of secrets. It provides security and identity to all components of Kubernetes. What I am going to talk about:
1. What is a PKI and what are certificates?
2. Why does the world need them?
3. How do I create a CA, certificates and sign them?
4. What's the significance in Kubernetes?
5. How do I handle certificates in Kubernetes?
6. What are the tools to generate certificates?
7. How does Kubeadm automatically generate the certificates for K8s Cluster?

Namespaces are a great way to achieve soft multi-tenancy in Kubernetes, but fall short of many use cases from the practical world. Hierarchical Namespaces was born out of these needs and is a kubernetes-sigs project. In this talk we will look at some practical examples and how HNC(Hierarchical Namespace Controller) helps in achieving those goals with some samples and demos. Some of real world examples we will talk about:
1. How to organise smaller teams within an umbrella organisation needing similar accesses & policies
2. How to achieve governance through policies which are global, but also applicable for a set of teams etc.
3. Enable teams to create namespaces as needed without needing central admin teams to help them or without giving higher level of access.
4. How to limit the resources and exclude namespaces from HNC (which may be required in big multi-tenant clusters)

The Cloud Native community has a large number of contributors, each with their own unique story on how they became a project maintainer or a community member. I want to share stories of a few of these key individuals while also highlighting how the CNCF helped them along their journey.

The Kubernetes Service Proxy is a critical extension point for businesses wanting to expand the scope of cloud native applications to more sophisticated networking models, larger scale clusters and for designing better services mesh technologies. Some might even say it is "the thing" that differentiates Kubernetes networking from other container platforms. For several years, extending it has required copying and pasting code from Kubernetes, or rebuilding its extremely sophisticated caching logic piecemeal.

Kube Proxy Next Generation (KPNG) is a Kubernetes SIG Network project which decouples the dataplane (backend), from the Kubernetes specific logic of the Service Proxy, allowing for innovation in the way networks are built on Kubernetes without the need for adding more technical debt to Kubernetes core. The KPNG project supports multiple operating systems and allows users to easily plugin high performance, in-memory service proxying technologies that are entirely powered by a GRPC integration layer.

This reduces load on the APIServer and creates a service extension model for Kubernetes. KPNG project is rapidly growing and the community is engaging and passionate about its overall mission. In this session, we will showcase how KPNG is structured to tackle the pain points around current implementation of Kubernetes Service Proxy along with a demo of KPNG in different backends like nft, iptables, ipvs and how to reason about kube-proxy’s logic in any mode, using a generic model. KPNG being a nascent project, we will also talk about what lies ahead and give a sneak peek of the project roadmap.

Kubectl commands are one of the essential building blocks which help in interaction with the Kubernetes cluster and using Plugins as sub-commands with it helps in extending the features of kubectl. In this talk, I will be explaining what Kubectl plugins are and how it is managed and installed by Krew, an open-source plugin manager for kubectl. Along with this, different kubectl plugins will be explained by showing a practical demo of them which will give attendees a better understanding of plugins and how to adapt it and use it in daily practice.
Some of the widely used plugins are kubectx,kubens, popeye, and so on. I am a final year Computer Science Engineering student who is learning about Kubernetes and the cloud-native world. I am working as a technical writer where I write blogs related to different cloud-native projects and kubectl plugins attracted me the most in the Kubernetes project and I decided to give a talk on kubectl plugins. As kubectl plugins are managed through Krew and these plugins give new and custom features to kubectl and give a way to consolidate common Kubernetes management actions in a way that are easily distributed across the team and it correctly fits in KCD and in an open-source ecosystem as these plugins help users and developers to manage and enhance kubectl, as well as giving a motivation to contribute in it.

Kubernetes has become the go-to container orchestration system when it comes to deploying microservices-based applications to production. Due to this, being able to replicate production like Kubernetes-based environments during development is becoming tremendously valuable. These development environments are particularly useful because: - They ensure that while developing, developers see the application exactly as it would look in production - Using Kubernetes features like Volume Snapshots in these environments allows developers to replicate huge production databases during development in a matter of minutes - They free up a lot of resources on machines by providing a way to avoid running resource-intensive tools This talk will cover what Kubernetes-based development environments are, why they are useful, and how you can set them up easily using open source tools.
This talk will be beneficial for the ecosystem for the same reasons the adoption of dev environments has been growing - it significantly increases developer productivity! Ever since switching to development environments, developers have reported: - Being able to completely deploy huge applications in minutes by leveraging cloud resources - A super quick onboarding experience for new and existing developers alike - Extremely fast data replication thanks to Kubernetes. A production database of 100 GBs can be replicated in dev environments in a matter of minutes - giving developers access to real data to work with during development After the talk, the viewers would not only understand how Kubernetes is shaping the future of modern-day development but also learn how they can get started using these development environments!

Kubernetes is the most widely adopted cloud-native container orchestration tool. While companies are widely adopting Kubernetes for their microservice architecture solutions for the much-required competitive edge, it is paramount to ensure the resiliency of these systems for ensuring reliable services for everyone. But how can we ensure the reliability of these systems while they change at the pace of hours and minutes for the much-required competitive edge?
LitmusChaos is an end-to-end chaos orchestration framework that can assess the reliability of your cloud-native systems against the unforeseen weaknesses that lead to its failure. In this talk, we'll talk about why resiliency is the cornerstone of every cloud-native application architecture and how LitmusChaos can help DevOps engineers and SREs to validate the reliability of an entire business use case.

Developers can leverage container tools such as Kubernetes, Docker and CRI-O to deploy, manage, and run lightweight WebAssembly applications. In this talk, there will be a demonstration of how Kubernetes ecosystem tools work with WasmEdge WebAssembly applications. Compared with Linux containers, WebAssembly could be 100x faster at startup, have a much smaller memory and disk footprint, and have a better-defined safety sandbox. However, the trade-off is that WebAssembly requires its own language SDKs, and compiler toolchains, making it a more constrained developer environment than Linux containers. WebAssembly is increasingly used in Edge Computing scenarios where it is difficult to deploy Linux containers or when the application performance is vital.

A Machine Learning model is only a tiny piece in a series of multiple processing steps executed as part of an ML workflow. A pipeline is a description of an ML workflow, including all the components in the workflow and how they combine in the form of a graph. This talk will provide an overview of ML pipelines, its common components and how to orchestrate the execution of Cloud Native ML pipelines in Kubernetes, using open-source project Kubeflow.

In this talk, I will be explaining how one can run local Kubernetes clusters using various tools such as minikube, kind, and microk8s.

While all of us have used kubernetes scheduler, but very few of us must have heard of Descheduler. The descheduler is a kubernetes-sigs project which works as an add-on to an existing Kubernetes cluster and can help in overcoming the scheduling problems. The descheduler can be added to cluster in the form of a Job, Deployment or as a Helm chart.

Kubernetes is the preferred container orchestration engine to manage microservices to build & deploy applications. However, to effectively manage the application deployment across multiple environments is still a challenge. How do we handle such situations of deploying applications across multiple environments in a safer & transparent way? Is there a way to do it?

Yes we have ArgoCD which continuously watches different cluster objects & Git repositories to make sure resources are in sync & Tekton which is Kubernetes-native & provides a lot of ready to use resources which will be helpful for users to write Pipeline. Tekton & ArgoCD together is like a match made in Kubernetes Heaven. Let's team up Argo with Tekton. In this talk, you will hear how easy it is to leverage these two cloud native technologies together & build CI/CD solutions for your project. As part of this talk, you will hear - Intro to Tekton & ArgoCD - How we can build CI/CD using Tekton & ArgoCD - Live demo

At Intuit, we’ve been building our Kubernetes Platform for several years now. We are running our kubernetes clusters on Amazon EKS. As more services are onboarded into Kubernetes clusters we realized we were running out of Ingress subnets as we provision Alb Ingress for every service. As we were reaching thresholds on the Ingres subnets instead of creating new clusters we thought of scaling the clusters vertically by expanding VPC's. This process of scaling Kubernetes clusters vertically by expanding VPC's should be done seamlessly so that we do not run into any issues with services already running on them.
We adopted a gitops framework where we update the VPC's using a configuration file that gets translated to cloudformation stacks and then gets executed on the target account where we want to expand VPC. Once VPC is expanded then we use a Gitops framework to update the kubernetes cluster by passing in the expansion name so that the cluster can then consume the new subnets created and assign the subnets to ALB's that have least used subnets this helped us reduce creation of additional kubernetes clusters and hence the overhead.

Rudderstack is an (open source) data pipeline company that helps send data from any source to any destination. In this talk, We want to start by explaining the Rudderstack architecture which is used to send data from any source to any destination that is similar to Kubernetes (ControlPlane/DataPlane), and how we deploy everything on Kubernetes using aws EKS. Following this focus is on giving a few case studies related to our incidents with Kubernetes and what actions we took to prevent the same to happen in the future.
Some examples are mentioned below: 1. How we took down the Kubernetes cluster by deleting config map 'aws-auth' that manages complete access management with EKS. Explain how we prevented this from happening again using the OPA gatekeeper. 2. How the EC2 worker node going down caused some downtime. Explain our runbook and how we improved the time to recover. We like to cover 3-4 such cases with our timeline of recovery and what action we took to prevent this from happening or improve recovery time.

In this workshop we'll be covering basics for Kubernetes. We'll start by learning its architecture and explore different building blocks like Pods, ReplicaSets, Deployment etc. We would then explore the Service object and see how we can expose our applications with different configurations.

With a growing number of developers building Cloud Native applications with Kubernetes as the preferred platform, managing workloads on Kubernetes effectively and then packaging and distributing these applications while ensuring reproducibility and security has been on the top of their minds.

This workshop starts with the fundamentals of cloud native application development with emphasis on GitOps and does a deep dive with Carvel. At the end of the workshop, the audience will learn how to manage and run their workloads on top of Kubernetes.

Carvel provides a set of reliable, single-purpose, composable tools that help you build, configure and deploy applications on Kubernetes. Carvel tools help reduce the burden of managing workloads on kubernetes, are transparent with the user and have a strong focus on simplicity to make the process of managing workloads intuitive.These tools follow the UNIX philosophy allowing users to integrate them with other tools that are already a part of their workflow conveniently.

When put together with each other, the tools allow users to declaratively set up GitOps (and other single-source-of-truth) workflows for deploying their resources on Kubernetes. Carvel's declarative APIs also allow users to package, version and distribute such workflows to consumers - with special considerations for air-gapped environments. The powerful CLI tools ensure that the workflow can be reproduced while developing the applications reliably, and become an essential part of the development process.

The speaker will be mainly presenting\talking about how to achieve Progressive Deployment(Canary/Blue-Green deployment) using Argo-Rollouts

Chaos Engineering has evolved in the past few years with the development of the Cloud-Native paradigm. Chaos testing is seen as a must for all Cloud-Native practitioners emphasizing reliability as a container challenge. With the introduction of the LitmusChaos tool which helps curate Cloud-Native Chaos Engineering in a controlled way, practicing Chaos has become easier. Belonging to the CNCF ecosystem, Litmus stresses upon applying Chaos Engineering to modern architectures and building resilient applications simultaneously. The features and ideas majorly surround Community Collaboration, Observability, GitOps, Open APIs & much more. This talk stresses on the evolution of Chaos Engineering with the introduction of the LitmusChaos 2.0

Istio is the most popular service mesh deployed into production across the cloud-native ecosystem, and for good reason. It’s feature rich, open-source, and most importantly, battle proven.
The workshop series for those looking to learn more about how Istio works and how to operationalize it for their organization. We cover things like the basics of routing, observability, and security, and then expand into leveraging Istio for a devops/gitops CI/CD flow, zero-downtime upgrades of Istio control plane, plugging in with existing PKI, and running Istio on VMs and across multiple clusters.
The Deploy Istio for Production Workshop is a hands-on workshop focused on what it takes to deploy Istio into production. You will have access to your own linux virtual machine with a Kubernetes cluster and Istio to complete the exercises. This is not an entry level workshop to learn about Istio. This workshop includes a certification option. This credential, by Solo.io, certifies that recipients possess the essential skills to deploy Istio, configure it, debug it, secure it and operationalize it for their organization.

Kyverno (which means “govern” in Greek) is a policy engine designed for Kubernetes. With Kyverno, policies are managed as Kubernetes resources and no new language is required to write policies. This allows using familiar tools such as kubectl, git, and kustomize to manage policies. Kyverno policies can validate, mutate, and generate any configuration data or Kubernetes resources plus ensure OCI image supply chain security. The Kyverno CLI can be used to test policies and validate resources as part of a CI/CD pipeline.

While the declarative nature of Kubernetes makes it very powerful, and provides self-healing capabilities, it also greatly increases the amount of configuration that has to be managed. To properly declare and control state, Kubernetes provides a lot of configuration knobs – and these will keep growing over time as new capabilities are added. Another challenge is determining whose responsibility it is to configure the right settings, for security, best practices, and standardization.

The solution to this challenge is to use policies to validate configurations for best practices and security compliance, and also automatically modify and generate additional configurations when needed.

If you are operating Kubernetes environments, check out Kyverno to help address Kubernetes complexity and easily enforce security and best practice policies across clusters and workloads.

While Kubernetes has become a de facto standard for running the Cloud Native workloads, the platform on which Kubernetes runs remains pretty diverse. Kubernetes multi-cloud story is about providing the platform and infrastructure engineers of an organization the freedom to create and manage production grade conformant Kubernetes clusters on infrastructure of their choice.

There are several projects that have come up to solve the challenges around managing the Kubernetes Lifecycle Management, with Cluster API becoming a standard way to tackle the problem.

This workshop will start with an introduction of the challenges around Kubernetes Lifecycle management from Day-0 to Day-n and deep dive into the Cluster API projects that tackle them in a declarative way. As an example, we will demonstrate how to use CAPI providers to manage Kubernetes Clusters on AWS and bare metal.

There are so many things you can track and observe in Kubernetes. The big question is - which one is essential that I should pay attention to immediately? In this talk, we will discuss and share our opinions, observations, and how to get started.

Why Kubernetes is the essential foundation for any organization looking to leverage multiple different infrastructures across their application portfolio.