TWIL: March 13, 2022
Most of my learning week was spent around Kubernetes, namely networking and observability topics. I also highlight the 2-part documentary about Kubernetes and an episode of the Azure podcast about Azure Database for Postgres. I hope you find it useful.
The Azure Podcast
Episode 412: Azure Database for Postgres
The team catches up with Prabhat Tripathi and Sunil Agarwal to learn all about Azure Database for Postgres and that service’s Flexible Server SKU that recently went generally available.
Kubernetes: The Documentary
Inspired by the open source success of Docker in 2013 and seeing the need for innovation in the area of large-scale cloud computing, a handful of forward-thinking Google engineers set to work on the container orchestrator that would come to be known as Kubernetes– this new tool would forever change the way the internet is built.
Kubernetes: The Documentary [PART 1]
Kubernetes: The Documentary [PART 2]
The Six Most Popular Kubernetes Networking Troubleshooting Issues
Kubernetes follows certain rules and policies when it comes to networking, and it’s not uncommon to encounter issues when trying to connect applications running in Kubernetes. Even the most trivial deployment needs to have the correct configuration so that K8s can assign the right IP address or ingress controller to the service. Furthermore, if you are operating the cluster on a public cloud provider like Google Cloud or AWS, you may have to follow their recommended configurations when deploying custom Kubernetes networking tools and certificate managers.
Understanding kubernetes networking: pods
This post is going to attempt to demystify the several layers of networking operating in a kubernetes cluster. Kubernetes is a powerful platform embodying many intelligent design choices, but discussing the way things interact can get confusing: pod networks, service networks, cluster IPs, container ports, host ports, node ports… I’ve seen a few eyes glaze over.
Understanding kubernetes networking: services
In the first post of this series I looked at how kubernetes employs a combination of virtual network devices and routing rules to allow a pod running on one cluster node to communicate with a pod running on another, as long as the sender knows the receiver’s pod network IP address. If you aren’t already familiar with how pods communicate then it’s worth a read before continuing.
Understanding kubernetes networking: ingress
In the first post of this series I described the network that enables pods to connect to each other across nodes in a kubernetes cluster. The second focused on how the service network provides load balancing for pods so that clients inside the cluster can communicate with them reliably. For this third and final installment I want to build on those concepts to show how clients outside the cluster can connect to pods using the same service network.
Network Policies demystified in Kubernetes
Network Policies are the Kubernetes resources that control the traffic between Kubernetes resources like Pods, network endpoints. It defines the network access policies for communication between Pods, network endpoints. Network policies allow us to specify the entities to which a Pod is authorized to connect.
NetworkPolicy is a standardized Kubernetes object to control the allowed network traffic patterns between Kubernetes pods and namespaces as well as any traffic entering or leaving the cluster. However, Kubernetes itself does not provide an implementation of NetworkPolicy, it is typically provided by the CNI plugin. If no NetworkPolicy is loaded, all communication is allowed which is clearly violating least-privilege and zero-trust security privileges.
NetworkPolicy Editor: Create, Visualize, and Share Kubernetes NetworkPolicies
Implementing Network Policy is a critical part of building a secure Kubernetes-based platform, but the learning curve from simple examples to more complex real-world policies is steep. Not only can it be painful to get the YAML syntax and formatting just right, but more importantly, there are many subtleties in the behavior of the network policy specification (e.g. default allow/deny, namespacing, wildcarding, rules combination, etc.). Even an experienced Kubernetes YAML-wrangler can still easily tie their brain in knots working through an advanced network policy use case.
What Cilium and BPF will bring to Istio
We are getting pinged multiple times a day with questions on how exactly Cilium and Istio relate to each other. This blog post serves to answer a couple of simple questions: How is Istio related to Cilium? Can I use both together? Will one benefit from the other?
YAKD: Yet Another Kubernetes Dashboard
The purpose of this post is to list some existing dashboard projects. The number of dashboards seems to be increasing each day, although some projects listed below already meet all the requirements of a dashboard application. A dashboard is a web-based Kubernetes user interface. The main purpose of a dashboard is to manage the life cycle of containerized applications deployed in a Kubernetes cluster. Fortunately, a dashboard comes with other benefits to make any operations on a cluster easier like troubleshooting a containerized application, and managing the cluster resources.
Deploy and Access the Kubernetes Dashboard
Dashboard is a web-based Kubernetes user interface. You can use Dashboard to deploy containerized applications to a Kubernetes cluster, troubleshoot your containerized application, and manage the cluster resources. You can use Dashboard to get an overview of applications running on your cluster, as well as for creating or modifying individual Kubernetes resources (such as Deployments, Jobs, DaemonSets, etc). For example, you can scale a Deployment, initiate a rolling update, restart a pod or deploy new applications using a deploy wizard.
Lens is the way the world runs Kubernetes. It provides the full situational awareness for everything that runs in Kubernetes. It’s lowering the barrier of entry for people just getting started and radically improving productivity for people with more experience.
Top Four Ways to Visualize Traffic Between Microservices in Kubernetes
You’re managing a complicated app on Kubernetes and want to see which microservices communicate with one another. Here are four different approaches you can take.
Fluent Logging Architecture – Fluent Bit, Fluentd & Elasticsearch
If we need to summarize the architecture, Fluent Bit acts as a daemon set in Kubernetes cluster. Runs in every node in Kubernetes collects and forwards stdout logs to the Fluentd, which is located outside Kubernetes cluster. Fluentd modifies, filters and processes these logs and sends them to the Elasticsearch cluster. Finally, Kibana visualizes these logs.
Kubernetes Useful Stuff
Kubernetes Operator Hub
OperatorHub.io is a new home for the Kubernetes community to share Operators. Find an existing Operator or list your own today.
Never stop learning. Have a great week.
Photo by Ihor Dvoretskyi on Unsplash