<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Services on Layer5 Documentation</title><link>/tags/services/</link><description>Recent content in Services on Layer5 Documentation</description><generator>Hugo</generator><language>en</language><atom:link href="/tags/services/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 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>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>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>