#Installing Alauda DevOps

This guide provides detailed steps for installing Alauda DevOps.

#Prerequisites

Ensure the Alauda DevOps v3 operator is uploaded before proceeding.

For more information on uploading the operator, please refer to

#Namespace Security Policy Requirements

• Katanomi only supports creating one instance. The instance can be deployed to any namespace, but the following conditions must be met:

  • Sufficient namespace resources
  • Namespace configured with privileged security policy

• Katanomi Operator requires the namespace to use privileged security policy configuration to function correctly. This requirement is based on the component's dependency on privileged containers and hostPath volume mounts.

  Root Cause: Katanomi Operator components require privileged container access and hostPath volume mounts (the audit log directory) for proper operation:

  • Privileged Containers: Multiple Katanomi Operator deployments utilize privileged: true security context:
    • apiserver deployment - The API server deployment requires privileged: true for executing chown to the audit log directory
    • api deployment - The API deployment uses privileged: true for executing chown to the audit log directory
    • devops-api deployment - The DevOps API deployment requires privileged: true for executing chown to the audit log directory
    • build-image-buildkit-v1 tasks - Build tasks explicitly use privileged: true for container image building capabilities

#Install Operator

Go to the platform's Administrator -> Marketplace -> OperatorHub page, search for the Alauda DevOps v3, and then click on the operator card to enter the operator details page.

Click Install to install the operator.

#Deployment location

Deploy Katanomi instances in the Global cluster. The business cluster can deploy instances as needed for CI/CD.

#Procedure

export NAMESPACE=cpaas-system
export EXTERNAL_URL=$(kubectl get prdb -n cpaas-system base -o jsonpath='{.spec.platformURL}')
cat <<EOF | kubectl apply -f -
apiVersion: operators.katanomi.dev/v1alpha1
kind: Katanomi
metadata:
  name: katanomi
  namespace: ${NAMESPACE}
spec:
  externalURL: ${EXTERNAL_URL}
  replicas: 1
  resources:
    limits:
      cpu: "2"
      memory: 4Gi
    requests:
      cpu: "1"
      memory: 2Gi
  service:
    ingress:
      protocol: HTTP
    type: Ingress
EOF

export NAMESPACE=katanomi-operator
export NODE_IP=$(kubectl get nodes -o jsonpath='{.items[0].status.addresses[?(@.type=="InternalIP")].address}' | awk -F" " '{print $1}')
export EXTERNAL_URL=http://${NODE_IP}:32001
cat <<EOF | kubectl apply -f -
apiVersion: operators.katanomi.dev/v1alpha1
kind: Katanomi
metadata:
  name: katanomi
  namespace: ${NAMESPACE}
spec:
  externalURL: ${EXTERNAL_URL}
  replicas: 1
  resources:
    limits:
      cpu: "2"
      memory: 4Gi
    requests:
      cpu: "1"
      memory: 2Gi
  service:
    nodePort:
      apiPort:
        httpPort: 32000
      pluginPort:
        httpPort: 32001
    type: NodePort
EOF

#Katanomi Parameter Description

#FAQ

#Katanomi Pod Fails to Start Due to Read-Only Root Filesystem: /cpaas Directory Not Writable

Katanomi requires write access to the /cpaas directory on the host system to store audit logs. If the pod is unable to write to this directory, it will fail to start.

To resolve this issue, you can configure an alternative audit log storage path. For example:

spec:
  helmValues:
    api:
      auditHostPath: /tmp/audit
    devopsApiServer:
      auditHostPath: /tmp/audit
    devopsApi:
      auditHostPath: /tmp/audit

This configuration directs Katanomi components to use /tmp/audit as the audit log storage path, ensuring compatibility with environments that enforce a read-only root filesystem. Adjust the path as needed to meet your security and operational requirements.

#How to Configure a Custom ImagePullSecret When Deploying Katanomi

To specify a custom ImagePullSecret for your Katanomi instance, add the following configuration:

spec:
  helmValues:
    global:
      registry:
        imagePullSecret:
          name: <imagePullSecretName>

This configuration ensures that Katanomi uses the specified ImagePullSecret for pulling container images from private registries. Replace imagePullSecretName with the name of your pre-created Kubernetes secret containing the required registry credentials.