Kubernetes: Too Complex?

The participants begin with different reasons for using Kubernetes. In a large organisation, a shared deployment approach establishes a common runtime, replaces incompatible solutions and lets teams reuse infrastructure work. Kachmashev notes that a managed cluster makes getting started easier and encourages developers to account for replicas and restarts. A personal server can have different priorities: Docker Compose may be sufficient, familiar Helm packages may be convenient, or the owner may reduce the server-side work altogether. Polomodov describes small projects with prebuilt pages and cloud handlers for the remaining dynamic functionality. A corporate standard therefore does not automatically answer every project’s needs. Creating a cluster, launching a Deployment and seeing a service run do not establish that its owner has the knowledge, time and tools to operate it reliably. The choice depends on the project’s purpose and how much maintenance someone is willing to take on.

The discussion then follows the accumulation of layers. Manifests acquire Helm, delivery tools and internal interfaces; operators and custom APIs grow around the original resources. Experienced engineers learned these pieces gradually, while newcomers encounter the whole stack at once. Polomodov describes the difficulty through leaky abstractions: lower-level details can stay hidden while the interface fulfils its promise, but an incident sends engineers across several boundaries. Networking provides concrete examples. Kachmashev recounts lengthy preparation for production because of a Calico setting, and additional network interfaces through Multus. Another experience with Cilium improved cluster operation but made familiar tcpdump-based troubleshooting insufficient for some traffic. A new technology removes an earlier constraint while requiring a new way to observe the system. Polomodov also argues that rewriting Kubernetes while preserving its interfaces and compatibility would retain the accumulated combinations of requirements.

Tochka’s platform began as a service library: a catalogue recording which services existed and who was responsible for each. It evolved into a basis for access control and self-service. Each service has its own namespace; teams can work on their resources without changing their neighbours’. Kubernetes request handlers and validation help enrich settings and prevent known mistakes. A shared Helm chart hides networking details and other infrastructure conventions: developers describe application parameters while the platform team maintains the implementation. This boundary helps when the standard workflow meets the need. An unusual workload may still require lower-level access. The shared template’s complexity also remains real: its maintainers must understand many use cases and the consequences of changes for teams that already depend on that interface.

Polomodov describes a different route to centralisation. Teams in a large company built their own infrastructure, delivery pipelines and observability tools until repeated work became a scaling problem. Standardisation made it possible to assign specialists to the shared tools. Resource constraints also accelerated migration, however: when computing capacity is available mainly through the platform, adoption alone no longer demonstrates product quality. Are teams choosing it because it works well, or because alternatives are closed? The experience of building Deckhouse adds the platform maintainer’s perspective. Modularity provides ready-made building blocks, but maintaining them requires a substantial internal runtime, compatibility work and accumulated code. Across these accounts, platforms remove work from product teams by concentrating it elsewhere. Evaluation needs both perspectives: how much easier routine work becomes for users, and who can handle exceptions or failures.

The AI discussion includes useful experiments: agents can inspect cluster state, investigate failures, generate settings from a schema and work in a separate test environment. Polomodov distinguishes three levels: reading information, recommending a solution and taking action independently. People assess results at the first two levels; the third requires a separate basis for trust. Kubernetes complexity matters here just as it does for engineers. An agent encounters a particular combination of networks, operators, constraints and internal conventions. Success on a standard task or someone else’s cluster does not guarantee success on your configuration. Reproducible evaluation scenarios and evidence from actual task attempts are therefore needed. Those scenarios should be rerun when the model, tools or context handling changes. Instructions help, but do not establish how reliably the agent will perform the intended action or which mistakes will escape detection.

One practical approach discussed is to give an agent a narrow interface backed by conventional engineering checks. It can propose a change to shared template parameters or open a merge request. Validation, tests and a person assess the proposal, and a controlled process applies it through GitOps. This separates the model’s probabilistic decision from the rules governing changes. Broad direct API access creates greater risk: while trying to repair an application, an agent might decide to change the network subsystem and affect the whole cluster. Participants discuss restricted permissions, short-lived authorisation for specific actions and escalation to a person for potentially dangerous operations. A laboratory experiment is not treated as permission to operate production infrastructure. Polomodov’s central questions concern how quality is measured and which controls work independently of the agent’s confidence. Autonomy follows evaluation and control; knowing how to write Kubernetes commands is only a starting point. In the closing discussion, Alexander adds traceability requirements: an agent needs its own identity, a record of who initiated the work and traces of its actions. Changes should follow the standard reproducible process so the team can understand what happened and repeat the result in another environment.