Home • Explore • Blog • CI
☰



kubernetes
1st chunk of `content/en/blog/_posts/2016-07-00-Kubernetes-In-Rancher-Further-Evolution.md`
84353bdb85eabfb2114408e9c506cd0655affd2443b975ed00000001000009fa
---
title: " Kubernetes in Rancher: the further evolution "
date: 2016-07-12
slug: kubernetes-in-rancher-further-evolution
url: /blog/2016/07/Kubernetes-In-Rancher-Further-Evolution
author: >
  [Alena Prokharchyk](https://github.com/alena1108) (Rancher Labs)
---

Kubernetes was the first external orchestration platform supported by [Rancher](http://rancher.com/kubernetes), and since its release, it has become one of the most widely used among our users, and continues to grow rapidly in adoption. As Kubernetes has evolved, so has Rancher in terms of adapting new Kubernetes features. We’ve started with supporting Kubernetes version 1.1, then switched to 1.2 as soon as it was released, and now we’re working on supporting the exciting new features in 1.3. I’d like to walk you through the features that we’ve been adding support for during each of these stages.  


### Rancher and Kubernetes 1.2

Kubernetes 1.2 introduced enhanced Ingress object to simplify allowing inbound connections to reach the cluster services: here’s an excellent [blog post about ingress](https://kubernetes.io/blog/2016/03/kubernetes-1-2-and-simplifying-advanced-networking-with-ingress/) policies. Ingress resource allows users to define host name routing rules and TLS config for the Load Balancer in a user friendly way. Then it should be backed up by an Ingress controller that would configure a corresponding cloud provider’s Load Balancer with the Ingress rules. Since Rancher already included a software defined Load Balancer based on HAproxy, we already supported all of the configuration requirements of the Ingress resource, and didn’t have to do any changes on the Rancher side to adopt Ingress. What we had to do was write an Ingress controller that would listen to Kubernetes ingress specific events, configure the Rancher Load Balancer accordingly, and propagate the Load Balancer public entry point back to Kubernetes:



 ![Screen-Shot-2016-05-13-at-11.15.56-AM.png](https://lh3.googleusercontent.com/C8wg_8Vih0evMIAEvCaX3IAbARddxhk5S_Mzv9jdpt87njQR9cbEEGZnFiWrKx7TPm-uPO1V4TP4LDOKvLg7gJ-19-esVMNhbkSf6fXSrbE3nS3Sr45rdP1c-VBuzShgpn9jDCiQ)

Now, the ingress controller gets deployed as a part of our Rancher Kubernetes system stack, and is managed by Rancher. Rancher monitors Ingress controller health, and recreates it in case of any failures. In addition to standard ingress features, Rancher also lets you to horizontally scale the Load Balancer supporting the ingress service by specifying scale via Ingress annotations. For example:
Title: Rancher's Evolution with Kubernetes: From 1.2 to 1.3
Summary
This blog post discusses Rancher's support for Kubernetes, starting with version 1.1 and evolving through 1.2 and 1.3. It highlights the adoption of new Kubernetes features in Rancher, specifically focusing on the Ingress object introduced in Kubernetes 1.2. Rancher's existing Load Balancer based on HAproxy already supported the Ingress resource's configuration requirements. Rancher created an Ingress controller to listen to Kubernetes events, configure the Rancher Load Balancer, and propagate the Load Balancer's public entry point back to Kubernetes. The Ingress controller is managed by Rancher and can be scaled horizontally.