Master
ThoughtWorks
Menu
Close
  • What we do
    • Go to overview
    • Customer Experience, Product and Design
    • Data Strategy, Engineering and Analytics
    • Digital Transformation and Operations
    • Enterprise Modernization, Platforms and Cloud
  • Who we work with
    • Go to overview
    • Automotive
    • Healthcare
    • Public Sector
    • Cleantech, Energy and Utilities
    • Media and Publishing
    • Retail and E-commerce
    • Financial Services and Insurance
    • Not-for-profit
    • Travel and Transport
  • Insights
    • Go to overview
    • Featured

      • Technology

        An in-depth exploration of enterprise technology and engineering excellence

      • Business

        Keep up to date with the latest business and industry insights for digital leaders

      • Culture

        The place for career-building content and tips, and our view on social justice and inclusivity

    • Digital Publications and Tools

      • Technology Radar

        An opinionated guide to technology frontiers

      • Perspectives

        A publication for digital leaders

      • Digital Fluency Model

        A model for prioritizing the digital capabilities needed to navigate uncertainty

      • Decoder

        The business execs' A-Z guide to technology

    • All Insights

      • Articles

        Expert insights to help your business grow

      • Blogs

        Personal perspectives from ThoughtWorkers around the globe

      • Books

        Explore our extensive library

      • Podcasts

        Captivating conversations on the latest in business and tech

  • Careers
    • Go to overview
    • Application process

      What to expect as you interview with us

    • Grads and career changers

      Start your tech career on the right foot

    • Search jobs

      Find open positions in your region

    • Stay connected

      Sign up for our monthly newsletter

  • About
    • Go to overview
    • Our Purpose
    • Awards & Recognition
    • Diversity & Inclusion
    • Our Leaders
    • Partnerships
    • News
    • Conferences & Events
  • Contact
Global | English
  • United States United States
    English
  • China China
    中文 | English
  • India India
    English
  • Canada Canada
    English
  • Singapore Singapore
    English
  • United Kingdom United Kingdom
    English
  • Australia Australia
    English
  • Germany Germany
    English | Deutsch
  • Brazil Brazil
    English | Português
  • Spain Spain
    English | Español
  • Global Global
    English
Blogs
Select a topic
View all topicsClose
Technology 
Agile Project Management Cloud Continuous Delivery  Data Science & Engineering Defending the Free Internet Evolutionary Architecture Experience Design IoT Languages, Tools & Frameworks Legacy Modernization Machine Learning & Artificial Intelligence Microservices Platforms Security Software Testing Technology Strategy 
Business 
Financial Services Global Health Innovation Retail  Transformation 
Careers 
Career Hacks Diversity & Inclusion Social Change 
Blogs

Topics

Choose a topic
  • Technology
    Technology
  • Technology Overview
  • Agile Project Management
  • Cloud
  • Continuous Delivery
  • Data Science & Engineering
  • Defending the Free Internet
  • Evolutionary Architecture
  • Experience Design
  • IoT
  • Languages, Tools & Frameworks
  • Legacy Modernization
  • Machine Learning & Artificial Intelligence
  • Microservices
  • Platforms
  • Security
  • Software Testing
  • Technology Strategy
  • Business
    Business
  • Business Overview
  • Financial Services
  • Global Health
  • Innovation
  • Retail
  • Transformation
  • Careers
    Careers
  • Careers Overview
  • Career Hacks
  • Diversity & Inclusion
  • Social Change
Evolutionary ArchitectureTechnology StrategyLanguages, Tools & FrameworksTechnology

The shift in mindset needed for Kubernetes adoption (Part 2)

Archana Chillala Archana Chillala
Krishnaswamy Subramanian Krishnaswamy Subramanian
Sunit Parekh Sunit Parekh

Published: Mar 8, 2021

In part 1 of the article, we discussed how organizations could employ the 4C framework to better adopt Kubernetes, the new age infrastructure . Now let’s look at the shift in mindset that's needed from the development team’s perspective.

Development team mindshift - 12 factor app, infrastructure as code, unlearn to relearn

The development team’s lens

Twelve-Factor App

The development team usually faces challenges when running applications on Kubernetes. Our advice is to follow the Twelve-Factor App principles usually leveraged when building cloud native applications


On-logs aspect
Let's consider the scenario where an application is logging into the file system rather than an i/o and error stream. If we packaged this application without any modification and ran it as a container workload in Kubernetes, the container could be terminated when the disk pressure is too high on the node. Instead, each running process writes its event stream, unbuffered, to Standard Output (Stdout), collected and sent to the central logging system.

Disposability aspect
While containerizing the application it’s important to consider fast startup time and graceful shutdowns. In Kubernetes, starting an application doesn’t mean it’s ready for traffic. For e.g. applications should start respecting the SIGHUP signal to close out existing requests, thus avoiding errors.

We’d suggest developers begin with some unlearning of conventional practices and methods for application deployment to VM, and adopt the twelve-factor methodology to create cloud native applications to make the smooth transition to Kubernetes.


The Infrastructure as Code paradigm

Developers should embrace an automated and sustainable way of building and maintaining infrastructure by following software development engineering practices. They should treat all infrastructure (Kubernetes or K8s) setup as code – scripts, configurations and check-in to version control. 

Also, all infrastructure code should have idempotency in execution. To learn more about the paradigm, we recommend reading ThoughtWorks’ Cloud Practice Lead, Kief Morris’s book, ‘Infrastructure as Code’.


Anti-patterns to avoid 

Anti-patterns are the best way to learn from industry experiences. Here’s a quick list of those we’ve observed, of which many are specific to the mindshift needed from the world of VM to Pods in K8s.

Missing healthcheck probes
Not using readiness, liveness and startup probes for effective health checks can lead to unexpected error-rates in servicing requests. This usually happens when K8s forwards requests to Pods that are not ready to take those requests. For instance with Java Virtual Machine (JVM) based applications, if a request is sent to the process before the significant warm up is completed, it results in an error. 

Unbounded resource limits
Deploying Pods without resource limits (like memory and CPU) can affect other applications in the same cluster, sometimes even bringing down nodes. This is also called the ‘noisy neighbour problem’ in the K8s world. To avoid it, we suggest defining quotas for resource management at the Pod level and the namespace level with defaults.

Environment specific docker images
Building different docker images for different environments, rather than effectively leveraging ConfigMaps and Secrets leads to untested images (code) reaching production - resulting in production downtime. 

One kubeconfig for all
Using a single admin configuration for all team members is a huge security risk. We recommend using service accounts and role-based access for a K8s environment.

Abusing the sidecar
VM world rookies, more often than not misuse the sidecar. It’s very common in VM to have multiple applications running on the same application servers and sometimes even databases. While Kubernetes technically allows one to run multiple containers in a single Pod, it’s not recommended. Mainly because it violates the single responsibility principle of Pods. Only when the application is tightly coupled with the other container and demands it, is this alright. This anti-pattern stems from the assumption of Pods being similar to a VM. 

Single cluster for all environments
Mixing both production and non-production workloads in the same cluster gives rise to issues like the misuse of namespaces to create a logical division when managing environments on a single cluster. In such a setup, when the cluster goes down, it affects all ‘environments’ and we lose the ability to perform experiments in lower environments. 

Not using package manager
Leveraging self-managing K8s YAMLs initially and only for a few resources might sound alright, however it becomes cumbersome as complexity increases. Instead use tools like Helm, as it’s not only a package management tool for K8s, but also possesses features that allows one to carry out complete release management using Helm CLI.

In summary, here’s a quick overview of the mindshift required to better equip organizations and teams as they adopt a Kubernetes ecosystem: 

a table that summarizes the shift from Traditional ‘don’t experiment’ culture to ‘Fail-fast’ experimental culture and similar shifts
 

Technology Hub

An in-depth exploration of enterprise technology and engineering excellence.

Explore
Related blogs
Cloud

Kubernetes: an exciting future for developers and infrastructure engineering

Inny So
James Gregory
Learn more
Cloud

Infrastructure as Code: From the Iron Age to the Cloud Age

Kief Morris
Learn more
Evolutionary Architecture

The mindset shift needed for Kubernetes adoption (Part 1)

Archana Chillala
Krishnaswamy Subramanian
Sunit Parekh
Learn more
Master
Privacy policy | Modern Slavery statement | Accessibility
Connect with us
×

WeChat

QR code to ThoughtWorks China WeChat subscription account
© 2021 ThoughtWorks, Inc.