Operations | Monitoring | ITSM | DevOps | Cloud

Another outstanding Kubernetes release, this time focused on making the CustomResource a first class citizen in your cluster, allowing for better extensibility and maintainability. But wait, there is much more! Here is the full list of what’s new in Kubernetes 1.15.

Getting started with Kubernetes is really easy. In just a matter of minutes you can set up a new cluster with minikube, kops, Amazon EKS, Google Kubernetes Engine, or Azure Kubernetes Service. What isn’t so easy is knowing what to do after you set up your cluster and run a few apps. One of the most important parts of setting up a Kubernetes cluster is to make sure your cluster is secure. In this blog post, we will go over some of the strategies you can use to help secure your Kubernetes cluster.

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.

Early adopter enterprises across verticals such as Retail, Manufacturing, Oil & Gas are looking to incorporate containers and Kubernetes as a way of modernizing their applications. Choosing k8s as a standard ensures that these applications can be deployed these on different data center infrastructures (bare metal/VMware/KVM on OpenStack etc) or on public clouds (AWS/Azure/GCP etc).

Today we are announcing support for Istio with Rancher 2.3 in Preview mode. Istio, and service mesh generally, has developed a huge amount of excitement in the Kubernetes ecosystem. Istio promises to add fault tolerance, canary rollouts, A/B testing, monitoring and metrics, tracing and observability, and authentication and authorization, eliminating the need for developers to instrument or write specific code to enable these capabilities.

This is the third of a series of three articles focusing on Kubernetes security: the outside attack, the inside attack, and dealing with resource consumption or noisy neighbors. A concern for many administrators setting up a multi-tenant Kubernetes cluster is how to prevent a co-tenant from becoming a “noisy neighbor,” one who monopolizes CPU, memory, storage and other resources.

Over the last year, along with Kubernetes, Serverless computing platforms have acquired tremendous mindshare among the development community. As Serverless implementations begin to proliferate, I want to make the case that there are tremendous synergies to be gained by bringing both these paradigms together. Some of these benefits have been covered in previous posts. The majority of enterprises are embarking on their DevOps journey. Scaling such processes across a large enterprise is complicated.

Kubernetes clusters use multiple certificates to provide both encryption of traffic to the Kubernetes components as well as authentication of these requests. These certificates are auto-generated for clusters launched by Rancher and also clusters launched by the Rancher Kubernetes Engine (RKE) CLI.