CNI, or container network interface, is a standard system for provision networking for containers, especially for multi-host orchestrators like Kubernetes. In this article, we'll describe what CNI is, why it's helpful, and then compare some popular CNI plugins for establishing the network for Kubernetes containers.
This article is a continuation in a series on migrating from Rancher 1.6 to Rancher 2.0. It explores how to expose Kubernetes workloads publicly using port mapping in Rancher 2.0
On July 25th, Luke Marsden from Weaveworks and Bill Maxwell from Rancher Labs led a webinar on ‘A Practical Toolbox to Supercharge Your Kubernetes Cluster’. In the talk they described how you can use Rancher and Weave Cloud to set up, manage and monitor an app in Kubernetes. In this blog, we’ll discuss how and why Weave developed the best-practice RED method for monitoring apps with Prometheus. What is Prometheus Monitoring?
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: since this article has posted, we’ve released Rancher 1.2.1, which addresses much of the feedback we have received on the initial release. You can read more about the v1.2.1 release on Github. * I am very excited to announce the release of Rancher 1.2! This release goes beyond the requisite support for the latest versions of Kubernetes, Docker, and Docker Compose, and includes major enhancements to the Rancher container management platform itself Rancher 1.
In less than a week, over 24,000 developers, sysadmins, and engineers will arrive in Las Vegas to attend AWS re:Invent (Nov. 28 - Dec 2). If you’re headed to the conference, we look forward to seeing you there! We’ll be onsite previewing enhancements included in our upcoming Rancher v1.2 release: Support for the latest versions of Kubernetes and Docker: As we’ve previously mentioned, we’re committed to supporting multiple container orchestration frameworks, and we’re eager to show off our latest support for Docker Native Orchestration and Kubernetes.
[Rancher is a complete container management solution, and to be a complete platform, we’ve placed careful consideration into how we handle networking between containers on our platform. So today, we’re posting a quick example to illustrate how networking in Rancher works. While Rancher can be deployed on a single node, or scaled to thousands of nodes, in this walkthrough, we’ll use just a handful of hosts and containers.] Setting up and Launching a Containerized Application [Our first task is to set up our infrastructure, and for this exercise, we’ll use AWS.
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.
On April 29th, Shannon Williams and Darren Shepherd hosted an online meetup to talk about deploying microservices based applications using Docker Compose and Rancher. The session included demonstrations of how to build a Docker Compose file, and how to use Rancher’s upcoming services capability to deploy, scale and manage docker environments. The first hour of the video includes overview content and the demonstrations. The rest of the recording are questions from the attendees.
Since I started playing with Docker I have been thinking that its network implementation is something that will need to be improved before I could really use it in production. It is based on container links and service discovery but it only works for host-local containers. This creates issues for a few use cases, for example when you are setting up services that need advanced network features like broadcasting/multicasting for clustering.