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