Kubernetes Learning Week Series 11
Why Can’t the PID 1 Process Be Terminated in a Container Sometimes?
This article explains why the kill command cannot terminate the PID 1 process (init process) in a container, even when using signals like SIGKILL. It covers two main concepts: the init process and Linux signals.
Key Points:
Init Process:
Each container runs a primary process with PID 1, known as the init process.
This process is responsible for managing other processes within the container.
The init process cannot be easily terminated because it has special handling in the Linux kernel.
Linux Signals:
Signals are notifications sent to processes to trigger specific actions.
Common signals include SIGTERM (request termination) and SIGKILL (force termination).
The init process is marked as “SIGNAL_UNKILLABLE,” meaning it ignores these signals by default.
Behaviour of Different Programs:
The article tests various programs (bash, C, Golang) as init processes to observe their responses to the kill command.
Results vary: while SIGKILL cannot terminate the init process, SIGTERM can succeed if the process has registered a handler for it.
Kernel Implementation:
The Linux kernel’s signal handling logic checks whether processes have custom handlers before acting on signals.
If no custom handler is registered, the init process ignores SIGTERM by default.
Conclusion:
The inability to terminate the init process in a container is due to its special role and handling in the Linux kernel. Understanding the interaction between init processes and signal handling is crucial for managing processes in containerized environments.
Causes and Solutions for Zombie Processes in Containers
https://blog.devops.dev/causes-and-solutions-for-zombie-processes-in-containers-35a9da1b8bd3
This article discusses the causes and solutions for zombie processes in containers, which is a common topic in operating system interviews.
Key Points:
Definition:
A zombie process refers to a process that has completed execution but still has an entry in the process table. When listed with commands like ps, they are displayed as “defunct.”
Symptoms:
Users may notice zombie processes while executing commands in running containers, potentially leading to resource issues.
Process States:
In Linux, processes go through various states, including running, sleeping, and zombie (EXIT_ZOMBIE) before termination (EXIT_DEAD).
Resource Limits:
Containers can reach the limit of processes they can run, controlled by the “pids” control group (Cgroup). If this limit is exceeded, no new processes can be created, causing operational failures.
Creation Mechanism:
Zombie processes occur when the parent process fails to call wait() or waitpid() to reclaim resources from its terminated child processes.
Solutions:
Use the pids.max file in Cgroups to enforce limits on the number of processes in a container.
Ensure the parent process handles child process exits properly to prevent zombies.
Use waitpid() with the WNOHANG option to avoid blocking while checking for zombie processes.
Conclusion:
Understanding zombie processes and their management is essential for maintaining well-functioning containerized applications. Properly handling child processes can prevent resource exhaustion and ensure system stability.
Understanding DNS in Kubernetes
This article discusses the critical role of DNS in Kubernetes, focusing on how it facilitates service discovery by allowing applications to use human-readable domain names instead of IP addresses. CoreDNS is identified as the default DNS provider in Kubernetes.
Key Points:
Overview of CoreDNS:
CoreDNS operates as a deployment within the Kubernetes cluster and is responsible for DNS resolution and service discovery.
Kubernetes DNS Policies:
ClusterFirst: The default policy for Pods, directing DNS queries to the kube-dns service.
Default: Inherits DNS settings from the node.
ClusterFirstWithHostNet: Applies ClusterFirst behavior to Pods using host networking.
None: Allows custom DNS configurations.
DNS Resolution Mechanism:
Applications typically interact with DNS using the getaddrinfo function via the C standard library (libc).
The /etc/resolv.conf file is critical for configuration, specifying the IP addresses of DNS servers.
DNS Library Comparison:
Differences between glibc and musl libraries are discussed, particularly how musl resolves DNS queries in parallel, potentially speeding up resolution.
Experimentation:
Various experiments demonstrate how different DNS policies and implementations impact query behavior, including scenarios involving non-existent domains, unresponsive nameservers, and slow DNS responses.
Performance Details:
Results highlight that the choice of DNS client implementation significantly affects application performance, especially in cases involving timeouts or slow responses.
Conclusion:
The article emphasizes the importance of selecting appropriate DNS settings to optimize application performance in Kubernetes environments.
Mix Helm, Kustomize, and Raw Manifests
https://itnext.io/helm-kustomize-raw-manifests-combination-570f81acf996
This article discusses the integration of Helm, Kustomize, and raw manifests to simplify Kubernetes manifest management. It outlines how these tools can be combined to create highly customizable deployment workflows, enhancing adaptability and efficiency in Kubernetes environments.
Key Points:
Introduction to Tools:
Helm: A package manager for Kubernetes that simplifies application deployment.
Helmfile: Manages multiple Helm charts in a single specification file.
Kustomize: Allows customization of Kubernetes manifests using patches.
Raw manifests: Basic YAML files that can be directly applied to Kubernetes.
Principles of Combining Tools:
Customizing Helm charts can lead to divergence from the original chart, making updates difficult.
When modifying an existing Helm chart is not feasible, raw manifests can be included for additional customization.
Implementation Approach:
The article introduces an algorithm that combines the strengths of Helm, Kustomize, and raw manifests.
A process flow diagram illustrates the workflow, highlighting that raw manifests have the highest priority.
Directory Structure:
Provides an example of directory layout for organizing Helm, Kustomize, and raw manifest files.
Pipeline Code:
Shares an example GitLab CI pipeline for automating the deployment process using these tools.
Conclusion:
The integrated approach offers unparalleled flexibility and control over Kubernetes deployments, making it well-suited for a variety of scenarios.
Securing Kubernetes Pods for Production Workloads
https://dev.to/thenjdevopsguy/securing-kubernetes-pods-for-production-workloads-51oh
Key Points:
Importance of Securing Pods:
Pods are a critical entry point for attackers, making their security essential.
This article highlights strategies for policy implementation, user access, service accounts, and traffic management.
SecurityContext:
A key feature that can be applied at both Pod and container levels. Key configurations include:
runAsNonRoot: Ensures the Pod runs as a non-root user.
allowPrivilegeEscalation: Prevents processes from gaining additional privileges.
readOnlyRootFilesystem: Mounts the file system as read-only to enhance security.
Pod Security Standards (PSS):
These standards categorize security policies into three levels:
Privileged: Provides unrestricted access.
Baseline: A middle ground with some restrictions.
Restricted: Adheres to strict security best practices.
Policy Enforcement:
Tools such as Open Policy Agent (OPA) with Gatekeeper and Kyverno are recommended for enforcing security policies and preventing misconfigurations.
Network Policies:
Manage traffic between Pods, ensuring communication is controlled and secure.
Admission Controllers:
All Kubernetes traffic is validated through these controllers, which enforce policies and block unauthorized requests.