Kubernetes Learning Week Series 16
Nan Song
Kubernetes Learning Week Series 15
How RBAC Works in Kubernetes
https://medium.com/@amansinghsonkh/how-rbac-works-in-the-kubernetes-0d421bf5cf39
This article provides an in-depth explanation of Role-Based Access Control (RBAC) in Kubernetes, covering key concepts of authentication and authorization, as well as how to set up Roles and RoleBindings to control user access to resources within a Kubernetes cluster.
Key Points
RBAC allows control over access to Kubernetes resources by assigning specific roles and permissions to users, groups, and service accounts.
The process involves creating a role with the required permissions and then binding that role to a user or group.
Cluster-level Roles and RoleBindings can be used to grant access across multiple namespaces, simplifying permission management for a large number of users.
Service Accounts (SAs) can be used to provide the necessary permissions for applications running in Pods to access Kubernetes resources without exposing user credentials.
Related Interview Questions
How can you verify if a user has the correct permissions to perform certain actions in a Kubernetes cluster?
What is the difference between Roles and ClusterRoles in Kubernetes RBAC?
How do you create a custom Service Account (SA) and assign it to a Pod to access specific Kubernetes resources?
How can you manage RBAC permissions for a large number of users in a Kubernetes cluster?
Generate, Transform, and Modify Kubernetes Configurations Using Kustomize
Kustomize is a Kubernetes configuration management tool that allows you to generate, transform, and modify Kubernetes configurations. It was created to meet the need for a simple, declarative solution for managing Kubernetes configurations, complementing tools like Helm.
Key Points
Compared to parameter-driven configuration templates and generators, Kustomize was introduced to provide a declarative, Kubernetes-native solution for managing configurations.
Kustomize supports patching and transforming configurations, enabling the combination of configurations using a “base” and “overlay” approach, which is particularly useful for managing different environments.
Kustomize’s transformation-based approach differs from other Kubernetes configuration tools that generate the entire configuration from scratch each time. It is designed to balance simplicity and flexibility.
Kustomize has become one of the most popular Kubernetes configuration tools, second only to Helm, and can be used alongside Helm to manage Kubernetes deployments.
Master GitOps with Flux
https://adoreme.tech/mastering-gitops-with-flux-adoreme-024b56ac397b
Key Points
Adore Me leverages GitOps and Flux to manage its complex infrastructure, ensuring consistency, security, and efficiency for its Kubernetes clusters.
Adore Me has developed a streamlined workflow for managing and deploying applications using GitOps and Flux, with two main variations to handle different types of changes.
Combining GitOps with Flux has brought several benefits to Adore Me, such as preventing configuration drift, enhancing security, automating processes, and simplifying management through a single Git repository.
Implementing Flux comes with its own challenges, including a learning curve and the need for careful infrastructure planning to fully leverage Flux’s flexibility.
Monitor AZ-Level Pod-to-Pod Traffic Using Retina (an eBPF-Based Tool)
This article discusses how to analyze pod-to-pod traffic within a Kubernetes cluster, with a particular focus on cross-AZ (Availability Zone) communication. It provides a step-by-step guide on implementing pod-to-pod traffic monitoring using the eBPF-based tool Retina, along with Prometheus and Grafana. The author’s goal is to identify opportunities to reduce cross-AZ traffic, which can significantly increase cloud costs.
Key Points
Introduction to eBPF and its use in monitoring network traffic within Kubernetes.
Overview of Retina, an eBPF-based network observability tool for Kubernetes.
Step-by-step guide on deploying two sample services, installing and configuring Retina, and integrating Prometheus to collect metrics.
Explanation of PromQL queries for analyzing cross-AZ traffic using Retina metrics and Kubernetes state metrics.
Creating Grafana dashboards to visualize and analyze the collected network traffic data.
Exploring the Basics of Istio Traffic Management
https://medium.com/@arivermar/exploring-the-basics-of-istio-traffic-management-cee13f0817c2
This article provides an overview of Istio, a popular service mesh solution, with a focus on its traffic management capabilities. It discusses the Istio architecture, including the control plane and data plane, and then delves into how to deploy sample microservices on a Kubernetes cluster using Istio.
Key Points
Istio is a service mesh that provides capabilities like security, scalability, high availability, and observability for microservice architectures.
The Istio control plane, represented by the istiod pod, is responsible for configuring proxies and managing certificates, while the data plane consists of Envoy proxies deployed as sidecars in microservice pods.
Istio can be installed on a Kubernetes cluster using the minikube plugin, which sets up Istio CRDs, istiod, and istio-ingressgateway.
The article demonstrates deploying a “hello-world” microservice in the hello-world namespace, where Istio automatically injects an Envoy sidecar.
Istio’s DestinationRule is used to define traffic balancing, circuit breaking, and session affinity policies.
Circuit breaking in Istio can be implemented to evict unhealthy pods from the load balancing pool, preventing failures and protecting applications during traffic spikes.
Istio’s subsets and VirtualServices enable A/B testing and canary deployments, allowing traffic to be directed to specific versions of microservices.
Related Interview Questions
What are the key components of Istio’s architecture?
How do you manage traffic between microservices using Istio?
What features does Istio provide to enhance the reliability and resilience of microservices?
How can you implement canary releases and A/B testing with Istio?
Exploring Network Policies
https://aditya-tanwar.hashnode.dev/kubernetes-network-policies
Key Points
Network policies are a mechanism for controlling network traffic within a Kubernetes cluster. They allow you to define which Pods are permitted to exchange network traffic.
Network policies can be used to secure databases, isolate sensitive Pods, and control communication between different applications running in the cluster.
Kubernetes network policies can specify ingress (incoming) and egress (outgoing) rules for a set of Pods using Pod selectors, namespace selectors, or IP address blocks.
It is recommended to create a default “deny-all” network policy to ensure that Pods are not accidentally exposed to unauthorized access, and then create additional policies to explicitly allow necessary traffic.
Related Interview Questions
Can network policies be used to protect sensitive data in a Kubernetes cluster?
What are the different ways to specify allowed traffic in ingress or egress network policies?
Why is it important to have a default “deny-all” network policy in a Kubernetes cluster?
Subscribe to my newsletter
Read articles from Nan Song directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by