Continental Innovates with Rancher and Kubernetes
Learn how to use HAProxy as your Ingress Controller with Rancher. We explore features including zero downtime reloads, performance and observability
Learn different ways of load balancing traffic to your kuberentes workload with Rancher
Last month I had the great pleasure of attending Kubecon 2017, which took place in Austin, TX. The conference was super informative, and deciding on what session to join was really hard as all of them were great. But what deserves special recognition is how well the organizers respected the attendees’ diversity of Kubernetes experiences. Support is especially important if you are new to the project and need advice (and sometimes encouragement) to get started.
It’s finally here: the Rancher you’ve all been waiting for. Rancher 2.0 is now in preview mode and available to deploy! Rancher 2.0 brings us a whole new Kubernetes-based structure, with new features like platform-wide multi-select, adoption of existing Kubernetes clusters, and much, much more. If you’re looking to dive in with Rancher 2.0, you’ve come to the right place.
Assumptions You have a Linux host with at least 4 GB of RAM.
Join Rancher in taking a closer look at Kubernetes load balancing, and the built-in tools used for managing communication between individual pods.
For teams building and deploying containerized applications using Docker, selecting the right orchestration engine can be a challenge. The decision affects not only deployment and management, but how applications are architected as well. DevOps teams need to think about details like how data is persisted, how containerized services communicate with one another, load balancing, service discovery, packaging and more. It turns out that the choice of orchestration engine is critical to all these areas.
In the world of containers, Kubernetes has become the community standard for container orchestration and management. But there are some basic elements surrounding networking that need to be considered as applications are built to ensure that full multi-cloud capabilities can be leveraged.
The Basics of Kubernetes Networking: Pods The basic unit of management inside Kubernetes is not a container—It is called a pod. A pod is simply one or more containers that are deployed as a unit.
Note: This post is the first in a two-part series on using GitLab and Rancher together for continuous integration and deployment, and part two is now up. We’ve also made the entire walkthrough available for download.
Introduction GitLab is, at its core, a tool for centrally managing Git repositories. As one might expect form a platform that provides this service, GitLab provides a robust authentication and authorization mechanism, groups, issue tracking, wiki, and snippets, along with public, internal, and private repositories.
In Kubernetes, we often hear terms like resource management, scheduling and load balancing. While Kubernetes offers many capabilities, understanding these concepts is key to appreciating how workloads are placed, managed and made resilient. In this short article, I provide an overview of each facility, explain how they are implemented in Kubernetes, and how they interact with one another to provide efficient management of containerized *workloads. *If you’re new to Kubernetes and seeking to learn the space, please consider reading our case for Kubernetes article.
If you’re going to successfully deploy containers in production, you need more than just container orchestration Kubernetes is a valuable tool Kubernetes is an open-source container orchestrator for deploying and managing containerized applications. Building on 15 years of experience running production workloads at Google, it provides the advantages inherent to containers, while enabling DevOps teams to build container-ready environments which are customized to their needs. The Kubernetes architecture is comprised of loosely coupled components combined with a rich set of APIs, making Kubernetes well-suited for running highly distributed application architectures, including microservices, monolithic web applications and batch applications.
This is the last part in a series on designing resilient containerized workloads. In case you missed it, Parts 1, 2, 3, and 4 are already available online. In Part 4 last week, we covered in-service and rolling updates for single and multiple hosts. Now, let’s dive into common errors that can pop up during these updates:
Common Problems Encountered with Updates Below is a brief accounting of all the supporting components required during an upgrade.
Rancher ships with two types of catalog items to deploy applications; Rancher certified catalog and community catalog, which enable the community to contribute to the reusable pre-built application stack templates. One of the recent interesting community catalog templates is the external load balancer for AWS Classic Elastic Load Balancer, which keeps an existing Load balancer updated with the EC2 instances on which Rancher services that have one or more exposed ports and specific label.
Note: You can find an updated comparison of Kubernetes vs. Docker Swarm in a recent blog post here.
Recent versions of Rancher have added support for several common orchestration engines in addition to the standard Cattle. The three newly supported engines, Swarm (soon to be Docker Native Orchestration), Kubernetes and Mesos are the most widely used orchestration systems in the Docker community and provide a gradient of usability versus feature sets.
*Note: Since publishing this post, we’ve created a guide comparing Kubernetes with Docker Swarm. You can read the details in the blog post here..* Over the last six months, Rancher has grown very quickly, and now includes support for multiple orchestration frameworks in addition to Cattle, Rancher’s native orchestrator. The first framework to arrive was Kubernetes, and not long after, Docker Swarm was added. This week, the team at Rancher added support for Mesos.
Alena is a principal software engineer at Rancher Labs. Rancher has supported Kubernetes as one of our orchestration framework options since March 2016. We’ve incorporated Kubernetes as an essential element within Rancher. It is integrated with all of the core Rancher capabilities to achieve the maximum advantage for both platforms. Writing the Rancher ingress controller to backup the Kubernetes Ingress feature is a good example of that. In this article, I will give a high-level design overview of the feature and describe what steps need to be taken to implement it from a developer’s point of view.
Raul is a DevOps microservices architect specializing in scrum, kanban, microservices, CI/CD, open source and other new technologies. This post focuses on the Traefik \“active mode\” load balancer technology that works in conjunction with Docker labels and Rancher meta-data to configure itself automatically and provide access to services. Load balancers/proxies are software programs that make it possible for you to access your services backend. In the microservices architectures scope, they have an additional challenge to manage high dynamism.
Hello, I’m Alena Prokharchyk, one of the developers here at Rancher. In my previous blog posts, I’ve covered various aspects of Service Discovery, a feature we use to discover and interconnect services of user applications deployed in Rancher. This discovery is done by services registering themselves dynamically to Rancher’s internal DNS so that other services in the system can discover them by fully qualified domain name (FQDN). Service Discovery can also be registered to Rancher’s Load Balancer (LB) service which allows it to balance traffic between all of a services’ containers.
I have already talked about several ways to monitor docker containers and also using Prometheus to monitor Rancher deployments. However, until now it has been a manual process of launching monitoring agents on our various hosts. With the release of the Rancher beta with scheduling and support for Docker compose we can begin to make monitoring a lot more automated. In today’s post we will look at using Rancher’s new \“Rancher compose\” tool to bring up our deployment with a single command, using scheduling to make sure we have a monitoring agent running on every host, and using labels to isolate and present our metrics.
An open source software platform that provides a complete set of infrastructure services for managing containers in production, as well as a formal
Recently Rancher provided a disk image to be used to deploy RancherOS v0.3 on Google Compute Engine (GCE). The image supports RancherOS cloud config functionality. Additionally, it merges the SSH keys from the project, instance and cloud-config and adds them to the rancher user.
Building The Setup In this post, I will cover how to use the RancherOS image on GCE to set up a MongoDB Replica Set. Additionally I will cover how to use one of the recent features of Rancher platform which is the Load Balancer.
Hi everyone, my name is Alena Prokharchyk, part of the engineering team here at Rancher, and still loving working on container infrastructure. A few months ago I wrote an articleintroducing Docker load balancing in Rancher. Today, I want to focus on how we’ve built a brand new service discovery capability into Rancher, as well as how we’ve integrated it with load balancing. If you’re not familiar with service discovery, it is a networking capability that allows groups of devices (or in our case containers) to be identified with a common name, and discovered by other services on the network.
I have blogged about monitoring docker deployments a couple times now (here & here), however, up to this point we have been monitoring container stats without looking at the bigger picture. How do these containers fit into a larger unit and how we get insights into the deployment as a whole rather than individual containers. In this post I will cover leveraging docker labels and Rancher’s projects and services support to provide monitoring information that understands the deployment structure.
Note: Rancher has come a long way since this was first published in June 2015. We’ve revised this post (as of August 2016) to reflect the updates in our enterprise container management service. Read on for the updated tutorial!
Rancher supports multiple orchestration engines for its managed environments, including Kubernetes, Mesos, Docker Swarm, and Cattle (the default Rancher managed environment). The Cattle environment is rich with features like stacks, services, and load balancing, and in this post, we’ll highlight common uses for these features.
A little over a month ago I wrote about setting up a Magento cluster on Docker using Rancher. At the I identified some short comings of Rancher such as its lack of support fot load-balancing. Rancher released support for load balancing and docker machine with 0.16, and I would like to revisit our Magento deployment to cover the use of load balancers for scalability as well as availability. Furthermore, I would also like to cover how the docker machine integration makes it easier to launch Rancher compute nodes directly from the Rancher UI.
Hello, my name is Alena Prokharchyk and I am a part of the software development team at Rancher Labs. In this article I’m going to give an overview of a new feature I’ve been working on, which was released this week with Rancher 0.16 - a Docker Load Balancing service. One of the most frequently requested Rancher features, load balancers are used to distribute traffic between docker containers. Now Rancher users can configure, update and scale up an integrated load balancing service to meet their application needs, using either Rancher’s UI or API.