This is the first part of a series of posts which will look into different types of network policies and create conflicting rules to observe the outcome. Tests in this series of posts have been performed using Minikube with the Cilium CNI, using a different CNI may change the observed results. Demo environment The Kubernetes environment used for this post will start with the following: 2 Namespaces np-deepdive-one np-deepdive-two 2 types of pods Web to test ingress policies BusyBox to perform the tests from A service for the web pod Additional objects will be created through out the examples.

Kubernetes network policies allow platform consumers to restrict layer 3 and 4 network traffic. All ingress and egress traffic is permitted (default-allow) for namespaces without network policies in place. When at least one network policy exists, any traffic that does not match the specified rules is dropped (default-block). It is essential to be mindful of the default allow state when providing a Kubernetes service to users as it could impact platform and service design decisions.

I have just completed my first week as a Senior Consultant at Red Hat, and I’d like to what I’ve learnt about working for a company with an ‘open-source business model’. This post intends to share something I found interesting and not to market a company or employer. InterLock-Down My first week at Red Hat aligned with an internal event called ‘InterLock’, or for 2020 ‘InterLock Down’; this event allowed me to learn about the Red Hat ANZ business and people involved.

ConfigMaps enable decoupling of application configuration settings and a pod, improving workload portability. ConfigMaps are a key/value store for non-sensitive information such as; command line argument values, environment-specific strings and URL’s. Do not use ConfigMaps to store sensitive or encrypted data; instead, use secrets for this use case. You can create a ConfigMap by using the command kubectl create configmap [NAME] [DATA], where data is entered as literal values or read from a file.

Pods are not assigned to any node when they are first created; it is the job of the scheduler to assign the pod to a node. A scheduler watches the apiServer for pods that have no value in the spec.nodeName field. The scheduler finds the most suitable node for a pod-based on the podSpec and node statistics. After finding a suitable node, the scheduler sends an event to the apiServer, assigning the pod to the node.

A LimitRange object is used by cluster administrators to set default request and limit values for containers within a namespace. And minimum and maximum values for containers and pods within a namespace. If you’re unfamiliar with container requests and limits within Kubernetes; click here. Configuration a containers requests and limits setting is a well documented best practice. Cluster administrators use LimitRange objects to ensure that containers within a namespace align to this best practice.

Container CPU and Memory requests and limits configuration guarantees a minimum amount of resources to a container and sets a maximum consumable amount. Resource Configuration Values Memory is measured in bytes and expressed as an integer or using a fixed point integer. For example; memory: 1 is 1 byte, memory: 1Mi is 1 mebibyte / megabyte, memory: 1Gi is 1 gibibyte / gigabyte. Memory is not a compressible resource, and there is no throttling.

I noticed that none of the Kubernetes services are writing logs to /var/log/ on the master nodes. I built my lab with kubeadm and a reasonably basic configuration file, just the settings needed to make it work. The configuration file contained just enough information to build the lab and make it work. The Kubernetes services apiServer, ControlManager and Scheduler have several configuration flags for logging. In this post, I am going to go through my experience, enabling logging with kubeadm.

Static pods are like regular pods, except they are managed by the kubelet service on a node and not the API server. The kubelet creates a mirror pod on the API server, which is a read-only copy that allows the pod to be seen on the API server but not controlled. The kubelet service is responsible for managing the state of the pod and controlling restarts, for example. The kubelet process watches the location specified with the configuration parameter --manifest-url or --pod-manifest-path.

A DaemonSet is an object which ensures that there is a copy of a pod running on each node. This type of object is commonly used to deploy pods which provide a management service, such as log collection daemons or monitoring daemons to provide data to a solution such as Prometheus. The scheduler places a copy of the pod specified in a DaemonSet on all eligible nodes within the cluster.

Labels are a key/value formatted peice of metadata attached to an object within Kubernetes. Labels provide additional information about the object with relevance to the consumer or object. For example, a label can specify hardware characteristics of a node or if a workload is for testing of production. Labels implicitly group like objects together while providing a lookup mechanism for users, controllers and external systems. For this example, I have a deployment for a web service which runs on internal infrastructure and one which runs on DMZ infrastructure.

I’ve recently started learning Kubernetes, working through the CKA curriculum and performing various administrative tasks. During my study so far, I have found that there are a lot of manual steps involved when looking at an end to end process. Often the process required to achieve an outcome requires the same data to be entered in multiple places, for example, labels and selectors. A process which I have found to be overly manual and prone to misconfiguration is user management.

Build Performance Requirements into the Logical Design