This is a guest post written by Appranix. Now that Red Hat OpenShift 4 has officially been released, it’s time to start thinking about migration from Red Hat OpenShift Container Platform 3 to OpenShift Container Platform 4. You can check out the details about the differences between OpenShift 3 and 4 here. One of the biggest differences between OpenShift 3 and 4 is how OpenShift 4 clusters operate using immutable and automated infrastructure enabled by RHEL CoreOS and automation.

Service mesh provides a dedicated network for service-to-service communication in a transparent way. Istio aims to help developers and operators address service mesh features such as dynamic service discovery, mutual transport layer security (TLS), circuit breakers, rate limiting, and tracing. Jaeger with Istio augments monitoring and tracing of cloud-native apps on a distributed networking system.

Two years ago, Pusher started building an internal Kubernetes based platform. As we transitioned from a single product to multiproduct company, we wanted to help our product teams spend less time worrying about shared concerns such as infrastructure and be able to focus more on writing business logic for our products. Over this period, our platform team have solved many of the problems that Kubernetes doesn’t solve out of the box. Until recently, we had not solved the problem of configuration.

We are very excited to announce Calico v3.8. Here are some highlights from the release. You can now view IP address usage for each IP pool using calicoctl. This allows you to more easily manage the IP space in your cluster, providing a simple way to see which IP pools have addresses available and which are running low. See the calicoctl reference documentation for more detailed information on how to use this feature.

This article originated from http://leebriggs.co.uk///blog/2018/11/07/kr8-kubernetes-config-mgmt.html Previous visitors to this blog will remember I wrote about configuration mgmt for Kubernetes clusters, and how the space was lacking. For those not familiar, the problem statement is this: it’s really hard to maintain and manage configuration for components of multiple Kubernetes clusters.

One of these problems is that Kubernetes has no login process. Ordinarily, the client software would initiate this login flow, but kubectl does not have this built in. Kubernetes leaves it up to you to design the login experience. In this post, I will explain the journey we took to get engineers logged in from the terminal and the challenges we faced along the way. The first step to SSO was to set up Dex as our Identity Provider.