Skip to content

[Docs] Migrate Kubernetes Request Flow tutorial from Meshery Docs#1021

Open
leecalcote wants to merge 2 commits intomasterfrom
claude/migrate-kubernetes-tutorial-1POvc
Open

[Docs] Migrate Kubernetes Request Flow tutorial from Meshery Docs#1021
leecalcote wants to merge 2 commits intomasterfrom
claude/migrate-kubernetes-tutorial-1POvc

Conversation

@leecalcote
Copy link
Copy Markdown
Member

Summary

Migrates the Kubernetes Request Flow – A Visual Guide tutorial from Meshery Docs into Layer5 Docs under the Kanvas tutorials section.

  • New page: content/en/kanvas/tutorials/kubernetes-request-flow.md
  • Diagram asset stored alongside the page at content/en/kanvas/tutorials/images/kubernetes-request-flow/k8s-request-flow.png
  • Aliases preserve the original Meshery Docs URLs (/guides/tutorials/kubernetes-request-flow and /guides/tutorials/kubernetes/kubernetes-request-flow)
  • Terminology updated to use Kanvas naming (Designer Mode / Operator Mode) instead of legacy "Meshery Kanvas → Design / Operate Mode"
  • Notes converted from Markdown blockquotes to Docsy {{< alert >}} shortcodes for visual consistency with other Kanvas tutorials

A companion PR removing the original page from Meshery Docs is filed at meshery/meshery.

Test plan

  • hugo server renders the page at /kanvas/tutorials/kubernetes-request-flow/ without warnings
  • The diagram image loads on the page
  • The two image link wrappers (the prebuilt design link and the diagram screenshot link) both work
  • Aliases redirect old Meshery Docs paths to the new location
  • Page shows up in the Kanvas Tutorials section index

Generated by Claude Code

Add the Kubernetes Request Flow visual tutorial under
content/en/kanvas/tutorials/, with aliases preserving the original
Meshery Docs URLs. Updates terminology to use Kanvas naming
(Designer/Operator modes) and stores the diagram asset alongside
the page.

Signed-off-by: Lee Calcote <leecalcote@gmail.com>
@leecalcote leecalcote force-pushed the claude/migrate-kubernetes-tutorial-1POvc branch from 55b9959 to c115428 Compare May 8, 2026 19:40
Copy link
Copy Markdown
Contributor

@gemini-code-assist gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces a new visual tutorial for understanding Kubernetes request flows using Kanvas. The guide covers key components such as Services, Deployments, and Pods. Feedback was provided to resolve a logical inconsistency in the Service description and to ensure grammatical consistency when listing advanced Kubernetes objects like Ingress Controllers and HPAs.

#### 2. Service (ClusterIP)

- This is the entry point into the cluster.
- It forwards traffic to the Pods. While this visual is a placeholder, in a real Kubernetes Service, we would typically define a type (like ClusterIP or NodePort) and use selectors to route traffic to matching Pods. This is how services know where to forward requests.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

There is a logical inconsistency here. The Lab Scenario (line 28) states that the service is a ClusterIP routing the request, but this line describes the visual as a "placeholder" and suggests that one would "typically define a type (like ClusterIP)" in a real service. Since the scenario already specifies the type and function, it's better to describe how this specific component is configured in the design.

Suggested change
- It forwards traffic to the Pods. While this visual is a placeholder, in a real Kubernetes Service, we would typically define a type (like ClusterIP or NodePort) and use selectors to route traffic to matching Pods. This is how services know where to forward requests.
- In this design, the Service is configured as a **ClusterIP**. In a production setup, you would use selectors to route traffic to matching Pods, which is how the Service knows where to forward requests.

- **Scale smarter** — Once we know where the load hits, we can add replicas where it actually matters.
- **Design better** — From tracing logs to optimizing performance, knowing the flow helps us place the right tools in the right spots.

Think of this request path as the backbone of your Kubernetes understanding. Everything else like Ingress, HPA (Horizontal Pod Autoscalers), or Service Meshes builds upon this foundation.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

The list of components uses a mix of singular and plural forms ("Ingress", "HPA", "Service Meshes"). For consistency, especially since "Service Meshes" is plural, it's better to use plural forms for all or ensure they match the phrasing used later in the conclusion (line 120).

Suggested change
Think of this request path as the backbone of your Kubernetes understanding. Everything else like Ingress, HPA (Horizontal Pod Autoscalers), or Service Meshes builds upon this foundation.
Think of this request path as the backbone of your Kubernetes understanding. Everything else, such as Ingress Controllers, HPAs (Horizontal Pod Autoscalers), or Service Meshes, builds upon this foundation.

@github-actions
Copy link
Copy Markdown

github-actions Bot commented May 8, 2026

🚀 Preview deployment: https://layer5io.github.io/docs/pr-preview/pr-1021/

Note: Preview may take a moment (GitHub Pages deployment in progress). Please wait and refresh. Track deployment here

Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR migrates the “Kubernetes Request Flow – A Visual Guide” tutorial into Layer5 Docs under the Kanvas Tutorials section, preserving legacy Meshery Docs URLs via aliases and updating terminology for Kanvas.

Changes:

  • Adds a new Kanvas tutorial page for Kubernetes request flow.
  • Includes legacy URL aliases to redirect prior Meshery Docs tutorial paths.
  • Uses Docsy alert shortcodes for note styling and links to a prebuilt Kanvas design.


[![Kubernetes Flow Diagram](/kanvas/tutorials/images/kubernetes-request-flow/k8s-request-flow.png)](https://kanvas.new/extension/meshmap?mode=design&design=629b6039-ebb3-4bd8-9b1b-19184fade225)

> Click the image above to open the interactive design in Kanvas.
Comment on lines +60 to +61
- This is the entry point into the cluster.
- It forwards traffic to the Pods. While this visual is a placeholder, in a real Kubernetes Service, we would typically define a type (like ClusterIP or NodePort) and use selectors to route traffic to matching Pods. This is how services know where to forward requests.
- **Scale smarter** — Once we know where the load hits, we can add replicas where it actually matters.
- **Design better** — From tracing logs to optimizing performance, knowing the flow helps us place the right tools in the right spots.

Think of this request path as the backbone of your Kubernetes understanding. Everything else like Ingress, HPA (Horizontal Pod Autoscalers), or Service Meshes builds upon this foundation.
- Clarify ClusterIP access boundary (reachable only from inside the
  cluster; external traffic enters via Ingress/LoadBalancer/NodePort).
- State that the design uses a ClusterIP Service rather than calling
  the visual a placeholder, since the lab scenario already names the
  type.
- Make the advanced-objects list grammatically consistent
  (Ingress Controllers, HPAs (Horizontal Pod Autoscalers),
  Service Meshes).
- Convert the remaining blockquote note under the prebuilt-design
  link into a Docsy alert shortcode for consistency with the rest of
  the page.

Signed-off-by: Lee Calcote <leecalcote@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants