All Posts By

Kaitlyn Barnard

CNCF Survey: Use of Cloud Native Technologies in Production Has Grown Over 200%

By | Blog

The bi-annual CNCF survey takes a pulse of the community to better understand the adoption of cloud native technologies. This is the sixth time CNCF has taken the temperature of the container management marketplace.

Key Takeaways

  • Production usage of CNCF projects has grown more than 200% on average since December 2017, and evaluation has jumped 372%.
  • The use of serverless technology continues to grow, up 22% since December 2017 with the majority of respondents using hosted platforms such as AWS Lambda (70%).
  • The top three benefits of cloud native technology are faster deployment time, improved scalability, and cloud portability.
  • 40% of respondents from enterprise companies (5000+) are running Kubernetes in production.

About the Survey Methodology & Respondents

This was most responses we’ve received to date with 2,400 people taking part the survey, primarily from North America (40%) and Europe (36%) in Developer or IT-related roles:

  • Developer: 49%
  • Operations: 36%
  • IT Manager: 11%
  • Development Manager: 14%

The majority of respondents are from companies with more than 5,000 employees, skewing the results of this survey toward usage of CNCF technologies in the enterprise. The top industries are technology (22%), software (22%), financial services (9%), and telecommunications (8%).

This survey was conducted in English, and we have a Chinese version currently underway, the results of which will be available later in the year. You can view additional demographics breakdowns below: 

The Changing Landscape of Application Development

In this most recent version of the survey, we’ve added additional questions on releases to learn more about how companies are managing their software development cycles. One of the benefits of microservices architectures is the ability for flexible deployments, allowing companies to cut releases as often as they need. Prior to microservices, typical release cycles happened much less often, typically once or twice a year. Responses highlighted this with the breakdown of respondents’ release cycles fairly evenly spread out:

  • Weekly (20%)
  • Monthly (18%)
  • Daily (15%)
  • Adhoc (14%)

What are your release cycles?

The majority of these releases are automated (42%), with 25% of respondents using a hybrid release method and 27% doing manual releases. As automated releases grow, so does the popularity of tools to manage CI/CD pipelines with Jenkins as the leading tool (70%) followed by Terraform (27%) and Custom Scripts (26%).

Are release cycles manual or automated?

In addition, 67% of respondents are checking in code multiple times per day compared to 28% checking in code a few times a week and 6% a few times per month.

As for number of machines (including VMs, bare metal, etc.) in fleet, we’re starting to see this slightly increase with 5000+ at 17% up from 14% during our last survey in December 2017, 6-20 (16% down from 18%), 21-50 (14%), 51-100 (11%).

On average, how many machines are in your fleet?

What Cloud?

We’re continuing to see companies use a mix of on premise (64%), private cloud (50%), and public cloud (77%) solutions.

Which of the following data center types does your company/organization use?

As for containers, the majority of companies are deploying to AWS (63% down from 69%), followed by on premise servers (43% down from 51%), Google Cloud Platform (35% down from 39%), Microsoft Azure (29% up from 16%), VMware (24%), and OpenStack (20% down from 22%).

Your company/organization deploys containers to which of the following environments?

These numbers continue to be inline with the trends we’ve seen over the past year, with two notable changes. On-premise use is down from 51% in December 2017 to 43%, most likely due to growing use of private clouds. Secondly, this is the first time we’ve seen extensive use of VMware in these survey results, with only 1.2% of people citing usage in the December 2017 survey.

Growth of Containers

73% (compared to 75%) of respondents are currently using containers in production today, with the remaining 27% (compared to 25%) planning to use them in the future. 89% of respondents are currently using containers for proof of concepts, as well as testing (85%) and development (86%).

Your company/organization uses containers for:

The number of containers that organizations are typically running is also holding steady with 29% running less than 50, 50-249 (27%), 250-999 (17%), and 15% running more than 5,000 containers. There is a slight increase in organizations who are using less than 50, up to 29% from 23% in December 2017, and a slight decrease in organizations running 250-999 (down to 17% from 22%).

How many containers does your company/organization typically run?

As for container management tools, Kubernetes remains the leader with 83% (up from 77%) of respondents citing use followed by Amazon ECS (24% up from 18%), Docker Swarm (21% up from 17%), and Shell Scripts (20% up from 12%).

Your company/organization manages containers with:


58% of respondents are using Kubernetes in production, while 42% are evaluating it for future use. In comparison, 40% of enterprise companies (5000+) are running Kubernetes in production.

In production, 40% of respondents are running 2-5 clusters, 1 cluster (22%), 6-10 clusters (14%), and more than 50 clusters (13% up from 9%).

As for which environment Kubernetes is being run in, 51% are using AWS (down from 57%), on premise servers (37% down from 51%), Google Cloud Platform (32% down from 39%), Microsoft Azure (20% down from 23%), OpenStack (16% down from 22%), and VMware (15% up from 1%). The graph below illustrates where respondents are running Kubernetes vs. where they’re deploying containers.

Kubernetes Environment vs. Container Environment

For local development, the majority of respondents are targeting environments such as Minikube (45%), Docker Kubernetes (39%), and on prem Kubernetes installations (30%).

We also asked respondents about the tools they are using to manage various aspects of their applications:

The preferred method for packaging is Helm (68%) followed by managed Kubernetes offerings (19%).

The majority of respondents are autoscaling stateless applications (64%), followed by Java applications (45%), and task/queue processing applications (37%). Those who are not using autoscaling were either not aware of the functionality (21%) or do not want to autoscale their workloads at this time (31%).

Ingress Providers
The top Kubernetes ingress providers cited are nginx (64% up from 57%), HAProxy (29%), F5 (15% up from 11%), and Envoy (15% up from 9%).

Exposing Cluster External Services
The number one way respondents are exposing Cluster External Services like internet or other VMs is through load-balancer services (67%). This is followed by L7 ingress (39%) and integration with 3rd-party load-balancer (33%).

Separating Kubernetes in an Organization with Multiple Teams
Respondents are separating multiple teams within Kubernetes using Namespaces (71%), separate Ccusters (51%), and Only labels (15%).

Separating Kubernetes Applications
Respondents are separating Kubernetes applications using Namespaces (78%), separate clusters (50%), and Only labels (21%).

Cloud Native in Production

What are the benefits of cloud native projects? Respondents cited the top three reasons as:

  • Faster deployment time (50%)
  • Improved scalability (45%)
  • Cloud portability (42%)

As for the cloud native projects that are being used in production and evaluated:

CNCF Projects

Many CNCF projects showed significant jumps in production usage since our last survey, such as Containerd (45% up from 18%), CoreDNS (36% up from 7%), Envoy (24% up from 4%), Fluentd (57% up from 38%), gRPC (45% up from 22%), Jaeger (25% up from 5%), Linkerd (16% up from 3%), and OpenTracing (21% up from 8%). On average, CNCF project usage is up over 200% since our last survey.

The number of respondents evaluating CNCF projects also jumped with Containerd (55% up from 22%), CoreDNS (64% up from 14%), Envoy (74% up from 26%), Fluentd (43% up from 22%), gRPC (55% up from 16%), Jaeger (75% up from 15%), Linkerd (84% up from 15%), and OpenTracing (80% up from 25%). On average, CNCF project evaluation is up 372% since our last survey.

Projects that are new to CNCF also have high rates of consideration, with respondents notably evaluating SPIRE (94%), TUF (93%), Open Policy Agent (92%), Vitess (92%), and SPIFEE (92%).

Challenges in Using & Deploying Containers

As cloud native technologies change the way companies are designing and building applications, challenges are inevitable. The top challenges that respondents face are:

  • Cultural Changes with Development Team (41%)
  • Complexity (40% up from 35%)
  • Lack of Training (40%)
  • Security (38% down from 43%)
  • Monitoring (34% down from 38%)
  • Storage (30% down from 41%)
  • Networking (30% down from 38%)

There are two notable changes to these top challenges. While this is the first time we explicitly asked about cultural changes with the development team, it was cited as the number one challenge in using and deploying containers. Second, lack of training is a new addition to the survey. While CNCF has invested heavily in Kubernetes training over the past year including both free and paid courses and certification for Kubernetes Administrators and Application Developers, we continue to host new projects that need additional training resources as they grow.

The remainder of top challenges have been consistent over our past surveys, but the percentages are continuing to drop as more resources and tools are added to solve these problems.

What are your challenges in using / deploying containers:

Also interesting is the decrease in storage and networking as a challenge alongside the growth of cloud native storage projects such as:

  • Rook: 11% using in production of respondents while 89% (up from 29%) are evaluating.
  • Minio: 27% of respondents are using in production while 73% (up from 28%) are evaluating.
  • OpenSDS: 16% (up from 7%) of respondents are using in production while 84% (up from 14%) are evaluating.
  • REX-Ray: 18% of respondents are using in production while 82% are evaluating.
  • Openstorage: 19% (down from 31%) of respondents are using in production while 81% (up from 36%) are evaluating.

Which of these cloud native storage projects is your company / organization using:

Growth of Serverless

We also continued to track the growth of serverless technology in this survey. 38% of organizations are currently using serverless technology which is up from 31%, with 32% using a hosted platform and 6% using installable software.

37% are not using serverless technology which is down from 41%, but an additional 26% plan to within the next 12-18 months.

Top installable serverless platforms are:

  • Kubeless (42% up from 2%)
  • Apache OpenWhisk (25% up from 12%)
  • OpenFaas (20% up from 10%)

Which installable serverless platforms does your organization use?

Top hosted serverless platforms are:

  • AWS Lambda (70%)
  • Google Cloud Functions (25% up from 13%)
  • Azure Functions (20% up from 12%)

Which hosted serverless platforms does your organization use?

As usage of serverless grew, there is also significant interest in the serverless project CloudEvents with 80% of respondents evaluating the project for us and 21% using it in production. CloudEvents is an effort organized by CNCF’s Serverless Working Group to create a specification for describing event data in a common way.

How to Learn More?

Are you just getting started or want to learn more about cloud native projects? Here are the top ways respondents are learning about cloud native technologies:


20% of respondents use documentation to learn about cloud native projects, the number one resource cited in this survey. For example, SIG-Docs helps maintains an extensive resource of detailed Kubernetes documentation. This includes everything from how to get started with a specific feature to best ways to get involved as a contributor. Each CNCF project hosts extensive documentation on their websites, which can be found here.

KubeCon + CloudNativeCon

12% of respondents attend KubeCon + CloudNativeCon to learn more about the technologies they’re using. KubeCon + CloudNativeCon gathers all CNCF projects under one roof and brings together leading technologists from open source cloud native communities to further the advancement of cloud native computing. The event happens three times per year in Europe, China, and North America.

CNCF Website and Webinars

12% of respondents visit the CNCF website and attend webinars to get more information. is the main resource for all cloud native projects, housing information on a variety of subjects including upcoming events, training, certification, blog posts, and more.

The CNCF Webinar Series takes place every Tuesday from 10am-11am PT. You can see the upcoming schedule and view recordings and slides of previous webinars.

Meetups and Local Events

11% of respondents attend meetups and local events to learn about cloud native technologies. CNCF hosts 149 meetups under our umbrella across 33 countries with over 76,000 members. You can find your local meetup here.

CNCF and the local cloud native communities support events all over the world, from conferences to roadshows. You can view upcoming events here.


10% of respondents get their information from Twitter. CNCF tweets out project, community, and foundation news from our Twitter handle. You can also follow your favorite cloud native projects, a list of their Twitter handles (and additional social accounts) can be found here.

How do you learn about cloud native technologies?

A huge thank you to everyone who participated in our survey. We hope to see you at KubeCon + CloudNativeCon in Shanghai (November 12-15, 2018) and Seattle (December 11-13, 2018).

Stay tuned for our follow-up to this survey with results from our Chinese survey coming out later this year!

You can also view the findings from past surveys here:

March 2018: China is Going Native with Cloud
December 2017: Cloud Native Technologies Are Scaling Production Applications
June 2017: Survey Shows Kubernetes Leading as Orchestration Platform
January 2017: Kubernetes moves out of testing and into production
June 2016: Container Survey
March 2016: Container survey results

Demystifying RBAC in Kubernetes

By | Blog

Today’s post is written by Javier Salmeron, Engineer at Bitnami

Many experienced Kubernetes users may remember the Kubernetes 1.6 release, where the Role-Based Access Control (RBAC) authorizer was promoted to beta. This provided an alternative authentication mechanism to the already existing, but difficult to manage and understand, Attribute-Based Access Control (ABAC) authorizer. While everyone welcomed this feature with excitement, it also created innumerable frustrated users. StackOverflow and Github were rife with issues involving RBAC restrictions because most of the docs or examples did not take RBAC into account (although now they do). One paradigmatic case is that of Helm: now simply executing “helm init + helm install” did not work. Suddenly, we needed to add “strange” elements like ServiceAccounts or RoleBindings prior to deploying a WordPress or Redis chart (more details in this guide).

Leaving these “unsatisfactory first contacts” aside, no one can deny the enormous step that RBAC meant for seeing Kubernetes as a production-ready platform. Since most of us have played with Kubernetes with full administrator privileges, we understand that in a real environment we need to:

  • Have multiple users with different properties, establishing a proper authentication mechanism.
  • Have full control over which operations each user or group of users can execute.
  • Have full control over which operations each process inside a pod can execute.
  • Limit the visibility of certain resources of namespaces.

In this sense, RBAC is a key element for providing all these essential features. In this post, we will quickly go through the basics (for more details, check the video below) and dive a bit deeper into some of the most confusing topics.

The key to understanding RBAC in Kubernetes

In order to fully grasp the idea of RBAC, we must understand that three elements are involved:

  • Subjects: The set of users and processes that want to access the Kubernetes API.
  • Resources: The set of Kubernetes API Objects available in the cluster. Examples include Pods, Deployments, Services, Nodes, and PersistentVolumes, among others.
  • Verbs: The set of operations that can be executed to the resources above. Different verbs are available (examples: get, watch, create, delete, etc.), but ultimately all of them are Create, Read, Update or Delete (CRUD) operations.

With these three elements in mind, the key idea of RBAC is the following:

We want to connect subjects, API resources, and operations. In other words, we want to specify, given a user, which operations can be executed over a set of resources.

Understanding RBAC API Objects

So, if we think about connecting these three types of entities, we can understand the different RBAC API Objects available in Kubernetes.

  • Roles: Will connect API Resources and Verbs. These can be reused for different subjects. These are binded to one namespace (we cannot use wildcards to represent more than one, but we can deploy the same role object in different namespaces). If we want the role to be applied cluster-wide, the equivalent object is called ClusterRoles.
  • RoleBinding: Will connect the remaining entity-subjects. Given a role, which already binds API Objects and verbs, we will establish which subjects can use it. For the cluster-level, non-namespaced equivalent, there are ClusterRoleBindings.

| TIP: Watch the video for a more detailed explanation.

In the example below, we are granting the user jsalmeron the ability to read, list and create pods inside the namespace test. This means that jsalmeron will be able to execute these commands:

But not these:

Example yaml files:

Another interesting point would be the following: now that the user can create pods, can we limit how many? In order to do so, other objects, not directly related to the RBAC specification, allow configuring the amount of resources: ResourceQuota and LimitRanges. It is worth checking them out for configuring such a vital aspect of the cluster.

Subjects: Users and… ServiceAccounts?

One topic that many Kubernetes users struggle with is the concept of subjects, but more specifically the difference between regular users and ServiceAccounts. In theory it looks simple:

  • Users: These are global, and meant for humans or processes living outside the cluster.
  • ServiceAccounts: These are namespaced and meant for intra-cluster processes running inside pods.

Both have in common that they want to authenticate against the API in order to perform a set of operations over a set of resources (remember the previous section), and their domains seem to be clearly defined. They can also belong to what is known as groups, so a RoleBinding can bind more than one subject (but ServiceAccounts can only belong to the “system:serviceaccounts” group). However, the key difference is a cause of several headaches: users do not have an associated Kubernetes API Object. That means that while this operation exists:

this one doesn’t:

This has a vital consequence: if the cluster will not store any information about users, then, the administrator will need to manage identities outside the cluster. There are different ways to do so: TLS certificates, tokens, and OAuth2, among others.

In addition, we would need to create kubectl contexts so we could access the cluster with these new credentials. In order to create the credential files, we could use the kubectl config commands (which do not require any access to the Kubernetes API, so they could be executed by any user). Watch the video above to see a complete example of user creation with TLS certificates.

RBAC in Deployments: A use case

We have seen an example where we establish what a given user can do inside the cluster. However, what about deployments that require access to the Kubernetes API? We’ll see a use case to better understand this.

Let’s go for a common infrastructure application: RabbitMQ. We will use the Bitnami RabbitMQ Helm chart (in the official helm/charts repository), which uses the bitnami/rabbitmq container. This container bundles a Kubernetes plugin responsible for detecting other members of the RabbitMQ cluster. As a consequence, the process inside the container requires accessing the Kubernetes API, and so we require to configure a ServiceAccount with the proper RBAC privileges.

When it comes to ServiceAccounts, follow this essential good practice:

Have ServiceAccounts per deployment with the minimum set of privileges to work.

For the case of applications that require access to the Kubernetes API, you may be tempted to have a type of “privileged ServiceAccount” that could do almost anything in the cluster. While this may seem easier, this could pose a security threat down the line, as unwanted operations could occur. Watch video above to see the example of Tiller, and the consequences of having ServiceAccounts with too many privileges.

In addition, different deployments will have different needs in terms of API access, so it makes sense to have different ServiceAccounts for each deployment.

With that in mind, let’s check what the proper RBAC configuration for our RabbitMQ deployment should be.

From the plugin documentation page and its source code, we can see that it queries the Kubernetes API for the list of Endpoints. This is used for discovering the rest of the peer of the RabbitMQ cluster. Therefore, what the Bitnami RabbitMQ chart creates is:

A ServiceAccount for the RabbitMQ pods.A Role (we assume that the whole RabbitMQ cluster will be deployed in a single namespace) that allows the “get” verb for the resource Endpoint.

A RoleBinding that connects the ServiceAccount and the role.

The diagram shows how we enabled the processes running in the RabbitMQ pods to perform “get” operations over Endpoint objects. This is the minimum set of operations it requires to work. So, at the same time, we are ensuring that the deployed chart is secure and will not perform unwanted actions inside the Kubernetes cluster.

Final thoughts

In order to work with Kubernetes in production, RBAC policies are not optional. These can’t be seen as only a set of Kubernetes API Objects that administrators must know. Indeed, application developers will need them to deploy secure applications and to fully exploit the potential that the Kubernetes API offers to their cloud-native applications. For more information on RBAC, check the following links:

Getting the Most out of Istio with CNCF Projects

By | Blog

This guest post was written by Neeraj Poddar, Platform Lead, Aspen Mesh

Are you considering or using a service mesh to help manage your microservices infrastructure? If so, here are some basics on how a service mesh can help, the different architectural options, and tips and tricks on using some key CNCF tools that are included with Istio to get the most out of it.

The beauty of a service mesh is that it bundles so many capabilities together, freeing engineering teams from having to spend inordinate amounts of time managing microservices architectures. Kubernetes has solved many build and deploy challenges, but it is still time consuming and difficult to ensure reliability at runtime. A service mesh handles the difficult, error-prone parts of cross-service communication such as latency-aware load balancing, connection pooling, service-to-service encryption, TLS, instrumentation, and request-level routing.

Once you have decided a service mesh makes sense to help manage your microservices, the next step is deciding what service mesh to use. There are several architectural options, from the earliest model of a library approach, the node agent architecture, and the model which seems to be gaining the most traction – the sidecar model. We have also recently seen an evolution from data plane meshes like Envoy, to control plane meshes such as Istio. As active users of Istio and believers in the sidecar architecture striking the right balance between a robust set of features and a lightweight footprint, so let’s drill down into how to get the most out of Istio.

One of the capabilities Istio provides is distributed tracing. Tracing provides service dependency analysis for different microservices and it provides tracking for requests as they are traced through multiple microservices. It’s also a great way to identify performance bottlenecks and zoom into a particular request to define things like which microservice contributed to the latency of a request or which service created an error.

We use and recommend Jaeger for tracing as it has several advantages:

  • OpenTracing compatible API
  • Flexible & scalable architecture
  • Multiple storage backends
  • Advanced sampling
  • Accepts Zipkin spans
  • Great UI
  • CNCF project and active OS community

Another powerful thing you gain with Istio is the ability to collect metrics. Metrics are key to understanding historically what has happened in your applications, and when they were healthy compared to when they were not. A service mesh can gather telemetry data from across the mesh and produce consistent metrics for every hop. This makes it easier to quickly solve problems and build more resilient applications in the future.

We use and recommend Prometheus for gathering metrics for several reasons:

  • Pull model
  • Flexible query API
  • Efficient storage
  • Easy integration with Grafana
  • CNCF project and active OS community

Check out the recent CNCF webinar on this topic for a deeper look into what you can do with these tools and more.

Kubernetes 1.10: Stabilizing Storage, Security, and Networking

By | Blog

Editor’s note: today’s post is by the 1.10 Release Team

Originally posted on

We’re pleased to announce the delivery of Kubernetes 1.10, our first release of 2018!

Today’s release continues to advance maturity, extensibility, and pluggability of Kubernetes. This newest version stabilizes features in 3 key areas, including storage, security, and networking. Notable additions in this release include the introduction of external kubectl credential providers (alpha), the ability to switch DNS service to CoreDNS at install time (beta), and the move of Container Storage Interface (CSI) and persistent local volumes to beta.

Let’s dive into the key features of this release:

Storage – CSI and Local Storage move to beta

This is an impactful release for the Storage Special Interest Group (SIG), marking the culmination of their work on multiple features. The Kubernetes implementation of the Container Storage Interface (CSI) moves to beta in this release: installing new volume plugins is now as easy as deploying a pod. This in turn enables third-party storage providers to develop their solutions independently outside of the core Kubernetes codebase. This continues the thread of extensibility within the Kubernetes ecosystem.

Durable (non-shared) local storage management progressed to beta in this release, making locally attached (non-network attached) storage available as a persistent volume source. This means higher performance and lower cost for distributed file systems and databases.

This release also includes many updates to Persistent Volumes. Kubernetes can automatically prevent deletion of Persistent Volume Claims that are in use by a pod (beta) and prevent deletion of a Persistent Volume that is bound to a Persistent Volume Claim (beta). This helps ensure that storage API objects are deleted in the correct order.

Security – External credential providers (alpha)

Kubernetes, which is already highly extensible, gains another extension point in 1.10 with external kubectl credential providers (alpha). Cloud providers, vendors, and other platform developers can now release binary plugins to handle authentication for specific cloud-provider IAM services, or that integrate with in-house authentication systems that aren’t supported in-tree, such as Active Directory. This complements the Cloud Controller Manager feature added in 1.9.  

Networking – CoreDNS as a DNS provider (beta)

The ability to switch the DNS service  to CoreDNS at install time is now in beta. CoreDNS has fewer moving parts: it’s a single executable and a single process, and supports additional use cases.

Each Special Interest Group (SIG) within the community continues to deliver the most-requested enhancements, fixes, and functionality for their respective specialty areas. For a complete list of inclusions by SIG, please visit the release notes.


Kubernetes 1.10 is available for download on GitHub. To get started with Kubernetes, check out these interactive tutorials.

2 Day Features Blog Series

If you’re interested in exploring these features more in depth, check back next week for our 2 Days of Kubernetes series where we’ll highlight detailed walkthroughs of the following features:

  • Day 1 – Container Storage Interface (CSI) for Kubernetes going Beta
  • Day 2 – Local Persistent Volumes for Kubernetes going Beta

Release team

This release is made possible through the effort of hundreds of individuals who contributed both technical and non-technical content. Special thanks to the release team led by Jaice Singer DuMars, Kubernetes Ambassador for Microsoft. The 10 individuals on the release team coordinate many aspects of the release, from documentation to testing, validation, and feature completeness.

As the Kubernetes community has grown, our release process represents an amazing demonstration of collaboration in open source software development. Kubernetes continues to gain new users at a rapid clip. This growth creates a positive feedback cycle where more contributors commit code creating a more vibrant ecosystem.

Project Velocity

The CNCF has continued refining an ambitious project to visualize the myriad contributions that go into the project. K8s DevStats illustrates the breakdown of contributions from major company contributors, as well as an impressive set of preconfigured reports on everything from individual contributors to pull request lifecycle times. Thanks to increased automation, issue count at the end of the release was only slightly higher than it was at the beginning. This marks a major shift toward issue manageability. With 75,000+ comments, Kubernetes remains one of the most actively discussed projects on GitHub.

User Highlights

According to a recent CNCF survey, more than 49% of Asia-based respondents use Kubernetes in production, with another 49% evaluating it for use in production. Established, global organizations are using Kubernetes in production at massive scale. Recently published user stories from the community include:

  • Huawei, the largest telecommunications equipment manufacturer in the world, moved its internal IT department’s applications to run on Kubernetes. This resulted in the global deployment cycles decreasing from a week to minutes, and the efficiency of application delivery improved by tenfold.
  • Jinjiang Travel International, one of the top 5 largest OTA and hotel companies, use Kubernetes to speed up their software release velocity from hours to just minutes. Additionally, they leverage Kubernetes to increase the scalability and availability of their online workloads.
  • Haufe Group, the Germany-based media and software company, utilized Kubernetes to deliver a new release in half an hour instead of days. The company is also able to scale down to around half the capacity at night, saving 30 percent on hardware costs.
  • BlackRock, the world’s largest asset manager, was able to move quickly using Kubernetes and built an investor research web app from inception to delivery in under 100 days.

Is Kubernetes helping your team? Share your story with the community.

Ecosystem Updates

  • The CNCF is expanding its certification offerings to include a Certified Kubernetes Application Developer exam. The CKAD exam certifies an individual’s ability to design, build, configure, and expose cloud native applications for Kubernetes. The CNCF is looking for beta testers for this new program. More information can be found here.
  • Kubernetes documentation now features user journeys: specific pathways for learning based on who readers are and what readers want to do. Learning Kubernetes is easier than ever for beginners, and more experienced users can find task journeys specific to cluster admins and application developers.  
  • CNCF also offers online training that teaches the skills needed to create and configure a real-world Kubernetes cluster.


The world’s largest Kubernetes gathering, KubeCon + CloudNativeCon is coming to Copenhagen from May 2-4, 2018 and will feature technical sessions, case studies, developer deep dives, salons and more! Check out the schedule of speakers and register today!


Join members of the Kubernetes 1.10 release team on April 10th at 10am PDT to learn about the major features in this release including Local Persistent Volumes and the Container Storage Interface (CSI). Register here.

Get Involved:

The simplest way to get involved with Kubernetes is by joining one of the many Special Interest Groups (SIGs) that align with your interests. Have something you’d like to broadcast to the Kubernetes community? Share your voice at our weekly community meeting, and through the channels below.

Thank you for your continued feedback and support.

  • Post questions (or answer questions) on Stack Overflow
  • Join the community portal for advocates on K8sPort
  • Follow us on Twitter @Kubernetesio for latest updates
  • Chat with the community on Slack
  • Share your Kubernetes story.

CNCF Survey: China is Going Native with Cloud

By | Blog

By Swapnil Bhartiya, Founder & Writer at TFiR: The Fourth Industrial Revolution

Swapnil is a journalist and writer who has been covering Linux & Open Source for 10 years. He is also a science fiction writer whose stories have been broadcast on Indian radio and published in leading Indian magazines.

To better gauge how quickly Asian companies are adopting open source and cloud native technologies like Kubernetes and Prometheus, CNCF recently conducted its cloud native survey in Chinese.  The bi-annual survey takes a pulse of the community to understand the adoption of cloud native technologies. More than 700 people responded to the December 2017 surveys, with 500 responding to the English version and 187 responding to the Chinese version.

For the first time, we have a very comprehensive sample and data to understand the adoption of cloud native technologies in China. Since the survey was conducted in Mandarin, it reflects the Chinese market more than the overall Asian market, excluding major economies like Japan. We expect that future surveys will be conducted in more languages to get an ever clearer picture.

KubeCon + CloudNativeCon Europe is around the corner from May 2-4 in Copenhagen, and the first KubeCon + CloudNativeCon will be held in China in November. It will be interesting to see how the representation and responses change as CNCF reaches new developers, vendors, and user attendees in other parts of the world. I can’t wait for the next KubeCon to learn more about the cloud native journey of Asian players. Read on to learn more about new cloud native developments in China.

P.S. This blog is a follow up to “Cloud Native Technologies Are Scaling Production Applications,” which analyzed trends and data from our global survey conducted in English.  

China, an Open Source Cloud Native Powerhouse

The survey data collected validates the fact that China is embracing cloud native and open source technologies at a phenomenal rate.

We already know the famous BAT (Baidu, Alibaba and Tencent) organizations are using open source technologies to build their services that serve more than a billion users.  For example, I recently interviewed Bowyer Liu, the chief architect at Tencent, which built their own public cloud using OpenStack. It’s called TStack, which is running more than 12,000 virtual machines (VMs), covering 17 clusters, spread across 7 data centers in 4 regions. TStack is managing more than 300 services that include QQ and WeChat. TStack is also using open source projects like CoreOS, Docker, Kubernetes, KVM, HAProxy, Keepalived, Clear Container, Rabbitmq, MariaDB, Nginx, Ansible, Jenkins, Git, ELK, Zabbix, Grafana, InfluxDB, Tempest and Rally.

Of the 18 CNCF platinum members, 4 are located in Asia; of its 8 gold members, 3 are based in Asia. The community runs 18 CNCF Meetups across Asia, with 8 in China alone. Furthermore, in the past quarter, 3 of the top 10 most active companies — Huawei, Fujitsu and Treasure Data — contributing across all CNCF projects are based in Asia.

About the Survey Methodology & Respondents

The respondents represented a variety of company sizes from small startups to large enterprises:

  • Over 5000 employees: 22%
  • 1000-4999 employees: 16%
  • 500-999: 14%
  • 100-499: 27%
  • 50-99: 12%
  • 10-49: 8%

Out of the total respondents, 26% represented the tech industry; 13% represented Container/Cloud Solutions vendors, 12% came from the Financial Services industry; 11% from the Consumer industry; 6% from the Government and 6% from Manufacturing. In comparison, the North American survey had 44% representation from the tech industry and the second largest representation was from the container/cloud vendors 14%, the financial services industry was the 3rd largest with 7% representation. China is embracing cloud native technologies across the board, and the Chinese financial service industry seems to be more open to cloud native technologies as compared to their Western counterparts.

What Cloud Are They Running?

While public cloud continues to dominate the U.S. market, the Chinese market is more diverse. 24% of respondents were using private cloud and only 16% were using public cloud. 60% of respondents were using on-prem. Compare that number to North America where more than 81% of respondents were using the public cloud, and 61% were running on premise; whereas 44% are using some private cloud.

In China, Alibaba Cloud remains the leader with more than 55% of respondents said to be using it, 30% were using AWS, 28% were using OpenStack Cloud, 12% were using Microsoft Azure and around 6% were using Google Cloud Platform.

In North America, AWS remains the leader with 70% of respondents deploying their containers in AWS environment. Google Cloud Platform was at the second spot with 40% and Microsoft Azure took the 3rd spot with 23%. Compared to China, only 22% of respondents from North America acknowledged using OpenStack.

Growth of Containers

Out of the total respondents, only 6% were using more than 5,000 containers. A majority of the respondents, around 32% are using less than 50 containers, and around 30% of respondents were using 50-249 containers. 36% of respondents were using containers in development stage, whereas 32% were using it in production. 57% of respondents said that they are planning to use containers in production in future. A majority of respondents (22%) are using between 6-20 machines in their fleet, with 21-50 machines close behind at 17%; only 6% have more than 5,000 machines, which includes VMs and bare metal.

What about Kubernetes?

No surprises — Kubernetes remains the No. 1 platform to manage containers. 35% of Asian respondents said they were using Kubernetes to manage their containers. Azure Container Service was used by 19%. Docker Swarm was reported to be used by 16% of respondents. ECS came in at the 4 spot with 13% and 11% reporting using another Linux Foundation Project Cloud Foundry. 6% said they were using OpenShift, while another 6% reported using CoreOS Tectonic. This data shows a much more diverse cloud native ecosystem in China as compared to the United States.

Where Are They Running Kubernetes?

The most interesting finding from the survey was that more than 49% of respondents were using Kubernetes in production, with another 49% evaluating it for use. Some of the most well-known examples include Jinjiang Travel International, one of the top 5 largest OTA and hotel companies that sells hotels, travel packages, and car rentals. They use Kubernetes containers to speed up their software release velocity from hours to just minutes, and they leverage Kubernetes to increase the scalability and availability of their online workloads. China Mobile uses containers to replace VMs to run various applications on their platform in a lightweight fashion, leveraging Kubernetes to increase resource utilization. State Power Grid, the state-owned power supply company in China, uses containers and Kubernetes to provide failure resilience and fast recovery., one of China’s largest companies and the first Chinese Internet company to make the Global Fortune 500 list, chronicled their shift to Kubernetes from OpenStack in this blog from last year.

As expected, 52% of respondents were using Kubernetes with Alibaba public cloud, 26% were using AWS. China is bigger consumer of OpenStack as compared to the North America market (16%), around 26% of respondents were using OpenStack. A majority of respondents were running 10 or less clusters in production; 14% were running 1 cluster, 40% were running 2-5 clusters and 26% were running 6-10 clusters. Only 6% of the respondents running Kubernetes have more than 50 clusters in production.

One Ring to Bind Them All…

CNCF is at the bedrock of this cloud native movement and the survey shows adoption of CNCF projects is growing quickly in China. While Kubernetes remains the crown jewel, other CNCF projects are getting into production. 20% of respondents were running OpenTracing in production; 16% were using Prometheus; 13% were using gRPC; 10% were using CoreDNS; and 7% were using Fluentd. China is still warming up to newer projects like Istio where only 3% of respondents were using it in production.

Talking about new CNCF projects, we can’t ignore ‘serverless’ or ‘function as a service.’ The CNCF Serverless Working Group recently came out with a whitepaper to define serverless computing. The survey found that more than 25% of respondents are already using serverless technology and around 23% planned to use it in the next 12-18 months.

China leans heavily toward open source when it comes to serverless technologies. Apache OpenWhisk is the dominant serverless platform in China with more than 30% of respondents using it as their preferred platform. AWS Lambda is in the second spot with 24% of respondents using it. Azure was mentioned by 14% and Google Cloud Functions was mentioned by 9% of respondents.

We will hear more about serverless technologies in 2018, especially at the upcoming KubeCon + CloudNativeCon, May 2-4 in Copenhagen.

Challenges Ahead

As impressive as the findings of the survey are, we are talking about some fairly young technologies. Respondents cited many new and old challenges. Complexity remains the No. 1 concern, with more than 44% of respondents citing it as their biggest challenge followed by reliability (43%); monitoring (38%); and difficulty in choosing an orchestration solution (40%).

In contrast, for the North American respondents security remains the No. 1 concern, with 43% of respondents citing it as their biggest challenge followed by storage (41%); networking (38%); monitoring (38%); complexity (35%) and logging (32%).

This is a clear indication that the Chinese market is younger and still going through basic challenges that their Western counterparts have already overcome. To help Chinese companies move forward, documentation plays a very critical role in the proliferation of any technology, so it’s promising to see massive work going on to translate Kubernetes documentation into Mandarin.

The good news is that finding a vendor is not one of the biggest challenges for either of the two markets. With the release of the Certified Kubernetes Conformance Program, CNCF has instilled more confidence in users to pick and choose a vendor without fearing being locked down.

Getting Ready for Cloud Native World?

There is no playbook to help you embark on your journey to the cloud native world. However, there are some best practices that one can follow. A little under a year ago, Dr. Ying Xiong, Chief Architect of Cloud Computing at Huawei, talked about the company’s move toward cloud native architecture at KubeCon + CloudNativeCon Europe. Dr. Xiong has some tips – start with the right set of applications for cloud native journey; some apps are too difficult to redesign with microservice architecture; don’t start with those. Choose the easy ones, as you succeed you gain confidence and a model to replicate across your organization. He also advises in favor of using one platform to manage container and non container applications.

Be sure to join us at an upcoming CNCF Meetup.

For even deeper exposure to the cloud native community, ecosystem and user successes, be sure to attend our first KubeCon + CloudNativeCon China, Nov. 14-15 in Shanghai. 

This Week in Kubernetes: March 21st

By | Blog

Each week, the Kubernetes community shares an enormous amount of interesting and informative content including articles, blog posts, tutorials, videos, and much more. We’re highlighting just a few of our favorites from the week before. This week we’re talking machine learning, scalability, service mesh, and contributing to Kubernetes.

Running Apache Spark Jobs on AKS, Microsoft

Apache Spark, a fast engine for large-scale data processing, now supports native integration with Kubernetes clusters as a scheduler for Spark jobs. In this article, Lena Hall and Neil Peterson of Microsoft walk you through how to prepare and run Apache Spark jobs on an Azure Container Service (AKS) cluster. If you want to learn more about using Spark for large scale data processing on Kubernetes, check out this treehouse discussion video.

Introducing Agones: Open-source, Multiplayer, Dedicated Game-server Hosting Built on Kubernetes, Google

In the world of distributed systems, hosting and scaling dedicated game servers for online, multiplayer games presents some unique challenges. Because Kubernetes is an open-source, common standard for building complex workloads and distributed systems, it makes sense to expand this to scale game servers. In this article, Mark Mandel of Google introduces Agones, an open-source, dedicated game server hosting and scaling project built on top of Kubernetes, with the flexibility you need to tailor it to the needs of multiplayer games.

8 Ways to Bolster Kubernetes Security, TechBeacon

Kubernetes can affect many runtime security functions, including authentication, authorization, logging, and resource isolation. Since it also affects the container runtime environment, it’s a crucial part of maintaining a secure container infrastructure. In this article, John P. Mello Jr. of TechBeacon explains 8 ways to help keep Kubernetes secure.

Kubernetes from the Ground Up: Choosing a Configuration Method, OzNetNerd

Kubernetes’ configuration is simply a bunch of Kubernetes objects. In this article, Will Robinson of Contino takes you through a quick look at what these objects are, and what they’re used for. You’ll walk through imperative commands, imperative objects, and declarative objects including what imperative vs. declarative means and what is right for your application.

Stay tuned for more exciting content from the Kubernetes community next week, and join the KubeWeekly mailing list for the latest updates delivered directly to your inbox.

Is there a piece of content that you think we should highlight? Tweet at us! We’d love to hear what you’re reading, watching, or listening to.

Trace Your Microservices Application with Zipkin and OpenTracing

By | Blog

By Gianluca Arbezzano, Site Reliability Engineer at InfluxDB, CNCF Ambassador 

Walter Dal Mut is a certified Amazon Web Service consultant. He works at Corley SRL, an Italian company that helps other small and big companies move to the cloud.

During the first CNCF Italy Meetup, Walter shared his experience instrumenting a PHP microservices environment with Zipkin and OpenTracing.

Everybody doing logging in applications, and is effectively useful the problem is that we have a lot of detailed informations, they move very fast across multi services. They are almost impossible to read it in real time.

This is why we have monitors. With monitor I mean events, metrics and time series. One aspect of monitors that I love is the aggregation.

It makes easy to put things together and we can see so many things for example I can see the criticality of my issues looking at the occurances. I can compare the number of requests with the load time in just one graph. This is very useful and it’s something that I can’t see tailing logs.

With metrics we can measure changes. It is one of the most important things in my opinion for monitors because a deployment usually is the point in time when something change. If we are able to detect the entity of this change we can take any action based on how good or bad it is. We see immediately if what we changed is important or not. You will discover that so many times we change something that is not useful at all or my change is just not working as expected. Monitors are the only way to understand all of this.

Describing the image above I instrumented my application to send events and I collect them on InfluxDB. From the bottom right graph you can see green and red lines. Read lines tell to us that something is wrong, and now that we are know the distribution we can measure how a new version of our software improve or not the current state.

One tip to remember when you are building your dashboard is that a deploy is an important event. Based on what monitoring software you are using you can mark this special event with a vertical line, Grafana call this feature annotation. The annotation is printed across all the graphs part of the same dashboard. This line is the key to understand how a new release performs.

One missed information at some point is how the information is propagated in our system.

In a microservices it’s not really important the log generated by a single service we want to trace and jump across services following our request. I want to connect dots across my services and the tracing is designed to read time series in this terms.

In a traditional web application with a database, I want to understand the queries made to load a specific page. I want to understand how much it takes to keep them optimized and low in terms of numbers.

Tracing is all about spans and inter-process propagation and active span management.

A spans is a period of time that starts and ends, other than these two points we mark when the client send the request, when the server receive the request and when the server send the response to the client.

These four signals are important to understand the network latency between services.

Other than that you can mark custom events inside a span and you can calculate how long it takes to your application to end a specific task like generating a pdf, decompress a request, process a message queue and so on.

Inter-process propagation, the way that we propagate things as maybe using four eaters that we can send in my request. There is a trace indeed. It is the unity in fire that starts at time zero and ends when all my micro services are included. It is in the trace I.D. Then they have a spy identification using the spy effectively they want to use. Because the client send a request.

The inter-process propagation describe how we propagate things across network or processes. In HTTP we use headers to pass traces information across services. TraceId is the unique identifier for every single request every spans part of that requests is grouped under the same id. Every span has it’s id and it also have a parent span id. It is useful to aggregate all the spans to get the three of your spans.

There are different traces available the most famous open source are Jaeger (a project under the CNCF) an Zipkin started by Twitter.

During the talk Walter used Zipkin but they are both compatible with OpenTracing. If you use the right libraries you are able to switch between tracers transparently.

This is how a trace is represented by Zipkin. You can see the last of all your services on the left and every spans generated across your distributed system. The length of each span describes how much time it took and from this visualisation we already have a good set of information and optimisation points:

  • How many services we are calling to solve the request. Are they too much?
  • How many time I am calling the same service.
  • How much time a service is taking. If the authentication takes 80% of your request time every time you should fix it.
  • And many more.

Some spans have one or more dots, that white dots are logs. They are useful to understand when a specific event happen in time. You can use this feature to identify when you send an email or when a customer clicked a specific button tracking it’s UI experience.

The video shows a details demo about what Zipkin provides in terms of filtering, searching and event UI trick to quick identify traces that ended with an error. Other then showing how Zipkin works Walter shared his experience instrumenting PHP applications.

The focus of his talk is all about tricks and best practices really useful to listen in order to avoid some common mistakes.

They are a bit hard to transcribe and I will leave the video to you.

I will leave you the quote that he shared with us at the end of the presentation (spoiler alert)

“Measure is the key to science (Richard Feynman).”

Slides available


Cloud Native Computing Foundation Expands Certification Program to Kubernetes Application Developers – Beta Testers Needed

By | Blog

The Cloud Native Computing Foundation (CNCF), which sustains and integrates open source technologies like Kubernetes and Prometheus, announced today that it is expanding its certification program to include application developers who deploy to Kubernetes. After launching the highly successful Certified Kubernetes Administrator (CKA) exam and corresponding Kubernetes Certified Service Provider (KCSP) program back in September with more than 1,200 CKAs and 28 KCSPs to date, the natural follow-on was an exam focused on certifying application developers to cover the full spectrum of Kubernetes technical expertise.

We are looking for skilled Kubernetes professionals at vendor companies to beta test the exam curriculum.

Are you interested in getting an early peek as a beta tester? If so, please read on!

  • The online exam consists of a set of performance-based items (problems) to be solved in a command line.
  • The exam is expected to take approximately 2 hours to complete.
  • Beta testing is targeted for late April — early May.
  • After taking the exam, each beta tester will be asked to provide exam experience feedback in a questionnaire.

If you would like to be considered as a Beta tester for the CKAD exam, please sign-up via this short survey

You will be contacted with additional information when the exam is ready and the Beta team is selected. If you complete the beta exam with a passing grade, you will become one of the first Certified Kubernetes Application Developers.

With the majority of container-related job listings asking for proficiency in Kubernetes as an orchestration platform, the new program will help expand the pool of Kubernetes experts in the market, thereby enabling continued growth across the broad set of organizations a using the technology. Certification is a key step in that process, allowing certified application developers to quickly establish their credibility and value in the job market, and also allowing companies to more quickly hire high-quality teams to support their growth.

“The CKAD program was developed as an extension of CNCF’s Kubernetes training offerings which already includes certification for Kubernetes administrators. By introducing this new exam for application developers, anyone working with Kubernetes can now certify their competency in the platform,” said Dan Kohn Executive Director of Cloud Native Computing Foundation.  

To create the Certified Kubernetes Application Developer (CKAD) exam, 19 Kubernetes subject matter experts (SMEs) participated over four days in job analysis and item writing sessions co-located with Kubecon + CloudNativeCon in Austin, Texas in December. During these work sessions, the following exam scope statement was agreed upon:

CKAD Exam Scope Statement

The Certified Kubernetes Application Developer can design, build, configure, and expose cloud native applications for Kubernetes. The Certified Kubernetes Application Developer can define application resources and use core primitives to build, monitor, and troubleshoot scalable applications & tools in Kubernetes.

The exam assumes knowledge of, but does not test for, container runtimes and microservice architecture.

The successful candidate will be comfortable using:

  • An OCI-Compliant Container Runtime, such as Docker or rkt.
  • Cloud native application concepts and architectures.
  • A programming language, such as Python, Node.js, Go, or Java.

Also during the work sessions, the team defined seven content domains with a % weight in the exam:

  • 13%  Core Concepts
  • 18%  Configuration
  • 10%  Multi-Container Pods
  • 18%  Observability
  • 20%  Pod Design
  • 13%  Services & Networking
  • 8%   State Persistence

The SME group wrote exam problems, assigned complexity and difficulty ratings, and determine a provisional passing score of 66% during the working session.

CKAD exam launch is targeted for early May.

This Week in Kubernetes: March 14th

By | Blog

Each week, the Kubernetes community shares an enormous amount of interesting and informative content including articles, blog posts, tutorials, videos, and much more. We’re highlighting just a few of our favorites from the week before. This week we’re talking machine learning, scalability, service mesh, and contributing to Kubernetes.

7 Kubernetes Tools to Expand Your Container Architecture, Stackify

Kubernetes has become a vital resource for Agile and DevOps teams. As an open source tool, Kubernetes is becoming an ecosystem in itself, with other tools being developed to support it. Some of these extensions are coming straight from Kubernetes, while others are open source projects in their own right. In this article, John Julien of WeContent explores a few these tools in depth to help you better understand when and how you should be using them.

From Open Source to Sustainable Success: the Kubernetes Graduation Story, Google Cloud Platform

Kubernetes has graduated from CNCF incubation! Thanks to support of the Kubernetes project community, this milestone marks a significant achievement in the project’s maturity. In this article, Sarah Novotny and Aparna Sinha of Google share some of the best practices that were learned along the way and helped Kubernetes get where it is today. From building a community and user-friendly technology to investing in sustainability and enabling an ecosystem, take a look back at the evolution of Kubernetes.

How to Set Up Scalable Jenkins on Top of a Kubernetes Cluster, DZone

Jenkins is an open source continuous integration server used in many production applications and can be used on top of Kubernetes to help scale your application. In this article, Yuri Bushnev of AlphaSense walks you through how to use Jenkins auto-scaling inside a Kubernetes cluster. This allows all nodes to spin up automatically during builds, and be removed right after completion.

Single Sign-On for Kubernetes: An Introduction, The New Stack

Authentication and authorization are important steps in securing your Kubernetes clusters. And because Kubernetes separates these out, you have some flexibility in how to set this up. In this article, Joel Speed of Pusher gives an introductory explanation of authentication within Kubernetes and its approach to single sign-on. You’ll learn what authentication methods Kubernetes supports and take a deep dive into OpenID Connect.

Stay tuned for more exciting content from the Kubernetes community next week, and join the KubeWeekly mailing list for the latest updates delivered directly to your inbox.

Is there a piece of content that you think we should highlight? Tweet at us! We’d love to hear what you’re reading, watching, or listening to.

This Week in Kubernetes: March 7th

By | Blog

Each week, the Kubernetes community shares an enormous amount of interesting and informative content including articles, blog posts, tutorials, videos, and much more. We’re highlighting just a few of our favorites from the week before. This week we’re talking machine learning, scalability, service mesh, and contributing to Kubernetes.

First Beta Version of Kubernetes 1.10 is Here – Your Chance to Provide Feedback,

The Kubernetes community has been hard at work on the first beta version on Kubernetes 1.10. The March release is targeting over a dozen new alpha features, and over two dozen mature features including production-ready versions of Kubelet TLS Bootstrapping, API aggregation, and more detailed storage metrics. Nick Chase of Mirantis put together this sneak peek of what’s included in 1.10, and how you can provide your feedback during beta testing.

On Securing the Kubernetes Dashboard, Heptio

Recently, Tesla’s Kubernetes infrastructure was compromised and used by attackers to mine cryptocurrency. Tesla’s Kubernetes dashboard was exposed with to the internet, including visible AWS API keys and secrets. In this post, Joe Beda of Heptio explains how to secure your Kubernetes Dashboard to prevent this from happening including RBAC configurations, per-user credentials, and a full tutorial on screening with oauth2_proxy.  

How to know if Kubernetes is right for your SaaS, freeCodeCamp

Kubernetes is a great tool to scale, deploy, and manage SaaS applications. But it’s important to know if and when Kubernetes is a good fit for your current situation before investing the time and resources. If you’re currently deciding whether or not to adopt Kubernetes, check out this overview by Ben Sears of Walk through what you should know about the benefits of containers, if Kubernetes will solve your current problems, and if it fits into your future plans for your application architecture.

Ensure High Availability and Uptime With Kubernetes Horizontal Pod Autoscaler and Prometheus, Weaveworks

Autoscaling in Kubernetes allows you to automatically scale workloads up or down based on resource usage. In this post, Stefan Prodan of Weaveworks explains how to use Cluster Autoscaling and the Horizontal Pod Autoscaler (HPA) to optimize for availability and uptime, including how to set up Prometheus to expose the right metrics for autoscaling.

Stay tuned for more exciting content from the Kubernetes community next week, and join the KubeWeekly mailing list for the latest updates delivered directly to your inbox.

Is there a piece of content that you think we should highlight? Tweet at us! We’d love to hear what you’re reading, watching, or listening to.