BKE Bahriya Kubernetes Engine Start a 14-day trial

The trial, in an afternoon

This page is the evaluation path: three Debian servers to a working cluster with storage, ingress and an application serving traffic, using a self-service trial licence. Every command on it is the same one the full documentation describes — this page only puts them in an afternoon’s order and makes the evaluation-sized choices for you.

It assumes three machines. One will be the control plane and two will be workers, which is enough to see scheduling, replicated storage and ingress behave like a cluster rather than a demonstration. A single machine works too; where the two shapes differ, this page says so.

Before the afternoon starts

Three Debian 12 or 13 servers, each meeting the requirements in Before you begin: outbound HTTPS to the hosts listed there, 5 GB free on /, 20 GB free on /var/lib, a synchronised clock, and curl. Cloud instances, virtual machines and bare metal all work; a container does not, because registration derives a machine identity a container does not have.

A DNS name for the control plane. The control-plane endpoint is fixed for the life of the cluster, so even for an evaluation, point a DNS name at the first machine rather than using the machine’s own hostname — a later move to a load balancer is then a re-point rather than a rebuild.

A trial licence. Create an account in the console, create an organisation, and issue yourself a 14-day trial licence. The console asks for the control-plane endpoint — the DNS name above, with the port, as host:6443. The licence token is shown against the licence; you will place it on the first machine shortly.

Then check every machine before touching any of them:

curl -sL https://bke.maml.uk/check.sh | sh -s -- --version 2.0.0

It reads only and changes nothing. Fix anything it names now — a check failure found before the install costs a re-run; the same failure found during one costs the afternoon.

Register, then create the cluster

On the machine that will be the control plane, place the token and bind the licence:

install -d -m 0755 /etc/bke
printf '%s\n' 'YOUR-TOKEN' > /etc/bke/license
chmod 0600 /etc/bke/license

curl -sL https://bke.maml.uk/register.sh | sh            # report first
curl -sL https://bke.maml.uk/register.sh | sh -s -- --commit

Write /etc/bke/config.yaml next, because creating the cluster reads it. The file below is the evaluation shape: four components on, storage running without a backup store — supported for evaluation, stated explicitly rather than inferred — and single-replica volumes, which suits a first look and is revisited before anything holds real data.

schemaVersion: 1

cluster:
  name: trial
  region: eval
  podNetworkCidr: 192.168.0.0/16

auth:
  enabled: false

reporting:
  enabled: true

components:
  metrics-server:
    enabled: true
    namespace: kube-system

  cert-manager:
    enabled: true
    namespace: cert-manager
    settings:
      leaderElectionNamespace: kube-system

  longhorn:
    enabled: true
    namespace: longhorn-system
    settings:
      backup:
        target: ""
        credentialSecret: ""
      defaultClassReplicaCount: 1
      storageMinimalAvailablePercentage: 15

  kong:
    enabled: true
    namespace: kong

  kuma:
    enabled: false
    namespace: kuma-system

  fluent-bit:
    enabled: false
    namespace: logging

  netdata:
    enabled: false
    namespace: netdata

Then create the cluster, substituting your names:

curl -sL https://bke.maml.uk/install.sh | sh -s -- \
  --role master \
  --version 2.0.0 \
  --hostname m1.trial.k8s.example.com \
  --endpoint trial.bke.example.com:6443 \
  --dns-domain cluster.local

kubectl get nodes on this machine shows the node reach Ready once the network fabric is up.

Join the workers

On each of the other two machines:

curl -sL https://bke.maml.uk/install.sh | sh -s -- \
  --role worker \
  --version 2.0.0 \
  --hostname w1.trial.k8s.example.com

Then, on the control-plane machine, mint a join command:

kubeadm token create --print-join-command

and run what it prints on each worker, as root. kubectl get nodes shows all three Ready. If a worker stays NotReady, the near-certain cause is node-to-node ports blocked by something in front of the machines — a cloud security group, a firewall between subnets — which the preflight cannot see. Adding nodes covers it.

Install the components

On the control-plane machine, report first, then commit:

curl -sL https://bke.maml.uk/apply.sh | sh -s -- --version 2.0.0
curl -sL https://bke.maml.uk/apply.sh | sh -s -- --version 2.0.0 --commit

The report before --commit is worth a minute even on a trial: it is the same report a production upgrade produces, and it is half of what you are evaluating. When the commit finishes:

kubectl get pods -A

Everything in longhorn-system, kong and cert-manager reaches Running. You now have a cluster that can hold data and route traffic.

Put an application behind it

A deployment, a Service and an Ingress — the same three objects Ingress with Kong walks through in full. From the control-plane machine:

kubectl create namespace trial
kubectl -n trial create deployment hello --image=nginx --replicas=2
kubectl -n trial expose deployment hello --port 80

Then an Ingress, as a file:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hello
  namespace: trial
spec:
  ingressClassName: kong
  rules:
    - host: hello.trial.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: hello
                port:
                  number: 80

kubectl apply -f hello-ingress.yaml

Kong listens on port 32080 (HTTP) and 32443 (HTTPS) on the workers. Point DNS for the hostname at a worker — or, for a quick look, put a worker’s address against the hostname in your own /etc/hosts — and:

curl http://hello.trial.example.com:32080/

The nginx welcome page coming back has crossed your ingress. If the machines are internet-reachable and DNS is real, Ingress with Kong adds a certificate in two more resources — use Let’s Encrypt’s staging environment while evaluating, exactly as that page describes.

What to look at before the fourteen days end

The afternoon proves the mechanics. These four are what distinguish BKE, and each takes minutes:

  • Read /etc/bke/values/. One file per component, yours to edit, beside a .dist.yaml recording what BKE rendered. Change a setting in kong.yaml, run apply.sh again, and watch the report state exactly what your change moves — that report-then-commit shape is how every future upgrade treats your configuration.
  • Read the report a second time. Run apply.sh without --commit on the version you are already on: idempotence stated, not promised.
  • Run the daily report by hand and read what left your cluster — Cluster reporting gives the two commands, and the same page shows how to turn reporting off and verify that nothing remains.

  • Check what the cluster is running:

    curl -sL https://bke.maml.uk/version.sh | sh

Storage with real replication needs defaultClassReplicaCount raised and a backup target configured — Storage covers both, and doing it on the trial cluster is a fair test of the configuration workflow.

When the trial answers your questions, the pricing page is one number, and the licence the console issues for production is bound and installed exactly the way this one was.