Merge pull request #28 from yangchuansheng/fix/1024mi-resource-ladder

fix(docker-to-sealos): normalize 1024Mi resource ladder

Author: yangchuansheng

skills/docker-to-sealos/SKILL.md

@@ -174,6 +174,7 @@ If validation fails, fix template/rules/examples first.
 - MySQL cluster must follow upgraded structure (`kb.io/database: ac-mysql-8.0.30-1`, `clusterDefinitionRef: apecloud-mysql`, `clusterVersionRef: ac-mysql-8.0.30-1`, `tolerations: []`).
 - Redis cluster must follow upgraded structure (`componentDef: redis-7`, `componentDef: redis-sentinel-7`, `serviceVersion: 7.2.7`, main data PVC `1Gi`, topology `replication`).
 - Database cluster component resources must use `limits(cpu=500m,memory=512Mi)` and `requests(cpu=50m,memory=51Mi)` unless source docs explicitly require otherwise.
+- All managed workload container resources must use the Sealos resource ladder: `limits.cpu` only `100m/200m/500m/1/2/3/4/8`, `limits.memory` only `128Mi/256Mi/512Mi/1024Mi/2G/4G/8G/16G`, and `requests` must be derived from `limits` by dropping the last numeric digit (`500m→50m`, `512Mi→51Mi`, `1→100m`, `1024Mi→102Mi`). Do not invent non-ladder values.
 - Secret naming:
   - MongoDB: `${{ defaults.app_name }}-mongo-mongodb-account-root` (or `${{ defaults.app_name }}-mongodb-mongodb-account-root` when the MongoDB cluster name uses `-mongodb`)
   - Redis: `${{ defaults.app_name }}-redis-redis-account-default` (legacy `${{ defaults.app_name }}-redis-account-default` may be accepted for backward compatibility)
@@ -182,13 +183,33 @@ If validation fails, fix template/rules/examples first.
 
 ### Baseline runtime defaults
 
-Unless source docs explicitly require otherwise, use:
+Unless source docs explicitly require otherwise, use the lightweight app ladder entry:
 
 - container limits: `cpu=200m`, `memory=256Mi`
 - container requests: `cpu=20m`, `memory=25Mi`
 - `revisionHistoryLimit: 1`
 - `automountServiceAccountToken: false`
 
+For higher resource needs, move only to another allowed `limits` ladder entry and recompute `requests` from that `limits` value.
+
+### Browser / remote desktop resource validation
+
+For browser, VNC, WebRTC desktop, Xvfb, Selkies, noVNC, Kasm, or remote-desktop-style containers:
+
+- Do not treat a short smoke test as proof of a stable minimum memory value.
+- Validate memory with a fresh deployment, not only a patched warm pod.
+- Exercise cold start until readiness, a lightweight page, a real/medium page, an interactive/search page, and a 60s post-smoke stability check.
+- If observed cgroup memory reaches more than 80% of the limit during smoke, move to the next allowed Sealos memory ladder value.
+- Keep requests derived from limits according to the Sealos resource ladder.
+
+Example:
+- Bad: Chrome passes a short smoke at `512Mi` but reaches `503Mi`; shipping `512Mi` as the stable minimum is unsafe.
+- Good: raise to `1024Mi`, set request to `102Mi`, rerun smoke and stability checks.
+
+For Chrome + Xvfb + Selkies with 4K max display, use at least:
+- limits: `cpu=200m`, `memory=1024Mi`
+- requests: `cpu=20m`, `memory=102Mi`
+
 ### Defaults vs inputs
 
 - `defaults` for generated values (`app_name`, `app_host`, random passwords/keys).

skills/docker-to-sealos/references/conversion-mappings.md

@@ -521,6 +521,8 @@ env:
 
 ## Resource Limits Mapping
 
+Compose resource values must be normalized to the Sealos ladder. Use Compose limits only to choose the nearest allowed `limits` tier. Normalize 1G-class memory to `1024Mi`. Ignore Compose reservations for `requests`; Sealos `requests` are derived from the selected `limits` by dropping the last numeric digit, so `1024Mi` maps to `102Mi`.
+
 ### Docker Compose
 ```yaml
 services:
@@ -544,11 +546,11 @@ spec:
         - name: ${{ defaults.app_name }}
           resources:
             limits:
-              cpu: 1000m
+              cpu: 1
               memory: 1024Mi
             requests:
-              cpu: 500m
-              memory: 512Mi
+              cpu: 100m
+              memory: 102Mi
 ```
 
 ## Health Check Mapping

skills/docker-to-sealos/references/frappe-bench.md

@@ -17,9 +17,10 @@ Do not mix these models blindly. If a repo's `docker/docker-compose.yml` uses `f
 
 - Database services from Compose (`mariadb`, `mysql`, `redis`) should follow the Sealos database strategy. Redis must use the KubeBlocks Redis `Cluster` and its generated Secret (`${{ defaults.app_name }}-redis-redis-account-default`) unless the user explicitly asks for raw containers.
 - If using a prebuilt Frappe image with mounted `sites` and `logs` PVCs, set pod `securityContext.fsGroup: 1000` so the `frappe` user can write mounted volumes.
-- Init containers that run `bench init`, `bench new-site`, `bench migrate`, or app install steps must set explicit resources. Do not rely on namespace defaults; `64Mi` memory is too small. Use at least:
-  - light config init: `requests.memory: 128Mi`, `limits.memory: 256Mi`
-  - `bench new-site` / app install / migrate: `requests.memory: 512Mi`, `limits.memory: 2Gi`
+- Init containers that run `bench init`, `bench new-site`, `bench migrate`, or app install steps must set explicit resources from the Sealos ladder. Do not rely on namespace defaults; `64Mi` memory is too small. Use at least:
+  - light config init: `limits.memory: 256Mi`, `requests.memory: 25Mi`
+  - `bench new-site` / app install / migrate: `limits.memory: 2G`, `requests.memory: 200Mi`
+  - choose matching ladder CPU values and derive CPU requests the same way, for example `limits.cpu: 500m` → `requests.cpu: 50m`
 - Bootstrap scripts must be idempotent and recover from partial initialization:
   - create `sites/common_site_config.json` if a fresh PVC hides the image's bundled file
   - use `bench new-site --force` for first-site creation when the database may contain residue from a previous failed attempt

skills/docker-to-sealos/references/must-rules-map.yaml

@@ -236,6 +236,10 @@ must_rules:
     enforcement:
       type: rule
       target: R019
+  - must: "All managed workload container resources must use the Sealos resource ladder: `limits.cpu` only `100m/200m/500m/1/2/3/4/8`, `limits.memory` only `128Mi/256Mi/512Mi/1024Mi/2G/4G/8G/16G`, and `requests` must be derived from `limits` by dropping the last numeric digit (`500m→50m`, `512Mi→51Mi`, `1→100m`, `1024Mi→102Mi`). Do not invent non-ladder values."
+    enforcement:
+      type: rule
+      target: R038
   - must: "MongoDB: `${{ defaults.app_name }}-mongo-mongodb-account-root` (or `${{ defaults.app_name }}-mongodb-mongodb-account-root` when the MongoDB cluster name uses `-mongodb`)"
     enforcement:
       type: rule
@@ -254,12 +258,12 @@ must_rules:
       target: R007
   - must: "container limits: `cpu=200m`, `memory=256Mi`"
     enforcement:
-      type: manual
-      note: "Requires runtime-default validation with source-doc override awareness."
+      type: rule
+      target: R038
   - must: "container requests: `cpu=20m`, `memory=25Mi`"
     enforcement:
-      type: manual
-      note: "Requires runtime-default validation with source-doc override awareness."
+      type: rule
+      target: R038
   - must: "`revisionHistoryLimit: 1`"
     enforcement:
       type: rule

skills/docker-to-sealos/references/rules-registry.yaml

@@ -76,6 +76,9 @@ rules:
   - id: R019
     description: Database cluster component resources must use limits cpu=500m/memory=512Mi and requests cpu=50m/memory=51Mi.
     severity: error
+  - id: R038
+    description: Managed workload container resources must use allowed Sealos limits ladder values and derive requests from limits.
+    severity: error
   - id: R020
     description: Service spec.ports entries must define non-empty name fields in template artifacts.
     severity: error

skills/docker-to-sealos/references/sealos-specs.md

@@ -903,146 +903,127 @@ spec:
 
 ### Resource Limit Configuration
 
-**Important: The resources field of all containers must include both requests and limits!**
+**Important: The resources field of all containers must include both requests and limits.**
+
+All containers in application Deployments or StatefulSets must use the fixed Sealos resource ladder. Do not invent intermediate values during template generation or resource tuning.
+
+Allowed `limits.cpu` values use canonical Kubernetes quantities:
+
+- `100m` (0.1 core)
+- `200m` (0.2 core)
+- `500m` (0.5 core)
+- `1`
+- `2`
+- `3`
+- `4`
+- `8`
+
+Allowed `limits.memory` values:
+
+- `128Mi`
+- `256Mi`
+- `512Mi`
+- `1024Mi`
+- `2G`
+- `4G`
+- `8G`
+- `16G`
+
+`requests` must be derived from `limits` by dropping the last numeric digit:
+
+| limits | requests |
+|--------|----------|
+| `cpu: 100m` | `cpu: 10m` |
+| `cpu: 200m` | `cpu: 20m` |
+| `cpu: 500m` | `cpu: 50m` |
+| `cpu: 1` | `cpu: 100m` |
+| `cpu: 2` | `cpu: 200m` |
+| `cpu: 3` | `cpu: 300m` |
+| `cpu: 4` | `cpu: 400m` |
+| `cpu: 8` | `cpu: 800m` |
+| `memory: 128Mi` | `memory: 12Mi` |
+| `memory: 256Mi` | `memory: 25Mi` |
+| `memory: 512Mi` | `memory: 51Mi` |
+| `memory: 1024Mi` | `memory: 102Mi` |
+| `memory: 2G` | `memory: 200Mi` |
+| `memory: 4G` | `memory: 400Mi` |
+| `memory: 8G` | `memory: 800Mi` |
+| `memory: 16G` | `memory: 1600Mi` |
+
+**Default lightweight application quota:**
 
-All containers in application Deployments or StatefulSets must have resource quotas configured:
+```yaml
+resources:
+  requests:
+    cpu: 20m
+    memory: 25Mi
+  limits:
+    cpu: 200m
+    memory: 256Mi
+```
+
+**Standard backend or broker quota after validation:**
 
 ```yaml
-containers:
-  - name: ${{ defaults.app_name }}
-    image: example/app:1.0.0
-    imagePullPolicy: IfNotPresent
-    resources:
-      requests:
-        cpu: 100m      # Minimum CPU request (required)
-        memory: 128Mi  # Minimum memory request (required)
-      limits:
-        cpu: 500m      # CPU upper limit (required)
-        memory: 512Mi  # Memory upper limit (required)
+resources:
+  requests:
+    cpu: 50m
+    memory: 51Mi
+  limits:
+    cpu: 500m
+    memory: 512Mi
 ```
 
-**Quota setting guidelines**:
-
-1. **Lightweight frontend applications** (static file serving, simple web applications):
-   ```yaml
-   resources:
-     requests:
-       cpu: 20m
-       memory: 25Mi
-     limits:
-       cpu: 200m
-       memory: 256Mi
-   ```
-
-2. **Standard backend applications** (API services, medium-load applications):
-   ```yaml
-   resources:
-     requests:
-       cpu: 100m
-       memory: 256Mi
-     limits:
-       cpu: 1000m
-       memory: 1Gi
-   ```
-
-3. **Heavy-load applications** (AI processing, video processing, big data processing):
-   ```yaml
-   resources:
-     requests:
-       cpu: 500m
-       memory: 512Mi
-     limits:
-       cpu: 2000m
-       memory: 2Gi
-   ```
-
-4. **AI/Machine Learning applications** (requiring GPU or large computational resources):
-   ```yaml
-   resources:
-     requests:
-       cpu: 1000m
-       memory: 1Gi
-     limits:
-       cpu: 4000m
-       memory: 4Gi
-   ```
-
-**Quota setting explanation**:
-
-- **requests (request values)**: The minimum resources guaranteed for the container
-  - CPU uses `m` units (1000m = 1 CPU core)
-  - Memory uses `Mi` or `Gi` units
-  - Recommendation: Set requests to 70-80% of actual usage
-
-- **limits (limit values)**: The maximum resources the container can use
-  - CPU can burst up to the limit value
-  - Memory exceeding the limit will trigger OOM Kill
-  - Recommendation: Set limits to 2-4 times the requests
-
-**Golden rules for quota settings**:
-
-1. **Always set both requests and limits**
-   - Incorrect: Setting only requests may lead to resource starvation
-   - Incorrect: Setting only limits may cause scheduling failures
-   - Correct: Setting both guarantees performance and stability
-
-2. **Reasonable requests/limits ratio**
-   - CPU: limits can be 2-10 times the requests (CPU is compressible)
-   - Memory: limits should be 1.5-2 times the requests (memory is incompressible)
-
-3. **Adjust based on application type**
-   - Compute-intensive: Increase CPU quota
-   - Memory-intensive: Increase memory quota
-   - I/O-intensive: Balance CPU and memory
-
-4. **Monitor and adjust**
-   - Use conservative quotas for initial deployment
-   - Monitor actual resource usage
-   - Dynamically adjust based on monitoring data
-
-**Comparison examples**:
+**Heavy workload quota:**
 
 ```yaml
-# Incorrect: No resource limits
-containers:
-  - name: app
-    image: app:1.0.0
-    imagePullPolicy: IfNotPresent
-
-# Incorrect: Only requests
-containers:
-  - name: app
-    image: app:1.0.0
-    imagePullPolicy: IfNotPresent
-    resources:
-      requests:
-        cpu: 100m
-        memory: 128Mi
-
-# Incorrect: Only limits
-containers:
-  - name: app
-    image: app:1.0.0
-    imagePullPolicy: IfNotPresent
-    resources:
-      limits:
-        cpu: 500m
-        memory: 512Mi
-
-# Correct: Both requests and limits are present
-containers:
-  - name: app
-    image: app:1.0.0
-    imagePullPolicy: IfNotPresent
-    resources:
-      requests:
-        cpu: 100m
-        memory: 128Mi
-      limits:
-        cpu: 500m
-        memory: 512Mi
+resources:
+  requests:
+    cpu: 200m
+    memory: 200Mi
+  limits:
+    cpu: 2
+    memory: 2G
 ```
 
+**Invalid examples:**
+
+```yaml
+# Incorrect: non-ladder values
+resources:
+  requests:
+    cpu: 30m
+    memory: 160Mi
+  limits:
+    cpu: 300m
+    memory: 384Mi
+
+# Incorrect: requests copied from old ratio guidance instead of deriving from limits
+resources:
+  requests:
+    cpu: 100m
+    memory: 256Mi
+  limits:
+    cpu: 1
+    memory: 1024Mi
+
+# Incorrect: decimal G form is not the canonical 1G-class ladder value
+resources:
+  requests:
+    cpu: 100m
+    memory: 100Mi
+  limits:
+    cpu: 1
+    memory: 1G
+```
+
+**Tuning guidance:**
+
+1. Move only between allowed `limits` ladder values.
+2. Recompute `requests` from the selected `limits`; do not preserve old requests.
+3. If a StatefulSet fails readiness at a lower resource tier, recreate or cleanly roll the Pod before testing the next tier so a stale non-ready Pod is not mistaken for the next tier's result.
+4. Choose the lowest tier that becomes Ready and passes application-level probes.
+
 ## Image Configuration Specification
 
 ### Image Pull Policy