Ask Sendai

Helm is one of the best things about Kubernetes. (Which is why we talk about it in great depth here.) Rather than setting up an entirely new environment and configuring each kube object manually, you can now use Helm and Helm Charts—the template for different Kubernetes setups—to automate 90% of the work. For more on Helm Charts in full and how they’re designed to be flexible and robust, don’t forget to check out our Spotlight on Helm articles first.

In April the Guardian switched off the Mongo DB cluster used to store our content after completing a migration to PostgreSQL on Amazon RDS. This post covers why and how At the Guardian, the majority of content – including articles, live blogs, galleries and video content – is produced in our in-house CMS tool, Composer. This, until recently, was backed by a Mongo DB database running on AWS. This database is essentially the “source of truth” for all Guardian content that has been published online – approximately 2.

Kiam: Iterating for Security and ReliabilityPaul InglesBlockedUnblockFollowFollowingMay 1Kiam bridges Kubernetes’ Pods with Amazon’s Identity and Access Management (IAM). It makes it easy to assign short-lived AWS security credentials to your application. We created Kiam in 2017 to quickly address correctness issues we had running kube2iam in our production clusters. We’ve made a number of changes to it’s original design to make it more secure, reliable and easier to operate. This article covers a little of the story that led to us creating Kiam and more about what makes it novel.

At Ibotta, we chose kube2iam to assign AWS IAM Roles to containers running in our Kubernetes cluster. Lately, we’ve run into some issues with it—specifically when running a job that scores all of our service repos. This spins up a number of pods in parallel and has often failed to correctly access roles. After further investigation, the future of the project seems to be uncertain and there are other issues logged around race conditions, etc.

Here is how Istio and Hystrix differ in the implementation of the circuit breaker pattern, handling the lack of availability of a service. There is no denying that in the last few years, technologies like Docker and Kubernetes, to name a few of the most relevant, have revolutionized how we reason about software development and deployment. But whilst the fast pace of the software development industry pushes developers to adopt the most recent technologies, it is important to take a step back and to have a better look at established patterns that enable parts of these technologies.

In the previous blog posts in this series, we introduced the Netflix Media DataBase (NMDB) and its salient “Media Document” data model. In this post we will provide details of the NMDB system architecture beginning with the system requirements—these will serve as the necessary motivation for the architectural choices we made. A fundamental requirement for any lasting data system is that it should scale along with the growth of the business applications it wishes to serve.

Red Hat Container Development Kit (CDK) 3.7 is now available to run anOpenShift/Kubernetes cluster on your laptop for developing cloud- and container-based applications. We are pleased to announce the availability of theRed Hat Container Development Kit (CDK) 3.7.CDK 3.7 is based on Minishiftv1.27.0, a command-line tool to quickly provision anOpenShift and Kubernetes cluster on your local machine for developing cloud- and container-based applications. The CDK alsoincludes OpenShift Container Platform v3.

The Kubernetes platform’s evolution allows organizations to revisit how they develop new applications using microservices and containers. As with any new technology there can be the temptation to “move everything to containers”, yet history shows the length of such transitions is measured in years, or even decades. With a major part of the current application landscape residing in virtual machines, the mission of the open source KubeVirt project is to re-imagine virtualization in a Kubernetes world – enabling the use of Kubernetes as a converged platform for running and managing both application containers and virtual machines side by side.

Grafana is the defacto dashboarding solution for time-series data. It supports over 40 datasources (as of this writing), and the dashboarding story has matured considerably with new features, including the addition of teams and folders. We now want to move on from being a dashboarding solution to being an observability platform, to be the go-to place when you need to debug systems on fire. Observability. There are a lot of definitions out there as to what that means.

Deploying applications to a kubernetes cluster is well defined and can in some cases be as simple as kubectl create -f app.yaml. The user’s story to deploy apps across multiple clusters has not been that simple. How should an app workload be distributed? Should the app resources be replicated into all clusters, or replicated into selected clusters or partitioned into clusters? How is the access to clusters managed? What happens if some of the resources, which user wants to distribute pre-exist in all or fewer clusters in some form.