# control-plane Published articles for control-plane. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Kubernetes Architecture: Control Plane, Scheduler, and Kubelet DevFeed: [Kubernetes Architecture: Control Plane, Scheduler, and Kubelet]() Original publisher: [Read original article]() Author: Nimesha Jinarajadasa Published: 2026-09-17T06:25:02Z Content type: tutorial Language: en Sources: [Kubernetes - KodeKloud Blog | DevOps, Cloud, Kubernetes, AI Tutorials & More]() Topics: [Kubernetes](), [control-plane](), [api server](), [Containers](), [etcd](), [kubectl]() Tags: [api](), [api-server](), [containers](), [control-plane](), [controllers](), [etcd](), [kubectl](), [kubernetes](), [kubernetes-architecture](), [kubernetes-networking](), [node](), [scheduler]() ### AI overview A beginner-friendly tutorial explaining how Kubernetes maintains the desired state of containerized applications. It covers the control plane, API server, etcd, controllers, scheduler, and kubelet. ### Source excerpt Learn how Kubernetes works, from the control plane and scheduler to kubelet, pods, and Services, with simple answers to interview questions. ## Why Senior Leaders Should Attend Post-Incident Reviews for Major Cloud Incidents DevFeed: [Why Senior Leaders Should Attend Post-Incident Reviews for Major Cloud Incidents]() Original publisher: [Read original article]() Author: Sridhar Rajarao Published: 2026-08-29T00:00:00Z Content type: opinion Language: en Sources: [Sridhar Rajarao]() Topics: [incident](), [Cloud](), [control-plane](), [Deployment]() Tags: [cloud](), [control-plane](), [customers](), [deploy](), [incident](), [incident-management](), [leadership](), [major](), [operations](), [post](), [postmortems](), [reliability](), [review](), [service]() ### AI overview The article argues that senior leaders should attend Post Incident Reviews for major cloud incidents because failures can affect many customers and teams. Leadership helps approve cross-team changes, resolve trade-offs, and ensure corrective actions are completed. ### Source excerpt For major incidents, a Post Incident Review is not an operations meeting. It is where leaders remove the blockers that keep the service from becoming safer. ## 【kube-apiserver】控制面全景：缺口、五轴坐标系与 16 篇路线 DevFeed: [【kube-apiserver】控制面全景：缺口、五轴坐标系与 16 篇路线]() Original publisher: [Read original article]() Author: Liao Tonglang Published: 2026-08-28T00:00:00Z Content type: tutorial Language: zh Sources: [土法炼钢 - 系统与基础设施]() Topics: [Kubernetes](), [etcd]() Tags: [admission](), [apf](), [apiserver](), [auth](), [control-plane](), [distributed](), [etcd](), [kubernetes](), [network](), [overview](), [storage](), [v1-30-3](), [watch](), [watch-cache]() ### AI overview This article maps gaps in existing coverage of the Kubernetes control plane and proposes a 16-part reading route organized around Storage, Watch, Admission, Auth, and APF. It anchors the discussion to Kubernetes v1.30.3 and etcd v3.5.33, focusing on how requests travel through kube-apiserver and how to distinguish admission, caching, backend, and timeout failures. ### Source excerpt 相对 etcd/13、distributed/50、k8s-network 补齐 kube-apiserver 生产内核缺口；以 Storage/Watch/Admission/Auth/APF 五轴为坐标系定义 16 篇阅读路线；版本锚定 Kubernetes v1.30.3。 ## 【etcd】生产全景：缺口、五轴坐标系与 16 篇路线 DevFeed: [【etcd】生产全景：缺口、五轴坐标系与 16 篇路线]() Original publisher: [Read original article]() Author: Liao Tonglang Published: 2026-08-26T00:00:00Z Content type: article Language: zh Sources: [土法炼钢 - 系统与基础设施]() Topics: [etcd](), [Kubernetes]() Tags: [control-plane](), [distributed](), [etcd](), [kubernetes](), [lease](), [mvcc](), [overview](), [raft](), [v3-5](), [v3-5-33](), [wal](), [watch]() ### AI overview This article positions an etcd production series by identifying gaps in existing coverage and defining five troubleshooting axes spanning Raft consensus, WAL persistence and recovery, MVCC storage and capacity, Watch behavior, and Lease handling. It anchors the series to etcd v3.5.33 and points to Kubernetes control-plane coupling and a 16-article reading route. ### Source excerpt 相对 distributed/50、39、13 钉清 etcd 生产内核缺口；定义 Raft/WAL/MVCC/Watch/Lease 五轴排障坐标系，给出 16 篇阅读路线与 K8s 控制面耦合指针。版本锚定 v3.5.33。 ## 【etcd】Kubernetes 控制面耦合：apiserver、resourceVersion 与 Node Lease DevFeed: [【etcd】Kubernetes 控制面耦合：apiserver、resourceVersion 与 Node Lease]() Original publisher: [Read original article]() Author: Liao Tonglang Published: 2026-08-26T00:00:00Z Content type: tutorial Language: zh Sources: [土法炼钢 - 系统与基础设施]() Topics: [etcd](), [Kubernetes](), [API](), [Cache]() Tags: [api](), [apiserver](), [cache](), [control-plane](), [distributed](), [etcd](), [kubernetes](), [lease](), [mvcc](), [node-lease](), [raft](), [resourceversion](), [v3-5-33](), [watch](), [watch-cache]() ### AI overview This article explains how Kubernetes control-plane components interact with etcd. It covers the kube-apiserver boundary, the mapping of resourceVersion to etcd mod revision, Node Lease storage, watch cache behavior, and how compaction, caching, and event sharding affect troubleshooting and etcd load. ### Source excerpt 钉 kube-apiserver 与 etcd 的分层边界；resourceVersion 如何映射 Revision MVCC；Node Lease 如何落在 Lease 轴；以及 apiserver 超时应如何分列到 Raft/Watch/Quota 五轴。 ## 【Istio 控制面】控制面全景：从 CRD 到 xDS 的翻译与推送内核 DevFeed: [【Istio 控制面】控制面全景：从 CRD 到 xDS 的翻译与推送内核]() Original publisher: [Read original article]() Author: Liao Tonglang Published: 2026-08-11T00:00:00Z Content type: article Language: zh Sources: [土法炼钢 - 系统与基础设施]() Topics: [istio](), [Architecture & Design]() Tags: [ambient](), [control-plane](), [gateway-api](), [istio](), [istiod](), [k8s](), [kubernetes](), [network](), [pilot](), [service-mesh](), [sidecar](), [xds]() ### AI overview This first article in a 16-part series maps the Istio control plane's role between configuration inputs and proxy-side xDS consumption. It defines five analytical axes and uses Istio 1.30.3 as its version anchor, while outlining the series' scope and boundaries. ### Source excerpt 定位 Istio 控制面内核相对 Envoy 消费侧、Service Mesh 税文与 Gateway API 资源模型的缺口；给出五条坐标系、16 篇地图与本系列明确不写的范围，钉住 istiod 1.30.3 为主线。 ## Running out of runway: Migrating Temporal Cloud's billing store to ClickHouse DevFeed: [Running out of runway: Migrating Temporal Cloud's billing store to ClickHouse]() Original publisher: [Read original article]() Author: Paul Oh Published: 2026-08-11T00:00:00Z Content type: article Language: en Sources: [Temporal Blog]() Topics: [clickhouse](), [Cloud](), [data](), [Databases]() Tags: [clickhouse](), [cloud](), [control-plane](), [cost](), [data](), [database](), [databases](), [parallel](), [results](), [table](), [temporal-voices]() ### AI overview Temporal Cloud migrated its billing store to ClickHouse after its previous warehouse had limited capacity. The migration provided three to five years of projected headroom, reduced steady-state costs by about 70%, and delivered usage data to customers roughly 30 minutes sooner. Temporal validated billing accuracy by running both databases in parallel for six weeks. ### Source excerpt How Temporal Cloud migrated its billing store to ClickHouse, gaining years of headroom, cutting steady-state costs by about 70%, and improving data freshness. ## 【Istio 控制面】Linkerd 对照：非 xDS 的控制面机制 DevFeed: [【Istio 控制面】Linkerd 对照：非 xDS 的控制面机制]() Original publisher: [Read original article]() Author: Liao Tonglang Published: 2026-08-11T00:00:00Z Content type: article Language: zh Sources: [土法炼钢 - 系统与基础设施]() Topics: [istio](), [linkerd](), [API](), [proxy]() Tags: [api](), [control-plane](), [destination-controller](), [envoy](), [go](), [identity](), [istio](), [istiod](), [kubernetes](), [linkerd](), [mechanism-comparison](), [network](), [policy](), [proxy](), [route](), [rust](), [service](), [serviceaccount](), [sidecar](), [xds]() ### AI overview This article compares Linkerd's control-plane architecture with Istio's istiod and xDS model. It describes Linkerd's separately deployed destination, identity, and proxy-injector components; its proxy-specific gRPC APIs; and its CSR-based identity issuance, contrasting these with Istio's consolidated control plane and xDS/SDS resource model. It explicitly avoids declaring either system superior without workload-specific evidence. ### Source excerpt 以官方文档为准，对照 Linkerd destination/identity 控制面与 Istio istiod/xDS 的机制差异：资源模型、订阅形状、身份签发路径；只讲机制边界，不判定优劣。 ## Building a Minimal Control Plane to Reconcile Docker Containers for Model Serving DevFeed: [Building a Minimal Control Plane to Reconcile Docker Containers for Model Serving]() Original publisher: [Read original article]() Published: 2026-07-02T00:00:00Z Content type: tutorial Language: en Sources: [Alex Korbonits]() Topics: [control-plane](), [model-serving](), [Docker Container](), [Amazon Machine Learning](), [Streaming]() Tags: [container](), [control-plane](), [inference](), [model-serving](), [python]() ### AI overview The author explains control planes by building a small Python-based system that maintains a declared number of Docker containers for model serving. The system repeatedly compares desired and actual state and reconciles differences, including restoring a container after it stops. ### Source excerpt I can design batch, real-time, and streaming inference -- the data plane. But I'd never built the control plane that manages it. So I built the smallest one I could, from scratch, to finally understand reconciliation: the one idea that separates a control plane from a deploy script. ## In-place pod restarts: Boosting efficiency and workload reliability in Kubernetes v1.35 DevFeed: [In-place pod restarts: Boosting efficiency and workload reliability in Kubernetes v1.35]() Original publisher: [Read original article]() Author: Google Open Source (noreply@blogger.com) Published: 2026-06-18T18:30:00Z Content type: article Language: en Sources: [Google Open Source Blog]() Topics: [Kubernetes](), [reliability](), [Resilience](), [Containers](), [distributed-systems](), [etcd](), [benchmarking]() Tags: [ai](), [containers](), [control-plane](), [efficiency](), [etcd](), [google](), [kubernetes](), [ml](), [reliability](), [resilience]() ### AI overview This article explains how Kubernetes v1.35 introduces the RestartAllContainers action for in-place Pod restarts. It describes how restarting containers while preserving the Pod's runtime identity can reduce resource waste, control-plane churn, scheduling races, and recovery delays for complex, batch, and AI/ML workloads. ### Source excerpt by Duncan Campbell & Giuseppe Tinti Tomio, Kubernetes Operational efficiency and system resilience are critical when running scaled platforms. Yet, in Kubernetes, recovering from software crashes remains a headache because you couldn't trigger a clean restart of a Pod's containers without recreating the entire Pod object, leading to some amount of resource waste. To address this, Restart All Containers on Container Exits graduated to beta and is enabled by default in Kubernetes v1.36. Developed in close collaboration with the CNCF community, this capability represents Google's commitment to investing in the success of foundation-led open source projects. By sharing best practices from running large distributed systems internally, we are helping build a more resilient and efficient ecosystem. Letting containers restart while keeping the Pod's runtime identity provides a built-in way to perform in-place Pod recovery, boosting application reliability and saving resource costs. The Problem: The High Cost of Pod Re-creation Historically, Kubernetes managed failures using pod level restart policies. While sufficient for simple services, modern multi-container Pods often have complex dependencies. When a failure requires a full environment reset, your only option was deleting and recreating the entire Pod. This introduces massive control plane churn, causing latency and pressure on the etcd backend during large failures: Initialization Dependencies: If a main container corrupts a local environment, for example, single-use secrets that must be re-requested, restarting just that container is insufficient; the setup must run again. Watcher Interoperability: If a watcher sidecar detects a fatal error, it must trigger a full recreate of the entire pod and its infrastructure, including the sandbox. Stale States: If a database sidecar proxy restarts, the main application can get stuck attempting to use stale, broken connections. Resource Race Conditions: When a large job finds a ## Storage at scale: what I actually watched DevFeed: [Storage at scale: what I actually watched]() Original publisher: [Read original article]() Author: Sridhar Rajarao Published: 2026-05-28T00:00:00Z Content type: article Language: en Sources: [Sridhar Rajarao]() Topics: [dashboards](), [site-reliability-engineering](), [Latency](), [Availability](), [control-plane](), [Databases](), [Replication]() Tags: [availability](), [control-plane](), [database](), [latency](), [metrics](), [reliability](), [replication](), [service](), [sre](), [storage]() ### AI overview An SRE practitioner describes seven metrics for judging the health of a large-scale storage service, covering availability, durability, latency, synthetic canaries, hotspots, IOPS, and metadata-database behavior. ### Source excerpt For eight years I ran SRE for a storage system measured in exabytes. The dashboard I checked every morning shrank to seven numbers. Here they are. ## Kube-Agents: an intent-driven presentation layer for Kubernetes DevFeed: [Kube-Agents: an intent-driven presentation layer for Kubernetes]() Original publisher: [Read original article]() Author: Google Open Source (noreply@blogger.com) Published: 2026-05-21T18:30:00Z Content type: opinion Language: en Sources: [Google Open Source Blog]() Topics: [Kubernetes](), [control-plane](), [API](), [YAML]() Tags: [agents](), [api](), [autonomous](), [control-plane](), [kube-agents](), [kubectl](), [kubernetes](), [yaml]() ### AI overview The article presents Kube-Agents, a proposed system of autonomous and human-in-the-loop agents that would provide an intent-driven presentation layer for Kubernetes. It describes agents that complement existing Kubernetes interfaces by observing cluster state and carrying out operations through existing APIs. ### Source excerpt by Adrian Chung, Abdelfettah Sghiouar & Matt Larkin, Google Kubernetes Engine Empowering every engineer to do more with Kubernetes Kubernetes is the gold standard for container orchestration. Its power, flexibility, and rich API surface are exactly why it has become the foundation of modern cloud-first infrastructure. Today, engineers express that power through the K8s API, declarative YAML manifests, and cloud consoles, a remarkably expressive toolbox. We believe the next step is to expand how engineers interact with that toolbox. A Kubernetes expert should be able to converse with a deep-domain peer that speaks fluent control-plane and can reason about cluster state in real time. An engineer who isn't a Kubernetes specialist should be able to express higher-order intent, such as "deploy my application," "rebalance this workload" and have it carried out safely against the same powerful APIs. Both audiences get more leverage out of the platform they already trust. This is the vision behind Kube-Agents: a system of intelligent, autonomous, and human-in-the-loop agents that act as a new, intent-driven presentation layer for Kubernetes. We are moving from declarative intent via API to higher-order, human intent-driven operations while preserving everything that makes Kubernetes great underneath. The Vision: Expanding the Presentation Layer Today, engineers do impressive work stitching together metrics, alerts, and multi-step commands to keep clusters healthy. Agents extend that work, not replace it. By complementing existing interfaces with autonomous agents, engineers can choose the level of abstraction that fits the task: drop down to kubectl and YAML when precision matters, or describe intent in plain language when speed and clarity matter more. The agents continuously observe system state and can execute complex operations in real time on the engineer's behalf. This isn't about hiding Kubernetes. It's about giving every engineer a more capable collaborator on top o ## Why your platform control plane belongs on Temporal DevFeed: [Why your platform control plane belongs on Temporal]() Original publisher: [Read original article]() Author: Joshua Smith Published: 2026-03-31T00:00:00Z Content type: opinion Language: en Sources: [Temporal Blog]() Topics: [control-plane](), [Automation](), [Orchestration](), [Terraform]() Tags: [automation](), [control-plane](), [error](), [infrastructure](), [orchestration](), [platform](), [platform-teams](), [provisioning](), [scripts](), [self-service](), [temporal-voices]() ### AI overview This article argues that Temporal can serve as a durable backbone for platform teams building internal control planes. It describes the difficulty of managing infrastructure across creation, monitoring, upgrades, configuration changes, and decommissioning, and contrasts Temporal's orchestration model with Terraform's declarative provisioning and reconciliation focus. ### Source excerpt Discover why platform teams use Temporal to build resilient internal control planes. Learn how Durable Execution solves brittle infrastructure automation. ## Replay '25 Day Three: Technical Deep Dives and Temporal Case Studies DevFeed: [Replay '25 Day Three: Technical Deep Dives and Temporal Case Studies]() Original publisher: [Read original article]() Author: Tim Imkin Published: 2025-03-07T00:00:00Z Content type: article Language: en Sources: [Temporal Blog]() Topics: [reliability](), [Resilience](), [Databases](), [Automation](), [Amazon Web Services](), [Haskell](), [Kubernetes](), [Access Control](), [systems](), [Testing](), [control-plane](), [Artificial Intelligence]() Tags: [access-control](), [ai](), [automation](), [aws](), [case-studies](), [community](), [control-plane](), [haskell](), [kubernetes](), [monitoring](), [reliability](), [resilience](), [technical]() ### AI overview A recap of the final day of Replay '25, covering reliability, database automation, production patterns, enterprise adoption, and mission-critical applications built with Temporal. ### Source excerpt The final day of Replay '25 delivered a mix of technical deep dives and real-world case studies before concluding with an unexpected twist. ## Temporal Cloud: 1,000 customers, 1,000 thank yous DevFeed: [Temporal Cloud: 1,000 customers, 1,000 thank yous]() Original publisher: [Read original article]() Author: Maxim Fateev Published: 2024-04-16T04:00:00Z Content type: news Language: en Sources: [Temporal Blog]() Topics: [Cloud](), [Open Source](), [SDKs](), [control-plane](), [Users]() Tags: [announce](), [announcements](), [cloud](), [control-plane](), [customers](), [latency](), [open-source](), [releases](), [sdks](), [users]() ### AI overview Temporal announces that Temporal Cloud surpassed 1,000 customers in under a year and a half. The company also estimates that more than 200,000 developers use its SDKs and highlights its open-source project, releases, and platform architecture. ### Source excerpt We're thrilled to announce that Temporal Cloud has surpassed 1,000 customers in just under a year and a half! ## The Business Executive's Guide to Kubernetes DevFeed: [The Business Executive's Guide to Kubernetes]() Original publisher: [Read original article]() Published: 2019-07-23T15:09:26Z Content type: opinion Language: en Sources: [Jessie Frazelle]() Topics: [Kubernetes](), [Databases](), [data](), [Replication](), [dashboards]() Tags: [challenges](), [control-plane](), [data](), [database](), [kubernetes]() ### AI overview This opinion article explains Kubernetes considerations for business leaders, focusing on challenges with stateful data and the need for separate data-replication mechanisms. It also warns that organizations may expose or fail to secure the Kubernetes control-plane dashboard. ### Source excerpt Hello! I thought it would be fun to write a post aimed towards business leaders making technology decisions for their organizations. There is a lot of hype in our field and little truth behind the hype. Like most things I write about, this started from an idea I had on Twitter: has anyone ever done technical breakdowns of these products in Gartner reports that are actually just trash, is this something you'd read..? -- jessie frazelle 👩🏼🚀 (@jessfraz) July 24, 2019 This post will cover some hard truths of Kubernetes and what it means for your organization and business. You might have heard the term "Kubernetes" and you might have been led to believe that this will solve all the infrastructure pain for your organization. There is some truth to that, which will not be the focus of this post. To get to the state of enlightenment with Kubernetes, you need to first go through some hard challenges. Let's dive in to some of these hard truths. Stateful Data is Hard Kubernetes is not to be used for stateful data. There has been a lot of work done in this area but it is still not sufficent. For the more technical members of our audience I direct you to exhibit A. The linked issue goes over problems when a "StatefulSet" gets into an error during deploying or upgrading. This can lead to data loss or corruption since Kubernetes will need manual intervention to fix the state of the deployment. This could even lead to the point where the only recommended fix is you delete the state. What does this mean for your business? Well, if you lose or corrupt your data it could mean a lot of different things depending on what the data was. If the data was your customer database of new account signups, well you might have just lost the data for your new customers. If you are an ecommerce site, it might have been your latest sale. If you are in banking or investments, it might have been data accounting for the movement of capital. Databases holding valuable information like the examples above ## Secret Design Docs: Multi-Tenant Orchestrator DevFeed: [Secret Design Docs: Multi-Tenant Orchestrator]() Original publisher: [Read original article]() Published: 2019-02-12T15:09:26Z Content type: article Language: en Sources: [Jessie Frazelle]() Topics: [Containers](), [Docker](), [Security](), [Architecture & Design](), [Operating system](), [Network](), [Linux]() Tags: [cgroups](), [containers](), [control-plane](), [docker](), [firewall](), [operating-systems](), [security]() ### AI overview A design document for a multi-tenant container orchestrator intended to run third-party code with strong isolation. It proposes layered security controls, resource limits, network isolation, a secure minimal host operating system, and mechanisms to terminate abusive workloads and update the agent. ### Source excerpt I thought it would be fun to start a blog post series containing design docs from my personal archive that never saw the light of day. This will be the first of the series. It contains what I thought about in detail for a general multi-tenant secured container orchestrator. The use case would be for running third party code securely isolated from each other. If you would like to see this in google doc form it also lives here. Requirements Base API to run docker images in such a way that each process is isolated entirely from all the others. Abusive actions can be terminated immediately. The agent should be auto-updateable to handle security issues as they arise. Ability to use the entire syscall interface for the processes being run. This all assumes that you have some sort of software and hardware level root of trust you can use to ensure security as well. Other Features Disallow and kill any and all bitcoin miners from using the infrastructure, BPF tracers Firewall off any existing network endpoints Firewall off the container running the process from everything around it on the local links and any reachable internal IP If one layer of isolation is compromised, rely on another layer of isolation entirely. If two layers are compromised then we at least tried our best... Design The host OS and up needs to be secure. Overview We require the following per container running: Block/io cgroups so that disk does not have noisy neighbors CPU limit Memory limit Network/bandwidth limiting Isolated network from everything else on the network (BPF or iptables) Host OS The host OS should be a reduced operating system, minimal distribution (though possibly shared with the OS used inside containers). This is for reasons of security in locking down the available weaknesses in the host environment and lessening the control plane attack surface. Operating Systems Examples of these Operating Systems include: CoreOS Container Linux Container Optimized OS Intel Clear Linux LinuxKit Featur