Accelerate migration to K8s

Organizations migrate to Kubernetes because it solves critical scalability, reliability, security, and developer-velocity challenges that modern teams face. At its core, Kubernetes provides a standardized, automated, self-healing platform for running applications.

Accelerating a Kubernetes migration is often a strategic engineering decision made to meet certain business requirements, such as lowering infrastructure costs or improving MTTR, in a shorter timeframe.

To accelerate a migration to Kubernetes:

Launch a Kubernetes Deployment Baseline Scorecard. Cortex provides a prebuilt Kubernetes Scorecard template that you can use to track migration-related controls and standards.
Launch an Initiative associated with the Scorecard, which gives your engineers a deadline for when to complete certain goals.
Use reports and Cortex MCP to better understand progress and next steps.

Cortex customer LetsGetCheck cut their Kubernetes migration timeline from 24 months down to 16 months by targeting goals with Initiatives. Read the full case study here.

Create a Kubernetes Scorecard

Prerequisites

Before using this Scorecard template:

Ensure you have configured integrations for:
- Version control: Azure DevOps, Bitbucket, GitHub, or GitLab.
- Kubernetes

Step 1: Create the Scorecard and configure its basic settings

You can create a Scorecard in the Cortex UI, or you can add it to your workspace via GitOps or the Cortex API.

Create Scorecard in the Cortex UI

On the Scorecards page in your workspace, click Create Scorecard.
On the Kubernetes Deployment Baseline template, click Use.
Configure basic settings, including the Scorecard's name, unique identifier, description, and more.
- Learn about configuring the basic settings in the Creating a Scorecard documentation.

Create Scorecard via GitOps or API

When following a GitOps approach, you can add a Scorecard YAML file to your .cortex/scorecards directory in your version control repository. Note that GitOps must be enabled for Scorecards in your GitOps settings.

You could also use the Cortex API, where you can submit a Scorecard definition in YAML.

Kubernetes Scorecard YAML

Use the YAML file below to add this Scorecard to your workspace via the API or via a GitOps flow.

tag: kubernetes-deployment-baseline
name: Kubernetes Deployment Baseline
description: |-
  This Scorecard enforces a minimum set of standards for services running on Kubernetes. It validates resource requests/limits, probes, container image hygiene, and Git branch protection so that workloads are reliable, predictable, and safe to operate in production.
draft: true
notifications:
  enabled: true
  scoreDropNotificationsEnabled: false
exemptions:
  enabled: true
  autoApprove: false
  userSpecificNotifications: false
ladder:
  name: Default Ladder
  levels:
  - name: Foundational container hygiene
    rank: 1
    description: The service is at least containerized in a basic way.
    color: "#c38b5f"
  - name: Runtime ready
    rank: 2
    description: This container behaves predictably when scheduled on Kubernetes.
    color: "#8c9298"
  - name: Kubernetes production ready
    rank: 3
    description: This service is safe to run in production from a governance and reliability
      perspective.
    color: "#cda400"
rules:
- title: Memory limit is set
  description: "Prevents a single pod from consuming all node memory. To ensure all\
    \ containers have memory limits set, this rule compares the total number of containers\
    \ with the number of containers that have memory limits."
  expression: |-
    jq(k8s.spec(), "[.[].template.spec.containers[]] | length") ==
    jq(k8s.spec(), "[.[].template.spec.containers[] | select(.resources.limits.memory != null)] | length")
  identifier: 17376f1a-bfbe-361b-86d7-eac192f729d9
  weight: 1
  level: Runtime ready
- title: Git branch protection
  description: Prevent direct pushes and unsafe merges to the main branch; enforce
    reviews and status checks.
  expression: git.branchProtection() != null
  identifier: 21c30af3-6dd6-3bce-bbe5-56e43549015f
  weight: 1
  level: Kubernetes production ready
  failureMessage: Configure Git branch protection.
- title: CPU request is set
  description: "This rule checks if CPU resource requests are defined for all containers\
    \ in your Kubernetes deployments, which is important for: \n- Kubernetes scheduler\
    \ to properly place pods on nodes\n- CPU throttling behavior (requests affect\
    \ CPU shares)\n- Cluster capacity planning\n- QoS classification (along with limits\
    \ and memory requests)\n\nTo ensure all containers have CPU resource requests,\
    \ this rule compares the total number of containers with the number of containers\
    \ that have CPU resource requests."
  expression: |-
    jq(k8s.spec(), "[.[].template.spec.containers[]] | length") ==
    jq(k8s.spec(), "[.[].template.spec.containers[] | select(.resources.requests.cpu != null)] | length")
  identifier: 22d76d97-33a5-358a-8694-cf35909acc71
  weight: 1
  level: Runtime ready
- title: Memory request is set
  description: "Prevents a single pod from consuming all node memory. To ensure all\
    \ containers have memory limits set, this rule compares the total number of containers\
    \ with the number of containers that have memory limits."
  expression: "jq(k8s.spec(), \"[.[].template.spec.containers[]] | length\") == \n\
    jq(k8s.spec(), \"[.[].template.spec.containers[] | select(.resources.requests.memory\
    \ != null)] | length\")"
  identifier: 46f4d17e-ceab-37dd-9a64-ddac9ee4aa73
  weight: 1
  level: Runtime ready
- title: Runs in cluster
  description: This indicates operational use of Kubernetes.
  expression: k8s != null
  identifier: 6cfcc6f2-53ea-3da8-afaf-8659177d1896
  weight: 1
  level: Foundational container hygiene
- title: No "latest" tag for base image
  description: |-
    This is a best practice rule that ensures all base images have explicit version tags instead of using `:latest`, which:
    - Prevents unpredictable builds when `:latest` changes
    - Ensures build reproducibility
    - Makes it clear what version is being used
  expression: "git.fileContents(\"Dockerfile\").matchesIn(\"^FROM[ \\t]+(?!.*:latest\\\
    b).*$\")"
  identifier: 873c36b3-5a18-3a09-9c58-bff967ffd6bd
  weight: 1
  level: Kubernetes production ready
- title: Liveness probe is set
  description: |-
    This ensures your services have liveness probes configured, which are critical for:

    - Detecting when a container is stuck or deadlocked
    - Automatically restarting unhealthy containers
    - Improving service reliability and reducing MTTR
    - Preventing containers that are "running" but not actually functioning

    To ensure all containers have liveness probes, this rule compares the total number of containers with the number of containers that have liveness probes.
  expression: |-
    jq(k8s.spec(), "[.[].template.spec.containers[]] | length") ==
    jq(k8s.spec(), "[.[].template.spec.containers[] | select(.livenessProbe != null)] | length")
  identifier: b1f477fc-2ec5-39b0-9d48-b9a2922d7623
  weight: 1
  level: Runtime ready
- title: Readiness probe is set
  description: |-
    Ensures the service defines a Kubernetes readiness probe so that traffic is only routed to containers that are fully initialized and able to serve requests. A readiness probe prevents the service mesh or load balancer from sending user traffic to a pod that is still starting up, misconfigured, or temporarily degraded. This improves request success rates, reduces startup-induced errors, and helps maintain overall service reliability.

    To ensure all containers have readiness probes, this rule compares the total number of containers with the number of containers that have readiness probes.
  expression: "jq(k8s.spec(), \"[.[].template.spec.containers[]] | length\") == jq(k8s.spec(),\
    \ \"[.[].template.spec.containers[] | select(.readinessProbe != null)] | length\"\
    )"
  identifier: b4bed489-db7d-3566-826a-c78f6da22190
  weight: 1
  level: Runtime ready
  failureMessage: "This service does not have a Kubernetes readiness probe configured.\
    \ Without a readiness probe, the load balancer may send traffic to pods before\
    \ they are ready, leading to failed requests and degraded reliability. Add a readiness\
    \ probe to ensure only healthy, ready pods receive traffic."
- title: Dockerignore file exists
  description: Keep images lean and builds fast by excluding unnecessary files.
  expression: git.fileExists(".dockerignore")
  identifier: deb30726-2692-3a2d-8858-a828d33fea17
  weight: 1
  level: Foundational container hygiene
- title: Dockerfile exists
  description: Verify the service is containerized using a maintained Dockerfile.
    This enables consistency across different environments.
  expression: git.fileExists("Dockerfile")
  identifier: df928975-90e7-35ab-a05c-67ca7cb034a2
  weight: 1
  level: Foundational container hygiene
filter:
  kind: GENERIC
  types:
    include:
    - service

Step 2: Review and modify rules

Cortex's templated rules are based on common industry standards. See the template in-app for more context on each rule:

Level 1: Foundational container hygiene

Runs in cluster k8s != null
Dockerignore file exists git.fileExists(".dockerignore")
Dockerfile exists git.fileExists("Dockerfile")

Level 2: Runtime ready

Memory request is set jq(k8s.spec(), "[.[].template.spec.containers[]] | length") == jq(k8s.spec(), "[.[].template.spec.containers[] | select(.resources.requests.memory != null)] | length")
Memory limit is set jq(k8s.spec(), "[.[].template.spec.containers[]] | length") == jq(k8s.spec(), "[.[].template.spec.containers[] | select(.resources.limits.memory != null)] | length")
Liveness probe is set jq(k8s.spec(), "[.[].template.spec.containers[]] | length") == jq(k8s.spec(), "[.[].template.spec.containers[] | select(.livenessProbe != null)] | length")
Readiness probe is set jq(k8s.spec(), "[.[].template.spec.containers[]] | length") == jq(k8s.spec(), "[.[].template.spec.containers[] | select(.readinessProbe != null)] | length")
CPU request is set jq(k8s.spec(), "[.[].template.spec.containers[]] | length") == jq(k8s.spec(), "[.[].template.spec.containers[] | select(.resources.requests.cpu != null)] | length")

Level 3: Kubernetes production ready

Git branch protection git.branchProtection() != null
No "latest" tag for base image git.fileContents("Dockerfile").matchesIn("^FROM[ \t]+(?!.*:latest\b).$")

You can reorder, delete, and edit rules, add more rules to a level, and assign more points to a rule to signify its importance. Behind each rule is a Cortex Query Language (CQL) query; you can edit the existing CQL or write your own queries to further refine your rules.

Create a K8s acceleration Initiative

If you notice the team isn't making progress as quickly as expected, or you need to complete certain rules within a specific timeframe, you can create an Initiative to motivate completion.

Follow the steps below to create an Initiative:

Create a Kubernetes Initiative

While viewing your Kubernetes Deployment Baseline Scorecard, click Create Initiative in the upper right.
Configure the Initiative fields, including a descriptive name so your team members understand the purpose of the Initiative. For example, Accelerate K8s migration.
- Make sure to enable notifications so users are notified if an entity they own is failing the Initiative's goal.
- For the goal, you might want to ask your team to complete a certain level, or specific rules. Examples: Complete all "Runtime ready" level rules by the end of the quarter or Make sure a Dockerfile exists for every service by end of month.
Save the Initiative.

After the Initiative is published, entity owners will be notified if their entity is not meeting the goal. They will see action items listed on their engineering homepage and they will automatically receive a weekly progress update from the Initiative.

Learn more about creating Initiatives in the docs.

Measuring success

To understand progress of your Scorecard:

Ask Cortex MCP, "How is my Kubernetes Deployment Baseline Scorecard doing?" The MCP will respond with information on the entities that are failing rules and suggested next steps.
Review reports: The Bird's Eye report gives insight into how entities are performing against the Scorecard by visualizing the data as a heat map:

You can also review your Engineering Intelligence metrics for impact on key engineering metrics, such as:

MTTR: Kubernetes best practices, such as liveness probes in place, can result in faster diagnosis and auto-recovery. You may see MTTR decrease.
Change failure rate: With resource limits reducing pod crashes and no "latest" image tag resulting in deterministic builds, you may see more successful deploys on first attempt, thus decreasing change failure rate.

Last updated 4 days ago

Was this helpful?