Skip to main content
Ryvn deploys your applications to Kubernetes clusters running in your cloud account. You don’t need to be a Kubernetes expert to use Ryvn, but understanding a few core concepts will help you configure deployments, troubleshoot issues, and make sense of what’s happening under the hood.

​
How Ryvn Maps to Kubernetes

When you deploy a server service to an environment, Ryvn creates the Kubernetes resources needed to run and expose your application:
RyvnKubernetesWhat it does
EnvironmentClusterAn isolated Kubernetes cluster in your cloud account
Service—A deployment template (no direct K8s equivalent)
InstallationDeployment + Service + IngressA running instance of a service in an environment
PodPodA single container instance of your application

​
Pods

A pod is a single running instance of your application. When you configure the pod count in Ryvn, you’re controlling how many pods run simultaneously. Running multiple pods gives you:
  • Availability — if one pod crashes, others keep serving traffic
  • Throughput — traffic is distributed across pods via a load balancer
Pods are ephemeral. Kubernetes replaces them when they fail, when you deploy a new version, or when the cluster needs to rebalance. Don’t store important data inside a container’s filesystem — use environment variables, secrets, or external storage instead.

​
Resource Requests and Limits

Every pod needs CPU and memory. Kubernetes uses two settings to manage this:
  • Requests — the guaranteed minimum. The scheduler uses this to decide where your pod runs.
  • Limits — the maximum allowed. If a pod exceeds its memory limit, it’s killed (OOMKilled). If it exceeds CPU, it gets throttled (slower responses).
UnitMeaningExample
250m CPU0.25 coresLight API server
1000m CPU1 full coreCPU-intensive workload
256Mi memory256 megabytesSmall service
1Gi memory1 gigabyteLarger service
If a pod stays in Pending status, it usually means the cluster doesn’t have enough capacity to satisfy the request. Either reduce the resource request or scale up the cluster.

​
Health Checks

Ryvn uses health checks to determine whether a pod is ready to receive traffic. During a deployment, new pods must pass their health check before traffic is routed to them — this is how zero-downtime deployments work. How it works:
  1. Ryvn sends an HTTP GET request to your health check endpoint (e.g., /healthz)
  2. A 2xx or 3xx response means healthy
  3. If a pod fails health checks for 60+ seconds, it gets restarted
  4. If a new deployment fails health checks for 15+ minutes, the deployment is canceled and the previous version keeps running
A correct health check is critical — it’s the mechanism that prevents bad deployments from going live. Configure a health check endpoint in your application that returns a success status when the app is ready to handle requests. See Health Checks for setup details.

​
Deployments and Rolling Updates

When you deploy a new version, Ryvn uses rolling updates:
  1. New pods are created with the updated version
  2. Each new pod must pass its health check
  3. Once healthy, traffic shifts to the new pods
  4. Old pods are terminated
This means your application is never fully down during a deployment. If the new version fails health checks, the old version keeps running.

​
Autoscaling

Ryvn monitors CPU and memory utilization across your pods and automatically adjusts the pod count:
  • When average utilization exceeds the target, pods are added (up to your max)
  • When utilization drops, pods are removed (down to your min)
For example, with a target CPU of 70%, 2 min pods, and 10 max pods — if your 2 pods are averaging 90% CPU, Ryvn adds pods until utilization drops below 70%. See Scaling for configuration.

​
Networking

Ryvn configures three access modes that control how traffic reaches your application:
ModeWho can reach it
PublicAnyone on the internet
InternalServices within your VPC
PrivateServices within the cluster only
For public and internal services, traffic flows through a load balancer and ingress controller before reaching your pods. TLS certificates are provisioned automatically when you add a custom domain.

​
Common Troubleshooting

SymptomLikely causeWhat to do
Pod stuck in PendingNot enough CPU/memory on cluster nodesReduce resource requests or scale up the cluster
Pod in CrashLoopBackOffApplication crashes on startupCheck logs for errors — likely a missing env var or failed dependency
Deployment stuck/canceledHealth check failingVerify your health endpoint works and returns 2xx within 5 seconds
OOMKilledPod exceeded memory limitIncrease the memory limit or fix a memory leak
No traffic reaching serviceIngress or DNS misconfigurationCheck custom domain setup and networking mode