<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Kubernetes on Layer5 Documentation</title><link>/tags/kubernetes/</link><description>Recent content in Kubernetes on Layer5 Documentation</description><generator>Hugo</generator><language>en</language><atom:link href="/tags/kubernetes/index.xml" rel="self" type="application/rss+xml"/><item><title>Explore Pods</title><link>/kanvas/tutorials/kubernetes/kubernetes-pods/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/kanvas/tutorials/kubernetes/kubernetes-pods/</guid><description>&lt;p&gt;In this tutorial you build a single NGINX Pod in Kanvas, deploy it to a live cluster, expose it with a NodePort Service, and inspect the running Pod in Operator: its details, a shell inside its container, and its log stream. A Pod is the smallest unit Kubernetes schedules, and every workload controller you meet later (Deployments, StatefulSets, CronJobs) exists to create and replace Pods. Working with a bare Pod first shows you exactly what those controllers automate.&lt;/p&gt;</description></item><item><title>Explore Deployments</title><link>/kanvas/tutorials/kubernetes/kubernetes-deployments/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/kanvas/tutorials/kubernetes/kubernetes-deployments/</guid><description>&lt;p&gt;In this tutorial you build an NGINX Deployment with two replicas, deploy it, scale it to three, and roll it to a new image version, inspecting the result in Operator after each change. A Deployment is the controller most stateless applications run under: you declare how many Pods you want and what they look like, and Kubernetes keeps that many running and replaces them gradually when the template changes. Seeing the ReplicaSets and Pods appear and change shows you what the controller does on your behalf.&lt;/p&gt;</description></item><item><title>Explore Services</title><link>/kanvas/tutorials/kubernetes/kubernetes-services/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/kanvas/tutorials/kubernetes/kubernetes-services/</guid><description>&lt;p&gt;In this tutorial you put three Services in front of running workloads: a ClusterIP Service in front of a Deployment, a NodePort Service in front of one Pod, and a LoadBalancer Service in front of another. Pods come and go and change IP addresses every time they are replaced. A Service gives a changing set of Pods one stable address and finds them by label, and its type decides who can reach that address. Building all three side by side makes the difference between the types concrete.&lt;/p&gt;</description></item><item><title>Use ConfigMaps and Secrets</title><link>/kanvas/tutorials/kubernetes/kubernetes-configmaps-secrets/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/kanvas/tutorials/kubernetes/kubernetes-configmaps-secrets/</guid><description>&lt;p&gt;In this tutorial you design a MySQL Pod that takes its database name from a ConfigMap and its root password from a Secret, deploy it to a cluster, and prove from inside the container that each value arrived. Separating configuration and credentials from the container image is how one image runs unchanged in every environment, and knowing exactly how Kubernetes delivers those values tells you why a changed setting sometimes reaches a running container and sometimes does not.&lt;/p&gt;</description></item><item><title>Schedule Work with CronJobs</title><link>/kanvas/tutorials/kubernetes/exploring-kubernetes-cronjobs/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/kanvas/tutorials/kubernetes/exploring-kubernetes-cronjobs/</guid><description>&lt;p&gt;In this tutorial you design a CronJob that runs a small container every minute, deploy it, and watch Kubernetes turn the schedule into Jobs and the Jobs into Pods. Then you change the schedule in place and clean up. Scheduled work such as backups, report generation, and cache warming runs this way, and understanding the CronJob to Job to Pod chain is what lets you answer the two questions that matter in production: did it run, and where is its output.&lt;/p&gt;</description></item><item><title>Deploy a PHP Guestbook with Redis</title><link>/kanvas/tutorials/kubernetes/deploy-php-redis/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/kanvas/tutorials/kubernetes/deploy-php-redis/</guid><description>&lt;p&gt;In this tutorial you build the Kubernetes guestbook: a PHP frontend that writes entries to a Redis leader and reads them from Redis followers. Six manifests from the Kubernetes examples become one Kanvas design, which you deploy, inspect in Operator, scale, and remove. The application is small, but it carries the pattern behind most multi-tier systems: each tier runs as a Deployment, each tier is reached through a Service, and tiers find each other by Service name, never by Pod address.&lt;/p&gt;</description></item><item><title>Deploy WordPress and MySQL with Persistent Volumes</title><link>/kanvas/tutorials/kubernetes/wordpress-mysql-persistentvolume/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/kanvas/tutorials/kubernetes/wordpress-mysql-persistentvolume/</guid><description>&lt;p&gt;In this tutorial you deploy WordPress backed by a MySQL database, and you give both tiers storage that outlives their Pods. You import the two Kubernetes example manifests into one design, add the Secret that holds the database password, and add the PersistentVolumes that the claims bind to. Stateless Pods can be replaced at any moment; a database cannot lose its files when that happens. This tutorial shows how Kubernetes separates the data from the Pod, and exactly which pieces a deploy creates and an undeploy removes.&lt;/p&gt;</description></item><item><title>Deploy Cassandra with a StatefulSet</title><link>/kanvas/tutorials/kubernetes/deploy-apache-cassandra-with-statefulset/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/kanvas/tutorials/kubernetes/deploy-apache-cassandra-with-statefulset/</guid><description>&lt;p&gt;In this tutorial you deploy Apache Cassandra as a three-node ring. A Deployment treats its Pods as interchangeable; Cassandra cannot, because each node owns part of the data and other nodes must find it at a known address. A StatefulSet gives every replica a fixed ordinal, a fixed DNS name, and its own volume, and starts the replicas one at a time. You import the Kubernetes example manifests into a Kanvas design, adapt them to your cluster, deploy, and watch the ring form.&lt;/p&gt;</description></item><item><title>Kubernetes Request Flow</title><link>/kanvas/concepts/kubernetes-request-flow/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/kanvas/concepts/kubernetes-request-flow/</guid><description>&lt;p&gt;A request to an application in Kubernetes passes through several objects before it reaches a process in a container, and none of those objects is wired to the next by a fixed address. Each layer finds the next one by name or by label at the moment the request arrives. Knowing that path, and what each layer is responsible for, turns &amp;ldquo;why am I not getting a response?&amp;rdquo; into a short list of places to look. This page walks the path from the client to the container, explains why labels and selectors are what hold it together, and shows how the same path appears in a Kanvas design.&lt;/p&gt;</description></item></channel></rss>