Configure Core HTTPS routing on TKE - #2
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 30f12de45b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| ingress.cloud.tencent.com/auto-rewrite: "true" | ||
| ingress.cloud.tencent.com/rewrite-support: "true" | ||
| kubernetes.io/ingress.rule-mix: "true" | ||
| kubernetes.io/ingress.extensiveParameters: '{"ConnectTimeout":300000,"SendTimeout":900000,"ReadTimeout":900000}' |
There was a problem hiding this comment.
Configure timeouts on the existing listener
When the reused CLB does not already have these timeout values, this annotation will not apply them: Tencent documents kubernetes.io/ingress.extensiveParameters as parameters used only when creating a CLB and says changes after creation are ineffective, while this manifest explicitly selects an existing CLB with existLbId (TKE Ingress annotations). Consequently, long HTTP streams and Runtime WebSocket connections remain subject to the existing listener defaults; configure the listener through a referenced TkeServiceConfig or make the existing-CLB prerequisite explicit instead.
Useful? React with 👍 / 👎.
| kubernetes.io/ingress.extensiveParameters: '{"ConnectTimeout":300000,"SendTimeout":900000,"ReadTimeout":900000}' | ||
| kubernetes.io/ingress.http-rules: "null" | ||
| kubernetes.io/ingress.https-rules: | | ||
| [{"host":"${OAC_PUBLIC_HOST}","path":"/v1","backend":{"serviceName":"oac-core","servicePort":"8091"}}, |
There was a problem hiding this comment.
Derive the ingress hostname from OAC_PUBLIC_URL
If an operator sets OAC_PUBLIC_HOST differently from the hostname in OAC_PUBLIC_URL, the CLB routes only the former while Core advertises and Web accepts only the latter, so either the configured public URL has no matching rule or requests through the ingress are rejected by Web's host check. Avoid this independently configured second copy by deriving the ingress hostname from the canonical public URL, or at minimum validating equality before applying the template.
AGENTS.md reference: AGENTS.md:L46-L46
Useful? React with 👍 / 👎.
Adds a separately applied qcloud Ingress for the Core/Web public origin on an existing CLB, with /v1 and /api/v1 routed to Core and other paths to Web. The Services use NodePort, matching the existing TKE CLB backend mode, so subsequent image deployments preserve working routing.
Only deployment-owned files change. DNS, the managed certificate reference and application settings remain operator configuration; no upstream application or CI code changes.
Validation: rendered host/path rules, git diff --check, Ingress and Service server dry-runs against sandbase-prod, and independent static review. Live validation: qcloud Ingress Ready; public HTTPS Web home and /healthz return 200, /v1/agents returns the Core bearer-key error with 401, and the Runtime WebSocket path reaches its missing-parameters validator with 400. Existing shared-CLB Ingresses remain Ready. TLS verification used the Cloudflare address returned by public DNS because the local resolver returned unrelated addresses. An authenticated Runtime WebSocket session was not executed.