Kubernetes

Managed Kubernetes explained

Kubernetes runs and manages containers across a group of servers. It restarts containers that crash, spreads them across nodes, rolls out new versions without downtime, and scales them up under load. Doing all of that by hand is a lot of work, so Gewape Cloud runs the control plane and the servers for you. You get a standard, conformant Kubernetes cluster that you drive with the usual kubectl tool, so anything written for Kubernetes works here unchanged. You manage clusters under Kubernetes in the console. The pieces - A cluster template defines the shape of a cluster: the Kubernetes version, the node size, and networking. You can reuse a template for many clusters. - A cluster is created from a template. It has control-plane nodes (which run Kubernetes itself) and worker nodes (which run your containers). - A kubeconfig file authenticates kubectl to your cluster. When to use it, and when not Kubernetes is aimed at teams that package their applications as containers and want automated deployment, scaling and recovery. If you are running a single website or app, a Cloud Server is simpler and cheaper. Reach for Kubernetes when you have several services, need zero-downtime deploys, or want to scale parts of your system independently. How to - Create a Kubernetes cluster - Connect to your cluster with kubectl - Scale a cluster A cluster runs on real servers, so it draws from your wallet for as long as it exists. Delete clusters you are only testing.

Create a Kubernetes cluster

This creates a managed Kubernetes cluster you then drive with kubectl from your own machine. Create the cluster 1. Open Kubernetes in the console and start a new cluster. 2. Fill in: - Cluster Template: choose a template, which sets the Kubernetes version and the node type. Create one first if none fits. - Name: for example prod-k8s. - Keypair: the SSH key for node access. See Manage your SSH keys. - Number of worker nodes: start with two or three for a real workload. You can scale later. - Number of control-plane nodes: one is fine for testing; use three for production high availability. - Server Plan for nodes: the size of each node (see Server Plans explained). - Region: where the cluster runs. 3. Create it. Provisioning takes several minutes while the control plane and nodes come up. Get access When the cluster is healthy, download its kubeconfig file from the cluster page, then follow Connect to your cluster with kubectl. A cluster runs on real servers, so it draws from your wallet while it exists. Delete clusters you are only testing.

Connect to your cluster with kubectl

Once a cluster is running, you control it from your own computer with kubectl, the standard Kubernetes tool. Steps 1. Install kubectl. The Kubernetes project provides it for Mac, Windows and Linux. On Mac, brew install kubectl; on Linux, download the binary; on Windows, use the installer or winget. 2. Download your kubeconfig. In the console, open your cluster under Kubernetes and download its kubeconfig file. This file authenticates you to the cluster. 3. Point kubectl at it. Either save it as ~/.kube/config, or set export KUBECONFIG=/path/to/config in your terminal for that session. 4. Test it. Run kubectl get nodes. You should see your worker nodes listed as Ready. From here you use Kubernetes normally: kubectl apply -f your manifests, kubectl get pods, and so on. When you expose a service of type LoadBalancer, Kubernetes automatically requests a load balancer and a public IP. If kubectl cannot connect, the usual causes are the wrong kubeconfig file, a KUBECONFIG pointing at the wrong path, or the cluster not being finished provisioning yet. To change the cluster size, see Scale a cluster.

Scale a Kubernetes cluster

As demand changes you can add or remove worker nodes without rebuilding the cluster. Steps 1. Open your cluster under Kubernetes. 2. Choose the Resize or Update action. 3. Set the new node count and confirm. The cluster adds nodes (more capacity for your pods) or removes them (lower cost). When removing, Kubernetes drains the nodes first and reschedules their pods onto the remaining nodes, so running workloads move rather than disappear. What changes - Scaling nodes changes how many servers you run, so it changes what you pay. - It does not change the size of each node. To make individual nodes bigger, create a new cluster (or node group) on a larger Server Plan. - Making a single application handle more load is done inside Kubernetes with your deployment's replica count, not here. Keep at least two worker nodes for anything you care about staying available while one is updated or replaced.