Repository navigation
docs(networking): explain FQDN policy limitations with CNI chaining - #766
Open
Fedor Batonogov (batonogov) wants to merge 1 commit into
Open
Fedor Batonogov (batonogov) wants to merge 1 commit into
Fedor Batonogov (batonogov) wants to merge 1 commit into
Conversation
Signed-off-by: batonogov <[email protected]>
Fedor Batonogov (batonogov)
requested review from
Andrei Kvapil (kvaps),
Timofei Larkin (lllamnyp),
myasnikovdaniil and
Timur Tukaev (tym83)
as code owners
October 21, 2026 14:01
✅ Deploy Preview for cozystack ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Contributor
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configuration
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
myasnikovdaniil
added a commit
that referenced
this pull request
Oct 30, 2026
On the Kube-OVN + Cilium stack Cilium runs chained in generic-veth mode, where its Layer 7 policy, toFQDNs included, is not reliable, and a CiliumNetworkPolicy the API accepts can still do nothing on the dataplane. #766 warns about it and points to a managed Kubernetes cluster with Cilium as its primary CNI, but only in next/ and v1.6/. Both hold for v1.7.0: the kubeovn variant of the cilium package still sets chainingMode: generic-veth, and a tenant Kubernetes cluster always installs Cilium as its CNI. The change is #766's next/ diff with the rewrite release_next.sh applies. next/ and v1.6/ stay with #766. Assisted-By: LLM Signed-off-by: Myasnikov Daniil <[email protected]>
myasnikovdaniil
added a commit
that referenced
this pull request
Oct 30, 2026
On the Kube-OVN + Cilium stack Cilium runs chained in generic-veth mode, where its Layer 7 policy, toFQDNs included, is not reliable, and a CiliumNetworkPolicy the API accepts can still do nothing on the dataplane. #766 warns about it and points to a managed Kubernetes cluster with Cilium as its primary CNI, but only in next/ and v1.6/. Both hold for v1.7.0: the kubeovn variant of the cilium package still sets chainingMode: generic-veth, and a tenant Kubernetes cluster always installs Cilium as its CNI. The change is #766's next/ diff with the rewrite release_next.sh applies. next/ and v1.6/ stay with #766. Assisted-By: LLM Signed-off-by: Myasnikov Daniil <[email protected]>
myasnikovdaniil
added a commit
that referenced
this pull request
Oct 30, 2026
) The v1.7 docs were cut from `next/` in #780 while several docs PRs about v1.7.0 behaviour were still open against `next/` only, so `/docs/v1.7/` and the stable `/docs/` copy miss them. This adds their content to `content/en/docs/v1.7/`, checked against the v1.7.0 tag. Every page is the source PR's `next/` file with the same `/docs/next/` rewrite that `hack/release_next.sh` does, except where noted. - #763 - #747, hand-merged after `networking.kubeovn.MASTER_NODES` because main got the `networking.encryption.enabled` row after its base - #761, with four corrections below - #762 - #766 - #764, the HTTPCache section of the upgrade guide, in both `next/` and `v1.7/` on top of the fixes from #781. I'm not carrying 764 further, this PR takes over its content. Four lines of the Proxmox page are wrong for v1.7.0 and are fixed in the v1.7 copy only. `replicas: 2` in the KubernetesNodes example is now `minReplicas: 2` and `maxReplicas: 2`, there is no `replicas` field. The CCM and CSI controller Deployments are `kubernetes-<cluster>-pccm` and `kubernetes-<cluster>-pcsi-controller`. `bundles.enabledPackages` is set on the `cozystack.cozystack-platform` Package, no ConfigMap feeds it. The CSI release depends only on the tenant Cilium release, not on the CCM, so I cut that clause. The `next/` copy in 761 needs the same fixes. The `next/` side of 763, 747, 761, 762 and 766 and the `v1.6/` side of 763, 762 and 766 stay in their own PRs, so they still merge without conflicts with this one. Nothing generated is committed, the stable `/docs/` copies are built from `v1.7/` at build time. Hugo production and preview builds, `hack/check-i18n.sh` and a link and anchor check of every changed page pass locally, with the same Hugo warnings as main.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The default Kube-OVN + Cilium stack uses generic-veth chaining, whose L7 limitations are not explained on the network architecture page. Users who need both VM networking and FQDN egress policies have no documented placement option.
Document the limitation in v1.6 and next, explain the L3/L4 alternatives, and describe placing affected workloads in a managed Kubernetes cluster with Cilium as the primary CNI while retaining the management cluster's networking. Clarify policy scope, DNS-derived IP enforcement, and the need to test allowed and denied traffic.
Related to cozystack/cozystack#3820. The SecurityGroup API question remains outside this documentation change.
Validation: independent technical, security/anonymization, and documentation reviews; git diff --check; i18n key parity and translation freshness checks; Hugo 0.164.0 preview build and inspection of both generated pages. No deployment-specific identifiers or configuration are included. This PR changes documentation only; it does not validate a live dataplane.