Sai
06/05/2026, 8:11 AMRocky
06/05/2026, 8:11 AMroot password, the recommended approach is using the kube-starrocks Helm chart.
1. Update Root Password during Initial Deployment
The StarRocks Operator can automatically initialize the root password using a separate initialization job.
Step 1: Create a Kubernetes Secret
First, create a secret in the same namespace where you will deploy StarRocks. The secret must contain a key named password.
bash
kubectl create secret generic starrocks-root-pass --from-literal=password='your_secure_password'
Step 2: Configure Helm Values
In your values.yaml (or via --set flags), enable the initialization password feature and reference the secret:
yaml
starrocks:
initPassword:
enabled: true
passwordSecret: "starrocks-root-pass"
Note: During deployment, a pod named kube-starrocks-initpwd will be created. It may initially show Error or CrashLoopBackOff while waiting for the FE nodes to become ready. This is expected; the job will eventually succeed once the cluster is up.
──────────
2. Latest Stable Versions and Docker Tags
As of June 2026, the following versions are recommended for production:
Release Type | Version | Docker Image Tags (Example)
Stable (LTS) | 3.3.22 | starrocks/fe-ubuntu:3.3.22, starrocks/be-ubuntu:3.3.22
Latest Stable | 3.5.15 | starrocks/fe-ubuntu:3.5.15, starrocks/be-ubuntu:3.5.15
Latest Major | 4.0.8 | starrocks/fe-ubuntu:4.0.8, starrocks/be-ubuntu:4.0.8
Official Docker Repositories:
• FE: starrocks/fe-ubuntu
• BE: starrocks/be-ubuntu
• CN: starrocks/cn-ubuntu
• Operator: starrocks/operator (Latest version is typically v1.9.x or v1.11.x depending on your Helm chart version).
Quick Deployment Command
To deploy using the latest stable Helm chart:
bash
helm repo add starrocks <https://starrocks.github.io/starrocks-kubernetes-operator>
helm repo update
helm install starrocks-cluster starrocks/kube-starrocks -f my-values.yaml
Caution: If you are using a shared-data architecture (Cloud-Native), ensure your FE/BE images match and the run_mode is correctly configured in your spec.
References
• quick_start/helm.md
• loading/Spark-connector-starrocks.md
• loading/Kafka-connector-starrocks.md
• deployment/post_deployment_setup.mdSai
06/05/2026, 8:13 AMRocky
06/05/2026, 8:13 AMkube-starrocks-initpwd pod is in a CrashLoopBackOff state, this is often expected behavior during the initial minutes of deployment.
1. Why it crashes (Expected Behavior)
The initialization pod starts immediately after you run helm install. However, it cannot set the password until the FrontEnd (FE) nodes are fully initialized and the MySQL port (9030) is ready to accept connections.
* The behavior: The pod tries to connect, fails because the FE is still starting, crashes, and Kubernetes restarts it with an exponential backoff.
* The solution: You should ignore this for the first 5–10 minutes. Once the FE pods show 1/1 READY, the next retry of the initpwd pod will succeed and its status will change to Completed.
2. Troubleshooting (If it persists)
If the FE pods are already healthy (READY 1/1) and the initpwd pod is still crashing, check the following:
* Check the Logs: This is the most direct way to see why it's failing.
bash
kubectl logs <kube-starrocks-initpwd-pod-name>
* Verify the Secret Key: The StarRocks Operator specifically looks for a key named password inside your secret. If you named the key root-password or something else, it will fail.
bash
# Verify the key exists
kubectl get secret starrocks-root-pass -o jsonpath='{.data}'
* Check the FE Service: The init job connects via the internal FE service. Ensure the service exists and the selector matches your FE pods.
bash
kubectl get svc
* Resource Issues: On EKS, if your FE pods are also crashing, it is likely due to Insufficient Memory (FEs need at least 8GB to be stable) or PersistentVolume (PV) binding issues. Check kubectl describe pod <fe-pod-name>.
──────────
3. Latest Stable Versions and Docker Tags (June 2026)
For a production deployment on EKS, use these verified stable versions:
Release Type | StarRocks Version | Docker Image Tag
Stable (LTS) | 3.3.22 | starrocks/fe-ubuntu:3.3.22
Latest Stable | 3.5.15 | starrocks/fe-ubuntu:3.5.15
Current Major | 4.0.10 | starrocks/fe-ubuntu:4.0.10
Recommended Helm Chart & Operator:
* Helm Chart: kube-starrocks version 1.11.4
* Operator Image: starrocks/operator:v1.9.1 (or latest v1.11.x)
Example Docker Tags for your `values.yaml`:
yaml
starrocksFeSpec:
image: "starrocks/fe-ubuntu:3.5.15"
starrocksBeSpec:
image: "starrocks/be-ubuntu:3.5.15"
Note for EKS: Ensure your BE nodes have enough max_map_count configured on the underlying EC2 hosts (at least 262144), or the BE pods will crash immediately.
References
• quick_start/helm.md
• deployment/helm.md
• deployment/post_deployment_setup.md
• deployment/sr_operator.md
• administration/user_privs/authentication/native_authentication.mdSai
06/05/2026, 8:15 AMRocky
06/05/2026, 8:15 AMkube-starrocks-initpwd pod has been in CrashLoopBackOff for 30 minutes, it indicates a persistent issue rather than the normal startup delay.
1. Troubleshooting the CrashLoopBackOff
Please run the following command to see the exact error message:
bash
kubectl logs <kube-starrocks-initpwd-pod-name>
Common Root Causes
* FE Pods are not "Ready": Check if your FE pods show 1/1 READY. If the FEs are also crashing or stuck, the init job cannot connect. On EKS, this is often due to Insufficient CPU/Memory (FE requires at least 4-8GB) or Storage (PVCs not binding).
* Password Already Set: If this is not a truly fresh deployment (e.g., you deleted and re-installed the Helm chart but kept the Persistent Volumes), the root password might already be set. The initpwd job tries to log in with no password to set the new one; if it's already set, it will fail with Access denied.
* Incorrect Secret Key: The job specifically looks for a key named password.
* Fix: Ensure your secret was created as: kubectl create secret generic starrocks-root-pass --from-literal=password='your_pass'
* Network/DNS Issues: In some EKS VPC configurations, the pod may fail to resolve the FE service name (kube-starrocks-fe-service). The logs will show Unknown MySQL server host.
──────────
2. Latest Stable Versions (June 2026)
For a stable production environment on EKS, these are the current recommended versions:
Tier | Version | Docker Image Tags
Stable (LTS) | 3.3.22 | starrocks/fe-ubuntu:3.3.22, starrocks/be-ubuntu:3.3.22
Latest Stable | 3.5.15 | starrocks/fe-ubuntu:3.5.15, starrocks/be-ubuntu:3.5.15
Latest Major | 4.0.10 | starrocks/fe-ubuntu:4.0.10, starrocks/be-ubuntu:4.0.10
Kubernetes Operator:
* Chart Version: kube-starrocks-1.11.4 (or latest available)
* Operator Image: starrocks/operator:v1.9.1
──────────
3. Recommended values.yaml for EKS
Ensure your resource requests are high enough for EKS nodes to schedule them properly:
yaml
starrocks:
initPassword:
enabled: true
passwordSecret: "starrocks-root-pass"
starrocksFESpec:
image: "starrocks/fe-ubuntu:3.5.15"
resources:
requests:
cpu: 2
memory: 8Gi # Minimum recommended for FE
storageSpec:
name: fe-meta
storageSize: 20Gi
starrocksBeSpec:
image: "starrocks/be-ubuntu:3.5.15"
resources:
requests:
cpu: 4
memory: 16Gi
storageSpec:
name: be-data
storageSize: 100Gi
Note for BE on EKS: If the BE pods are also crashing, ensure you have set sysctl -w vm.max_map_count=262144 on your EKS worker nodes (usually via a Launch Template or UserData script).
References
• quick_start/helm.md
• deployment/helm.md
• deployment/post_deployment_setup.md