Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Formatting fixes to release notes #1778

Merged
merged 1 commit into from
Nov 20, 2024
+9 −10
Merged

Formatting fixes to release notes #1778

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 5 additions & 5 deletions calico-enterprise_versioned_docs/version-3.19-2/release-notes/index.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -110,17 +110,17 @@
* Calico panics if kube-proxy or other components are using native `nftables` rules instead of the `iptables-nft` compatibility shim. Until Calico supports native nftables mode, we recommend that you continue to use the iptables-nft compatibility layer for all components. (The compatibility layer was the only option before Kubernetes v1.29 added alpha-level `nftables` support.) Do not run Calico in "legacy" iptables mode on a system that is also using `nftables`. Although this combination does not panic or fail (at least on kernels that support both), the interaction between `iptables` "legacy" mode and `nftables` is confusing: both `iptables` and `nftables` rules can be executed on the same packet, leading to policy verdicts being "overturned".
* When a tier order is set to the maximum float value (1.7976931348623157e+308), this can cause policy re-ordering in the UI not to work properly. Since the `namespace-isolation` tier has this value by default, policy recommendation users are affected. To workaround this issue edit any tier that has this value for the order. For example: use `kubectl edit tier namespace-isolation` and set the order to `10000`.
* Linseed deployment needs to be manually restarted after an upgrade. Without a restart, Linseed can't ingest data because it can't authenticate with Elastic.
<li>
<li>
Some application layer features are not working as expected for $[prodname] installations with the following deployment types:
<ul>
<li>AKS clusters with Azure CNI for networking and $[prodname] for network policy</li>
<li>RKE2 clusters installed with Rancher UI</li>
</ul>
</ul>
During installation, for these deployment types, <code>kubeletVolumePluginPath</code> is set to <code>None</code> in the Installation CR, causing all application layer features to stop working.
The affected features include web application firewalls, application layer policies, and L7 logging.
As a workaround, you can restore the default value by running the following command on an affected cluster:
<CodeBlock language='bash'>{`kubectl patch installation.tigera.io default --type=merge -p '{"spec":{"kubeletVolumePluginPath":"/var/lib/kubelet"}}'`}</CodeBlock>
</li>
<CodeBlock language='bash'>{`kubectl patch installation.tigera.io default --type=merge -p '{"spec":{"kubeletVolumePluginPath":"/var/lib/kubelet"}}'`}</CodeBlock>

Check failure on line 122 in calico-enterprise_versioned_docs/version-3.19-2/release-notes/index.mdx

View workflow job for this annotation

GitHub Actions / runner / vale 

[vale] reported by reviewdog 🐶
[Vale.Terms] Use 'Tigera' instead of 'tigera'.

Raw Output:
{"message": "[Vale.Terms] Use 'Tigera' instead of 'tigera'.", "location": {"path": "calico-enterprise_versioned_docs/version-3.19-2/release-notes/index.mdx", "range": {"start": {"line": 122, "column": 59}}}, "severity": "ERROR"}
</li>

## Updating

Expand All @@ -130,7 +130,7 @@

:::

* ***Breaking change***: Upgrading from Calico Enterprise 3.18 or earlier $[prodname] will alter the UID of all `projectcalico.org/v3` resources.
* ***Breaking change:*** Upgrading from Calico Enterprise 3.18 or earlier $[prodname] will alter the UID of all `projectcalico.org/v3` resources.

Check failure on line 133 in calico-enterprise_versioned_docs/version-3.19-2/release-notes/index.mdx

View workflow job for this annotation

GitHub Actions / runner / vale 

[vale] reported by reviewdog 🐶
[Vale.Spelling] Did you really mean 'prodname'?

Raw Output:
{"message": "[Vale.Spelling] Did you really mean 'prodname'?", "location": {"path": "calico-enterprise_versioned_docs/version-3.19-2/release-notes/index.mdx", "range": {"start": {"line": 133, "column": 77}}}, "severity": "ERROR"}
If you're using the Calico API server, you must restart any controllers, including `kube-controller-manager`, that manage these resources after the upgrade.
This change addresses an issue where duplicate UIDs on different API resources could disrupt Kubernetes garbage collection.

Expand Down
9 changes: 4 additions & 5 deletions calico-enterprise_versioned_docs/version-3.20-2/release-notes/index.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -115,18 +115,17 @@
* *Multi-cluster management users only*. If the `manager-tls` and `internal-manager-tls` secrets have overlapping DNS names, components such as `es-calico-kube-controllers` will log certificate errors. If you have previously installed a version older than v3.13.0 and never changed your manager-tls secret from the tigera-operator namespace, you must delete both of these secrets. This applies to you if the following command prints a certificate: `$ kubectl get secret manager-tls -n tigera-operator -o "jsonpath={.data['cert']}"`.
* Upgrading to $[prodname] 3.18.0 on Rancher/RKE from $[prodname] 3.13.0 currently requires manually terminating the calico-node container for an upgrade to proceed.
* Calico panics if kube-proxy or other components are using native `nftables` rules instead of the `iptables-nft` compatibility shim. Until Calico supports native nftables mode, we recommend that you continue to use the iptables-nft compatibility layer for all components. (The compatibility layer was the only option before Kubernetes v1.29 added alpha-level `nftables` support.) Do not run Calico in "legacy" iptables mode on a system that is also using `nftables`. Although this combination does not panic or fail (at least on kernels that support both), the interaction between `iptables` "legacy" mode and `nftables` is confusing: both `iptables` and `nftables` rules can be executed on the same packet, leading to policy verdicts being "overturned".
<li>
<li>
Some application layer features are not working as expected for $[prodname] installations with the following deployment types:
<ul>
<li>AKS clusters with Azure CNI for networking and $[prodname] for network policy</li>
<li>RKE2 clusters installed with Rancher UI</li>
<li>AKS clusters with Azure CNI for networking and $[prodname] for network policy</li>

Check failure on line 121 in calico-enterprise_versioned_docs/version-3.20-2/release-notes/index.mdx

View workflow job for this annotation

GitHub Actions / runner / vale 

[vale] reported by reviewdog 🐶
[Vale.Spelling] Did you really mean 'prodname'?

Raw Output:
{"message": "[Vale.Spelling] Did you really mean 'prodname'?", "location": {"path": "calico-enterprise_versioned_docs/version-3.20-2/release-notes/index.mdx", "range": {"start": {"line": 121, "column": 56}}}, "severity": "ERROR"}
<li>RKE2 clusters installed with Rancher UI</li>
</ul>
During installation, for these deployment types, <code>kubeletVolumePluginPath</code> is set to <code>None</code> in the Installation CR, causing all application layer features to stop working.
The affected features include web application firewalls, application layer policies, and L7 logging.
As a workaround, you can restore the default value by running the following command on an affected cluster:
<CodeBlock language='bash'>{`kubectl patch installation.tigera.io default --type=merge -p '{"spec":{"kubeletVolumePluginPath":"/var/lib/kubelet"}}'`}</CodeBlock>
</li>

</li>
* When using eBPF mode with kernels older than 5.17 you may need to set `bpfDNSPolicyMode` to `NoDelay` in the `FelixConfiguration` to avoid a possible crash loop. Some distributions using kernel version < 5.17 may work depending on which backports are present in that kernel. For instance Ubuntu kernels 5.15+ and RH kernels 5.14+ have the necessary capabilities.

## Updating
Expand Down
Binary file added calicoctl
View file
Open in desktop
Binary file not shown.
Loading