{"id":164937,"date":"2026-03-28T21:46:49","date_gmt":"2026-03-28T18:46:49","guid":{"rendered":"https:\/\/computingforgeeks.com\/?p=164937"},"modified":"2026-03-28T21:46:50","modified_gmt":"2026-03-28T18:46:50","slug":"claude-code-kubernetes-guide","status":"publish","type":"post","link":"https:\/\/computingforgeeks.com\/claude-code-kubernetes-guide\/","title":{"rendered":"Deploy and Debug Kubernetes Apps with Claude Code"},"content":{"rendered":"\n<p>Kubernetes YAML is the most common thing engineers ask AI to generate. The manifests are verbose, the schema is strict, and getting resource limits, probes, and selectors right on the first try is rare. Claude Code handles this well because Kubernetes objects follow predictable patterns. It also diagnoses failing deployments by reading <code>kubectl describe<\/code> output and pod logs, which is where most debugging time goes.<\/p>\n\n\n\n<p>This guide is part of the <a href=\"https:\/\/computingforgeeks.com\/claude-code-devops-engineers\/\" target=\"_blank\" rel=\"noreferrer noopener\">Claude Code for DevOps Engineers<\/a> series. Every demo ran on a real Kubernetes 1.35.0 cluster (kind on Docker Desktop). The pod names, events, error messages, and Helm history are from actual execution. For kubectl reference, the <a href=\"https:\/\/computingforgeeks.com\/kubectl-cheat-sheet-kubernetes\/\" target=\"_blank\" rel=\"noreferrer noopener\">kubectl cheat sheet<\/a> covers the commands used throughout this guide.<\/p>\n\n\n\n<p><em>Verified working: <strong>March 2026<\/strong> on Kubernetes 1.35.0 (kind), Helm 3.19.1, Nginx 1.27-alpine<\/em><\/p>\n\n\n\n<h2 class=\"wp-block-heading\">What You Need<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/code.claude.com\/docs\/en\/overview\" target=\"_blank\" rel=\"noreferrer noopener\">Claude Code<\/a> installed and authenticated<\/li>\n\n<li>A Kubernetes cluster (kind, minikube, Docker Desktop, or a cloud cluster)<\/li>\n\n<li>kubectl 1.28+ and Helm 3.12+ installed<\/li>\n\n<li>Use a non-production cluster for these demos (they create and delete deployments)<\/li>\n<\/ul>\n\n\n\n<p>To spin up a disposable cluster with kind:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>kind create cluster --name demo<\/code><\/pre>\n\n\n\n<p>This creates a single-node Kubernetes cluster inside Docker in about 30 seconds.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Deploy a Full Application Stack<\/h2>\n\n\n\n<p>The first demo generates a complete application deployment: namespace, ConfigMap, Deployment with probes and resource limits, Service, and NetworkPolicy. One prompt produces production-grade manifests.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Generate Kubernetes manifests for a web application:\n- Namespace called \"demo\"\n- ConfigMap with a custom HTML index page\n- Deployment with 3 replicas of nginx:1.27-alpine\n- Resource requests (50m CPU, 64Mi memory) and limits (200m, 128Mi)\n- Liveness and readiness probes on port 80\n- ClusterIP Service on port 80\n- NetworkPolicy allowing only port 80 ingress\nValidate with --dry-run=client, then apply.<\/code><\/pre>\n\n\n\n<p>Claude Code generates five resources in a single YAML file. The dry run confirms they&#8217;re valid:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>kubectl apply -f app.yaml --dry-run=client<\/code><\/pre>\n\n\n\n<p>All five resources pass validation:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>namespace\/demo configured (dry run)\nconfigmap\/nginx-config created (dry run)\ndeployment.apps\/web created (dry run)\nservice\/web created (dry run)\nnetworkpolicy.networking.k8s.io\/web-allow-http created (dry run)<\/code><\/pre>\n\n\n\n<p>After applying, all three replicas come up and pass their readiness probes:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>kubectl get pods -n demo<\/code><\/pre>\n\n\n\n<p>Three pods running:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>NAME                   READY   STATUS    RESTARTS   AGE\nweb-55dd865988-6m47w   1\/1     Running   0          38s\nweb-55dd865988-8r24q   1\/1     Running   0          38s\nweb-55dd865988-ns7f7   1\/1     Running   0          38s<\/code><\/pre>\n\n\n\n<p>Port-forwarding to the service confirms the custom HTML is served:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>kubectl port-forward -n demo svc\/web 8888:80 &\ncurl -s http:\/\/localhost:8888\/<\/code><\/pre>\n\n\n\n<p>The response shows our ConfigMap-mounted HTML:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>&lt;html&gt;\n&lt;head&gt;&lt;title&gt;Claude Code K8s Demo&lt;\/title&gt;&lt;\/head&gt;\n&lt;body&gt;\n&lt;h1&gt;Deployed by Claude Code on Kubernetes&lt;\/h1&gt;\n&lt;p&gt;Cluster: kind-claude-demo&lt;\/p&gt;\n&lt;p&gt;Namespace: demo&lt;\/p&gt;\n&lt;\/body&gt;\n&lt;\/html&gt;<\/code><\/pre>\n\n\n\n<p>Notice what Claude Code included by default: resource requests AND limits (most hand-written manifests skip requests), both probe types with sensible timing, a dedicated namespace (not default), and a NetworkPolicy restricting ingress to port 80. These are production best practices that most engineers add after the first incident, not during initial deployment.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Debug a Failing Deployment<\/h2>\n\n\n\n<p>Two real failure scenarios that account for most Kubernetes debugging time. Both were captured from an actual cluster.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">ImagePullBackOff: Wrong image tag<\/h3>\n\n\n\n<p>A deployment references <code>nginx:99.99-nonexistent<\/code>. The pod gets stuck:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>kubectl get pods -n demo -l app=broken-app<\/code><\/pre>\n\n\n\n<p>The status says it all:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>NAME                          READY   STATUS             RESTARTS   AGE\nbroken-app-7cbf6548f8-sf76x   0\/1     ImagePullBackOff   0          15s<\/code><\/pre>\n\n\n\n<p>Tell Claude Code &#8220;my pod is stuck in ImagePullBackOff&#8221; and it runs <code>kubectl describe pod<\/code> to read the events:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Events:\n  Warning  Failed   13s  kubelet  Failed to pull image \"nginx:99.99-nonexistent\":\n    rpc error: code = NotFound desc = failed to pull and unpack image\n    \"docker.io\/library\/nginx:99.99-nonexistent\": not found\n  Warning  Failed   13s  kubelet  Error: ErrImagePull\n  Normal   BackOff  13s  kubelet  Back-off pulling image \"nginx:99.99-nonexistent\"\n  Warning  Failed   13s  kubelet  Error: ImagePullBackOff<\/code><\/pre>\n\n\n\n<p>The error is unambiguous: the image tag doesn&#8217;t exist on Docker Hub. Claude Code fixes the tag to a valid version (<code>nginx:1.27-alpine<\/code>), patches the deployment, and waits for the rollout to complete. The entire diagnosis takes under 10 seconds because the events contain the full error path.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">CrashLoopBackOff: Container exits on startup<\/h3>\n\n\n\n<p>A container starts, prints an error, and exits. Kubernetes restarts it, it crashes again, and the back-off timer increases. The pod cycles between Error and CrashLoopBackOff.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>NAME                         READY   STATUS   RESTARTS      AGE\ncrash-app-6d99cd5cf8-tkkfl   0\/1     Error    4 (66s ago)   105s<\/code><\/pre>\n\n\n\n<p>Claude Code reads the pod logs to find the actual error:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>kubectl logs crash-app-6d99cd5cf8-tkkfl -n demo<\/code><\/pre>\n\n\n\n<p>The log reveals the root cause:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Missing config: \/etc\/app\/config.yml not found<\/code><\/pre>\n\n\n\n<p>The events confirm the crash loop pattern:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Events:\n  Normal   Pulled   56s (x5 over 2m32s)  kubelet  Container image already present\n  Normal   Created  56s (x5 over 2m32s)  kubelet  Container created\n  Normal   Started  56s (x5 over 2m32s)  kubelet  Container started\n  Warning  BackOff  56s (x4 over 2m30s)  kubelet  Back-off restarting failed container<\/code><\/pre>\n\n\n\n<p>Five creates, five starts, four back-offs. The container starts successfully but immediately exits because it can&#8217;t find its config file. Claude Code fixes this by creating a ConfigMap with the expected config and mounting it at <code>\/etc\/app\/config.yml<\/code>. The deployment rolls out with the volume mount, and the crash loop stops.<\/p>\n\n\n\n<p>The debugging pattern is always the same: <code>kubectl get pods<\/code> (see the status), <code>kubectl describe pod<\/code> (read events), <code>kubectl logs<\/code> (find the application error). Claude Code runs all three in sequence without being told.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Generate and Manage Helm Charts<\/h2>\n\n\n\n<p>Raw manifests work for one-off deployments. Helm charts work for repeatable deployments across environments. Claude Code converts raw manifests to Helm charts and manages the release lifecycle.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Convert the web deployment manifests into a Helm chart with\nconfigurable replicas, image tag, and resource limits.\nInstall it, then upgrade to 4 replicas.<\/code><\/pre>\n\n\n\n<p>Claude Code creates the chart structure with <code>Chart.yaml<\/code>, <code>values.yaml<\/code>, and templated manifests under <code>templates\/<\/code>. The values file exposes the parameters you&#8217;ll change between environments:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>replicaCount: 2\nimage:\n  repository: nginx\n  tag: \"1.27-alpine\"\nservice:\n  type: ClusterIP\n  port: 80\nresources:\n  requests:\n    cpu: 50m\n    memory: 64Mi\n  limits:\n    cpu: 200m\n    memory: 128Mi<\/code><\/pre>\n\n\n\n<p>Installing the chart:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>helm install my-web .\/web-chart -n demo<\/code><\/pre>\n\n\n\n<p>Helm confirms the deployment:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>NAME: my-web\nLAST DEPLOYED: Sat Mar 28 10:39:03 2026\nNAMESPACE: demo\nSTATUS: deployed\nREVISION: 1<\/code><\/pre>\n\n\n\n<p>Upgrading to 4 replicas with a single flag:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>helm upgrade my-web .\/web-chart -n demo --set replicaCount=4<\/code><\/pre>\n\n\n\n<p>Four pods now running:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>NAME                      READY   STATUS    RESTARTS   AGE\nmy-web-64ddbdb848-8bjj2   1\/1     Running   0          8s\nmy-web-64ddbdb848-gwxmm   1\/1     Running   0          15s\nmy-web-64ddbdb848-pzs67   1\/1     Running   0          8s\nmy-web-64ddbdb848-qn8vs   1\/1     Running   0          15s<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Rollback a bad Helm upgrade<\/h3>\n\n\n\n<p>Push a broken image tag through Helm and the new pods fail with ErrImagePull while the old ones keep running (Kubernetes&#8217; rolling update protects you). Claude Code detects the failure and rolls back:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>helm upgrade my-web .\/web-chart -n demo --set image.tag=99.99-broken<\/code><\/pre>\n\n\n\n<p>The new pod fails while old pods continue serving:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>NAME                      READY   STATUS         RESTARTS   AGE\nmy-web-574474d994-8mpdd   0\/1     ErrImagePull   0          11s\nmy-web-64ddbdb848-8bjj2   1\/1     Running        0          29s\nmy-web-64ddbdb848-pzs67   1\/1     Running        0          29s<\/code><\/pre>\n\n\n\n<p>Claude Code identifies the ErrImagePull and rolls back to the last working revision:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>helm rollback my-web 2 -n demo<\/code><\/pre>\n\n\n\n<p>Rollback confirmed:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Rollback was a success! Happy Helming!<\/code><\/pre>\n\n\n\n<p>The Helm history shows the full lifecycle:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>REVISION  UPDATED                  STATUS      CHART          DESCRIPTION\n1         Sat Mar 28 10:39:03 2026 superseded  web-app-0.1.0  Install complete\n2         Sat Mar 28 10:39:11 2026 superseded  web-app-0.1.0  Upgrade complete\n3         Sat Mar 28 10:39:29 2026 superseded  web-app-0.1.0  Upgrade complete\n4         Sat Mar 28 10:39:40 2026 deployed    web-app-0.1.0  Rollback to 2<\/code><\/pre>\n\n\n\n<p>Four revisions: initial install, scale to 4 replicas, broken upgrade, rollback to revision 2. Every state is tracked and reversible. This is why Helm matters for production: <code>kubectl apply<\/code> has no built-in rollback.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Kubernetes Debugging Cheat Sheet<\/h2>\n\n\n\n<p>After debugging dozens of deployments through Claude Code, these are the status patterns and what they mean:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><thead><tr><th>Status<\/th><th>Meaning<\/th><th>First Command to Run<\/th><\/tr><\/thead><tbody><tr><td>ImagePullBackOff<\/td><td>Image tag doesn&#8217;t exist or registry auth failed<\/td><td><code>kubectl describe pod<\/code> (check Events)<\/td><\/tr><tr><td>CrashLoopBackOff<\/td><td>Container starts then crashes repeatedly<\/td><td><code>kubectl logs POD<\/code> (find the app error)<\/td><\/tr><tr><td>Pending<\/td><td>No node can schedule the pod (resource limits, taints, affinity)<\/td><td><code>kubectl describe pod<\/code> (check Conditions)<\/td><\/tr><tr><td>ContainerCreating<\/td><td>Image pulling or volume mounting (stuck = check events)<\/td><td><code>kubectl describe pod<\/code> (check Events)<\/td><\/tr><tr><td>OOMKilled<\/td><td>Container exceeded memory limit<\/td><td>Increase <code>resources.limits.memory<\/code><\/td><\/tr><tr><td>Evicted<\/td><td>Node ran out of disk or memory<\/td><td><code>kubectl describe node<\/code> (check Conditions)<\/td><\/tr><tr><td>CreateContainerError<\/td><td>Missing ConfigMap, Secret, or volume mount<\/td><td><code>kubectl describe pod<\/code> (check Events)<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p>Claude Code follows this same decision tree. When you say &#8220;my pod is failing,&#8221; it checks the status first, then runs the appropriate describe or logs command based on what it finds.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">What Claude Code Gets Right (and Wrong) with Kubernetes<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><thead><tr><th>Task<\/th><th>Quality<\/th><th>Notes<\/th><\/tr><\/thead><tbody><tr><td>Deployments + Services<\/td><td>Excellent<\/td><td>Correct selectors, labels, resource specs every time<\/td><\/tr><tr><td>Probes<\/td><td>Excellent<\/td><td>Adds both liveness and readiness with sensible timing<\/td><\/tr><tr><td>Resource limits<\/td><td>Excellent<\/td><td>Includes both requests and limits (rare in hand-written manifests)<\/td><\/tr><tr><td>ConfigMaps and Secrets<\/td><td>Good<\/td><td>Correct mounting, sometimes forgets <code>readOnly: true<\/code><\/td><\/tr><tr><td>Helm chart generation<\/td><td>Good<\/td><td>Proper templating, sensible values.yaml defaults<\/td><\/tr><tr><td>Debugging (describe + logs)<\/td><td>Excellent<\/td><td>Follows the right diagnostic sequence every time<\/td><\/tr><tr><td>NetworkPolicies<\/td><td>Fair<\/td><td>Gets basic ingress rules right, complex egress needs review<\/td><\/tr><tr><td>RBAC<\/td><td>Fair<\/td><td>Generates overly permissive roles, always tighten manually<\/td><\/tr><tr><td>Ingress with TLS<\/td><td>Good<\/td><td>Knows cert-manager annotations, sometimes outdated API versions<\/td><\/tr><tr><td>StatefulSets<\/td><td>Good<\/td><td>Correct volumeClaimTemplates, sometimes misses headless service<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">Practical Kubernetes Prompts<\/h2>\n\n\n\n<p><strong>Specify the namespace.<\/strong> Claude Code uses <code>default<\/code> if you don&#8217;t specify. Always include &#8220;in namespace X&#8221; to keep demo resources isolated from production workloads.<\/p>\n\n\n\n<p><strong>Ask for both probes and resource limits upfront.<\/strong> &#8220;Deploy nginx with liveness probe, readiness probe, resource requests and limits&#8221; produces a complete manifest. Without this, Claude Code sometimes generates minimal manifests that pass validation but lack production essentials.<\/p>\n\n\n\n<p><strong>For debugging, paste the pod name and namespace.<\/strong> &#8220;Pod web-55dd865988-6m47w in namespace demo is in CrashLoopBackOff&#8221; gives Claude Code everything it needs to run <code>kubectl describe<\/code> and <code>kubectl logs<\/code> with the correct arguments. Just saying &#8220;my pod is crashing&#8221; forces it to list pods first.<\/p>\n\n\n\n<p><strong>Use Helm for anything you&#8217;ll deploy more than once.<\/strong> Ask Claude Code to &#8220;convert these manifests to a Helm chart&#8221; and it creates the chart structure with parameterized values. Helm gives you rollback, revision history, and environment-specific overrides that raw <code>kubectl apply<\/code> lacks.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Part of the Claude Code for DevOps Series<\/h2>\n\n\n\n<p>This Kubernetes spoke connects to the broader series. The <a href=\"https:\/\/computingforgeeks.com\/claude-code-docker-guide\/\" target=\"_blank\" rel=\"noreferrer noopener\">Docker guide<\/a> covers building the container images that Kubernetes deploys. The <a href=\"https:\/\/computingforgeeks.com\/claude-code-terraform-guide\/\" target=\"_blank\" rel=\"noreferrer noopener\">Terraform guide<\/a> covers provisioning the clusters themselves. For deploying a full cluster from scratch, the <a href=\"https:\/\/computingforgeeks.com\/deploy-kubernetes-rancher\/\" target=\"_blank\" rel=\"noreferrer noopener\">Kubernetes cluster deployment with Rancher<\/a> guide covers that.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/computingforgeeks.com\/claude-code-devops-engineers\/\" target=\"_blank\" rel=\"noreferrer noopener\">Set Up Claude Code for DevOps Engineers<\/a> (pillar with safety rules and permissions)<\/li>\n\n<li><a href=\"https:\/\/computingforgeeks.com\/claude-code-ssh-server-management\/\" target=\"_blank\" rel=\"noreferrer noopener\">Manage Servers with Claude Code via SSH<\/a><\/li>\n\n<li><a href=\"https:\/\/computingforgeeks.com\/claude-code-docker-guide\/\" target=\"_blank\" rel=\"noreferrer noopener\">Build and Debug Docker Containers with Claude Code<\/a><\/li>\n\n<li><a href=\"https:\/\/computingforgeeks.com\/claude-code-terraform-guide\/\" target=\"_blank\" rel=\"noreferrer noopener\">Deploy Infrastructure with Claude Code and Terraform<\/a><\/li>\n\n<li><a href=\"https:\/\/computingforgeeks.com\/claude-code-ansible-guide\/\" target=\"_blank\" rel=\"noreferrer noopener\">Generate and Debug Ansible Playbooks with Claude Code<\/a><\/li>\n\n<li><a href=\"https:\/\/computingforgeeks.com\/claude-code-github-actions-infrastructure\/\" target=\"_blank\" rel=\"noreferrer noopener\"><strong>Claude Code + GitHub Actions<\/strong><\/a>: automated PR review, infrastructure validation<\/li>\n<\/ul>\n\n\n\n<p>The <a href=\"https:\/\/computingforgeeks.com\/claude-code-cheat-sheet\/\" target=\"_blank\" rel=\"noreferrer noopener\">Claude Code cheat sheet<\/a> covers every command and shortcut for quick reference.<\/p>\n\n","protected":false},"excerpt":{"rendered":"<p>Kubernetes YAML is the most common thing engineers ask AI to generate. The manifests are verbose, the schema is strict, and getting resource limits, probes, and selectors right on the first try is rare. Claude Code handles this well because Kubernetes objects follow predictable patterns. It also diagnoses failing deployments by reading kubectl describe output &#8230; <a title=\"Deploy and Debug Kubernetes Apps with Claude Code\" class=\"read-more\" href=\"https:\/\/computingforgeeks.com\/claude-code-kubernetes-guide\/\" aria-label=\"Read more about Deploy and Debug Kubernetes Apps with Claude Code\">Read more<\/a><\/p>\n","protected":false},"author":3,"featured_media":164938,"comment_status":"open","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[39034,690,299,317],"tags":[],"class_list":["post-164937","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ai","category-dev","category-how-to","category-kubernetes"],"_links":{"self":[{"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/posts\/164937","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/comments?post=164937"}],"version-history":[{"count":1,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/posts\/164937\/revisions"}],"predecessor-version":[{"id":164983,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/posts\/164937\/revisions\/164983"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/media\/164938"}],"wp:attachment":[{"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/media?parent=164937"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/categories?post=164937"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/tags?post=164937"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}