From a27f437f9a0410918e1d394cabd274a8f2282a0c Mon Sep 17 00:00:00 2001 From: Chris Tauchen Date: Mon, 12 Oct 2026 16:31:48 +0100 Subject: [PATCH] DOCS-3052: Hold Fluent Bit and the eBPF v5.17 kernel back from Calico Cloud next --- calico-cloud/_includes/components/ReqsSys.js | 2 +- calico-cloud/get-started/cc-arch-diagram.mdx | 6 +- .../get-started/operator-checklist.mdx | 28 ++++---- .../observability/elastic/archive-storage.mdx | 31 ++------- .../elastic/dns/filtering-dns.mdx | 57 +++++++-------- .../observability/elastic/flow/filtering.mdx | 69 +++++++++---------- .../observability/elastic/overview.mdx | 18 +++-- calico-cloud/observability/kube-audit.mdx | 2 +- calico-cloud/observability/packetcapture.mdx | 10 +-- calico-cloud/operations/comms/index.mdx | 24 +++---- .../operations/ebpf/enabling-ebpf.mdx | 19 ++--- .../elasticsearch-and-fluentd-metrics.mdx | 36 ++++------ .../monitor/prometheus/byo-prometheus.mdx | 56 +++++++++------ .../configure-resources.mdx | 28 +++----- 14 files changed, 172 insertions(+), 214 deletions(-) diff --git a/calico-cloud/_includes/components/ReqsSys.js b/calico-cloud/_includes/components/ReqsSys.js index de88780dab..be8e5b7f0b 100644 --- a/calico-cloud/_includes/components/ReqsSys.js +++ b/calico-cloud/_includes/components/ReqsSys.js @@ -308,7 +308,7 @@ function NetworkRequirementsEnt(props) { Logs and storage - Elasticsearch log storage + Elasticsearch with fluentd datastore TCP 9200 (default) diff --git a/calico-cloud/get-started/cc-arch-diagram.mdx b/calico-cloud/get-started/cc-arch-diagram.mdx index f42b18fc0b..9955c7c2ec 100644 --- a/calico-cloud/get-started/cc-arch-diagram.mdx +++ b/calico-cloud/get-started/cc-arch-diagram.mdx @@ -31,8 +31,8 @@ The following diagram shows the major components in a managed cluster, followed | $[prodname] installer | Gets installation resources from the $[prodname] portal, registers a managed cluster, and reports installation or upgrade progress. | • TCP 443 to $[prodname] hosted service
• TCP 6443 to Kubernetes API server | | $[prodname] tunnel server | Communicates with managed clusters by creating secure TLS tunnels. | Port 9000 from managed clusters | | calico-node | Bundles key components that are required for networking containers with $[prodname]:

• Felix
• BIRD
• confd | • TCP 5473 to Typha
• TCP 9900 and 9081 from Prometheus API service | -| Compliance | Generates compliance reports for the Kubernetes cluster. Reports are based on archived flow and audit logs for Calico Cloud resources, plus any audit logs you’ve configured for Kubernetes resources in the Kubernetes API server. Compliance reports provide the following high-level information:

• Endpoints explicitly protected using ingress or egress policy
• Policies and services
- Policies and services associated with endpoints
- Policy audit logs
• Traffic
- Allowed ingress/egress traffic to/from namespaces, and to/from the internet Compliance includes these components:

**compliance-snapshotter**
Handles listing of required Kubernetes and $[prodname] configuration and pushes snapshots to Elasticsearch. Snapshots give you visibility into configuration changes, and how the cluster-wide configuration has evolved within a reporting interval.

**compliance-reporter**
Handles report generation. Reads configuration history from Elasticsearch and determines time evolution of cluster-wide configuration, including relationships between policies, endpoints, services, and network sets. Data is then passed through a zero-trust aggregator to determine the “worst-case outliers” in the reporting interval.

**compliance-controller**
Reads report configuration and manages creation, deletion, and monitoring of report generation jobs.

**compliance-benchmarker**
A DaemonSet that runs checks in the CIS Kubernetes Benchmark on each node so you can see if Kubernetes is securely deployed.
| • TCP 8080 to Guardian
• TCP 6443 to Kubernetes API server | -| Fluent Bit | Open-source, lightweight log processor and forwarder. Collects and forwards $[prodname] logs (flows, DNS, L7) to log storage. | • TCP 8080 to Guardian
• TCP 2020 from Prometheus API service | +| Compliance | Generates compliance reports for the Kubernetes cluster. Reports are based on archived flow and audit logs for Calico Cloud resources, plus any audit logs you’ve configured for Kubernetes resources in the Kubernetes API server. Compliance reports provide the following high-level information:

• Endpoints explicitly protected using ingress or egress policy
• Policies and services
- Policies and services associated with endpoints
- Policy audit logs
• Traffic
- Allowed ingress/egress traffic to/from namespaces, and to/from the internet Compliance includes these components:

**compliance-snapshotter**
Handles listing of required Kubernetes and $[prodname]configuration and pushes snapshots to Elasticsearch. Snapshots give you visibility into configuration changes, and how the cluster-wide configuration has evolved within a reporting interval.

**compliance-reporter**
Handles report generation. Reads configuration history from Elasticsearch and determines time evolution of cluster-wide configuration, including relationships between policies, endpoints, services, and network sets. Data is then passed through a zero-trust aggregator to determine the “worst-case outliers” in the reporting interval.

**compliance-controller**
Reads report configuration and manages creation, deletion, and monitoring of report generation jobs.

**compliance-benchmarker**
A daemonset that runs checks in the CIS Kubernetes Benchmark on each node so you can see if Kubernetes is securely deployed.
| • TCP 8080 to Guardian
• TCP 6443 to Kubernetes API server | +| Fluentd | Open-source data collector for unified logging. Collects and forwards $[prodname] logs (flows, DNS, L7) to log storage. | • TCP 8080 to Guardian
• TCP 9080 from Prometheus API service | | Guardian | An agent running in each managed cluster that proxies communication between the $[prodname] tunnel server and your managed cluster. Secured using TLS tunnels.
| • Port 9000 to tunnel server
• TCP 6443 to Kubernetes API server
• TCP 6443 from $[prodname] components | | Installation endpoints | Endpoints at `*.calicocloud.io` and `*.projectcalico.org`. | TCP 443 for both | | Intrusion detection controller | Handles integrations with threat intelligence feeds and $[prodname] custom alerts. | • TCP 8080 to Guardian
• TCP 6443 to Kubernetes API server | @@ -40,7 +40,7 @@ The following diagram shows the major components in a managed cluster, followed | kube-controllers | Monitors the Kubernetes API and performs actions based on cluster state. $[prodname] kube-controllers container includes these controllers:

• Node
• Service
• Federated services
• Authorization
| • TCP 9094 from Prometheus API service
• TCP 6443 to Kubernetes API server | | Log storage | Storage for logs (flows, L7, DNS, audit). Data for each managed cluster is isolated and protected against unauthorized access. | n/a | | Packet capture API | Retrieves capture files (pcap format) generated by a packet capture for use with network protocol analysis tools like Wireshark. Packet capture data is visible in the web console and Service Graph. | • TCP 8449 Guardian to Packet Capture API
• TCP 6443 to Kubernetes API server | -| Prometheus API service | Collects metrics from $[prodname] components and makes the metrics available to the web console. | • TCP 6443 to Kubernetes API server
• TCP 2020 to Fluent Bit
• TCP 9900 and 9081 to Prometheus API service | +| Prometheus API service | Collects metrics from $[prodname] components and makes the metrics available to the web console. | • TCP 6443 to Kubernetes API server
• TCP 9080 to Fluentd
• TCP 9900 and 9081 to Prometheus API service | | Tigera API server | Allows users to manage $[prodname] resources such as policies and tiers through kubectl or the Kubernetes API server. | • TCP 9095 to Prometheus API service
• TCP 8080 from Kubernetes API server | | Typha | Increases scale by reducing each node’s impact on the datastore. | TCP 5473 from calico-node to Typha | | User access to the web console | Authenticated users can access the browser-based the web console, which provides network traffic visibility and troubleshooting, centralized multi-cluster management, threat-defense, policy lifecycle management, and compliance for multiple roles/stakeholders. | Port 443 to $[prodname] tunnel server | \ No newline at end of file diff --git a/calico-cloud/get-started/operator-checklist.mdx b/calico-cloud/get-started/operator-checklist.mdx index 268b7a359f..381a323f8e 100644 --- a/calico-cloud/get-started/operator-checklist.mdx +++ b/calico-cloud/get-started/operator-checklist.mdx @@ -82,7 +82,7 @@ If you are using the **AWS or Azure CNI plugin**, a degraded state is likely bec **Sample output** -In the following example, the `typha` component has an issue because it is showing `AVAILABLE: FALSE`, and `DEGRADED: TRUE`. To understand details of $[prodname] components, see [Deep dive into custom resources](#deep-dive-into-custom-resources). +In the following example, the typha component has an issue because it is showing `AVAILABLE: FALSE`, and `DEGRADED: TRUE`. To understand details of $[prodname] components, see [Deep dive into custom resources](#deep-dive-into-custom-resources). ```yaml apiVersion: v1 @@ -387,9 +387,9 @@ kubectl get tigerastatus | 7 | management-cluster-connection | TRUE | FALSE | FALSE | 9m54s | | 8 | monitor | TRUE | FALSE | FALSE | 11m | -**1 - API server** +**1 - api server** -`apiserver` is a required component that is an aggregated API server. It is required for things like applying the Tigera license. If `tigerastatus` reports it as unavailable or degraded, check the pods and logs in the `calico-system` namespace. For example, +`apiserver` is a required component that is an aggregated api-server. It is required for things like applying the tigera license. If `tigerastatus` reports it as unavailable or degraded, check the pods and logs in the `calico-system`namespace. For example, ```bash kubectl get pods -n calico-system @@ -470,19 +470,19 @@ intrusion-detection-es-job-installer-xm22v 1/1 Running 0 6 **6 - log-collector** -`log-collector` collects flow and other logs and forwards them to $[prodname]. Check the `calico-fluent-bit` pods and logs in the `calico-system` namespace. You should have one pod running on each of your nodes. +`log-collector` collects flow and other logs and forwards them to $[prodname]. Check the pods and logs in the `tigera-fluentd` namespace. You should have one pod running on each of your nodes. ```bash -kubectl get pods -n calico-system -l k8s-app=calico-fluent-bit +kubectl get pods -n tigera-fluentd ``` ``` -NAME READY STATUS RESTARTS AGE -calico-fluent-bit-5mzh6 1/1 Running 0 70m -calico-fluent-bit-7vmxw 1/1 Running 0 70m -calico-fluent-bit-bbc4p 1/1 Running 0 70m -calico-fluent-bit-chfz4 1/1 Running 0 70m -calico-fluent-bit-d6f56 1/1 Running 0 70m +NAME READY STATUS RESTARTS AGE +fluentd-node-5mzh6 1/1 Running 0 70m +fluentd-node-7vmxw 1/1 Running 0 70m +fluentd-node-bbc4p 1/1 Running 0 70m +fluentd-node-chfz4 1/1 Running 0 70m +fluentd-node-d6f56 1/1 Running 0 70m ``` **7 - management-cluster-connection** @@ -534,7 +534,7 @@ cmEtdm9sdHJvbjAeFw0yMDEyMjExOTA1MzhaFw0yNTEyMjAxOTA1MzhaMBkxFzAV **8 - monitor** -`monitor` is responsible for configuring Prometheus and associated custom resources. Check the pods and logs in the `tigera-prometheus` namespace. +`monitor` is responsible for configuring prometheus and associated custom resources. Check the pods and logs in the `tigera-prometheus` namespace. ```bash $ kubectl get pods -n tigera-prometheus @@ -607,8 +607,8 @@ If cluster does not have enough capacity, it will not be able to deploy pods. Th The high-level components $[prodname] needs to run are: -- Per node: 1 `fluent-bit`, 1 `compliance-benchmarker` -- On top of per node: 3 `alertmanager` (from StatefulSet), 1 `prometheus`, 1 `prometheus` operator, 1 kube-controllers, 2 compliance snapshotter and controller, 1 guardian, 1 ids controller, 1 `apiserver` +- Per node: 1 fluentd, 1 compliance benchmarker +- On top of per node: 3 alertmanager (from statefulset), 1 prometheus, 1 prometheus operator, 1 kube-controllers, 2 compliance snapshotter and controller, 1 guardian, 1 ids controller, 1 apiserver Some clusters have limited pod-networked pod capacity. diff --git a/calico-cloud/observability/elastic/archive-storage.mdx b/calico-cloud/observability/elastic/archive-storage.mdx index a2f23db14e..2082c6140c 100644 --- a/calico-cloud/observability/elastic/archive-storage.mdx +++ b/calico-cloud/observability/elastic/archive-storage.mdx @@ -71,29 +71,6 @@ Because $[prodname] and Kubernetes logs are integral to $[prodname] diagnostics, kubectl edit logcollector tigera-secure ``` - $[prodname] writes one directory per log type under `bucketPath`, and names each object - for the UTC day it covers: - - ``` - /flows/20260101_.gz - /dns/20260101_.gz - /l7/20260101_.gz - /audit_kube/20260101_.gz - /audit_tsee/20260101_.gz - ``` - - Flow logs from non-cluster hosts are archived under `non_cluster_flows/` instead of - being mixed into `flows/`. - - :::note - - If you are upgrading from a release that collected logs with Fluentd, these keys have - changed. Fluentd wrote flat keys with the date concatenated onto the log type, as in - `/flows20260101_1.gz`. Update any downstream tooling that matches the old - pattern. - - ::: - @@ -111,8 +88,8 @@ Because $[prodname] and Kubernetes logs are integral to $[prodname] diagnostics, syslog: # (Required) Syslog endpoint, in the format protocol://host:port endpoint: tcp://1.2.3.4:514 - # (Optional) Maximum message size in bytes. Defaults to 2048. - packetSize: 2048 + # (Optional) If messages are being truncated set this field + packetSize: 1024 # (Required) Types of logs to forward to Syslog (must specify at least one option) logTypes: - Audit @@ -158,8 +135,8 @@ Because $[prodname] and Kubernetes logs are integral to $[prodname] diagnostics, syslog: # (Required) Syslog endpoint, in the format protocol://host:port endpoint: tcp://1.2.3.4:514 - # (Optional) Maximum message size in bytes. Defaults to 2048. - packetSize: 2048 + # (Optional) If messages are being truncated set this field + packetSize: 1024 # (Optional) To Configure TLS mode encryption: TLS # (Required) Types of logs to forward to Syslog (must specify at least one option) diff --git a/calico-cloud/observability/elastic/dns/filtering-dns.mdx b/calico-cloud/observability/elastic/dns/filtering-dns.mdx index 6127246f09..6705170172 100644 --- a/calico-cloud/observability/elastic/dns/filtering-dns.mdx +++ b/calico-cloud/observability/elastic/dns/filtering-dns.mdx @@ -1,5 +1,5 @@ --- -description: Suppress low-value Calico Cloud DNS log entries with Fluent Bit filters configured through a ConfigMap in the operator namespace of connected clusters. +description: Suppress low-value Calico Cloud DNS log entries with Fluentd filters configured through a ConfigMap in the operator namespace of connected clusters. --- # Filter DNS logs @@ -7,22 +7,6 @@ description: Suppress low-value Calico Cloud DNS log entries with Fluent Bit fil $[prodname] supports filtering out DNS logs based on user provided configuration. Use filtering to suppress logs of low significance. -## Before you begin - -**Required** - -If you already filter DNS logs, migrate your filters before you upgrade. Earlier releases collected logs with Fluentd and read filters written in Fluentd `` syntax from a ConfigMap named `fluentd-filters`. $[prodname] now collects logs with Fluent Bit, which does not read that ConfigMap and cannot translate Fluentd syntax. Rewrite each filter as a Fluent Bit filter list using the steps on this page, and create it in a ConfigMap named `fluent-bit-filters`. - -Until you do, $[prodname] ships DNS logs unfiltered, which increases your log volume and storage costs. If a key in `fluent-bit-filters` is not valid Fluent Bit YAML, $[prodname] skips that key, keeps shipping unfiltered logs, and reports a warning naming the key: - -```bash -kubectl get tigerastatus log-collector -o yaml -``` - -**Limitations** - -Filters apply to logs collected from Linux nodes. The Windows log collector does not read them. - ## Configure DNS filtering DNS log filtering is configured through a ConfigMap in the `tigera-operator` @@ -34,35 +18,46 @@ To enable DNS log filtering, follow these steps: your desired filter using [Filter configuration files](#filter-configuration-files). If you are also adding [flow filters](../flow/filtering.mdx) also add the `flow` file to the directory. -1. Create the `fluent-bit-filters` ConfigMap in the `tigera-operator` namespace +1. Create the `fluentd-filters` ConfigMap in the `tigera-operator` namespace with the following command. ```bash - kubectl create configmap fluent-bit-filters -n tigera-operator --from-file=filters + kubectl create configmap fluentd-filters -n tigera-operator --from-file=filters ``` -The operator inserts the filters inline into the log collector configuration and rolls the -`calico-fluent-bit` DaemonSet automatically. - ## Filter configuration files -Each file holds a YAML list of [Fluent Bit filter](https://docs.fluentbit.io/manual/data-pipeline/filters/) entries. The `calico-fluent-bit` log collector ships four Fluent Bit filters — [`grep`](https://docs.fluentbit.io/manual/data-pipeline/filters/grep), [`record_modifier`](https://docs.fluentbit.io/manual/data-pipeline/filters/record-modifier), [`parser`](https://docs.fluentbit.io/manual/data-pipeline/filters/parser), and [`lua`](https://docs.fluentbit.io/manual/data-pipeline/filters/lua) — and no others. The examples below use `grep`. Filters in the `dns` file are applied to DNS logs automatically; you do not need to set a `match` on each entry. For the fields you can filter on, see the [DNS log schema](dns-logs.mdx). +The filters defined by the ConfigMap are inserted into the fluentd configuration file. +The [upstream fluentd documentation](https://docs.fluentd.org/filter/grep) +describes how to write fluentd filters. The [DNS log schema](dns-logs.mdx) can be referred to +for the specification of the various fields you can filter based on. Remember to ensure +that the config file is properly indented in the ConfigMap. ## Example 1: filter out cluster-internal lookups This example filters out lookups for domain names ending with ".cluster.local". More -logs could be filtered by adjusting the regular expression, or by adding -additional `exclude` rules. +logs could be filtered by adjusting the regular expression "pattern", or by adding +additional `exclude` blocks. -```yaml -- name: grep - exclude: qname \.cluster\.local$ +``` + + @type grep + + key qname + pattern /\.cluster\.local$/ + + ``` ## Example 2: keep logs only for particular domain names This example will filter out all logs _except_ those for domain names ending `.co.uk`. -```yaml -- name: grep - regex: qname \.co\.uk$ +``` + + @type grep + + key qname + pattern /\.co\.uk$/ + + ``` diff --git a/calico-cloud/observability/elastic/flow/filtering.mdx b/calico-cloud/observability/elastic/flow/filtering.mdx index df713fdedc..15738b32c8 100644 --- a/calico-cloud/observability/elastic/flow/filtering.mdx +++ b/calico-cloud/observability/elastic/flow/filtering.mdx @@ -1,5 +1,5 @@ --- -description: Filter Calico Cloud flow logs through Fluent Bit to drop low-significance traffic and reduce managed Elasticsearch volume and cost. +description: Filter Calico Cloud flow logs through Fluentd to drop low-significance traffic and reduce managed Elasticsearch volume and cost. --- # Filter flow logs @@ -46,22 +46,6 @@ reporter packetsIn packetsOut bytesIn bytesOut action - Aggregated names (such as “pod prefix”), are noted by `*` at the end of the name - If `srcName` or `dstName` fields contain only a `*`, aggregation was performed using other means (such as specific labels), and no unique prefix was present. -## Before you begin - -**Required** - -If you already filter flow logs, migrate your filters before you upgrade. Earlier releases collected logs with Fluentd and read filters written in Fluentd `` syntax from a ConfigMap named `fluentd-filters`. $[prodname] now collects logs with Fluent Bit, which does not read that ConfigMap and cannot translate Fluentd syntax. Rewrite each filter as a Fluent Bit filter list using the steps on this page, and create it in a ConfigMap named `fluent-bit-filters`. - -Until you do, $[prodname] ships flow logs unfiltered, which increases your log volume and storage costs. If a key in `fluent-bit-filters` is not valid Fluent Bit YAML, $[prodname] skips that key, keeps shipping unfiltered logs, and reports a warning naming the key: - -```bash -kubectl get tigerastatus log-collector -o yaml -``` - -**Limitations** - -Filters apply to logs collected from Linux nodes. The Windows log collector does not read them. - ## How to - [Create flow log filters](#create-flow-log-filters) @@ -69,43 +53,56 @@ Filters apply to logs collected from Linux nodes. The Windows log collector does ### Create flow log filters -Filters are written as a YAML list of [Fluent Bit filter](https://docs.fluentbit.io/manual/data-pipeline/filters/) entries. The `calico-fluent-bit` log collector ships four Fluent Bit filters — [`grep`](https://docs.fluentbit.io/manual/data-pipeline/filters/grep), [`record_modifier`](https://docs.fluentbit.io/manual/data-pipeline/filters/record-modifier), [`parser`](https://docs.fluentbit.io/manual/data-pipeline/filters/parser), and [`lua`](https://docs.fluentbit.io/manual/data-pipeline/filters/lua) — and no others. Filters you add under the `flow` key are applied to flow logs automatically; you do not need to set a `match` on each entry. +Create your [fluentd filters](https://docs.fluentd.org/filter/grep). **Example: filter out a specific namespace** -This example filters out all flow logs whose source or destination namespace is `dev`. A record is dropped when it matches any of the `exclude` rules; additional namespaces could be filtered by adjusting the regular expressions, or by adding more `exclude` rules. +This example filters out all flow logs whose source or destination namespace is "dev". Additional namespaces could be filtered by adjusting the regular expression "pattern"s, or by adding additional `exclude` blocks. -```yaml -- name: grep - exclude: - - source_namespace dev - - dest_namespace dev +``` + + @type grep + + key source_namespace + pattern dev + + + key dest_namespace + pattern dev + + ``` **Example: filter out internet traffic to a specific deployment** -This example filters inbound internet traffic to the deployment with pods named, `nginx-internet-*`. Note the use of `logical_op: and` to filter out only the traffic that is both to the deployment, and from the internet (source `pub`). +This example filters inbound internet traffic to the deployment with pods named, `nginx-internet-*`. Note the use of the `and` directive to filter out traffic that is both to the deployment, and from the internet (source `pub`). -```yaml -- name: grep - logical_op: and - exclude: - - dest_name_aggr ^nginx-internet - - source_name_aggr pub +``` + + @type grep + + + key dest_name_aggr + pattern ^nginx-internet + + + key source_name_aggr + pattern pub + + + ``` ### Add filters to ConfigMap file -1. Create a `filters` directory with a file called `flow` with your desired filters. If you are also adding [DNS filters](../dns/filtering-dns.mdx), add the `dns` file to the directory. +1. Create a `filters` directory with a file called `flow` with your desired filters. If you are also adding [dns filters](../dns/filtering-dns.mdx), add the `dns` file to the directory. -1. Create the `fluent-bit-filters` ConfigMap in the `tigera-operator` namespace with the following command. +1. Create the `fluentd-filters` ConfigMap in the `tigera-operator` namespace with the following command. ```bash - kubectl create configmap fluent-bit-filters -n tigera-operator --from-file=filters + kubectl create configmap fluentd-filters -n tigera-operator --from-file=filters ``` -The operator inserts the filters inline into the log collector configuration and rolls the `calico-fluent-bit` DaemonSet automatically. - ## Additional resources - [Flow log aggregation](aggregation.mdx) diff --git a/calico-cloud/observability/elastic/overview.mdx b/calico-cloud/observability/elastic/overview.mdx index 2a5a74b3c7..3d7812b309 100644 --- a/calico-cloud/observability/elastic/overview.mdx +++ b/calico-cloud/observability/elastic/overview.mdx @@ -29,25 +29,23 @@ Elasticsearch logs provide the visibility and troubleshooting backend for $[prod | Log type | Description | Log source | RBAC | Index | | -------- | ---------------------------------------------------------------------------------------------- | ------------------------------------------- | ------------ | ----------------------------- | -| `flow` | Network flows for workloads: source and destination namespaces, pods, labels, and policies | $[prodname] cnx-node (Felix) | `flows` | `tigera_secure_ee_flows` | -| `audit` | Audit logs for $[prodname] resources | $[prodname] API server | `audit_ee` | `tigera_secure_ee_audit_ee` | -| | Audit logs for Kubernetes resources | Kubernetes API server | `audit_kube` | `tigera_secure_ee_audit_kube` | +| flow | Network flows for workloads: source and destination namespaces, pods, labels, and policies | $[prodname] cnx-node (Felix) | `flows` | `tigera_secure_ee_flows` | +| audit | Audit logs for $[prodname] resources | $[prodname] apiserver | `audit_ee` | `tigera_secure_ee_audit_ee` | +| | Audit logs for Kubernetes resources | Kubernetes apiserver | `audit_kube` | `tigera_secure_ee_audit_kube` | | | | Both audit logs above | `audit*` | `tigera_secure_ee_audit*` | -| `bgp` | $[prodname] networking BGP peering and route propagation | $[prodname] cnx-node (BIRD) | `ee_bgp` | `tigera_secure_ee_bgp.*` | -| `dns` | DNS lookups and responses from $[prodname] domain-based policy | $[prodname] cnx-node (Felix) | `ee_dns` | `tigera_secure_ee_dns` | -| `ids` | $[prodname] intrusion detection events: suspicious IPs, suspicious domains, and global alerts | $[prodname] intrusion-detection-controller | `ee_events` | `tigera_secure_ee_events` | +| bgp | $[prodname] networking BGP peering and route propagation | $[prodname] cnx-node (BIRD) | `ee_bgp` | `tigera_secure_ee_bgp.*` | +| dns | DNS lookups and responses from $[prodname] domain-based policy | $[prodname] cnx-node (Felix) | `ee_dns` | `tigera_secure_ee_dns` | +| ids | $[prodname] intrusion detection events: suspicious IPs, suspicious domains, and global alerts | $[prodname] intrusion-detection-controller | `ee_events` | `tigera_secure_ee_events` | :::note -Because of their high-volume, flow and DNS logs support aggregation. +Because of their high-volume, flow and dns logs support aggregation. ::: ### Default log configuration and security -$[prodname] automatically installs Fluent Bit on all nodes and collects flow, audit, and DNS logs. You can configure additional destinations like Amazon S3, Syslog, Splunk. - -Fluent Bit buffers logs on each node's filesystem, under `/var/log/calico/calico-fluent-bit/storage`, so chunks that have not been delivered yet survive a log collector restart. Each destination gets its own buffer with its own cap: 500 MB for flow logs and for each additional destination, and 100 MB for each of the other log types. Account for that disk usage when you size your nodes. Fluent Bit retries a chunk until it is delivered, so a destination that stays unreachable long enough to fill its buffer starts losing data for that destination only; the others keep shipping. +$[prodname] automatically installs fluentd on all nodes and collects flow, audit, and DNS logs. You can configure additional destinations like Amazon S3, Syslog, Splunk. $[prodname] enables user authentication in Elasticsearch, and secures access to Elasticsearch using network policy. diff --git a/calico-cloud/observability/kube-audit.mdx b/calico-cloud/observability/kube-audit.mdx index 2f7ab95941..87ee4998fb 100644 --- a/calico-cloud/observability/kube-audit.mdx +++ b/calico-cloud/observability/kube-audit.mdx @@ -84,7 +84,7 @@ rules: The following updates require a restart to the Kubernetes API Server. -To enable Kubernetes resource audit logs to be read by the $[prodname] Fluent Bit log collector, follow these steps. +To enable Kubernetes resource audit logs to be read by $[prodname] in fluentd, follow these steps. On the Kubernetes API Server, update these flags. diff --git a/calico-cloud/observability/packetcapture.mdx b/calico-cloud/observability/packetcapture.mdx index 88006d9dee..e99031de8e 100644 --- a/calico-cloud/observability/packetcapture.mdx +++ b/calico-cloud/observability/packetcapture.mdx @@ -12,7 +12,7 @@ Capture live traffic inside a Kubernetes cluster, and export to visualization to $[prodname] packet capture is implemented in a Kubernetes-native way so you can troubleshoot service/application connectivity issues and performance issues. You can start a packet capture in the web console Service Graph, or using the CLI. -Packet capture integration with **Service Graph** makes it very easy to capture traffic for a specific namespace, service, ReplicaSet, DaemonSet, StatefulSet, or pod. Just right-click on an endpoint to start or schedule a capture, and then download capture files to your favorite visualization tool like Wireshark. +Packet capture integration with **Service Graph** makes it very easy to capture traffic for a specific namespace, service, replica set, daemonset, statefulset, or pod. Just right-click on an endpoint to start or schedule a capture, and then download capture files to your favorite visualization tool like Wireshark. With $[prodname] packet capture you can: @@ -79,7 +79,7 @@ EOF ### Packet capture in Service Graph -1. Select an endpoint from the service graph (for example, namespace, service, ReplicaSet, DaemonSet, StatefulSet, or pod), right-click, and select **Initiate packet capture**. +1. Select an endpoint from the service graph (for example, namespace, service, replica set, daemonset, statefulset, or pod), right-click, and select **Initiate packet capture**. ![start-capture](/img/calico-enterprise/start-capture.png) @@ -226,19 +226,19 @@ status: Get the pod on the node with the packet capture that you want. ```bash -kubectl get pods -n calico-system -l k8s-app=calico-node --no-headers --field-selector spec.nodeName="" +kubectl get pods -n tigera-fluentd --no-headers --field-selector spec.nodeName="" ``` Copy the packet capture using the pod information. ```bash -kubectl cp calico-system/:var/log/calico/pcap/sample/sample-capture/ . +kubectl cp tigera-fluentd/:var/log/calico/pcap/sample/sample-capture/ . ``` **Delete packet capture files** ```bash -kubectl exec -it -n calico-system -- sh -c "rm -r /var/log/calico/pcap/sample/sample-capture/" +kubectl exec -it tigera-fluentd/ -- sh -c "rm -r /var/log/calico/pcap/sample/sample-capture/" ``` ### Store and rotate capture files diff --git a/calico-cloud/operations/comms/index.mdx b/calico-cloud/operations/comms/index.mdx index c7e8bda22b..5c0aeee98e 100644 --- a/calico-cloud/operations/comms/index.mdx +++ b/calico-cloud/operations/comms/index.mdx @@ -47,18 +47,18 @@ The **Deployed to** column shows the namespace where the operator places the sec | Secret name | DNS name(s) | Deployed to | Owner resource | |---|---|---|---| -| `calico-apiserver-certs` | `calico-api` | `calico-system` | `APIServer/tigera-secure` | -| `calico-kube-controllers-metrics-tls` | `calico-kube-controllers-metrics` | `calico-system` | `Installation/default` | -| `calico-node-prometheus-client-tls` | `calico-node-prometheus-client-tls` | `tigera-prometheus` | `Monitor/tigera-secure` | -| `calico-node-prometheus-server-tls` | `calico-node-metrics` | `calico-system` | `Installation/default` | -| `calico-node-prometheus-tls` | `prometheus-http-api` | `tigera-prometheus` | `Monitor/tigera-secure` | -| `deep-packet-inspection-tls` | `intrusion-detection-tls` | `tigera-dpi` | `IntrusionDetection/tigera-secure` | -| `node-certs` | `typha-client` | `calico-system` | `Installation/default` | -| `node-certs` | `typha-client` | `tigera-dpi` | `IntrusionDetection/tigera-secure` | -| `tigera-ee-elasticsearch-metrics-tls` | `tigera-elasticsearch-metrics` | `tigera-elasticsearch` | `LogStorage/tigera-secure` | -| `calico-fluent-bit-tls` | `calico-fluent-bit-http-input` | `calico-system` | `LogCollector/tigera-secure` | -| `typha-certs` | `typha-server` | `calico-system` | `Installation/default` | -| `typha-certs-noncluster-host` | `typha-server-noncluster-host` | `calico-system` | `Installation/default` | +| `calico-apiserver-certs` | `calico-api` | `calico-system` | APIServer/tigera-secure | +| `calico-kube-controllers-metrics-tls` | `calico-kube-controllers-metrics` | `calico-system` | Installation/default | +| `calico-node-prometheus-client-tls` | `calico-node-prometheus-client-tls` | `tigera-prometheus` | Monitor/tigera-secure | +| `calico-node-prometheus-server-tls` | `calico-node-metrics` | `calico-system` | Installation/default | +| `calico-node-prometheus-tls` | `prometheus-http-api` | `tigera-prometheus` | Monitor/tigera-secure | +| `deep-packet-inspection-tls` | `intrusion-detection-tls` | `tigera-dpi` | IntrusionDetection/tigera-secure | +| `node-certs` | `typha-client` | `calico-system` | Installation/default | +| `node-certs` | `typha-client` | `tigera-dpi` | IntrusionDetection/tigera-secure | +| `tigera-ee-elasticsearch-metrics-tls` | `tigera-elasticsearch-metrics` | `tigera-elasticsearch` | LogStorage/tigera-secure | +| `tigera-fluentd-prometheus-tls` | `fluentd-http-input` | `tigera-fluentd` | LogCollector/tigera-secure | +| `typha-certs` | `typha-server` | `calico-system` | Installation/default | +| `typha-certs-noncluster-host` | `typha-server-noncluster-host` | `calico-system` | Installation/default | :::tip diff --git a/calico-cloud/operations/ebpf/enabling-ebpf.mdx b/calico-cloud/operations/ebpf/enabling-ebpf.mdx index 225299edc3..4c0f463653 100644 --- a/calico-cloud/operations/ebpf/enabling-ebpf.mdx +++ b/calico-cloud/operations/ebpf/enabling-ebpf.mdx @@ -28,9 +28,9 @@ eBPF (or "extended Berkeley Packet Filter"), is a technology that allows safe mi - arm64 (little-endian) - Linux distribution/kernel: - - Ubuntu 24.04 or above, or Ubuntu 22.04 with the HWE kernel (the 22.04 GA kernel, v5.15, is too old). - - Red Hat Enterprise Linux 9 or above (kernel v5.14; Red Hat has backported the required features to that build). - - Another supported distribution with Linux kernel v5.17 or above. {/*TODO-XREFS-CC */} + - Ubuntu 22.04 or above. + - Red Hat v8.4 with Linux kernel v4.18.0-305 or above (Red Hat have backported the required features to that build). + - Another supported distribution with Linux kernel v5.10 or above. {/*TODO-XREFS-CC */} - Immutable operating systems (e.g., Talos Linux): Ensure the `CgroupV2Path` in the `FelixConfiguration` CRD is set to a writable path. #### Kernel version requirements for eBPF features @@ -39,13 +39,14 @@ Some eBPF features require a higher kernel version than the base eBPF data plane | Feature | Minimum kernel version | Details | |---|---|---| -| Base eBPF data plane | v5.17 (RHEL: v5.14) | Required by all eBPF features | +| Base eBPF data plane | v5.10 (RHEL: v4.18.0-305) | CO-RE supported at this version for better performance | +| Log rules in eBPF mode | v5.16 | Logs sent to trace pipe via `bpftool prog tracelog` | | [QoS bandwidth controls](../../networking/configuring/qos-controls.mdx) | v6.6 | Requires `tcx` support. Established connection limits not supported with eBPF | | [DNS policy inline mode](../../network-policy/domain-based-policy.mdx) | v5.17 (RHEL: v5.14) | `BPFDNSPolicyMode: Inline` parses DNS responses in eBPF before they reach the application. Only wildcard prefixes (`*.x.y.z`) supported. Falls back to `NoDelay` on older kernels | :::warning -The minimum kernel version required for the eBPF data plane is v5.17 (RHEL: v5.14). $[prodname] uses [CO-RE (Compile Once - Run Everywhere)](https://docs.ebpf.io/concepts/core/), which improves compatibility and performance across kernel versions. For access to all eBPF features, we recommend kernel v6.6 or above. +The minimum kernel version required for the eBPF data plane is v5.10, which includes support for [CO-RE (Compile Once - Run Everywhere)](https://docs.ebpf.io/concepts/core/). CO-RE significantly improves compatibility and performance across kernel versions. For access to all eBPF features, we recommend kernel v6.6 or above. ::: @@ -108,18 +109,18 @@ uname -rv The output should look like this: ``` -6.8.0-45-generic #45~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Wed Sep 11 15:25:05 UTC 2024 +5.10.0-26-generic #28~20.04.1-Ubuntu SMP Fri Jan 27 14:30:10 UTC 2023 ``` -In this case the kernel version is v6.8, which is suitable. +In this case the kernel version is v5.10, which is suitable. On Red Hat-derived distributions, you may see something like this: ``` -5.14.0-427.13.1.el9_4.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Apr 10 10:29:16 EDT 2024 +4.18.0-305.el8.x86_64 (mockbuild@x86-vm-08.build.eng.bos.redhat.com) ``` -Since this is a RHEL 9 kernel (v5.14), it is suitable. +Since the Red Hat kernel is v4.18 with at least build number 305 (RHEL 8.4), this kernel is suitable. ### Configure $[prodname] to talk directly to the API server diff --git a/calico-cloud/operations/monitor/metrics/elasticsearch-and-fluentd-metrics.mdx b/calico-cloud/operations/monitor/metrics/elasticsearch-and-fluentd-metrics.mdx index 5edc4b6222..842f83e06b 100644 --- a/calico-cloud/operations/monitor/metrics/elasticsearch-and-fluentd-metrics.mdx +++ b/calico-cloud/operations/monitor/metrics/elasticsearch-and-fluentd-metrics.mdx @@ -1,12 +1,12 @@ --- -description: Track Calico Cloud Fluent Bit metrics in Prometheus to alert on flow, DNS, and audit log collection disruptions on connected clusters. +description: Track Calico Cloud Fluentd metrics in Prometheus to alert on flow, DNS, and audit log collection disruptions on connected clusters. --- -# Fluent Bit metrics +# Fluentd metrics ## Big picture -Use the Prometheus monitoring and alerting tool for Fluent Bit metrics to ensure continuous network visibility. +Use the Prometheus monitoring and alerting tool for Fluentd metrics to ensure continuous network visibility. ## Value @@ -16,14 +16,14 @@ Platform engineering teams rely on logs for visibility into their networks. If c | Component | Description | | ---------- | ------------------------------------------------------------ | -| Prometheus | Monitoring tool that scrapes metrics from instrumented jobs and displays time series data in a visualizer (such as Grafana). For $[prodname], the “jobs” that Prometheus can harvest metrics from the Fluent Bit component. | -| Fluent Bit | Ships $[prodname] logs to the log storage backend. | +| Prometheus | Monitoring tool that scrapes metrics from instrumented jobs and displays time series data in a visualizer (such as Grafana). For $[prodname], the “jobs” that Prometheus can harvest metrics from the Fluentd component. | +| Fluentd | Sends $[prodname] logs to Elasticsearch for storage. | ## How to -### Create Prometheus alerts for Fluent Bit +### Create Prometheus alerts for Fluentd -The following example creates a Prometheus rule to monitor some important Fluent Bit metrics, and alert when they have crossed certain thresholds: +The following example creates a Prometheus rule to monitor some important Fluentd metrics, and alert when they have crossed certain thresholds: ```yaml noValidation apiVersion: monitoring.coreos.com/v1 @@ -38,28 +38,18 @@ spec: groups: - name: tigera-log-collection.rules rules: - - alert: FluentBitPodConsistentlyLowBufferSpace - expr: avg_over_time(fluentbit_output_chunk_available_capacity_percent[5m]) < 75 + - alert: FluentdPodConsistentlyLowBufferSpace + expr: avg_over_time(fluentd_output_status_buffer_available_space_ratio[5m]) < 75 labels: severity: Warning annotations: - summary: "Fluent Bit pod {{$labels.pod}}'s output buffer space is consistently below 75 percent capacity." - description: "Fluent Bit pod {{$labels.pod}} has very low buffer space for output {{$labels.name}}. There may be -connection issues between Fluent Bit and the log destination, or there are too many logs to write out; check the logs -for the Fluent Bit pod." - - alert: FluentBitPodDroppingLogs - expr: rate(fluentbit_output_retries_failed_total[5m]) > 0 - labels: - severity: Warning - annotations: - summary: "Fluent Bit pod {{$labels.pod}} is dropping log chunks." - description: "Fluent Bit pod {{$labels.pod}} gave up retrying to deliver log chunks for output {{$labels.name}}. -Logs are being lost; check the logs for the Fluent Bit pod and the health of the log destination." + summary: "Fluentd pod {{$labels.pod}}'s buffer space is consistently below 75 percent capacity." + description: "Fluentd pod {{$labels.pod}} has very low buffer space. There may be connection issues between Elasticsearch +and Fluentd or there are too many logs to write out, check the logs for the Fluentd pod." ``` #### The alerts created in the example are described as follows: | Alert | Severity | Requires | Issue/reason | | ---------------------------------------- | --------------------- | -------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| **FluentBitPodConsistentlyLowBufferSpace** | Non-critical, warning | Immediate investigation to ensure logs are being gathered correctly. | A Fluent Bit pod’s available output buffer capacity has averaged less than 75% over the last 5 minutes.

This could mean Fluent Bit is having trouble communicating with a log destination, the destination is down, or there are simply too many logs to process. | -| **FluentBitPodDroppingLogs** | Non-critical, warning | Immediate investigation to ensure logs are not being lost. | A Fluent Bit pod exhausted the retries for one or more log chunks and dropped them. | +| **FluentdPodConsistentlyLowBufferSpace** | Non-critical, warning | Immediate investigation to ensure logs are being gathered correctly. | A Fluentd pod’s available buffer size has averaged less than 75% over the last 5 minutes.

This could mean Fluentd is having trouble communicating with the Elasticsearch cluster, the Elasticsearch cluster is down, or there are simply too many logs to process. | diff --git a/calico-cloud/operations/monitor/prometheus/byo-prometheus.mdx b/calico-cloud/operations/monitor/prometheus/byo-prometheus.mdx index 1222745062..4dd7c62153 100644 --- a/calico-cloud/operations/monitor/prometheus/byo-prometheus.mdx +++ b/calico-cloud/operations/monitor/prometheus/byo-prometheus.mdx @@ -15,12 +15,12 @@ Scrape $[prodname] metrics for Bring Your Own (BYO) Prometheus. $[prodname] uses the Prometheus monitoring tool to scrape metrics from instrumented jobs, and displays time-series data in a visualizer such as Grafana. You can scrape the following time-series metrics for $[prodname] components to your own Prometheus: -- `elasticsearch` -- `fluent-bit` -- `calico-node` -- `kube-controllers` -- `felix` -- `typha` (not enabled by default) +- elasticsearch +- fluentd +- calico-node +- kube-controllers +- felix +- typha (not enabled by default) ## Before you begin @@ -41,7 +41,7 @@ For the supported version of Prometheus in this release, see the [Release Notes] In this section we create a service monitor that scrapes all enabled metrics. To enable metrics that are not enabled by default, please consult the [next section](#scrape-metrics-from-specific-components-directly). -The following example shows a Prometheus server installed in namespace `external-prometheus` with a `serviceMonitorSelector` that selects all service monitors with the label `k8s-app=tigera-external-prometheus`. +The following example shows a Prometheus server installed in namespace "external-prometheus" with a `serviceMonitorSelector` that selects all service monitors with the label `k8s-app=tigera-external-prometheus`. 1. Save the following configuration in a file called `monitor.yaml`. @@ -123,12 +123,33 @@ kubectl apply -f $[filesUrl_CE]/manifests/prometheus/elasticsearch-metrics-servi The .yamls have no namespace defined so when you apply `kubectl`, it is applied in the $NAMESPACE. - + -**Create the service monitor** +**Configure TLS certificates** + +1. Copy the required secret and configmap to your namespace. +2. Save the manifest of the required TLS secret and CA configmap. + + ```bash + kubectl get secret calico-node-prometheus-client-tls -n tigera-prometheus -o yaml > calico-node-prometheus-client-tls.yaml + ``` -Fluent Bit serves its metrics over plain HTTP (port 2020, path `/api/v2/metrics/prometheus`), so no TLS -configuration is required. + ```bash + kubectl get configmap -n tigera-prometheus tigera-ca-bundle -o yaml > tigera-ca-bundle.yaml + ``` + +3. Edit `calico-node-prometheus-client-tls.yaml` and `tigera-ca-bundle.yaml` and change the namespace to the namespace where your prometheus instance is running. +4. Apply the manifests to your cluster. + + ```bash + kubectl apply -f calico-node-prometheus-client-tls.yaml + ``` + + ```bash + kubectl apply -f tigera-ca-bundle.yaml + ``` + +**Create the service monitor** Apply the ServiceMonitor to the namespace where Prometheus is running. @@ -137,20 +158,11 @@ export NAMESPACE= ``` ```bash -kubectl apply -f $[filesUrl_CE]/manifests/prometheus/fluent-bit-metrics-service-monitor.yaml -n $NAMESPACE +kubectl apply -f $[filesUrl_CE]/manifests/prometheus/fluentd-metrics-service-monitor.yaml -n $NAMESPACE ``` The .yamls have no namespace defined so when you apply `kubectl`, it is applied in the $NAMESPACE. -:::note - -Access to the Fluent Bit metrics port is restricted by the `calico-system.allow-calico-fluent-bit` network policy, -which by default admits only the $[prodname] Prometheus pods in the `tigera-prometheus` namespace. Create a policy -that allows your BYO Prometheus pods to reach port 2020 on the `calico-fluent-bit` pods (see -[Create policy to secure traffic between pods](#create-policy-to-secure-traffic-between-pods)). - -::: - @@ -349,7 +361,7 @@ The .yamls have no namespace defined so when you apply `kubectl`, it is applied kubectl port-forward pod/byo-prometheus-pod 9090:9090 -n $NAMESPACE ``` -1. Browse to the Prometheus dashboard: `http://localhost:9090`. +1. Browse to the Prometheus dashboard: http://localhost:9090. 1. In the Expression text box, enter your metric name and click the **Execute** button. diff --git a/calico-cloud/reference/component-resources/configure-resources.mdx b/calico-cloud/reference/component-resources/configure-resources.mdx index d415e5a359..646748356a 100644 --- a/calico-cloud/reference/component-resources/configure-resources.mdx +++ b/calico-cloud/reference/component-resources/configure-resources.mdx @@ -550,36 +550,30 @@ This command will output the configured resource requests and limits for the Int ## LogCollector custom resource -The [LogCollector](../../reference/installation/api.mdx#logcollector) CR provides a way to configure resources for CalicoFluentBitDaemonSet, EKSLogForwarderDeployment. +The [LogCollector](../../reference/installation/api.mdx#logcollector) CR provides a way to configure resources for FluentdDaemonSet, EKSLogForwarderDeployment. -### CalicoFluentBitDaemonSet. +### FluentdDaemonSet. -To configure resource specification for the [CalicoFluentBitDaemonSet](../../reference/installation/api.mdx#logcollector), patch the LogCollector CR using the below command: +To configure resource specification for the [FluentdDaemonSet](../../reference/installation/api.mdx#fluentddaemonset), patch the LogCollector CR using the below command: ```bash -kubectl patch logcollector tigera-secure --type=merge --patch='{"spec": {"calicoFluentBitDaemonSet":{"spec": {"template": {"spec": {"containers":[{"name":"calico-fluent-bit","resources":{"limits":{"cpu":"1", "memory":"1000Mi"},"requests":{"cpu":"100m", "memory":"100Mi"}}}]}}}}}}' +kubectl patch logcollector tigera-secure --type=merge --patch='{"spec": {"fluentdDaemonSet":{"spec": {"template": {"spec": {"containers":[{"name":"fluentd","resources":{"limits":{"cpu":"1", "memory":"1000Mi"},"requests":{"cpu":"100m", "memory":"100Mi"}}}]}}}}}}' ``` This command sets the CPU request to 100 milliCPU (mCPU) and the memory request is set to 100 Mebibytes (MiB) while the CPU limit is set to 1 CPU and the memory limit is set to 1000 Mebibytes (MiB). -:::note - -`fluentdDaemonSet` is a deprecated alias for `calicoFluentBitDaemonSet`, retained for one release so that overrides written for the Fluentd log collector keep working. Over the same period, the container name `fluentd` is accepted as an alias for `calico-fluent-bit`, and `tigera-fluentd-prometheus-tls-key-cert-provisioner` for `calico-fluent-bit-tls-key-cert-provisioner`. If you set both fields, `calicoFluentBitDaemonSet` takes precedence. Move your overrides to the new field and container names. - -::: - #### Verification You can verify the configured resources using the following command: ```bash -kubectl get daemonset.apps/calico-fluent-bit -n calico-system -o json | jq '.spec.template.spec.containers[] | {name: .name, resources: .resources}' +kubectl get daemonset.apps/fluentd-node -n tigera-fluentd -o json | jq '.spec.template.spec.containers[] | {name: .name, resources: .resources}' ``` -This command will output the configured resource requests and limits for the CalicoFluentBitDaemonSet in JSON format. +This command will output the configured resource requests and limits for the FluentdDaemonSet in JSON format. ```bash { - "name": "calico-fluent-bit", + "name": "fluentd", "resources": { "limits": { "cpu": "1", @@ -603,18 +597,12 @@ kubectl patch logcollector tigera-secure --type=merge --patch='{"spec": {"eksLo ``` This command sets the CPU request to 100 milliCPU (mCPU) and the memory request is set to 100 Mebibytes (MiB) while the CPU limit is set to 1 CPU and the memory limit is set to 1000 Mebibytes (MiB). -:::note - -The deployment runs a single container, `eks-log-forwarder`. Releases that collected logs with Fluentd also ran an `eks-log-forwarder-startup` init container; overrides that target that init container by name no longer apply. - -::: - #### Verification You can verify the configured resources using the following command: ```bash -kubectl get deployment.apps/eks-log-forwarder -n calico-system -o json | jq '.spec.template.spec.containers[] | {name: .name, resources: .resources}' +kubectl get deployment.apps/eks-log-forwarder -n tigera-fluentd -o json | jq '.spec.template.spec.containers[] | {name: .name, resources: .resources}' ``` This command will output the configured resource requests and limits for the EKSLogForwarderDeployment in JSON format.