• BuildPiper is compatible with Kubernetes versions 1.25 through 1.32.
• BuildPiper is compatible with managed Kubernetes services from all leading cloud providers, ensuring unified DevOps workflows across your cloud infrastructure.

buildpiper@prod-hanuman-app-bpproduct-siddharthgupta-bp:~/deploy_buildpiper$ kubectl version --short

Client Version: v1.23.6
Server Version: v1.32.6

buildpiper@prod-hanuman-app-bpproduct-siddharthgupta-bp:~$ export KUBECONFIG=~/.kube/prod-noida-app-cluster/config
buildpiper@prod-hanuman-app-bpproduct-siddharthgupta-bp:~$ kubectl get nodes

NAME                             STATUS   ROLES           AGE    VERSION
k8s-master1.prd.bp.opstree.net   Ready    control-plane   236d   v1.32.6
k8s-master2.prd.bp.opstree.net   Ready    control-plane   236d   v1.32.6
k8s-master3.prd.bp.opstree.net   Ready    control-plane   236d   v1.32.6
k8s-worker1.prd.bp.opstree.net   Ready    worker          236d   v1.32.6
k8s-worker2.prd.bp.opstree.net   Ready    worker          236d   v1.32.6
k8s-worker3.prd.bp.opstree.net   Ready    worker          236d   v1.32.6

The KUBECONFIG file generated by the cloud provider typically contains dynamic credentials (such as short-lived tokens or auto-rotating authentication data).

However, BuildPiper references a KUBECONFIG file configured with static credentials to ensure consistent and uninterrupted cluster access. Refer to the SOP below to apply static KUBECONFIG credentials.

When using GCP as the cloud provider, it tends to automatically create a network policy for the namespace when it is created. This will impact ingress communication and will need to be deleted to restore proper connectivity.

In the case of an OpenShift cluster, the setupAdminUser.sh script may need to be updated. Replace all kubectl commands with the oc equivalent.

rajat_vats@bp-ohio:~/k8s-ro-user/admin$ cat setupAdminUser.sh
#!/bin/bash

NAMESPACE="default"

sed -i "s|#NAMESPACE#|${NAMESPACE}|g" service-account.yaml
sed -i "s|#NAMESPACE#|${NAMESPACE}|g" cluster-role-binding.yaml

kubectl apply -f cluster-role.yaml
kubectl apply -f service-account.yaml
kubectl apply -f cluster-role-binding.yaml

TOKEN_NAME=$(kubectl get sa config-admin -o jsonpath='{.secrets[0].name}' -n ${NAMESPACE})
TOKEN=$(kubectl -n ${NAMESPACE} get secret $TOKEN_NAME -o jsonpath='{.data.token}'| base64 --decode)

cp ~/.kube/config ~/.kube/config-sa-config-admin
export KUBECONFIG=~/.kube/config-sa-config-admin

kubectl config set-credentials config-admin --token=$TOKEN
kubectl config set-context --current --user=config-admin

cp cluster-role.yaml cluster-role.yaml.bak
cp service-account.yaml service-account.yaml.bak
cp cluster-role-binding.yaml cluster-role-binding.yaml.bak

sed -i "s|#NAMESPACE#|${NAMESPACE}|g" service-account.yaml
sed -i "s|#NAMESPACE#|${NAMESPACE}|g" cluster-role-binding.yaml

oc apply -f cluster-role.yaml
oc apply -f service-account.yaml
oc apply -f cluster-role-binding.yaml

mv cluster-role.yaml.bak cluster-role.yaml
mv service-account.yaml.bak service-account.yaml
mv cluster-role-binding.yaml.bak cluster-role-binding.yaml

TOKEN=$(oc -n ${NAMESPACE} get secret config-admin -o jsonpath='{.data.token}'| base64 --decode)

cp ~/.kube/config ~/.kube/config-sa-config-admin
export KUBECONFIG=~/.kube/config-sa-config-admin

oc config set-credentials config-admin --token=$TOKEN

• If your cloud provider is GCP, you can use both standard and Autopilot clusters.
• Clients can also onboard Kubernetes clusters running on LDC environments such as Proxmox, OpenShift, and other similar platforms.