KubeCon + CloudNativeCon Japan 2025

Open source communities are a celebration of our different cultures. The single reason open source communities are able to build and ship software like Kubernetes, which is used so widely, is because of the collaboration of people from all around the globe.

This also means a lot of challenges when people are working together, like language barriers, cultural differences and timezones. In this talk I'll be sharing some lessons I've learnt about fostering open source communities amidst the differences. In the last two years, serving in the K8s release team and as the SIG Docs New Contributor Ambassador, I've experienced first hand how challenges like language barriers can hinder enthusiastic contributors. This talk is about these different challenges and how we can overcome them.

In an effort to inspire everyone in the open source community to embrace our differences and welcome everyone as we work together, I'm learning Nihongo to attempt giving this talk in the Japanese language.

Excessive DNS query pressure can cause CoreDNS failures, leading to a cluster-wide meltdown. Thus, per-pod or per-node DNS proxy is a common high-availability solution. By binding the clusterIP of the kube-dns service to the local node, node-local DNS can provide seamless DNS interception and proxying, meeting the demands of low latency and high throughput. However, proxy's breakdown can directly lead to access failures, lacking high availability.
To solve this issue, we use cgroup eBPF to implement enhanced service redirection for node-local DNS, inspired by Cilium's LocalRedirectPolicy. Based on the health status of the local proxy or the redirection QoS strategy, the query of the kube-dns service can be dynamically resolved to the local node-local DNS, otherwise normally forwarded to CoreDNS. This scheme is independent of the CNI, and could cooperate with kube-proxy, offer multiple service redirection strategies and provide production-grade quality assurance for node-local DNS.

When a process like /usr/bin/curl runs in a pod (e.g., xwing in the default namespace), Tetragon detects it like bellow:

```
🚀 process default/xwing /bin/bash -c "curl https://ebpf.io/applications/#tetragon"
🚀 process default/xwing /usr/bin/curl https://ebpf.io/applications/#tetragon
💥 exit default/xwing /usr/bin/curl https://ebpf.io/applications/#tetragon 60
```

But how does it map that process to its pod?

This Lightning Talk explores how Tetragon connects the Linux kernel to Kubernetes by enriching eBPF-detected process data with Kubernetes metadata. I’ll break down how it extracts cgroup information from task_struct in kernel space and maps it to pod details using the Kubernetes API.

While typical web applications do not require large amounts of resources constantly, there are cases where specific processes consume significant CPU and memory.
In this session, we will introduce an architecture that offloads such resource-intensive processes to Kubernetes Jobs.
We will explain specific methods for Job management, how to integrate web applications (Next.js, @kubernetes/client-node) with the Kubernetes API, methods for data integration between Jobs and web applications, and real-time tracking of Job progress in the UI, all while sharing practical examples. Furthermore, we will provide a detailed introduction to a pattern where Kubernetes Job definitions generated from applications are managed using ConfigMaps, enabling quick configuration switching between environments, and offer hints to optimize your applications in terms of cost, performance, and management.

Knative is a widely adopted CNCF-hosted software for running serverless applications using Kubernetes. Knative Serving consists of many system components, such as Activator, Autoscaler, Controller, Webhook, and Istio or Kourier as an ingress gateway. Therefore, end users need to implement monitors for common error patterns and best metrics from many metrics. However, there is relatively little knowledge and resources for Knative end users.

This talk will present a production case study of monitoring for Knative Service. Specifically, it will explain how we can monitor Knative control plane efficiency, reconciliation operations, pod scaling health, concurrency observation, HTTP request success rate, and more.
That includes how Knative components implement Prometheus metrics, metrics pipelines (on Google Kubernetes Engine), dashboards and alerts.

This case study will benefit existing Knative users and potential users considering employing Knative in their Kubernetes clusters.

Have you ever used automatic PVC resizing tools in Kubernetes? Have you ever encountered a situation where newly created PVCs remained at the small, template-defined size, causing capacity shortages during restores or clones?

To address this challenge, this session introduces a new approach in pvc-autoresizer, one of the tools for automatically resizing PVCs. By aligning newly created PVCs with the largest capacity in the same group, it ensures that PVCs have sufficient space right from creation time. Using annotations and a Mutating Webhook, we avoid capacity shortages during restores by provisioning enough volume capacity immediately after a PVC is generated. We will also explain why we chose a Webhook-based method over a Controller-based one, along with the design trade-offs involved.

Anyone seeking to enhance reliability for stateful workloads should not miss this session. Learn how a new PVC management strategy can deliver more stable Kubernetes storage.

Join us for an exciting overview of the latest developments in Prometheus-Operator! This lightning talk will explore game-changing features, including the new ScrapeClasses for simplified monitoring configuration, DaemonSet Mode in PrometheusAgent for enhanced deployment flexibility, and expanded Service Discovery support across multiple cloud providers.

We'll explore how these additions, along with our improved documentation and new Scale Subresource capabilities, are making Prometheus-Operator more powerful and user-friendly than ever. You'll also learn about "poctl", our new command-line tool that is designed to handle Prometheus-Operator custom resources.

Plus, get a sneak peek into our roadmap and upcoming features that will shape the future of Kubernetes monitoring. Perfect for anyone interested in Kubernetes monitoring, this talk will equip you with knowledge about the latest tools to enhance your observability stack.

When using container image vulnerability scanners like Trivy, a large number of vulnerabilities may be detected. However, not all of them necessarily require an action. This is because not all libraries or command-line tools included in the container image are actually utilized.

For example, the `python:3.12.4` image includes a `git` binary with the vulnerability CVE-2024-32002. This vulnerability does not need an immediate action if it is known that the Python application being run does not execute `git` commands.

VEX (Vulnerability-Exploitability eXchange) formats such as OpenVEX can be used to suppress such false alarms.
However, VEX is still not widely adopted due to the difficulty of manual analysis and classification of vulnerabilities.

This presentation introduces VexLLM, a tool that helps writing VEX by leveraging LLMs. VexLLM is available as a plugin for Trivy.

GitHub: https://github.com/AkihiroSuda/vexllm