PikoSystem IT engineering services
فا Emergency Talk to an engineer
DevOps

Kubernetes cluster setup and support

Kubernetes is powerful, and a badly built cluster quickly becomes the cause of your outages. We start with node and network design, build the cluster with a highly available control plane, and plan backups, monitoring and upgrades from day one.

Get a quote 021-00000000
Tools & technology kubernetes
  • Kubernetes
  • kubeadm
  • RKE2
  • Rancher
  • Helm
  • Calico
  • Longhorn
  • Velero
  • cert-manager
  • ingress-nginx
6work areas
4deliverables
4steps

What is Kubernetes Clusters?

Kubernetes setup means building a cluster of servers that run containers together and shift the load when one node fails, with backups, access control and an upgrade plan in place from day one. It suits teams with too many services to manage containers by hand, a self-built cluster nobody dares to upgrade, or a need for pods to scale with traffic. PikoSystem sizes control plane and worker nodes, installs the cluster with kubeadm or RKE2 on your own servers, on VMs or as cloud Kubernetes, sets up Longhorn or Ceph storage with etcd snapshots and Velero backups, and defines namespaces and RBAC per team. Services move over one at a time with a way back. You receive a kubeconfig per role, Helm charts in Git, runbooks for upgrades and etcd restore, and an architecture diagram.

When you need Kubernetes Clusters

  • We have too many services to manage containers by hand.
  • We built a cluster ourselves and now nobody dares to upgrade it.
  • The cluster certificates expired and every service went down.
  • We want pods to scale out automatically when traffic grows.

What Kubernetes Clusters includes

01

Cluster design

Control plane and worker sizing, pod networking with Calico or Cilium, and etcd placement, based on your workload and budget.

02

Installation

Setup with kubeadm or RKE2, an ingress controller, cert-manager for TLS, and MetalLB for bare-metal or VM clusters without a cloud load balancer.

03

Storage and backup

A StorageClass on Longhorn or Ceph, scheduled etcd snapshots, and Velero backups of resources and persistent volumes.

04

Access and security

Namespaces and RBAC per team, NetworkPolicies, ResourceQuotas and Pod Security Standards.

05

Migrating workloads

Manifests or Helm charts for your existing services, moved over one at a time from Docker Compose or plain servers.

06

Ongoing maintenance

Kubernetes version upgrades, certificate renewals, node health checks and troubleshooting. Scope and response times are set in the contract.

What you get from Kubernetes Clusters

  • A working cluster with a separate kubeconfig for each role
  • Helm charts or manifests for your services in Git
  • Runbooks for cluster upgrades, etcd restore and adding nodes
  • An architecture diagram of the cluster and network

Kubernetes Clusters: a practical guide

kubeadm, RKE2 or k3s: which Kubernetes distribution fits?

kubeadm gives you upstream Kubernetes and full control, while certificate renewal and node-by-node upgrades stay with you. Certificates generated by kubeadm are valid for one year by default, so a cluster that isn't upgraded or renewed with kubeadm certs renew in that time will see its API server stop accepting connections.

RKE2 ships with hardened defaults, embeds etcd and has a simpler upgrade path, which makes it our usual recommendation for production clusters on your own hardware. k3s is light and fits test environments, small servers and branch sites. With cloud Kubernetes from a local provider, the control plane is theirs to run and your real decisions are about storage and networking.

Is your application ready to migrate to Kubernetes?

Running in Docker doesn't make an app Kubernetes-ready. A pod can be rescheduled onto another node at any moment, so the app can't depend on local files or a fixed IP. It should handle SIGTERM and finish in-flight requests, and expose separate endpoints for readiness and liveness probes so traffic only arrives once it is ready.

Every workload also needs CPU and memory requests and limits. Without them the scheduler places pods blindly, and one hungry service can starve a node. Since registry.k8s.io and Docker Hub aren't reliably reachable from Iran, image mirrors should be configured in containerd before installation starts.

Common Kubernetes cluster mistakes

etcd is sensitive to disk write latency. Put it on slow disks or busy shared storage and you get repeated leader elections and an unstable cluster. Control plane nodes need SSDs, ideally dedicated ones.

By default Secrets are only base64-encoded in etcd, so without an EncryptionConfiguration anyone holding an etcd backup can read your passwords. Missing PodDisruptionBudgets mean that draining a node for an upgrade can stop every replica of a service at once. And when every team connects with the same admin kubeconfig, there is no record of who changed what.

What affects the cost of a Kubernetes cluster?

Node count and size come first, with the storage choice close behind. Longhorn runs on the worker nodes and is straightforward to operate. Ceph handles larger volumes well but asks for more disks, faster networking and more operational skill.

Beyond that: how many services need Helm charts or manifests, whether you need several clusters managed through Rancher, integration with your identity provider, security requirements such as NetworkPolicies in every namespace, and whether a registry and deployment pipeline already exist.

How Kubernetes Clusters works

  1. 01

    Requirements

    We review your services, load, existing infrastructure and your team's capacity to run a cluster, then propose an architecture.

  2. 02

    Test cluster

    We build a test cluster and run one or two services on it to validate the design before production.

  3. 03

    Build and migrate

    We build the production cluster and move services across one by one, with a way back for each.

  4. 04

    Handover and support

    You get documentation and access, your team gets training, and we can continue maintenance under a support contract.

Kubernetes Clusters: frequently asked questions

Do you build clusters on our own hardware or only in the cloud?

Both. We work on bare metal, Proxmox or VMware virtual machines, and managed Kubernetes from cloud providers. We recommend an option based on budget, workload and how much your team can maintain.

What is the minimum number of servers?

For production we usually recommend three control plane nodes and at least two workers, so losing one server doesn't take the cluster down. A test environment can run on one or two servers. The exact sizing depends on your workload.

Do you install Rancher?

If your team wants a web interface to manage several clusters, we install Rancher and connect it to your identity provider. For a single small cluster, kubectl and a simple dashboard are often enough.

Who maintains the cluster after setup?

We can train your team and hand over the runbooks, or take on Kubernetes management under a support contract. Scope and response times are written into the agreement.

Related searches

  • Kubernetes services
  • Kubernetes cluster
  • managed Kubernetes
  • Kubernetes consulting
  • Rancher
  • migrate to Kubernetes

Related services

Quote

Tell us what you need, we'll come back with a plan and a price

A few lines on where things stand and what you want is enough. An engineer calls you back, not a sales rep.

  1. 01We read your request and call if anything is unclear.
  2. 02If needed, we do a quick remote review or a site visit.
  3. 03You get a written proposal with scope, timeline and cost.

Your details are only used to answer this request.