Home • Explore • Blog • CI
☰



kubernetes
2nd chunk of `content/en/blog/_posts/2016-07-00-Kubernetes-In-Rancher-Further-Evolution.md`
d3cf205e6092e292df69c6f2d7c5c47e7337715a658ad88d0000000100000a9d
![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:  


```
apiVersion: extensions/v1beta1

kind: Ingress

metadata:

 name: scalelb

 annotations:

 scale: "2"

spec:

  rules:

  - host: foo.bar.com

    http:

      paths:

      - path: /foo

        backend:

          serviceName: nginx-service

          servicePort: 80
 ```



As a result of the above, 2 instances of Rancher Load Balancer will get started on separate hosts, and Ingress will get updated with 2 public ip addresses:  





```
kubectl get ingress

NAME      RULE          BACKEND   ADDRESS

scalelb      -                    104.154.107.202, 104.154.107.203  // hosts ip addresses where Rancher LB instances are deployed

          foo.bar.com

          /foo           nginx-service:80
 ```




More details on Rancher Ingress Controller implementation for Kubernetes can be found here:

- [Blog post](http://rancher.com/rancher-controller-for-the-kubernetes-ingress-feature/)
- [Rancher documentation on Ingress](http://docs.rancher.com/rancher/latest/en/kubernetes/ingress/)
- [Rancher ingress controller repo](https://github.com/rancher/ingress-controller)

### Rancher and Kubernetes 1.3


We’ve very excited about Kubernetes 1.3 release, and all the new features that are included with it. There are two that we are especially interested in: Stateful Apps and Cluster Federation.  


#### Kubernetes Stateful Apps

Stateful Apps is a new resource to Kubernetes to represent a set of pods in stateful application. This is an alternative to the using Replication Controllers, which are best leveraged for running stateless apps. This feature is specifically useful for apps that rely on quorum with leader election (such as MongoDB, Zookeeper, etcd) and decentralized quorum (Cassandra). Stateful Apps create and maintains a set of pods, each of which have a stable network identity. In order to provide the network identity, it must be possible to have a resolvable DNS name for the pod that is tied to the pod identity as per [Kubernetes design doc](https://github.com/smarterclayton/kubernetes/blob/961f1f94c35d4979ac83bbad482090cb6c22781c/docs/proposals/petset.md):
Title: Rancher's Ingress Controller and Kubernetes 1.3: Stateful Apps and Cluster Federation
Summary
The text elaborates on Rancher's Ingress controller for Kubernetes, detailing how it allows horizontal scaling of the Load Balancer supporting the ingress service using annotations. It then transitions to Kubernetes 1.3, highlighting two features of particular interest: Stateful Apps and Cluster Federation. Stateful Apps, designed for stateful applications, provide stable network identities for pods, a departure from Replication Controllers which are better suited for stateless apps. The key aspect of Stateful Apps is that each pod has a resolvable DNS name tied to its identity, as detailed in the Kubernetes design document.