diff --git a/README.md b/README.md index 43544d41db..70554312f2 100644 --- a/README.md +++ b/README.md @@ -87,7 +87,7 @@ All commands support `CONTAINERIZED=true` for Docker-based builds (e.g., `make b ``` docs/ ├── calico/ # Calico OSS — next (unreleased) version -├── calico_versioned_docs/ # Calico OSS — released versions (3.29 through 3.32) +├── calico_versioned_docs/ # Calico OSS — released versions (3.30 through 3.32) ├── calico-enterprise/ # Enterprise — next (unreleased) version ├── calico-enterprise_versioned_docs/ # Enterprise — released versions (3.21-2 through 3.24-1) ├── calico-cloud/ # Cloud — next (unreleased) version @@ -237,7 +237,6 @@ make show_current_branches # Example output: # Calico branch targets: # * calico__operator_reference -# * calico_versioned_docs/version-3.29__operator_reference # * calico_versioned_docs/version-3.30__operator_reference # * calico_versioned_docs/version-3.31__operator_reference # * calico_versioned_docs/version-3.32__operator_reference diff --git a/calico_versioned_docs/version-3.29/_includes/components/AutoHostendpointsMigrate.js b/calico_versioned_docs/version-3.29/_includes/components/AutoHostendpointsMigrate.js deleted file mode 100644 index 2fa83d4362..0000000000 --- a/calico_versioned_docs/version-3.29/_includes/components/AutoHostendpointsMigrate.js +++ /dev/null @@ -1,65 +0,0 @@ -import React from 'react'; - -import Admonition from '@theme/Admonition'; -import Link from '@docusaurus/Link'; -import CodeBlock from '@theme/CodeBlock'; -import Heading from '@theme/Heading'; - -import { prodname, baseUrl } from '../../variables'; - -export default function AutoHostendpointsMigrate(props) { - return ( - <> - - Migrating to auto host endpoints - - - Auto host endpoints have an allow-all profile attached which allows all traffic in the absence of network - policy. This may result in unexpected behavior and data. - -

In order to migrate existing all-interfaces host endpoints to {prodname}-managed auto host endpoints:

-
    -
  1. -

    - Add any labels on existing all-interfaces host endpoints to their corresponding {props.orch} nodes.{' '} - {prodname} manages labels on automatic host endpoints by syncing labels from their nodes. Any labels on - existing all-interfaces host endpoints should be added to their respective nodes. For example, if your - existing all-interface host endpoint for node node1 has the label{' '} - environment: dev, then you must add that same label to its node: -

    - - {props.orch === 'OpenShift' - ? 'oc label node node1 environment=dev' - : 'kubectl label node node1 environment=dev'} - -
    2. -
  2. -

    - Enable auto host endpoints by following the{' '} - - enable automatic host endpoints how-to guide - - . Note that automatic host endpoints are created with a profile attached that allows all traffic in the - absence of network policy. -

    - - calicoctl patch kubecontrollersconfiguration default --patch = - {'{"spec": {"controllers": {"node": {"hostEndpoint": {"autoCreate": "Enabled"}}}}}'} - -
    3. -
  3. -

    - Delete old all-interfaces host endpoints. You can distinguish host endpoints managed by {prodname} from - others in several ways. First, automatic host endpoints have the label{' '} - projectcalico.org/created-by: calico-kube-controllers. Secondly, automatic host - endpoints' name have the suffix -auto-hep. -

    - calicoctl delete hostendpoint <old_hostendpoint_name> -
    4. -
- - ); -} diff --git a/calico_versioned_docs/version-3.29/_includes/components/CalicoWindowsInstall.js b/calico_versioned_docs/version-3.29/_includes/components/CalicoWindowsInstall.js deleted file mode 100644 index d9dbc524a1..0000000000 --- a/calico_versioned_docs/version-3.29/_includes/components/CalicoWindowsInstall.js +++ /dev/null @@ -1,196 +0,0 @@ -import React from 'react'; - -import Admonition from '@theme/Admonition'; -import CodeBlock from '@theme/CodeBlock'; -import Link from '@docusaurus/Link'; - -import { prodname, prodnameWindows } from '../../variables'; - -function CalicoWindowsInstallFirstStep(props) { - if (props.networkingType === 'vxlan') { - return ( - <> -
  • - Ensure that cross-subnet encapsulation is disabled. You must use VXLAN and NOT VXLANCrossSubnet - as the encapsulation: of your IP pool. Use this command to change it if you only have one IP pool configured: -
    -
    - - {`kubectl patch installation default --type='json' -p='[{"op": "replace", "path": "/spec/calicoNetwork/ipPools/0/encapsulation", "value": "VXLAN"}]`} - -
    • -
  • - Ensure that BGP is disabled. - -
    • - - ); - } - - return ( -
  • -

    - Enable BGP service on the Windows nodes. Install the RemoteAccess service using the following Powershell - commands: -

    - - Install-WindowsFeature RemoteAccess{'\n'} - Install-WindowsFeature RSAT-RemoteAccess-PowerShell - {'\n'} - Install-WindowsFeature Routing - -

    Then restart the computer:

    - Restart-Computer -Force -

    before running:

    - Install-RemoteAccess -VpnType RoutingOnly -

    - Sometimes the remote access service fails to start automatically after install. To make sure it is running, run - the following command: -

    - Start-Service RemoteAccess -
    • - ); -} - -export default function CalicoWindowsInstall(props) { - return ( -
      - -
    1. -

      - Get the cluster's Kubernetes API server host and port, which will be used to update the {prodnameWindows}{' '} - config map. The API server host and port is required so that the {prodnameWindows} installation script can - create a kubeconfig file for {prodname} services. If your Windows nodes already have {prodnameWindows}{' '} - installed manually, skip this step. The installation script will use the API server host and port from your - node's existing kubeconfig file if the KUBERNETES_SERVICE_HOST and{' '} - KUBERNETES_SERVICE_PORT variables are not provided in the calico-windows-config{' '} - ConfigMap. -

      -

      First, make a note of the address of the API server:

      -
        -
      • -

        - If you have a single API server with a static IP address, you can use its IP address and port. The IP can - be found by running: -

        - kubectl get endpoints kubernetes -o wide -

        The output should look like the following, with a single IP address and port under "ENDPOINTS":

        - - {`NAME ENDPOINTS AGE -kubernetes 172.16.101.157:6443 40m`} - -

        - If there are multiple entries under "ENDPOINTS", then your cluster must have more than one API server. In - this case, use the appropriate load balancing option below for your cluster. -

        -
        • -
      • -

        - If using DNS load balancing (as used by kops), use the FQDN and port of the API server{' '} - - api.internal.{'<'}clustername{'>'} - - . -

        -
        • -
      • -

        - If you have multiple API servers with a load balancer in front, you should use the IP and port of the load - balancer. -

        -
        • - -

        - If your cluster uses a ConfigMap to configure kube-proxy you can find the "right" way to - reach the API server by examining the config map. For example: -

        - - kubectl get configmap -n kube-system kube-proxy -o yaml | grep server{'\n'} - server: https://d881b853ae312e00302a84f1e346a77.gr7.us-west-2.eks.amazonaws.com - -

        - In this case, the server is d881b853aea312e00302a84f1e346a77.gr7.us-west-2.eks.amazonaws.com{' '} - and the port is 443 (the standard HTTPS port). -

        -         -
      -
      2. -
    2. -

      - Create the kubernetes-services-endpoint ConfigMap with the Kubernetes API server - host and port (discovered in the previous step) used to create a kubeconfig file for {prodname} services. - {`kubectl apply -f - << EOF -kind: ConfigMap -apiVersion: v1 -metadata: - name: kubernetes-services-endpoint - namespace: tigera-operator -data: - KUBERNETES_SERVICE_HOST: "$\{APISERVER_ADDR\}" - KUBERNETES_SERVICE_PORT: "$\{APISERVER_PORT\}" -EOF`} - -

      -
      3. -
    3. -

      - Get the Kubernetes service clusterIP range configured in your cluster. This must - match the service-cluster-ip-range used by kube-apiserver. -

      -
      4. -
    4. -

      - Add the Kubernetes service CIDR (discovered in the previous step) enable {prodnameWindows} on the Tigera Operator installation resource. -

      -

      - For example, with a Kubernetes service clusterIP range of 10.96.0.0/12: - {`kubectl patch installation default --type merge --patch='{"spec": {"serviceCIDRs": ["10.96.0.0/12"], "calicoNetwork": {"windowsDataplane": "HNS"}}}'`} -

      -
      5. -
    5. - Install kube-proxy on Windows nodes. -

      - Depending on your platform, you may already have kube-proxy running on your Windows nodes. If kube-proxy is - already running on your Windows nodes, skip this step. If kube-proxy is not running, you must install and run - kube-proxy on each of the Windows nodes in your cluster. Note: The - manifest provided in the kubernetes-sigs sig-windows-tools repository depends on the kubeconfig - provided by the kube-proxy ConfigMap in the kube-system namespace. -

      -

      - You must replace KUBE_PROXY_VERSION with your cluster's Kubernetes version in kube-proxy.yml to ensure the daemonset uses a kube-proxy Windows image that is compatible with your Kubernetes cluster. Use a command like the following to retrieve the YAML file, replace the version, and apply it: - {`curl -L https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/hostprocess/calico/kube-proxy/kube-proxy.yml | sed "s/KUBE_PROXY_VERSION/\/g" | kubectl apply -f -`} -

      -
      6. -
    6. -

      Monitor the installation.

      - The {prodnameWindows} HPC installation has 2 initContainers: uninstall-calico, which deals with removing previous manually installed {prodnameWindows} services, if any - and install-cni, which installs needed CNI binaries and configuration, when using Calico CNI. - - kubectl logs -f -n calico-system -l k8s-app=calico-node-windows -c uninstall-calico{'\n'} - kubectl logs -f -n calico-system -l k8s-app=calico-node-windows -c install-cni{'\n'} - -

      - After these initContainers finish their execution, installation is complete. Next, the - {prodnameWindows} services are started in separate containers: -

      - - kubectl logs -f -n calico-system -l k8s-app=calico-node-windows -c node{'\n'} - kubectl logs -f -n calico-system -l k8s-app=calico-node-windows -c felix{'\n'} - {props.networkingType === 'windows-bgp' - ? `kubectl logs -f -n calico-system -l k8s-app=calico-node-windows -c confd` - : null} - -

      - The calico-node-windows pods will be ready after their containers finish initializing. -

      -
      7. -
    - ); -} diff --git a/calico_versioned_docs/version-3.29/_includes/components/ComponentVersions.js b/calico_versioned_docs/version-3.29/_includes/components/ComponentVersions.js deleted file mode 100644 index f32c20bdae..0000000000 --- a/calico_versioned_docs/version-3.29/_includes/components/ComponentVersions.js +++ /dev/null @@ -1,64 +0,0 @@ -import React from 'react'; -import Link from '@docusaurus/Link'; -import Heading from '@theme/Heading'; - -import { toKebab } from '@site/src/components/utils/formatters'; - -import variables from '../../variables'; - -export default function ComponentVersions() { - const { prodname, version, downloadsurl } = variables; - - const releases = variables.releases.map((release) => { - return release; - }).filter(release => release); - - return ( - <> - {releases.map((release) => ( -
    - - Component versions for {variables.prodname} {release.title.startsWith('v') ? release.title.substring(1) : release.title} - -

    - {release.title !== 'master' && ( -

    - - Release archive - {' '} - with Kubernetes manifests. -

    - )} - This release comprises the following components, and can be installed using{' '} - - {release['tigera-operator'].registry}/{release['tigera-operator'].image}: - {release['tigera-operator'].version} - -

    - - - - - - - - - {Object.keys(release.components).map((componentName) => ( - - - - - ))} - -
    ComponentVersion
    {componentName}{release.components[componentName].version}
    -
    - ))} - - ); -} diff --git a/calico_versioned_docs/version-3.29/_includes/components/DownloadOpenShiftManifests.js b/calico_versioned_docs/version-3.29/_includes/components/DownloadOpenShiftManifests.js deleted file mode 100644 index 5489e91f97..0000000000 --- a/calico_versioned_docs/version-3.29/_includes/components/DownloadOpenShiftManifests.js +++ /dev/null @@ -1,17 +0,0 @@ -import React from 'react'; - -import CodeBlock from '@theme/CodeBlock'; - -import { prodname, releaseTitle, calicoReleasesURL } from '../../variables'; - -export default function DownloadOpenShiftManifests() { - return ( - <> -

    Download the {prodname} manifests for OpenShift:

    - - {`mkdir calico -wget -qO- ${calicoReleasesURL}/${releaseTitle}/ocp.tgz | tar xvz --strip-components=1 -C calico`} - - - ); -} diff --git a/calico_versioned_docs/version-3.29/_includes/components/EnvironmentFile.js b/calico_versioned_docs/version-3.29/_includes/components/EnvironmentFile.js deleted file mode 100644 index cdeecc20ee..0000000000 --- a/calico_versioned_docs/version-3.29/_includes/components/EnvironmentFile.js +++ /dev/null @@ -1,201 +0,0 @@ -import React from 'react'; - -import Admonition from '@theme/Admonition'; -import CodeBlock from '@theme/CodeBlock'; -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; -import Link from '@docusaurus/Link'; - -import { prodname, baseUrl } from '../../variables'; - -export default function EnvironmentFile(props) { - if (props.target === 'felix') { - var etcd_endpoints = 'FELIX_ETCDENDPOINTS'; - var etcd_cert_file = 'FELIX_ETCDCERTFILE'; - var etcd_key_file = 'FELIX_ETCDKEYFILE'; - var etcd_ca_file = 'FELIX_ETCDCAFILE'; - var datastore_type = 'FELIX_DATASTORETYPE'; - } else { - var etcd_endpoints = 'ETCD_ENDPOINTS'; - var etcd_cert_file = 'ETCD_CERT_FILE'; - var etcd_key_file = 'ETCD_KEY_FILE'; - var etcd_ca_file = 'ETCD_CA_CERT_FILE'; - var datastore_type = 'DATASTORE_TYPE'; - } - - return ( - <> -

    - - Use the following guidelines and sample file to define the environment variables for starting Calico on the - host. For more help, see the{' '} - - {props.install === 'container' ? ( - {props.nodecontainer} configuration reference - ) : ( - Felix configuration reference - )} -

    - - -

    For a Kubernetes datastore (default) set the following:

    - - - - - - - - - - - - - - - - - -
    VariableConfiguration guidance
    FELIX_DATASTORETYPE - Set to kubernetes -
    KUBECONFIGPath to kubeconfig file to access the Kubernetes API Server
    - {props.install === 'container' && ( - - You will need to volume mount the kubeconfig file into the container at the location specified by the - paths mentioned above. - - )} -     - -

    For an etcdv3 datastore set the following:

    - - - - - - - - - - - - - - - - - - - - - - - - - -
    VariableConfiguration guidance
    {datastore_type} - Set to etcdv3 -
    {etcd_endpoints}Comma separated list of etcdv3 cluster URLs, e.g. https://calico-datastore.example.com:2379
    {etcd_ca_file} - Path to CA certificate to validate etcd’s server cert. Required if using TLS and not using a public - CA. -
    - {etcd_cert_file} -
    - {etcd_key_file} -     		Paths to certificate and keys used for client authentication to the etcd cluster, if enabled.
    - {props.install === 'container' && ( - - If using certificates and keys, you will need to volume mount them into the container at the location - specified by the paths mentioned above. - - )} -     - -

    For either datastore set the following:

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    VariableConfiguration guidance
    CALICO_NODENAME - Identifies the node. If a value is not specified, the compute server hostname is used to identify the - Calico node. -
    CALICO_IP or CALICO_IP6 - If values are not specified for both, {prodname} uses the currently-configured values for the next hop - IP addresses for this node—these can be configured through the Node resource. If no next hop addresses - are configured, {prodname} automatically determines an IPv4 next hop address by querying the host - interfaces (and configures this value in the Node resource). You can set CALICO_IP to{' '} - autodetect for force auto-detection of IP address every time the node starts. If you set - IP addresses through these environment variables, it reconfigures any values currently set through the - Node resource. -
    CALICO_AS - If not specified, {prodname} uses the currently configured value for the AS Number for the node BGP - client—this can be configured through the Node resource. If the Node resource value is not set, Calico - inherits the AS Number from the global default value. If you set a value through this environment - variable, it reconfigures any value currently set through the Node resource. -
    NO_DEFAULT_POOLS - Set to true to prevent {prodname} from creating a default pool if one does not exist. Pools are used - for workload endpoints and not required for non-cluster hosts. -
    CALICO_NETWORKING_BACKEND - The networking backend to use. In bird mode, Calico will provide BGP networking using the - BIRD BGP daemon; VXLAN networking can also be used. In vxlan mode, only VXLAN networking - is provided; BIRD and BGP are disabled. If you want to run Calico for policy only, set to{' '} - none. -
    -

    - Sample EnvironmentFile - save to /etc/calico/calico.env -

    - - {`${datastore_type}=etcdv3 -${etcd_endpoints}=https://calico-datastore.example.com:2379 -${etcd_ca_file}="/pki/ca.pem" -${etcd_cert_file}="/pki/client-cert.pem" -${etcd_key_file}="/pki/client-key.pem"`} - {props.install === 'container' - ? ` -CALICO_NODENAME="" -NO_DEFAULT_POOLS="true" -CALICO_IP="" -CALICO_IP6="" -CALICO_AS="" -CALICO_NETWORKING_BACKEND=bird` - : ''} - -     -     - - ); -} diff --git a/calico_versioned_docs/version-3.29/_includes/components/FelixConfig/TableConfig.js b/calico_versioned_docs/version-3.29/_includes/components/FelixConfig/TableConfig.js deleted file mode 100644 index b0d6ba7edf..0000000000 --- a/calico_versioned_docs/version-3.29/_includes/components/FelixConfig/TableConfig.js +++ /dev/null @@ -1,55 +0,0 @@ -import React from 'react'; -import sanitizeHtml from 'sanitize-html'; -import styles from './styles.module.css'; - -const getSanitizedData = ({ fieldData }) => ({ - sanitizedDescription: { __html: sanitizeHtml(fieldData.DescriptionHTML) }, - sanitizedSchema: { __html: sanitizeHtml(fieldData.StringSchemaHTML) }, -}); - -const TableConfig = ({ fieldData }) => { - const { sanitizedDescription, sanitizedSchema } = getSanitizedData({ fieldData }); - - return ( - - - - - - - - - - - - - - - - - - - - - - - -
    AttributeValue
    Key - {fieldData.NameConfigFile || 'No Default Value'} -
    Description -
    Schema -
    Default - {fieldData.StringDefault === '' ? ( - 'none' - ) : fieldData.GoType === '*v1.Duration' ? ( - <> - {fieldData.StringDefault} ({fieldData.ParsedDefault}) - - ) : ( - {fieldData.StringDefault} - )} -
    - ); -}; - -export default TableConfig; diff --git a/calico_versioned_docs/version-3.29/_includes/components/FelixConfig/TableEnv.js b/calico_versioned_docs/version-3.29/_includes/components/FelixConfig/TableEnv.js deleted file mode 100644 index e71bbe32f8..0000000000 --- a/calico_versioned_docs/version-3.29/_includes/components/FelixConfig/TableEnv.js +++ /dev/null @@ -1,55 +0,0 @@ -import React from 'react'; -import sanitizeHtml from 'sanitize-html'; -import styles from './styles.module.css'; - -const getSanitizedData = ({ fieldData }) => ({ - sanitizedDescription: { __html: sanitizeHtml(fieldData.DescriptionHTML) }, - sanitizedSchema: { __html: sanitizeHtml(fieldData.StringSchemaHTML) }, -}); - -const TableEnv = ({ fieldData }) => { - const { sanitizedDescription, sanitizedSchema } = getSanitizedData({ fieldData }); - - return ( - - - - - - - - - - - - - - - - - - - - - - - -
    AttributeValue
    Key - {fieldData.NameEnvVar.toUpperCase() || 'No Default Value'} -
    Description -
    Schema -
    Default - {fieldData.StringDefault === '' ? ( - 'none' - ) : fieldData.GoType === '*v1.Duration' ? ( - <> - {fieldData.StringDefault} ({fieldData.ParsedDefault}) - - ) : ( - {fieldData.StringDefault} - )} -
    - ); -}; - -export default TableEnv; diff --git a/calico_versioned_docs/version-3.29/_includes/components/FelixConfig/TableResource.js b/calico_versioned_docs/version-3.29/_includes/components/FelixConfig/TableResource.js deleted file mode 100644 index 147333df4e..0000000000 --- a/calico_versioned_docs/version-3.29/_includes/components/FelixConfig/TableResource.js +++ /dev/null @@ -1,46 +0,0 @@ -import React from 'react'; -import sanitizeHtml from 'sanitize-html'; -import styles from './styles.module.css'; - -const getSanitizedData = ({ fieldData }) => ({ - sanitizedNAMEYAML: { __html: sanitizeHtml(fieldData.NameYAML) }, - sanitizedDescription: { __html: sanitizeHtml(fieldData.DescriptionHTML) }, - sanitizedSchema: { __html: sanitizeHtml(fieldData.YAMLSchemaHTML) }, -}); - -const TableResource = ({ fieldData }) => { - const { sanitizedNAMEYAML, sanitizedDescription, sanitizedSchema } = getSanitizedData({ fieldData }); - - return ( - - - - - - - - - - - - - - - - - - - - - - - -
    AttributeValue
    Key - -
    Description -
    Schema -
    Default{fieldData.YAMLDefault === '' ? 'none' : {fieldData.YAMLDefault}}
    - ); -}; - -export default TableResource; diff --git a/calico_versioned_docs/version-3.29/_includes/components/FelixConfig/config-params.json b/calico_versioned_docs/version-3.29/_includes/components/FelixConfig/config-params.json deleted file mode 100644 index ead3b29b75..0000000000 --- a/calico_versioned_docs/version-3.29/_includes/components/FelixConfig/config-params.json +++ /dev/null @@ -1,4612 +0,0 @@ -{ - "Comment": "This file generated by calico-felix-docgen, DO NOT EDIT.", - "Groups": [ - { - "Name": "Datastore connection", - "Fields": [ - { - "Group": "Datastore connection", - "GroupWithSortPrefix": "00 Datastore connection", - "NameConfigFile": "DatastoreType", - "NameEnvVar": "FELIX_DatastoreType", - "NameYAML": "", - "NameGoAPI": "", - "StringSchema": "One of: `etcdv3`, `kubernetes` (case insensitive)", - "StringSchemaHTML": "One of: etcdv3, kubernetes (case insensitive)", - "StringDefault": "etcdv3", - "ParsedDefault": "etcdv3", - "ParsedDefaultJSON": "\"etcdv3\"", - "ParsedType": "string", - "YAMLType": "", - "YAMLSchema": "", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "", - "YAMLDefault": "", - "Required": true, - "OnParseFailure": "Exit", - "AllowedConfigSources": "LocalOnly", - "Description": "Controls which datastore driver Felix will use. Typically, this is detected from the environment\nand it does not need to be set manually. (For example, if `KUBECONFIG` is set, the kubernetes datastore driver\nwill be used by default).", - "DescriptionHTML": "

    Controls which datastore driver Felix will use. Typically, this is detected from the environment\nand it does not need to be set manually. (For example, if KUBECONFIG is set, the kubernetes datastore driver\nwill be used by default).

    ", - "UserEditable": true, - "GoType": "" - }, - { - "Group": "Datastore connection", - "GroupWithSortPrefix": "00 Datastore connection", - "NameConfigFile": "EtcdAddr", - "NameEnvVar": "FELIX_EtcdAddr", - "NameYAML": "", - "NameGoAPI": "", - "StringSchema": "String matching regex `^[^:/]+:\\d+$`", - "StringSchemaHTML": "String matching regex ^[^:/]+:\\d+$", - "StringDefault": "127.0.0.1:2379", - "ParsedDefault": "127.0.0.1:2379", - "ParsedDefaultJSON": "\"127.0.0.1:2379\"", - "ParsedType": "string", - "YAMLType": "", - "YAMLSchema": "", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "LocalOnly", - "Description": "When using the `etcdv3` datastore driver, the etcd server and port to connect to. If EtcdEndpoints\nis also specified, it takes precedence.", - "DescriptionHTML": "

    When using the etcdv3 datastore driver, the etcd server and port to connect to. If EtcdEndpoints\nis also specified, it takes precedence.

    ", - "UserEditable": true, - "GoType": "" - }, - { - "Group": "Datastore connection", - "GroupWithSortPrefix": "00 Datastore connection", - "NameConfigFile": "EtcdCaFile", - "NameEnvVar": "FELIX_EtcdCaFile", - "NameYAML": "", - "NameGoAPI": "", - "StringSchema": "Path to file, which must exist", - "StringSchemaHTML": "Path to file, which must exist", - "StringDefault": "", - "ParsedDefault": "", - "ParsedDefaultJSON": "\"\"", - "ParsedType": "string", - "YAMLType": "", - "YAMLSchema": "", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "LocalOnly", - "Description": "When using the `etcdv3` datastore driver, path to TLS CA file to use when connecting to\netcd. If the CA file is specified, the other TLS parameters are mandatory.", - "DescriptionHTML": "

    When using the etcdv3 datastore driver, path to TLS CA file to use when connecting to\netcd. If the CA file is specified, the other TLS parameters are mandatory.

    ", - "UserEditable": true, - "GoType": "" - }, - { - "Group": "Datastore connection", - "GroupWithSortPrefix": "00 Datastore connection", - "NameConfigFile": "EtcdCertFile", - "NameEnvVar": "FELIX_EtcdCertFile", - "NameYAML": "", - "NameGoAPI": "", - "StringSchema": "Path to file, which must exist", - "StringSchemaHTML": "Path to file, which must exist", - "StringDefault": "", - "ParsedDefault": "", - "ParsedDefaultJSON": "\"\"", - "ParsedType": "string", - "YAMLType": "", - "YAMLSchema": "", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "LocalOnly", - "Description": "When using the `etcdv3` datastore driver, path to TLS certificate file to use when connecting to\netcd. If the certificate file is specified, the other TLS parameters are mandatory.", - "DescriptionHTML": "

    When using the etcdv3 datastore driver, path to TLS certificate file to use when connecting to\netcd. If the certificate file is specified, the other TLS parameters are mandatory.

    ", - "UserEditable": true, - "GoType": "" - }, - { - "Group": "Datastore connection", - "GroupWithSortPrefix": "00 Datastore connection", - "NameConfigFile": "EtcdEndpoints", - "NameEnvVar": "FELIX_EtcdEndpoints", - "NameYAML": "", - "NameGoAPI": "", - "StringSchema": "List of HTTP endpoints: comma-delimited list of `http(s)://hostname:port`", - "StringSchemaHTML": "List of HTTP endpoints: comma-delimited list of http(s)://hostname:port", - "StringDefault": "", - "ParsedDefault": "[]", - "ParsedDefaultJSON": "null", - "ParsedType": "[]string", - "YAMLType": "", - "YAMLSchema": "", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "LocalOnly", - "Description": "When using the `etcdv3` datastore driver, comma-delimited list of etcd endpoints to connect to,\nreplaces EtcdAddr and EtcdScheme.", - "DescriptionHTML": "

    When using the etcdv3 datastore driver, comma-delimited list of etcd endpoints to connect to,\nreplaces EtcdAddr and EtcdScheme.

    ", - "UserEditable": true, - "GoType": "" - }, - { - "Group": "Datastore connection", - "GroupWithSortPrefix": "00 Datastore connection", - "NameConfigFile": "EtcdKeyFile", - "NameEnvVar": "FELIX_EtcdKeyFile", - "NameYAML": "", - "NameGoAPI": "", - "StringSchema": "Path to file, which must exist", - "StringSchemaHTML": "Path to file, which must exist", - "StringDefault": "", - "ParsedDefault": "", - "ParsedDefaultJSON": "\"\"", - "ParsedType": "string", - "YAMLType": "", - "YAMLSchema": "", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "LocalOnly", - "Description": "When using the `etcdv3` datastore driver, path to TLS private key file to use when connecting to\netcd. If the key file is specified, the other TLS parameters are mandatory.", - "DescriptionHTML": "

    When using the etcdv3 datastore driver, path to TLS private key file to use when connecting to\netcd. If the key file is specified, the other TLS parameters are mandatory.

    ", - "UserEditable": true, - "GoType": "" - }, - { - "Group": "Datastore connection", - "GroupWithSortPrefix": "00 Datastore connection", - "NameConfigFile": "EtcdScheme", - "NameEnvVar": "FELIX_EtcdScheme", - "NameYAML": "", - "NameGoAPI": "", - "StringSchema": "One of: `http`, `https` (case insensitive)", - "StringSchemaHTML": "One of: http, https (case insensitive)", - "StringDefault": "http", - "ParsedDefault": "http", - "ParsedDefaultJSON": "\"http\"", - "ParsedType": "string", - "YAMLType": "", - "YAMLSchema": "", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "LocalOnly", - "Description": "EtcdAddr: when using the `etcdv3` datastore driver, the URL scheme to use. If EtcdEndpoints\nis also specified, it takes precedence.", - "DescriptionHTML": "

    EtcdAddr: when using the etcdv3 datastore driver, the URL scheme to use. If EtcdEndpoints\nis also specified, it takes precedence.

    ", - "UserEditable": true, - "GoType": "" - }, - { - "Group": "Datastore connection", - "GroupWithSortPrefix": "00 Datastore connection", - "NameConfigFile": "FelixHostname", - "NameEnvVar": "FELIX_FelixHostname", - "NameYAML": "", - "NameGoAPI": "", - "StringSchema": "String matching regex `^[a-zA-Z0-9_.-]+$`", - "StringSchemaHTML": "String matching regex ^[a-zA-Z0-9_.-]+$", - "StringDefault": "", - "ParsedDefault": "", - "ParsedDefaultJSON": "\"\"", - "ParsedType": "string", - "YAMLType": "", - "YAMLSchema": "", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "", - "YAMLDefault": "", - "Required": true, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "LocalOnly", - "Description": "The name of this node, used to identify resources in the datastore that belong to this node.\nAuto-detected from the node's hostname if not provided.", - "DescriptionHTML": "

    The name of this node, used to identify resources in the datastore that belong to this node.\nAuto-detected from the node's hostname if not provided.

    ", - "UserEditable": true, - "GoType": "" - }, - { - "Group": "Datastore connection", - "GroupWithSortPrefix": "00 Datastore connection", - "NameConfigFile": "TyphaAddr", - "NameEnvVar": "FELIX_TyphaAddr", - "NameYAML": "", - "NameGoAPI": "", - "StringSchema": "String matching regex `^[^:/]+:\\d+$`", - "StringSchemaHTML": "String matching regex ^[^:/]+:\\d+$", - "StringDefault": "", - "ParsedDefault": "", - "ParsedDefaultJSON": "\"\"", - "ParsedType": "string", - "YAMLType": "", - "YAMLSchema": "", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "LocalOnly", - "Description": "If set, tells Felix to connect to Typha at the given address and port. Overrides TyphaK8sServiceName.", - "DescriptionHTML": "

    If set, tells Felix to connect to Typha at the given address and port. Overrides TyphaK8sServiceName.

    ", - "UserEditable": true, - "GoType": "" - }, - { - "Group": "Datastore connection", - "GroupWithSortPrefix": "00 Datastore connection", - "NameConfigFile": "TyphaCAFile", - "NameEnvVar": "FELIX_TyphaCAFile", - "NameYAML": "", - "NameGoAPI": "", - "StringSchema": "Path to file, which must exist", - "StringSchemaHTML": "Path to file, which must exist", - "StringDefault": "", - "ParsedDefault": "", - "ParsedDefaultJSON": "\"\"", - "ParsedType": "string", - "YAMLType": "", - "YAMLSchema": "", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "LocalOnly", - "Description": "Path to the TLS CA file to use when communicating with Typha. If this parameter is specified,\nthe other TLS parameters must also be specified.", - "DescriptionHTML": "

    Path to the TLS CA file to use when communicating with Typha. If this parameter is specified,\nthe other TLS parameters must also be specified.

    ", - "UserEditable": true, - "GoType": "" - }, - { - "Group": "Datastore connection", - "GroupWithSortPrefix": "00 Datastore connection", - "NameConfigFile": "TyphaCN", - "NameEnvVar": "FELIX_TyphaCN", - "NameYAML": "", - "NameGoAPI": "", - "StringSchema": "String", - "StringSchemaHTML": "String", - "StringDefault": "", - "ParsedDefault": "", - "ParsedDefaultJSON": "\"\"", - "ParsedType": "string", - "YAMLType": "", - "YAMLSchema": "", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "LocalOnly", - "Description": "Common name to use when authenticating to Typha over TLS. If any TLS parameters are specified then one of\nTyphaCN and TyphaURISAN must be set.", - "DescriptionHTML": "

    Common name to use when authenticating to Typha over TLS. If any TLS parameters are specified then one of\nTyphaCN and TyphaURISAN must be set.

    ", - "UserEditable": true, - "GoType": "" - }, - { - "Group": "Datastore connection", - "GroupWithSortPrefix": "00 Datastore connection", - "NameConfigFile": "TyphaCertFile", - "NameEnvVar": "FELIX_TyphaCertFile", - "NameYAML": "", - "NameGoAPI": "", - "StringSchema": "Path to file, which must exist", - "StringSchemaHTML": "Path to file, which must exist", - "StringDefault": "", - "ParsedDefault": "", - "ParsedDefaultJSON": "\"\"", - "ParsedType": "string", - "YAMLType": "", - "YAMLSchema": "", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "LocalOnly", - "Description": "Path to the TLS certificate to use when communicating with Typha. If this parameter is specified,\nthe other TLS parameters must also be specified.", - "DescriptionHTML": "

    Path to the TLS certificate to use when communicating with Typha. If this parameter is specified,\nthe other TLS parameters must also be specified.

    ", - "UserEditable": true, - "GoType": "" - }, - { - "Group": "Datastore connection", - "GroupWithSortPrefix": "00 Datastore connection", - "NameConfigFile": "TyphaK8sNamespace", - "NameEnvVar": "FELIX_TyphaK8sNamespace", - "NameYAML": "", - "NameGoAPI": "", - "StringSchema": "String", - "StringSchemaHTML": "String", - "StringDefault": "kube-system", - "ParsedDefault": "kube-system", - "ParsedDefaultJSON": "\"kube-system\"", - "ParsedType": "string", - "YAMLType": "", - "YAMLSchema": "", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "", - "YAMLDefault": "", - "Required": true, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "LocalOnly", - "Description": "Namespace to look in when looking for Typha's service (see TyphaK8sServiceName).", - "DescriptionHTML": "

    Namespace to look in when looking for Typha's service (see TyphaK8sServiceName).

    ", - "UserEditable": true, - "GoType": "" - }, - { - "Group": "Datastore connection", - "GroupWithSortPrefix": "00 Datastore connection", - "NameConfigFile": "TyphaK8sServiceName", - "NameEnvVar": "FELIX_TyphaK8sServiceName", - "NameYAML": "", - "NameGoAPI": "", - "StringSchema": "String", - "StringSchemaHTML": "String", - "StringDefault": "", - "ParsedDefault": "", - "ParsedDefaultJSON": "\"\"", - "ParsedType": "string", - "YAMLType": "", - "YAMLSchema": "", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "LocalOnly", - "Description": "If set, tells Felix to connect to Typha by looking up the Endpoints of the given Kubernetes\nService in namespace specified by TyphaK8sNamespace.", - "DescriptionHTML": "

    If set, tells Felix to connect to Typha by looking up the Endpoints of the given Kubernetes\nService in namespace specified by TyphaK8sNamespace.

    ", - "UserEditable": true, - "GoType": "" - }, - { - "Group": "Datastore connection", - "GroupWithSortPrefix": "00 Datastore connection", - "NameConfigFile": "TyphaKeyFile", - "NameEnvVar": "FELIX_TyphaKeyFile", - "NameYAML": "", - "NameGoAPI": "", - "StringSchema": "Path to file, which must exist", - "StringSchemaHTML": "Path to file, which must exist", - "StringDefault": "", - "ParsedDefault": "", - "ParsedDefaultJSON": "\"\"", - "ParsedType": "string", - "YAMLType": "", - "YAMLSchema": "", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "LocalOnly", - "Description": "Path to the TLS private key to use when communicating with Typha. If this parameter is specified,\nthe other TLS parameters must also be specified.", - "DescriptionHTML": "

    Path to the TLS private key to use when communicating with Typha. If this parameter is specified,\nthe other TLS parameters must also be specified.

    ", - "UserEditable": true, - "GoType": "" - }, - { - "Group": "Datastore connection", - "GroupWithSortPrefix": "00 Datastore connection", - "NameConfigFile": "TyphaReadTimeout", - "NameEnvVar": "FELIX_TyphaReadTimeout", - "NameYAML": "", - "NameGoAPI": "", - "StringSchema": "Seconds (floating point)", - "StringSchemaHTML": "Seconds (floating point)", - "StringDefault": "30", - "ParsedDefault": "30s", - "ParsedDefaultJSON": "30000000000", - "ParsedType": "time.Duration", - "YAMLType": "", - "YAMLSchema": "", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "LocalOnly", - "Description": "Read timeout when reading from the Typha connection. If typha sends no data for this long,\nFelix will exit and restart. (Note that Typha sends regular pings so traffic is always expected.)", - "DescriptionHTML": "

    Read timeout when reading from the Typha connection. If typha sends no data for this long,\nFelix will exit and restart. (Note that Typha sends regular pings so traffic is always expected.)

    ", - "UserEditable": true, - "GoType": "" - }, - { - "Group": "Datastore connection", - "GroupWithSortPrefix": "00 Datastore connection", - "NameConfigFile": "TyphaURISAN", - "NameEnvVar": "FELIX_TyphaURISAN", - "NameYAML": "", - "NameGoAPI": "", - "StringSchema": "String", - "StringSchemaHTML": "String", - "StringDefault": "", - "ParsedDefault": "", - "ParsedDefaultJSON": "\"\"", - "ParsedType": "string", - "YAMLType": "", - "YAMLSchema": "", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "LocalOnly", - "Description": "URI SAN to use when authenticating to Typha over TLS. If any TLS parameters are specified then one of\nTyphaCN and TyphaURISAN must be set.", - "DescriptionHTML": "

    URI SAN to use when authenticating to Typha over TLS. If any TLS parameters are specified then one of\nTyphaCN and TyphaURISAN must be set.

    ", - "UserEditable": true, - "GoType": "" - }, - { - "Group": "Datastore connection", - "GroupWithSortPrefix": "00 Datastore connection", - "NameConfigFile": "TyphaWriteTimeout", - "NameEnvVar": "FELIX_TyphaWriteTimeout", - "NameYAML": "", - "NameGoAPI": "", - "StringSchema": "Seconds (floating point)", - "StringSchemaHTML": "Seconds (floating point)", - "StringDefault": "10", - "ParsedDefault": "10s", - "ParsedDefaultJSON": "10000000000", - "ParsedType": "time.Duration", - "YAMLType": "", - "YAMLSchema": "", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "LocalOnly", - "Description": "Write timeout when writing data to Typha.", - "DescriptionHTML": "

    Write timeout when writing data to Typha.

    ", - "UserEditable": true, - "GoType": "" - } - ] - }, - { - "Name": "Process: Feature detection/overrides", - "Fields": [ - { - "Group": "Process: Feature detection/overrides", - "GroupWithSortPrefix": "01 Process: Feature detection/overrides", - "NameConfigFile": "FeatureDetectOverride", - "NameEnvVar": "FELIX_FeatureDetectOverride", - "NameYAML": "featureDetectOverride", - "NameGoAPI": "FeatureDetectOverride", - "StringSchema": "Comma-delimited list of key=value pairs", - "StringSchemaHTML": "Comma-delimited list of key=value pairs", - "StringDefault": "", - "ParsedDefault": "map[]", - "ParsedDefaultJSON": "null", - "ParsedType": "map[string]string", - "YAMLType": "string", - "YAMLSchema": "String matching the regular expression `^([a-zA-Z0-9-_]+=(true|false|),)*([a-zA-Z0-9-_]+=(true|false|))?$`.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "String matching the regular expression ^([a-zA-Z0-9-_]+=(true|false|),)*([a-zA-Z0-9-_]+=(true|false|))?$.", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Used to override feature detection based on auto-detected platform capabilities. Values are specified in a comma separated list with no spaces, example; \"SNATFullyRandom=true,MASQFullyRandom=false,RestoreSupportsLock=\". A value of \"true\" or \"false\" will force enable/disable feature, empty or omitted values fall back to auto-detection.", - "DescriptionHTML": "

    Used to override feature detection based on auto-detected platform capabilities. Values are specified in a comma separated list with no spaces, example; \"SNATFullyRandom=true,MASQFullyRandom=false,RestoreSupportsLock=\". A value of \"true\" or \"false\" will force enable/disable feature, empty or omitted values fall back to auto-detection.

    ", - "UserEditable": true, - "GoType": "string" - }, - { - "Group": "Process: Feature detection/overrides", - "GroupWithSortPrefix": "01 Process: Feature detection/overrides", - "NameConfigFile": "FeatureGates", - "NameEnvVar": "FELIX_FeatureGates", - "NameYAML": "featureGates", - "NameGoAPI": "FeatureGates", - "StringSchema": "Comma-delimited list of key=value pairs", - "StringSchemaHTML": "Comma-delimited list of key=value pairs", - "StringDefault": "", - "ParsedDefault": "map[]", - "ParsedDefaultJSON": "null", - "ParsedType": "map[string]string", - "YAMLType": "string", - "YAMLSchema": "String matching the regular expression `^([a-zA-Z0-9-_]+=([^=]+),)*([a-zA-Z0-9-_]+=([^=]+))?$`.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "String matching the regular expression ^([a-zA-Z0-9-_]+=([^=]+),)*([a-zA-Z0-9-_]+=([^=]+))?$.", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Used to enable or disable tech-preview Calico features. Values are specified in a comma separated list with no spaces, example; \"BPFConnectTimeLoadBalancingWorkaround=enabled,XyZ=false\". This is used to enable features that are not fully production ready.", - "DescriptionHTML": "

    Used to enable or disable tech-preview Calico features. Values are specified in a comma separated list with no spaces, example; \"BPFConnectTimeLoadBalancingWorkaround=enabled,XyZ=false\". This is used to enable features that are not fully production ready.

    ", - "UserEditable": true, - "GoType": "string" - } - ] - }, - { - "Name": "Process: Go runtime", - "Fields": [ - { - "Group": "Process: Go runtime", - "GroupWithSortPrefix": "01 Process: Go runtime", - "NameConfigFile": "GoGCThreshold", - "NameEnvVar": "FELIX_GoGCThreshold", - "NameYAML": "goGCThreshold", - "NameGoAPI": "GoGCThreshold", - "StringSchema": "Integer: [-1,2^63-1]", - "StringSchemaHTML": "Integer: [-1,263-1]", - "StringDefault": "40", - "ParsedDefault": "40", - "ParsedDefaultJSON": "40", - "ParsedType": "int", - "YAMLType": "integer", - "YAMLSchema": "Integer: [-1,2^63-1]", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Integer: [-1,263-1]", - "YAMLDefault": "40", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Sets the Go runtime's garbage collection threshold. I.e. the percentage that the heap is allowed to grow before garbage collection is triggered. In general, doubling the value halves the CPU time spent doing GC, but it also doubles peak GC memory overhead. A special value of -1 can be used to disable GC entirely; this should only be used in conjunction with the GoMemoryLimitMB setting.\n\nThis setting is overridden by the GOGC environment variable.", - "DescriptionHTML": "

    Sets the Go runtime's garbage collection threshold. I.e. the percentage that the heap is allowed to grow before garbage collection is triggered. In general, doubling the value halves the CPU time spent doing GC, but it also doubles peak GC memory overhead. A special value of -1 can be used to disable GC entirely; this should only be used in conjunction with the GoMemoryLimitMB setting.

    \n

    This setting is overridden by the GOGC environment variable.

    ", - "UserEditable": true, - "GoType": "*int" - }, - { - "Group": "Process: Go runtime", - "GroupWithSortPrefix": "01 Process: Go runtime", - "NameConfigFile": "GoMaxProcs", - "NameEnvVar": "FELIX_GoMaxProcs", - "NameYAML": "goMaxProcs", - "NameGoAPI": "GoMaxProcs", - "StringSchema": "Integer: [-1,2^63-1]", - "StringSchemaHTML": "Integer: [-1,263-1]", - "StringDefault": "-1", - "ParsedDefault": "-1", - "ParsedDefaultJSON": "-1", - "ParsedType": "int", - "YAMLType": "integer", - "YAMLSchema": "Integer: [-1,2^63-1]", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Integer: [-1,263-1]", - "YAMLDefault": "-1", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Sets the maximum number of CPUs that the Go runtime will use concurrently. A value of -1 means \"use the system default\"; typically the number of real CPUs on the system.\n\nthis setting is overridden by the GOMAXPROCS environment variable.", - "DescriptionHTML": "

    Sets the maximum number of CPUs that the Go runtime will use concurrently. A value of -1 means \"use the system default\"; typically the number of real CPUs on the system.

    \n

    this setting is overridden by the GOMAXPROCS environment variable.

    ", - "UserEditable": true, - "GoType": "*int" - }, - { - "Group": "Process: Go runtime", - "GroupWithSortPrefix": "01 Process: Go runtime", - "NameConfigFile": "GoMemoryLimitMB", - "NameEnvVar": "FELIX_GoMemoryLimitMB", - "NameYAML": "goMemoryLimitMB", - "NameGoAPI": "GoMemoryLimitMB", - "StringSchema": "Integer: [-1,2^63-1]", - "StringSchemaHTML": "Integer: [-1,263-1]", - "StringDefault": "-1", - "ParsedDefault": "-1", - "ParsedDefaultJSON": "-1", - "ParsedType": "int", - "YAMLType": "integer", - "YAMLSchema": "Integer: [-1,2^63-1]", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Integer: [-1,263-1]", - "YAMLDefault": "-1", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Sets a (soft) memory limit for the Go runtime in MB. The Go runtime will try to keep its memory usage under the limit by triggering GC as needed. To avoid thrashing, it will exceed the limit if GC starts to take more than 50% of the process's CPU time. A value of -1 disables the memory limit.\n\nNote that the memory limit, if used, must be considerably less than any hard resource limit set at the container or pod level. This is because felix is not the only process that must run in the container or pod.\n\nThis setting is overridden by the GOMEMLIMIT environment variable.", - "DescriptionHTML": "

    Sets a (soft) memory limit for the Go runtime in MB. The Go runtime will try to keep its memory usage under the limit by triggering GC as needed. To avoid thrashing, it will exceed the limit if GC starts to take more than 50% of the process's CPU time. A value of -1 disables the memory limit.

    \n

    Note that the memory limit, if used, must be considerably less than any hard resource limit set at the container or pod level. This is because felix is not the only process that must run in the container or pod.

    \n

    This setting is overridden by the GOMEMLIMIT environment variable.

    ", - "UserEditable": true, - "GoType": "*int" - } - ] - }, - { - "Name": "Process: Health port and timeouts", - "Fields": [ - { - "Group": "Process: Health port and timeouts", - "GroupWithSortPrefix": "01 Process: Health port and timeouts", - "NameConfigFile": "HealthEnabled", - "NameEnvVar": "FELIX_HealthEnabled", - "NameYAML": "healthEnabled", - "NameGoAPI": "HealthEnabled", - "StringSchema": "Boolean: `true`, `1`, `yes`, `y`, `t` accepted as True; `false`, `0`, `no`, `n`, `f` accepted (case insensitively) as False.", - "StringSchemaHTML": "Boolean: true, 1, yes, y, t accepted as True; false, 0, no, n, f accepted (case insensitively) as False.", - "StringDefault": "false", - "ParsedDefault": "false", - "ParsedDefaultJSON": "false", - "ParsedType": "bool", - "YAMLType": "boolean", - "YAMLSchema": "Boolean.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Boolean.", - "YAMLDefault": "false", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "If set to true, enables Felix's health port, which provides readiness and liveness endpoints.", - "DescriptionHTML": "

    If set to true, enables Felix's health port, which provides readiness and liveness endpoints.

    ", - "UserEditable": true, - "GoType": "*bool" - }, - { - "Group": "Process: Health port and timeouts", - "GroupWithSortPrefix": "01 Process: Health port and timeouts", - "NameConfigFile": "HealthHost", - "NameEnvVar": "FELIX_HealthHost", - "NameYAML": "healthHost", - "NameGoAPI": "HealthHost", - "StringSchema": "String matching regex `^[a-zA-Z0-9:._+-]{1,64}$`", - "StringSchemaHTML": "String matching regex ^[a-zA-Z0-9:._+-]{1,64}$", - "StringDefault": "localhost", - "ParsedDefault": "localhost", - "ParsedDefaultJSON": "\"localhost\"", - "ParsedType": "string", - "YAMLType": "string", - "YAMLSchema": "String.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "String.", - "YAMLDefault": "localhost", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "The host that the health server should bind to.", - "DescriptionHTML": "

    The host that the health server should bind to.

    ", - "UserEditable": true, - "GoType": "*string" - }, - { - "Group": "Process: Health port and timeouts", - "GroupWithSortPrefix": "01 Process: Health port and timeouts", - "NameConfigFile": "HealthPort", - "NameEnvVar": "FELIX_HealthPort", - "NameYAML": "healthPort", - "NameGoAPI": "HealthPort", - "StringSchema": "Integer: [0,65535]", - "StringSchemaHTML": "Integer: [0,65535]", - "StringDefault": "9099", - "ParsedDefault": "9099", - "ParsedDefaultJSON": "9099", - "ParsedType": "int", - "YAMLType": "integer", - "YAMLSchema": "Integer: [0,65535]", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Integer: [0,65535]", - "YAMLDefault": "9099", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "The TCP port that the health server should bind to.", - "DescriptionHTML": "

    The TCP port that the health server should bind to.

    ", - "UserEditable": true, - "GoType": "*int" - }, - { - "Group": "Process: Health port and timeouts", - "GroupWithSortPrefix": "01 Process: Health port and timeouts", - "NameConfigFile": "HealthTimeoutOverrides", - "NameEnvVar": "FELIX_HealthTimeoutOverrides", - "NameYAML": "healthTimeoutOverrides", - "NameGoAPI": "HealthTimeoutOverrides", - "StringSchema": "Comma-delimited list of `=` pairs, where durations use Go's standard format (e.g. 1s, 1m, 1h3m2s)", - "StringSchemaHTML": "Comma-delimited list of <key>=<duration> pairs, where durations use Go's standard format (e.g. 1s, 1m, 1h3m2s)", - "StringDefault": "", - "ParsedDefault": "map[]", - "ParsedDefaultJSON": "null", - "ParsedType": "map[string]time.Duration", - "YAMLType": "array", - "YAMLSchema": "List of health timeout overrides: `[{name: \"\", timeout: \"\"}, ...]` where `` is in the Go duration format, for example `1m30s`.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "List of health timeout overrides: [{name: \"<name>\", timeout: \"<duration>\"}, ...] where <duration> is in the Go duration format, for example 1m30s.", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Allows the internal watchdog timeouts of individual subcomponents to be overridden. This is useful for working around \"false positive\" liveness timeouts that can occur in particularly stressful workloads or if CPU is constrained. For a list of active subcomponents, see Felix's logs.", - "DescriptionHTML": "

    Allows the internal watchdog timeouts of individual subcomponents to be overridden. This is useful for working around \"false positive\" liveness timeouts that can occur in particularly stressful workloads or if CPU is constrained. For a list of active subcomponents, see Felix's logs.

    ", - "UserEditable": true, - "GoType": "[]v3.HealthTimeoutOverride" - } - ] - }, - { - "Name": "Process: Logging", - "Fields": [ - { - "Group": "Process: Logging", - "GroupWithSortPrefix": "01 Process: Logging", - "NameConfigFile": "LogDebugFilenameRegex", - "NameEnvVar": "FELIX_LogDebugFilenameRegex", - "NameYAML": "logDebugFilenameRegex", - "NameGoAPI": "LogDebugFilenameRegex", - "StringSchema": "Regular expression", - "StringSchemaHTML": "Regular expression", - "StringDefault": "", - "ParsedDefault": "", - "ParsedDefaultJSON": "null", - "ParsedType": "*regexp.Regexp", - "YAMLType": "string", - "YAMLSchema": "String.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "String.", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Controls which source code files have their Debug log output included in the logs. Only logs from files with names that match the given regular expression are included. The filter only applies to Debug level logs.", - "DescriptionHTML": "

    Controls which source code files have their Debug log output included in the logs. Only logs from files with names that match the given regular expression are included. The filter only applies to Debug level logs.

    ", - "UserEditable": true, - "GoType": "string" - }, - { - "Group": "Process: Logging", - "GroupWithSortPrefix": "01 Process: Logging", - "NameConfigFile": "LogFilePath", - "NameEnvVar": "FELIX_LogFilePath", - "NameYAML": "logFilePath", - "NameGoAPI": "LogFilePath", - "StringSchema": "Path to file", - "StringSchemaHTML": "Path to file", - "StringDefault": "/var/log/calico/felix.log", - "ParsedDefault": "/var/log/calico/felix.log", - "ParsedDefaultJSON": "\"/var/log/calico/felix.log\"", - "ParsedType": "string", - "YAMLType": "string", - "YAMLSchema": "String.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "String.", - "YAMLDefault": "/var/log/calico/felix.log", - "Required": false, - "OnParseFailure": "Exit", - "AllowedConfigSources": "All", - "Description": "The full path to the Felix log. Set to none to disable file logging.", - "DescriptionHTML": "

    The full path to the Felix log. Set to none to disable file logging.

    ", - "UserEditable": true, - "GoType": "string" - }, - { - "Group": "Process: Logging", - "GroupWithSortPrefix": "01 Process: Logging", - "NameConfigFile": "LogPrefix", - "NameEnvVar": "FELIX_LogPrefix", - "NameYAML": "logPrefix", - "NameGoAPI": "LogPrefix", - "StringSchema": "String", - "StringSchemaHTML": "String", - "StringDefault": "calico-packet", - "ParsedDefault": "calico-packet", - "ParsedDefaultJSON": "\"calico-packet\"", - "ParsedType": "string", - "YAMLType": "string", - "YAMLSchema": "String.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "String.", - "YAMLDefault": "calico-packet", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "The log prefix that Felix uses when rendering LOG rules.", - "DescriptionHTML": "

    The log prefix that Felix uses when rendering LOG rules.

    ", - "UserEditable": true, - "GoType": "string" - }, - { - "Group": "Process: Logging", - "GroupWithSortPrefix": "01 Process: Logging", - "NameConfigFile": "LogSeverityFile", - "NameEnvVar": "FELIX_LogSeverityFile", - "NameYAML": "logSeverityFile", - "NameGoAPI": "LogSeverityFile", - "StringSchema": "One of: `DEBUG`, `ERROR`, `FATAL`, `INFO`, `WARNING` (case insensitive)", - "StringSchemaHTML": "One of: DEBUG, ERROR, FATAL, INFO, WARNING (case insensitive)", - "StringDefault": "INFO", - "ParsedDefault": "INFO", - "ParsedDefaultJSON": "\"INFO\"", - "ParsedType": "string", - "YAMLType": "string", - "YAMLSchema": "One of: `Debug`, `Error`, `Fatal`, `Info`, `Warning`.", - "YAMLEnumValues": [ - "Debug", - "Error", - "Fatal", - "Info", - "Warning" - ], - "YAMLSchemaHTML": "One of: Debug, Error, Fatal, Info, Warning.", - "YAMLDefault": "Info", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "The log severity above which logs are sent to the log file.", - "DescriptionHTML": "

    The log severity above which logs are sent to the log file.

    ", - "UserEditable": true, - "GoType": "string" - }, - { - "Group": "Process: Logging", - "GroupWithSortPrefix": "01 Process: Logging", - "NameConfigFile": "LogSeverityScreen", - "NameEnvVar": "FELIX_LogSeverityScreen", - "NameYAML": "logSeverityScreen", - "NameGoAPI": "LogSeverityScreen", - "StringSchema": "One of: `DEBUG`, `ERROR`, `FATAL`, `INFO`, `WARNING` (case insensitive)", - "StringSchemaHTML": "One of: DEBUG, ERROR, FATAL, INFO, WARNING (case insensitive)", - "StringDefault": "INFO", - "ParsedDefault": "INFO", - "ParsedDefaultJSON": "\"INFO\"", - "ParsedType": "string", - "YAMLType": "string", - "YAMLSchema": "One of: `Debug`, `Error`, `Fatal`, `Info`, `Warning`.", - "YAMLEnumValues": [ - "Debug", - "Error", - "Fatal", - "Info", - "Warning" - ], - "YAMLSchemaHTML": "One of: Debug, Error, Fatal, Info, Warning.", - "YAMLDefault": "Info", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "The log severity above which logs are sent to the stdout.", - "DescriptionHTML": "

    The log severity above which logs are sent to the stdout.

    ", - "UserEditable": true, - "GoType": "string" - }, - { - "Group": "Process: Logging", - "GroupWithSortPrefix": "01 Process: Logging", - "NameConfigFile": "LogSeveritySys", - "NameEnvVar": "FELIX_LogSeveritySys", - "NameYAML": "logSeveritySys", - "NameGoAPI": "LogSeveritySys", - "StringSchema": "One of: `DEBUG`, `ERROR`, `FATAL`, `INFO`, `WARNING` (case insensitive)", - "StringSchemaHTML": "One of: DEBUG, ERROR, FATAL, INFO, WARNING (case insensitive)", - "StringDefault": "INFO", - "ParsedDefault": "INFO", - "ParsedDefaultJSON": "\"INFO\"", - "ParsedType": "string", - "YAMLType": "string", - "YAMLSchema": "One of: `Debug`, `Error`, `Fatal`, `Info`, `Warning`.", - "YAMLEnumValues": [ - "Debug", - "Error", - "Fatal", - "Info", - "Warning" - ], - "YAMLSchemaHTML": "One of: Debug, Error, Fatal, Info, Warning.", - "YAMLDefault": "Info", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "The log severity above which logs are sent to the syslog. Set to None for no logging to syslog.", - "DescriptionHTML": "

    The log severity above which logs are sent to the syslog. Set to None for no logging to syslog.

    ", - "UserEditable": true, - "GoType": "string" - } - ] - }, - { - "Name": "Process: Prometheus metrics", - "Fields": [ - { - "Group": "Process: Prometheus metrics", - "GroupWithSortPrefix": "01 Process: Prometheus metrics", - "NameConfigFile": "PrometheusGoMetricsEnabled", - "NameEnvVar": "FELIX_PrometheusGoMetricsEnabled", - "NameYAML": "prometheusGoMetricsEnabled", - "NameGoAPI": "PrometheusGoMetricsEnabled", - "StringSchema": "Boolean: `true`, `1`, `yes`, `y`, `t` accepted as True; `false`, `0`, `no`, `n`, `f` accepted (case insensitively) as False.", - "StringSchemaHTML": "Boolean: true, 1, yes, y, t accepted as True; false, 0, no, n, f accepted (case insensitively) as False.", - "StringDefault": "true", - "ParsedDefault": "true", - "ParsedDefaultJSON": "true", - "ParsedType": "bool", - "YAMLType": "boolean", - "YAMLSchema": "Boolean.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Boolean.", - "YAMLDefault": "true", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Disables Go runtime metrics collection, which the Prometheus client does by default, when set to false. This reduces the number of metrics reported, reducing Prometheus load.", - "DescriptionHTML": "

    Disables Go runtime metrics collection, which the Prometheus client does by default, when set to false. This reduces the number of metrics reported, reducing Prometheus load.

    ", - "UserEditable": true, - "GoType": "*bool" - }, - { - "Group": "Process: Prometheus metrics", - "GroupWithSortPrefix": "01 Process: Prometheus metrics", - "NameConfigFile": "PrometheusMetricsEnabled", - "NameEnvVar": "FELIX_PrometheusMetricsEnabled", - "NameYAML": "prometheusMetricsEnabled", - "NameGoAPI": "PrometheusMetricsEnabled", - "StringSchema": "Boolean: `true`, `1`, `yes`, `y`, `t` accepted as True; `false`, `0`, `no`, `n`, `f` accepted (case insensitively) as False.", - "StringSchemaHTML": "Boolean: true, 1, yes, y, t accepted as True; false, 0, no, n, f accepted (case insensitively) as False.", - "StringDefault": "false", - "ParsedDefault": "false", - "ParsedDefaultJSON": "false", - "ParsedType": "bool", - "YAMLType": "boolean", - "YAMLSchema": "Boolean.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Boolean.", - "YAMLDefault": "false", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Enables the Prometheus metrics server in Felix if set to true.", - "DescriptionHTML": "

    Enables the Prometheus metrics server in Felix if set to true.

    ", - "UserEditable": true, - "GoType": "*bool" - }, - { - "Group": "Process: Prometheus metrics", - "GroupWithSortPrefix": "01 Process: Prometheus metrics", - "NameConfigFile": "PrometheusMetricsHost", - "NameEnvVar": "FELIX_PrometheusMetricsHost", - "NameYAML": "prometheusMetricsHost", - "NameGoAPI": "PrometheusMetricsHost", - "StringSchema": "String matching regex `^[a-zA-Z0-9:._+-]{1,64}$`", - "StringSchemaHTML": "String matching regex ^[a-zA-Z0-9:._+-]{1,64}$", - "StringDefault": "", - "ParsedDefault": "", - "ParsedDefaultJSON": "\"\"", - "ParsedType": "string", - "YAMLType": "string", - "YAMLSchema": "String.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "String.", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "The host that the Prometheus metrics server should bind to.", - "DescriptionHTML": "

    The host that the Prometheus metrics server should bind to.

    ", - "UserEditable": true, - "GoType": "string" - }, - { - "Group": "Process: Prometheus metrics", - "GroupWithSortPrefix": "01 Process: Prometheus metrics", - "NameConfigFile": "PrometheusMetricsPort", - "NameEnvVar": "FELIX_PrometheusMetricsPort", - "NameYAML": "prometheusMetricsPort", - "NameGoAPI": "PrometheusMetricsPort", - "StringSchema": "Integer: [0,65535]", - "StringSchemaHTML": "Integer: [0,65535]", - "StringDefault": "9091", - "ParsedDefault": "9091", - "ParsedDefaultJSON": "9091", - "ParsedType": "int", - "YAMLType": "integer", - "YAMLSchema": "Integer: [0,65535]", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Integer: [0,65535]", - "YAMLDefault": "9091", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "The TCP port that the Prometheus metrics server should bind to.", - "DescriptionHTML": "

    The TCP port that the Prometheus metrics server should bind to.

    ", - "UserEditable": true, - "GoType": "*int" - }, - { - "Group": "Process: Prometheus metrics", - "GroupWithSortPrefix": "01 Process: Prometheus metrics", - "NameConfigFile": "PrometheusProcessMetricsEnabled", - "NameEnvVar": "FELIX_PrometheusProcessMetricsEnabled", - "NameYAML": "prometheusProcessMetricsEnabled", - "NameGoAPI": "PrometheusProcessMetricsEnabled", - "StringSchema": "Boolean: `true`, `1`, `yes`, `y`, `t` accepted as True; `false`, `0`, `no`, `n`, `f` accepted (case insensitively) as False.", - "StringSchemaHTML": "Boolean: true, 1, yes, y, t accepted as True; false, 0, no, n, f accepted (case insensitively) as False.", - "StringDefault": "true", - "ParsedDefault": "true", - "ParsedDefaultJSON": "true", - "ParsedType": "bool", - "YAMLType": "boolean", - "YAMLSchema": "Boolean.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Boolean.", - "YAMLDefault": "true", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Disables process metrics collection, which the Prometheus client does by default, when set to false. This reduces the number of metrics reported, reducing Prometheus load.", - "DescriptionHTML": "

    Disables process metrics collection, which the Prometheus client does by default, when set to false. This reduces the number of metrics reported, reducing Prometheus load.

    ", - "UserEditable": true, - "GoType": "*bool" - }, - { - "Group": "Process: Prometheus metrics", - "GroupWithSortPrefix": "01 Process: Prometheus metrics", - "NameConfigFile": "PrometheusWireGuardMetricsEnabled", - "NameEnvVar": "FELIX_PrometheusWireGuardMetricsEnabled", - "NameYAML": "prometheusWireGuardMetricsEnabled", - "NameGoAPI": "PrometheusWireGuardMetricsEnabled", - "StringSchema": "Boolean: `true`, `1`, `yes`, `y`, `t` accepted as True; `false`, `0`, `no`, `n`, `f` accepted (case insensitively) as False.", - "StringSchemaHTML": "Boolean: true, 1, yes, y, t accepted as True; false, 0, no, n, f accepted (case insensitively) as False.", - "StringDefault": "true", - "ParsedDefault": "true", - "ParsedDefaultJSON": "true", - "ParsedType": "bool", - "YAMLType": "boolean", - "YAMLSchema": "Boolean.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Boolean.", - "YAMLDefault": "true", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Disables WireGuard metrics collection, which the Prometheus client does by default, when set to false. This reduces the number of metrics reported, reducing Prometheus load.", - "DescriptionHTML": "

    Disables WireGuard metrics collection, which the Prometheus client does by default, when set to false. This reduces the number of metrics reported, reducing Prometheus load.

    ", - "UserEditable": true, - "GoType": "*bool" - } - ] - }, - { - "Name": "Data plane: Common", - "Fields": [ - { - "Group": "Data plane: Common", - "GroupWithSortPrefix": "10 Dataplane: Common", - "NameConfigFile": "AllowIPIPPacketsFromWorkloads", - "NameEnvVar": "FELIX_AllowIPIPPacketsFromWorkloads", - "NameYAML": "allowIPIPPacketsFromWorkloads", - "NameGoAPI": "AllowIPIPPacketsFromWorkloads", - "StringSchema": "Boolean: `true`, `1`, `yes`, `y`, `t` accepted as True; `false`, `0`, `no`, `n`, `f` accepted (case insensitively) as False.", - "StringSchemaHTML": "Boolean: true, 1, yes, y, t accepted as True; false, 0, no, n, f accepted (case insensitively) as False.", - "StringDefault": "false", - "ParsedDefault": "false", - "ParsedDefaultJSON": "false", - "ParsedType": "bool", - "YAMLType": "boolean", - "YAMLSchema": "Boolean.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Boolean.", - "YAMLDefault": "false", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Controls whether Felix will add a rule to drop IPIP encapsulated traffic from workloads.", - "DescriptionHTML": "

    Controls whether Felix will add a rule to drop IPIP encapsulated traffic from workloads.

    ", - "UserEditable": true, - "GoType": "*bool" - }, - { - "Group": "Data plane: Common", - "GroupWithSortPrefix": "10 Dataplane: Common", - "NameConfigFile": "AllowVXLANPacketsFromWorkloads", - "NameEnvVar": "FELIX_AllowVXLANPacketsFromWorkloads", - "NameYAML": "allowVXLANPacketsFromWorkloads", - "NameGoAPI": "AllowVXLANPacketsFromWorkloads", - "StringSchema": "Boolean: `true`, `1`, `yes`, `y`, `t` accepted as True; `false`, `0`, `no`, `n`, `f` accepted (case insensitively) as False.", - "StringSchemaHTML": "Boolean: true, 1, yes, y, t accepted as True; false, 0, no, n, f accepted (case insensitively) as False.", - "StringDefault": "false", - "ParsedDefault": "false", - "ParsedDefaultJSON": "false", - "ParsedType": "bool", - "YAMLType": "boolean", - "YAMLSchema": "Boolean.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Boolean.", - "YAMLDefault": "false", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Controls whether Felix will add a rule to drop VXLAN encapsulated traffic from workloads.", - "DescriptionHTML": "

    Controls whether Felix will add a rule to drop VXLAN encapsulated traffic from workloads.

    ", - "UserEditable": true, - "GoType": "*bool" - }, - { - "Group": "Data plane: Common", - "GroupWithSortPrefix": "10 Dataplane: Common", - "NameConfigFile": "ChainInsertMode", - "NameEnvVar": "FELIX_ChainInsertMode", - "NameYAML": "chainInsertMode", - "NameGoAPI": "ChainInsertMode", - "StringSchema": "One of: `append`, `insert` (case insensitive)", - "StringSchemaHTML": "One of: append, insert (case insensitive)", - "StringDefault": "insert", - "ParsedDefault": "insert", - "ParsedDefaultJSON": "\"insert\"", - "ParsedType": "string", - "YAMLType": "string", - "YAMLSchema": "One of: `Append`, `Insert`.", - "YAMLEnumValues": [ - "Append", - "Insert" - ], - "YAMLSchemaHTML": "One of: Append, Insert.", - "YAMLDefault": "Insert", - "Required": true, - "OnParseFailure": "Exit", - "AllowedConfigSources": "All", - "Description": "Controls whether Felix hooks the kernel's top-level iptables chains by inserting a rule at the top of the chain or by appending a rule at the bottom. insert is the safe default since it prevents Calico's rules from being bypassed. If you switch to append mode, be sure that the other rules in the chains signal acceptance by falling through to the Calico rules, otherwise the Calico policy will be bypassed.", - "DescriptionHTML": "

    Controls whether Felix hooks the kernel's top-level iptables chains by inserting a rule at the top of the chain or by appending a rule at the bottom. insert is the safe default since it prevents Calico's rules from being bypassed. If you switch to append mode, be sure that the other rules in the chains signal acceptance by falling through to the Calico rules, otherwise the Calico policy will be bypassed.

    ", - "UserEditable": true, - "GoType": "string" - }, - { - "Group": "Data plane: Common", - "GroupWithSortPrefix": "10 Dataplane: Common", - "NameConfigFile": "DataplaneDriver", - "NameEnvVar": "FELIX_DataplaneDriver", - "NameYAML": "dataplaneDriver", - "NameGoAPI": "DataplaneDriver", - "StringSchema": "Path to executable, which must exist. If not an absolute path, the directory containing this binary and the system path will be searched.", - "StringSchemaHTML": "Path to executable, which must exist. If not an absolute path, the directory containing this binary and the system path will be searched.", - "StringDefault": "calico-iptables-plugin", - "ParsedDefault": "calico-iptables-plugin", - "ParsedDefaultJSON": "\"calico-iptables-plugin\"", - "ParsedType": "string", - "YAMLType": "string", - "YAMLSchema": "String.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "String.", - "YAMLDefault": "calico-iptables-plugin", - "Required": true, - "OnParseFailure": "Exit", - "AllowedConfigSources": "All", - "Description": "Filename of the external dataplane driver to use. Only used if UseInternalDataplaneDriver is set to false.", - "DescriptionHTML": "

    Filename of the external dataplane driver to use. Only used if UseInternalDataplaneDriver is set to false.

    ", - "UserEditable": true, - "GoType": "string" - }, - { - "Group": "Data plane: Common", - "GroupWithSortPrefix": "10 Dataplane: Common", - "NameConfigFile": "DataplaneWatchdogTimeout", - "NameEnvVar": "FELIX_DataplaneWatchdogTimeout", - "NameYAML": "dataplaneWatchdogTimeout", - "NameGoAPI": "DataplaneWatchdogTimeout", - "StringSchema": "Seconds (floating point)", - "StringSchemaHTML": "Seconds (floating point)", - "StringDefault": "90", - "ParsedDefault": "1m30s", - "ParsedDefaultJSON": "90000000000", - "ParsedType": "time.Duration", - "YAMLType": "string", - "YAMLSchema": "Duration string, for example `1m30s123ms` or `1h5m`.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Duration string, for example 1m30s123ms or 1h5m.", - "YAMLDefault": "1m30s", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "The readiness/liveness timeout used for Felix's (internal) dataplane driver. Deprecated: replaced by the generic HealthTimeoutOverrides.", - "DescriptionHTML": "

    The readiness/liveness timeout used for Felix's (internal) dataplane driver. Deprecated: replaced by the generic HealthTimeoutOverrides.

    ", - "UserEditable": true, - "GoType": "*v1.Duration" - }, - { - "Group": "Data plane: Common", - "GroupWithSortPrefix": "10 Dataplane: Common", - "NameConfigFile": "DefaultEndpointToHostAction", - "NameEnvVar": "FELIX_DefaultEndpointToHostAction", - "NameYAML": "defaultEndpointToHostAction", - "NameGoAPI": "DefaultEndpointToHostAction", - "StringSchema": "One of: `ACCEPT`, `DROP`, `RETURN` (case insensitive)", - "StringSchemaHTML": "One of: ACCEPT, DROP, RETURN (case insensitive)", - "StringDefault": "DROP", - "ParsedDefault": "DROP", - "ParsedDefaultJSON": "\"DROP\"", - "ParsedType": "string", - "YAMLType": "string", - "YAMLSchema": "One of: `Accept`, `Drop`, `Return`.", - "YAMLEnumValues": [ - "Accept", - "Drop", - "Return" - ], - "YAMLSchemaHTML": "One of: Accept, Drop, Return.", - "YAMLDefault": "Drop", - "Required": true, - "OnParseFailure": "Exit", - "AllowedConfigSources": "All", - "Description": "Controls what happens to traffic that goes from a workload endpoint to the host itself (after the endpoint's egress policy is applied). By default, Calico blocks traffic from workload endpoints to the host itself with an iptables \"DROP\" action. If you want to allow some or all traffic from endpoint to host, set this parameter to RETURN or ACCEPT. Use RETURN if you have your own rules in the iptables \"INPUT\" chain; Calico will insert its rules at the top of that chain, then \"RETURN\" packets to the \"INPUT\" chain once it has completed processing workload endpoint egress policy. Use ACCEPT to unconditionally accept packets from workloads after processing workload endpoint egress policy.", - "DescriptionHTML": "

    Controls what happens to traffic that goes from a workload endpoint to the host itself (after the endpoint's egress policy is applied). By default, Calico blocks traffic from workload endpoints to the host itself with an iptables \"DROP\" action. If you want to allow some or all traffic from endpoint to host, set this parameter to RETURN or ACCEPT. Use RETURN if you have your own rules in the iptables \"INPUT\" chain; Calico will insert its rules at the top of that chain, then \"RETURN\" packets to the \"INPUT\" chain once it has completed processing workload endpoint egress policy. Use ACCEPT to unconditionally accept packets from workloads after processing workload endpoint egress policy.

    ", - "UserEditable": true, - "GoType": "string" - }, - { - "Group": "Data plane: Common", - "GroupWithSortPrefix": "10 Dataplane: Common", - "NameConfigFile": "DeviceRouteProtocol", - "NameEnvVar": "FELIX_DeviceRouteProtocol", - "NameYAML": "deviceRouteProtocol", - "NameGoAPI": "DeviceRouteProtocol", - "StringSchema": "Integer", - "StringSchemaHTML": "Integer", - "StringDefault": "3", - "ParsedDefault": "3", - "ParsedDefaultJSON": "3", - "ParsedType": "int", - "YAMLType": "integer", - "YAMLSchema": "Integer", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Integer", - "YAMLDefault": "3", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Controls the protocol to set on routes programmed by Felix. The protocol is an 8-bit label used to identify the owner of the route.", - "DescriptionHTML": "

    Controls the protocol to set on routes programmed by Felix. The protocol is an 8-bit label used to identify the owner of the route.

    ", - "UserEditable": true, - "GoType": "*int" - }, - { - "Group": "Data plane: Common", - "GroupWithSortPrefix": "10 Dataplane: Common", - "NameConfigFile": "DeviceRouteSourceAddress", - "NameEnvVar": "FELIX_DeviceRouteSourceAddress", - "NameYAML": "deviceRouteSourceAddress", - "NameGoAPI": "DeviceRouteSourceAddress", - "StringSchema": "IPv4 address", - "StringSchemaHTML": "IPv4 address", - "StringDefault": "", - "ParsedDefault": "", - "ParsedDefaultJSON": "\"\"", - "ParsedType": "net.IP", - "YAMLType": "string", - "YAMLSchema": "String.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "String.", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "IPv4 address to set as the source hint for routes programmed by Felix. When not set the source address for local traffic from host to workload will be determined by the kernel.", - "DescriptionHTML": "

    IPv4 address to set as the source hint for routes programmed by Felix. When not set the source address for local traffic from host to workload will be determined by the kernel.

    ", - "UserEditable": true, - "GoType": "string" - }, - { - "Group": "Data plane: Common", - "GroupWithSortPrefix": "10 Dataplane: Common", - "NameConfigFile": "DeviceRouteSourceAddressIPv6", - "NameEnvVar": "FELIX_DeviceRouteSourceAddressIPv6", - "NameYAML": "deviceRouteSourceAddressIPv6", - "NameGoAPI": "DeviceRouteSourceAddressIPv6", - "StringSchema": "IPv6 address", - "StringSchemaHTML": "IPv6 address", - "StringDefault": "", - "ParsedDefault": "", - "ParsedDefaultJSON": "\"\"", - "ParsedType": "net.IP", - "YAMLType": "string", - "YAMLSchema": "String.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "String.", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "IPv6 address to set as the source hint for routes programmed by Felix. When not set the source address for local traffic from host to workload will be determined by the kernel.", - "DescriptionHTML": "

    IPv6 address to set as the source hint for routes programmed by Felix. When not set the source address for local traffic from host to workload will be determined by the kernel.

    ", - "UserEditable": true, - "GoType": "string" - }, - { - "Group": "Data plane: Common", - "GroupWithSortPrefix": "10 Dataplane: Common", - "NameConfigFile": "DisableConntrackInvalidCheck", - "NameEnvVar": "FELIX_DisableConntrackInvalidCheck", - "NameYAML": "disableConntrackInvalidCheck", - "NameGoAPI": "DisableConntrackInvalidCheck", - "StringSchema": "Boolean: `true`, `1`, `yes`, `y`, `t` accepted as True; `false`, `0`, `no`, `n`, `f` accepted (case insensitively) as False.", - "StringSchemaHTML": "Boolean: true, 1, yes, y, t accepted as True; false, 0, no, n, f accepted (case insensitively) as False.", - "StringDefault": "false", - "ParsedDefault": "false", - "ParsedDefaultJSON": "false", - "ParsedType": "bool", - "YAMLType": "boolean", - "YAMLSchema": "Boolean.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Boolean.", - "YAMLDefault": "false", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Disables the check for invalid connections in conntrack. While the conntrack invalid check helps to detect malicious traffic, it can also cause issues with certain multi-NIC scenarios.", - "DescriptionHTML": "

    Disables the check for invalid connections in conntrack. While the conntrack invalid check helps to detect malicious traffic, it can also cause issues with certain multi-NIC scenarios.

    ", - "UserEditable": true, - "GoType": "*bool" - }, - { - "Group": "Data plane: Common", - "GroupWithSortPrefix": "10 Dataplane: Common", - "NameConfigFile": "EndpointStatusPathPrefix", - "NameEnvVar": "FELIX_EndpointStatusPathPrefix", - "NameYAML": "endpointStatusPathPrefix", - "NameGoAPI": "EndpointStatusPathPrefix", - "StringSchema": "Path to file", - "StringSchemaHTML": "Path to file", - "StringDefault": "", - "ParsedDefault": "", - "ParsedDefaultJSON": "\"\"", - "ParsedType": "string", - "YAMLType": "string", - "YAMLSchema": "String.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "String.", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "The path to the directory where endpoint status will be written. Endpoint status file reporting is disabled if field is left empty.\n\nChosen directory should match the directory used by the CNI plugin for PodStartupDelay.", - "DescriptionHTML": "

    The path to the directory where endpoint status will be written. Endpoint status file reporting is disabled if field is left empty.

    \n

    Chosen directory should match the directory used by the CNI plugin for PodStartupDelay.

    ", - "UserEditable": true, - "GoType": "string" - }, - { - "Group": "Data plane: Common", - "GroupWithSortPrefix": "10 Dataplane: Common", - "NameConfigFile": "ExternalNodesCIDRList", - "NameEnvVar": "FELIX_ExternalNodesCIDRList", - "NameYAML": "externalNodesList", - "NameGoAPI": "ExternalNodesCIDRList", - "StringSchema": "Comma-delimited list of CIDRs", - "StringSchemaHTML": "Comma-delimited list of CIDRs", - "StringDefault": "", - "ParsedDefault": "[]", - "ParsedDefaultJSON": "null", - "ParsedType": "[]string", - "YAMLType": "array", - "YAMLSchema": "List of strings: `[\"\", ...]`.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "List of strings: [\"<string>\", ...].", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "Exit", - "AllowedConfigSources": "All", - "Description": "A list of CIDR's of external, non-Calico nodes from which VXLAN/IPIP overlay traffic will be allowed. By default, external tunneled traffic is blocked to reduce attack surface.", - "DescriptionHTML": "

    A list of CIDR's of external, non-Calico nodes from which VXLAN/IPIP overlay traffic will be allowed. By default, external tunneled traffic is blocked to reduce attack surface.

    ", - "UserEditable": true, - "GoType": "*[]string" - }, - { - "Group": "Data plane: Common", - "GroupWithSortPrefix": "10 Dataplane: Common", - "NameConfigFile": "FailsafeInboundHostPorts", - "NameEnvVar": "FELIX_FailsafeInboundHostPorts", - "NameYAML": "failsafeInboundHostPorts", - "NameGoAPI": "FailsafeInboundHostPorts", - "StringSchema": "Comma-delimited list of numeric ports with optional protocol and CIDR:`(tcp|udp)::`, `(tcp|udp):` or ``. IPv6 CIDRs must be enclosed in square brackets.", - "StringSchemaHTML": "Comma-delimited list of numeric ports with optional protocol and CIDR:(tcp|udp):<cidr>:<port>, (tcp|udp):<port> or <port>. IPv6 CIDRs must be enclosed in square brackets.", - "StringDefault": "tcp:22,udp:68,tcp:179,tcp:2379,tcp:2380,tcp:5473,tcp:6443,tcp:6666,tcp:6667", - "ParsedDefault": "[{tcp 22 } {udp 68 } {tcp 179 } {tcp 2379 } {tcp 2380 } {tcp 5473 } {tcp 6443 } {tcp 6666 } {tcp 6667 }]", - "ParsedDefaultJSON": "[{\"protocol\":\"tcp\",\"port\":22},{\"protocol\":\"udp\",\"port\":68},{\"protocol\":\"tcp\",\"port\":179},{\"protocol\":\"tcp\",\"port\":2379},{\"protocol\":\"tcp\",\"port\":2380},{\"protocol\":\"tcp\",\"port\":5473},{\"protocol\":\"tcp\",\"port\":6443},{\"protocol\":\"tcp\",\"port\":6666},{\"protocol\":\"tcp\",\"port\":6667}]", - "ParsedType": "[]v3.ProtoPort", - "YAMLType": "array", - "YAMLSchema": "List of protocol/port objects with optional CIDR match: `[{protocol: \"TCP|UDP\", port: , net: \"\"}, ...]`.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "List of protocol/port objects with optional CIDR match: [{protocol: \"TCP|UDP\", port: <port>, net: \"<cidr>\"}, ...].", - "YAMLDefault": "[{\"protocol\":\"tcp\",\"port\":22},{\"protocol\":\"udp\",\"port\":68},{\"protocol\":\"tcp\",\"port\":179},{\"protocol\":\"tcp\",\"port\":2379},{\"protocol\":\"tcp\",\"port\":2380},{\"protocol\":\"tcp\",\"port\":5473},{\"protocol\":\"tcp\",\"port\":6443},{\"protocol\":\"tcp\",\"port\":6666},{\"protocol\":\"tcp\",\"port\":6667}]", - "Required": false, - "OnParseFailure": "Exit", - "AllowedConfigSources": "All", - "Description": "A list of ProtoPort struct objects including UDP/TCP/SCTP ports and CIDRs that Felix will allow incoming traffic to host endpoints on irrespective of the security policy. This is useful to avoid accidentally cutting off a host with incorrect configuration. For backwards compatibility, if the protocol is not specified, it defaults to \"tcp\". If a CIDR is not specified, it will allow traffic from all addresses. To disable all inbound host ports, use the value \"[]\". The default value allows ssh access, DHCP, BGP, etcd and the Kubernetes API.", - "DescriptionHTML": "

    A list of ProtoPort struct objects including UDP/TCP/SCTP ports and CIDRs that Felix will allow incoming traffic to host endpoints on irrespective of the security policy. This is useful to avoid accidentally cutting off a host with incorrect configuration. For backwards compatibility, if the protocol is not specified, it defaults to \"tcp\". If a CIDR is not specified, it will allow traffic from all addresses. To disable all inbound host ports, use the value \"[]\". The default value allows ssh access, DHCP, BGP, etcd and the Kubernetes API.

    ", - "UserEditable": true, - "GoType": "*[]v3.ProtoPort" - }, - { - "Group": "Data plane: Common", - "GroupWithSortPrefix": "10 Dataplane: Common", - "NameConfigFile": "FailsafeOutboundHostPorts", - "NameEnvVar": "FELIX_FailsafeOutboundHostPorts", - "NameYAML": "failsafeOutboundHostPorts", - "NameGoAPI": "FailsafeOutboundHostPorts", - "StringSchema": "Comma-delimited list of numeric ports with optional protocol and CIDR:`(tcp|udp)::`, `(tcp|udp):` or ``. IPv6 CIDRs must be enclosed in square brackets.", - "StringSchemaHTML": "Comma-delimited list of numeric ports with optional protocol and CIDR:(tcp|udp):<cidr>:<port>, (tcp|udp):<port> or <port>. IPv6 CIDRs must be enclosed in square brackets.", - "StringDefault": "udp:53,udp:67,tcp:179,tcp:2379,tcp:2380,tcp:5473,tcp:6443,tcp:6666,tcp:6667", - "ParsedDefault": "[{udp 53 } {udp 67 } {tcp 179 } {tcp 2379 } {tcp 2380 } {tcp 5473 } {tcp 6443 } {tcp 6666 } {tcp 6667 }]", - "ParsedDefaultJSON": "[{\"protocol\":\"udp\",\"port\":53},{\"protocol\":\"udp\",\"port\":67},{\"protocol\":\"tcp\",\"port\":179},{\"protocol\":\"tcp\",\"port\":2379},{\"protocol\":\"tcp\",\"port\":2380},{\"protocol\":\"tcp\",\"port\":5473},{\"protocol\":\"tcp\",\"port\":6443},{\"protocol\":\"tcp\",\"port\":6666},{\"protocol\":\"tcp\",\"port\":6667}]", - "ParsedType": "[]v3.ProtoPort", - "YAMLType": "array", - "YAMLSchema": "List of protocol/port objects with optional CIDR match: `[{protocol: \"TCP|UDP\", port: , net: \"\"}, ...]`.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "List of protocol/port objects with optional CIDR match: [{protocol: \"TCP|UDP\", port: <port>, net: \"<cidr>\"}, ...].", - "YAMLDefault": "[{\"protocol\":\"udp\",\"port\":53},{\"protocol\":\"udp\",\"port\":67},{\"protocol\":\"tcp\",\"port\":179},{\"protocol\":\"tcp\",\"port\":2379},{\"protocol\":\"tcp\",\"port\":2380},{\"protocol\":\"tcp\",\"port\":5473},{\"protocol\":\"tcp\",\"port\":6443},{\"protocol\":\"tcp\",\"port\":6666},{\"protocol\":\"tcp\",\"port\":6667}]", - "Required": false, - "OnParseFailure": "Exit", - "AllowedConfigSources": "All", - "Description": "A list of PortProto struct objects including UDP/TCP/SCTP ports and CIDRs that Felix will allow outgoing traffic from host endpoints to irrespective of the security policy. This is useful to avoid accidentally cutting off a host with incorrect configuration. For backwards compatibility, if the protocol is not specified, it defaults to \"tcp\". If a CIDR is not specified, it will allow traffic from all addresses. To disable all outbound host ports, use the value \"[]\". The default value opens etcd's standard ports to ensure that Felix does not get cut off from etcd as well as allowing DHCP, DNS, BGP and the Kubernetes API.", - "DescriptionHTML": "

    A list of PortProto struct objects including UDP/TCP/SCTP ports and CIDRs that Felix will allow outgoing traffic from host endpoints to irrespective of the security policy. This is useful to avoid accidentally cutting off a host with incorrect configuration. For backwards compatibility, if the protocol is not specified, it defaults to \"tcp\". If a CIDR is not specified, it will allow traffic from all addresses. To disable all outbound host ports, use the value \"[]\". The default value opens etcd's standard ports to ensure that Felix does not get cut off from etcd as well as allowing DHCP, DNS, BGP and the Kubernetes API.

    ", - "UserEditable": true, - "GoType": "*[]v3.ProtoPort" - }, - { - "Group": "Data plane: Common", - "GroupWithSortPrefix": "10 Dataplane: Common", - "NameConfigFile": "FloatingIPs", - "NameEnvVar": "FELIX_FloatingIPs", - "NameYAML": "floatingIPs", - "NameGoAPI": "FloatingIPs", - "StringSchema": "One of: `Disabled`, `Enabled` (case insensitive)", - "StringSchemaHTML": "One of: Disabled, Enabled (case insensitive)", - "StringDefault": "Disabled", - "ParsedDefault": "Disabled", - "ParsedDefaultJSON": "\"Disabled\"", - "ParsedType": "string", - "YAMLType": "string", - "YAMLSchema": "One of: `Disabled`, `Enabled`.", - "YAMLEnumValues": [ - "`Disabled`", - "`Enabled`" - ], - "YAMLSchemaHTML": "One of: Disabled, Enabled.", - "YAMLDefault": "Disabled", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Configures whether or not Felix will program non-OpenStack floating IP addresses. (OpenStack-derived floating IPs are always programmed, regardless of this setting.)", - "DescriptionHTML": "

    Configures whether or not Felix will program non-OpenStack floating IP addresses. (OpenStack-derived floating IPs are always programmed, regardless of this setting.)

    ", - "UserEditable": true, - "GoType": "*v3.FloatingIPType" - }, - { - "Group": "Data plane: Common", - "GroupWithSortPrefix": "10 Dataplane: Common", - "NameConfigFile": "IPForwarding", - "NameEnvVar": "FELIX_IPForwarding", - "NameYAML": "ipForwarding", - "NameGoAPI": "IPForwarding", - "StringSchema": "One of: `Disabled`, `Enabled` (case insensitive)", - "StringSchemaHTML": "One of: Disabled, Enabled (case insensitive)", - "StringDefault": "Enabled", - "ParsedDefault": "Enabled", - "ParsedDefaultJSON": "\"Enabled\"", - "ParsedType": "string", - "YAMLType": "string", - "YAMLSchema": "One of: `Disabled`, `Enabled`.", - "YAMLEnumValues": [ - "`Disabled`", - "`Enabled`" - ], - "YAMLSchemaHTML": "One of: Disabled, Enabled.", - "YAMLDefault": "Enabled", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Controls whether Felix sets the host sysctls to enable IP forwarding. IP forwarding is required when using Calico for workload networking. This should be disabled only on hosts where Calico is used solely for host protection.", - "DescriptionHTML": "

    Controls whether Felix sets the host sysctls to enable IP forwarding. IP forwarding is required when using Calico for workload networking. This should be disabled only on hosts where Calico is used solely for host protection.

    ", - "UserEditable": true, - "GoType": "string" - }, - { - "Group": "Data plane: Common", - "GroupWithSortPrefix": "10 Dataplane: Common", - "NameConfigFile": "InterfaceExclude", - "NameEnvVar": "FELIX_InterfaceExclude", - "NameYAML": "interfaceExclude", - "NameGoAPI": "InterfaceExclude", - "StringSchema": "Comma-delimited list of Linux interface names/regex patterns. Regex patterns must start/end with `/`.", - "StringSchemaHTML": "Comma-delimited list of Linux interface names/regex patterns. Regex patterns must start/end with /.", - "StringDefault": "kube-ipvs0", - "ParsedDefault": "[^kube-ipvs0$]", - "ParsedDefaultJSON": "[\"^kube-ipvs0$\"]", - "ParsedType": "[]*regexp.Regexp", - "YAMLType": "string", - "YAMLSchema": "String.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "String.", - "YAMLDefault": "kube-ipvs0", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "A comma-separated list of interface names that should be excluded when Felix is resolving host endpoints. The default value ensures that Felix ignores Kubernetes' internal `kube-ipvs0` device. If you want to exclude multiple interface names using a single value, the list supports regular expressions. For regular expressions you must wrap the value with `/`. For example having values `/^kube/,veth1` will exclude all interfaces that begin with `kube` and also the interface `veth1`.", - "DescriptionHTML": "

    A comma-separated list of interface names that should be excluded when Felix is resolving host endpoints. The default value ensures that Felix ignores Kubernetes' internal kube-ipvs0 device. If you want to exclude multiple interface names using a single value, the list supports regular expressions. For regular expressions you must wrap the value with /. For example having values /^kube/,veth1 will exclude all interfaces that begin with kube and also the interface veth1.

    ", - "UserEditable": true, - "GoType": "string" - }, - { - "Group": "Data plane: Common", - "GroupWithSortPrefix": "10 Dataplane: Common", - "NameConfigFile": "InterfacePrefix", - "NameEnvVar": "FELIX_InterfacePrefix", - "NameYAML": "interfacePrefix", - "NameGoAPI": "InterfacePrefix", - "StringSchema": "String matching regex `^[a-zA-Z0-9_-]{1,15}(,[a-zA-Z0-9_-]{1,15})*$`", - "StringSchemaHTML": "String matching regex ^[a-zA-Z0-9_-]{1,15}(,[a-zA-Z0-9_-]{1,15})*$", - "StringDefault": "cali", - "ParsedDefault": "cali", - "ParsedDefaultJSON": "\"cali\"", - "ParsedType": "string", - "YAMLType": "string", - "YAMLSchema": "String.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "String.", - "YAMLDefault": "cali", - "Required": true, - "OnParseFailure": "Exit", - "AllowedConfigSources": "All", - "Description": "The interface name prefix that identifies workload endpoints and so distinguishes them from host endpoint interfaces. Note: in environments other than bare metal, the orchestrators configure this appropriately. For example our Kubernetes and Docker integrations set the 'cali' value, and our OpenStack integration sets the 'tap' value.", - "DescriptionHTML": "

    The interface name prefix that identifies workload endpoints and so distinguishes them from host endpoint interfaces. Note: in environments other than bare metal, the orchestrators configure this appropriately. For example our Kubernetes and Docker integrations set the 'cali' value, and our OpenStack integration sets the 'tap' value.

    ", - "UserEditable": true, - "GoType": "string" - }, - { - "Group": "Data plane: Common", - "GroupWithSortPrefix": "10 Dataplane: Common", - "NameConfigFile": "InterfaceRefreshInterval", - "NameEnvVar": "FELIX_InterfaceRefreshInterval", - "NameYAML": "interfaceRefreshInterval", - "NameGoAPI": "InterfaceRefreshInterval", - "StringSchema": "Seconds (floating point)", - "StringSchemaHTML": "Seconds (floating point)", - "StringDefault": "90", - "ParsedDefault": "1m30s", - "ParsedDefaultJSON": "90000000000", - "ParsedType": "time.Duration", - "YAMLType": "string", - "YAMLSchema": "Duration string, for example `1m30s123ms` or `1h5m`.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Duration string, for example 1m30s123ms or 1h5m.", - "YAMLDefault": "1m30s", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "The period at which Felix rescans local interfaces to verify their state. The rescan can be disabled by setting the interval to 0.", - "DescriptionHTML": "

    The period at which Felix rescans local interfaces to verify their state. The rescan can be disabled by setting the interval to 0.

    ", - "UserEditable": true, - "GoType": "*v1.Duration" - }, - { - "Group": "Data plane: Common", - "GroupWithSortPrefix": "10 Dataplane: Common", - "NameConfigFile": "Ipv6Support", - "NameEnvVar": "FELIX_Ipv6Support", - "NameYAML": "ipv6Support", - "NameGoAPI": "IPv6Support", - "StringSchema": "Boolean: `true`, `1`, `yes`, `y`, `t` accepted as True; `false`, `0`, `no`, `n`, `f` accepted (case insensitively) as False.", - "StringSchemaHTML": "Boolean: true, 1, yes, y, t accepted as True; false, 0, no, n, f accepted (case insensitively) as False.", - "StringDefault": "true", - "ParsedDefault": "true", - "ParsedDefaultJSON": "true", - "ParsedType": "bool", - "YAMLType": "boolean", - "YAMLSchema": "Boolean.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Boolean.", - "YAMLDefault": "true", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Controls whether Felix enables support for IPv6 (if supported by the in-use dataplane).", - "DescriptionHTML": "

    Controls whether Felix enables support for IPv6 (if supported by the in-use dataplane).

    ", - "UserEditable": true, - "GoType": "*bool" - }, - { - "Group": "Data plane: Common", - "GroupWithSortPrefix": "10 Dataplane: Common", - "NameConfigFile": "MTUIfacePattern", - "NameEnvVar": "FELIX_MTUIfacePattern", - "NameYAML": "mtuIfacePattern", - "NameGoAPI": "MTUIfacePattern", - "StringSchema": "Regular expression", - "StringSchemaHTML": "Regular expression", - "StringDefault": "^((en|wl|ww|sl|ib)[Pcopsvx].*|(eth|wlan|wwan).*)", - "ParsedDefault": "^((en|wl|ww|sl|ib)[Pcopsvx].*|(eth|wlan|wwan).*)", - "ParsedDefaultJSON": "\"^((en|wl|ww|sl|ib)[Pcopsvx].*|(eth|wlan|wwan).*)\"", - "ParsedType": "*regexp.Regexp", - "YAMLType": "string", - "YAMLSchema": "String.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "String.", - "YAMLDefault": "^((en|wl|ww|sl|ib)[Pcopsvx].*|(eth|wlan|wwan).*)", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "A regular expression that controls which interfaces Felix should scan in order to calculate the host's MTU. This should not match workload interfaces (usually named cali...).", - "DescriptionHTML": "

    A regular expression that controls which interfaces Felix should scan in order to calculate the host's MTU. This should not match workload interfaces (usually named cali...).

    ", - "UserEditable": true, - "GoType": "string" - }, - { - "Group": "Data plane: Common", - "GroupWithSortPrefix": "10 Dataplane: Common", - "NameConfigFile": "NATOutgoingAddress", - "NameEnvVar": "FELIX_NATOutgoingAddress", - "NameYAML": "natOutgoingAddress", - "NameGoAPI": "NATOutgoingAddress", - "StringSchema": "IPv4 address", - "StringSchemaHTML": "IPv4 address", - "StringDefault": "", - "ParsedDefault": "", - "ParsedDefaultJSON": "\"\"", - "ParsedType": "net.IP", - "YAMLType": "string", - "YAMLSchema": "String.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "String.", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Specifies an address to use when performing source NAT for traffic in a natOutgoing pool that is leaving the network. By default the address used is an address on the interface the traffic is leaving on (i.e. it uses the iptables MASQUERADE target).", - "DescriptionHTML": "

    Specifies an address to use when performing source NAT for traffic in a natOutgoing pool that is leaving the network. By default the address used is an address on the interface the traffic is leaving on (i.e. it uses the iptables MASQUERADE target).

    ", - "UserEditable": true, - "GoType": "string" - }, - { - "Group": "Data plane: Common", - "GroupWithSortPrefix": "10 Dataplane: Common", - "NameConfigFile": "NATPortRange", - "NameEnvVar": "FELIX_NATPortRange", - "NameYAML": "natPortRange", - "NameGoAPI": "NATPortRange", - "StringSchema": "Port range: either a single number in [0,65535] or a range of numbers `n:m`", - "StringSchemaHTML": "Port range: either a single number in [0,65535] or a range of numbers n:m", - "StringDefault": "", - "ParsedDefault": "0", - "ParsedDefaultJSON": "0", - "ParsedType": "numorstring.Port", - "YAMLType": "integer or string", - "YAMLSchema": "String.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "String.", - "YAMLDefault": "0", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Specifies the range of ports that is used for port mapping when doing outgoing NAT. When unset the default behavior of the network stack is used.", - "DescriptionHTML": "

    Specifies the range of ports that is used for port mapping when doing outgoing NAT. When unset the default behavior of the network stack is used.

    ", - "UserEditable": true, - "GoType": "*numorstring.Port" - }, - { - "Group": "Data plane: Common", - "GroupWithSortPrefix": "10 Dataplane: Common", - "NameConfigFile": "NFTablesMode", - "NameEnvVar": "FELIX_NFTablesMode", - "NameYAML": "nftablesMode", - "NameGoAPI": "NFTablesMode", - "StringSchema": "One of: `Disabled`, `Enabled` (case insensitive)", - "StringSchemaHTML": "One of: Disabled, Enabled (case insensitive)", - "StringDefault": "Disabled", - "ParsedDefault": "Disabled", - "ParsedDefaultJSON": "\"Disabled\"", - "ParsedType": "string", - "YAMLType": "string", - "YAMLSchema": "One of: `Auto`, `Disabled`, `Enabled`.", - "YAMLEnumValues": [ - "`Auto`", - "`Disabled`", - "`Enabled`" - ], - "YAMLSchemaHTML": "One of: Auto, Disabled, Enabled.", - "YAMLDefault": "Disabled", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Configures nftables support in Felix.", - "DescriptionHTML": "

    Configures nftables support in Felix.

    ", - "UserEditable": true, - "GoType": "*v3.NFTablesMode" - }, - { - "Group": "Data plane: Common", - "GroupWithSortPrefix": "10 Dataplane: Common", - "NameConfigFile": "NetlinkTimeoutSecs", - "NameEnvVar": "FELIX_NetlinkTimeoutSecs", - "NameYAML": "netlinkTimeout", - "NameGoAPI": "NetlinkTimeout", - "StringSchema": "Seconds (floating point)", - "StringSchemaHTML": "Seconds (floating point)", - "StringDefault": "10", - "ParsedDefault": "10s", - "ParsedDefaultJSON": "10000000000", - "ParsedType": "time.Duration", - "YAMLType": "string", - "YAMLSchema": "Duration string, for example `1m30s123ms` or `1h5m`.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Duration string, for example 1m30s123ms or 1h5m.", - "YAMLDefault": "10s", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "The timeout when talking to the kernel over the netlink protocol, used for programming routes, rules, and other kernel objects.", - "DescriptionHTML": "

    The timeout when talking to the kernel over the netlink protocol, used for programming routes, rules, and other kernel objects.

    ", - "UserEditable": true, - "GoType": "*v1.Duration" - }, - { - "Group": "Data plane: Common", - "GroupWithSortPrefix": "10 Dataplane: Common", - "NameConfigFile": "PolicySyncPathPrefix", - "NameEnvVar": "FELIX_PolicySyncPathPrefix", - "NameYAML": "policySyncPathPrefix", - "NameGoAPI": "PolicySyncPathPrefix", - "StringSchema": "Path to file", - "StringSchemaHTML": "Path to file", - "StringDefault": "", - "ParsedDefault": "", - "ParsedDefaultJSON": "\"\"", - "ParsedType": "string", - "YAMLType": "string", - "YAMLSchema": "String.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "String.", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Used to by Felix to communicate policy changes to external services, like Application layer policy.", - "DescriptionHTML": "

    Used to by Felix to communicate policy changes to external services, like Application layer policy.

    ", - "UserEditable": true, - "GoType": "string" - }, - { - "Group": "Data plane: Common", - "GroupWithSortPrefix": "10 Dataplane: Common", - "NameConfigFile": "RemoveExternalRoutes", - "NameEnvVar": "FELIX_RemoveExternalRoutes", - "NameYAML": "removeExternalRoutes", - "NameGoAPI": "RemoveExternalRoutes", - "StringSchema": "Boolean: `true`, `1`, `yes`, `y`, `t` accepted as True; `false`, `0`, `no`, `n`, `f` accepted (case insensitively) as False.", - "StringSchemaHTML": "Boolean: true, 1, yes, y, t accepted as True; false, 0, no, n, f accepted (case insensitively) as False.", - "StringDefault": "true", - "ParsedDefault": "true", - "ParsedDefaultJSON": "true", - "ParsedType": "bool", - "YAMLType": "boolean", - "YAMLSchema": "Boolean.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Boolean.", - "YAMLDefault": "true", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Controls whether Felix will remove unexpected routes to workload interfaces. Felix will always clean up expected routes that use the configured DeviceRouteProtocol. To add your own routes, you must use a distinct protocol (in addition to setting this field to false).", - "DescriptionHTML": "

    Controls whether Felix will remove unexpected routes to workload interfaces. Felix will always clean up expected routes that use the configured DeviceRouteProtocol. To add your own routes, you must use a distinct protocol (in addition to setting this field to false).

    ", - "UserEditable": true, - "GoType": "*bool" - }, - { - "Group": "Data plane: Common", - "GroupWithSortPrefix": "10 Dataplane: Common", - "NameConfigFile": "RouteRefreshInterval", - "NameEnvVar": "FELIX_RouteRefreshInterval", - "NameYAML": "routeRefreshInterval", - "NameGoAPI": "RouteRefreshInterval", - "StringSchema": "Seconds (floating point)", - "StringSchemaHTML": "Seconds (floating point)", - "StringDefault": "90", - "ParsedDefault": "1m30s", - "ParsedDefaultJSON": "90000000000", - "ParsedType": "time.Duration", - "YAMLType": "string", - "YAMLSchema": "Duration string, for example `1m30s123ms` or `1h5m`.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Duration string, for example 1m30s123ms or 1h5m.", - "YAMLDefault": "1m30s", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "The period at which Felix re-checks the routes in the dataplane to ensure that no other process has accidentally broken Calico's rules. Set to 0 to disable route refresh.", - "DescriptionHTML": "

    The period at which Felix re-checks the routes in the dataplane to ensure that no other process has accidentally broken Calico's rules. Set to 0 to disable route refresh.

    ", - "UserEditable": true, - "GoType": "*v1.Duration" - }, - { - "Group": "Data plane: Common", - "GroupWithSortPrefix": "10 Dataplane: Common", - "NameConfigFile": "RouteSource", - "NameEnvVar": "FELIX_RouteSource", - "NameYAML": "routeSource", - "NameGoAPI": "RouteSource", - "StringSchema": "One of: `CalicoIPAM`, `WorkloadIPs` (case insensitive)", - "StringSchemaHTML": "One of: CalicoIPAM, WorkloadIPs (case insensitive)", - "StringDefault": "CalicoIPAM", - "ParsedDefault": "CalicoIPAM", - "ParsedDefaultJSON": "\"CalicoIPAM\"", - "ParsedType": "string", - "YAMLType": "string", - "YAMLSchema": "One of: `CalicoIPAM`, `WorkloadIPs`.", - "YAMLEnumValues": [ - "CalicoIPAM", - "WorkloadIPs" - ], - "YAMLSchemaHTML": "One of: CalicoIPAM, WorkloadIPs.", - "YAMLDefault": "CalicoIPAM", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Configures where Felix gets its routing information. - WorkloadIPs: use workload endpoints to construct routes. - CalicoIPAM: the default - use IPAM data to construct routes.", - "DescriptionHTML": "

    Configures where Felix gets its routing information. - WorkloadIPs: use workload endpoints to construct routes. - CalicoIPAM: the default - use IPAM data to construct routes.

    ", - "UserEditable": true, - "GoType": "string" - }, - { - "Group": "Data plane: Common", - "GroupWithSortPrefix": "10 Dataplane: Common", - "NameConfigFile": "RouteSyncDisabled", - "NameEnvVar": "FELIX_RouteSyncDisabled", - "NameYAML": "routeSyncDisabled", - "NameGoAPI": "RouteSyncDisabled", - "StringSchema": "Boolean: `true`, `1`, `yes`, `y`, `t` accepted as True; `false`, `0`, `no`, `n`, `f` accepted (case insensitively) as False.", - "StringSchemaHTML": "Boolean: true, 1, yes, y, t accepted as True; false, 0, no, n, f accepted (case insensitively) as False.", - "StringDefault": "false", - "ParsedDefault": "false", - "ParsedDefaultJSON": "false", - "ParsedType": "bool", - "YAMLType": "boolean", - "YAMLSchema": "Boolean.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Boolean.", - "YAMLDefault": "false", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Will disable all operations performed on the route table. Set to true to run in network-policy mode only.", - "DescriptionHTML": "

    Will disable all operations performed on the route table. Set to true to run in network-policy mode only.

    ", - "UserEditable": true, - "GoType": "*bool" - }, - { - "Group": "Data plane: Common", - "GroupWithSortPrefix": "10 Dataplane: Common", - "NameConfigFile": "RouteTableRange", - "NameEnvVar": "FELIX_RouteTableRange", - "NameYAML": "routeTableRange", - "NameGoAPI": "RouteTableRange", - "StringSchema": "Range of route table indices `n-m`, where `n` and `m` are integers in [0,250].", - "StringSchemaHTML": "Range of route table indices n-m, where n and m are integers in [0,250].", - "StringDefault": "", - "ParsedDefault": "{0 0}", - "ParsedDefaultJSON": "{\"Min\":0,\"Max\":0}", - "ParsedType": "idalloc.IndexRange", - "YAMLType": "object", - "YAMLSchema": "Route table range: `{min:, max}`.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Route table range: {min:<n>, max<m>}.", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "Exit", - "AllowedConfigSources": "All", - "Description": "Deprecated in favor of RouteTableRanges. Calico programs additional Linux route tables for various purposes. RouteTableRange specifies the indices of the route tables that Calico should use.", - "DescriptionHTML": "

    Deprecated in favor of RouteTableRanges. Calico programs additional Linux route tables for various purposes. RouteTableRange specifies the indices of the route tables that Calico should use.

    ", - "UserEditable": true, - "GoType": "*v3.RouteTableRange" - }, - { - "Group": "Data plane: Common", - "GroupWithSortPrefix": "10 Dataplane: Common", - "NameConfigFile": "RouteTableRanges", - "NameEnvVar": "FELIX_RouteTableRanges", - "NameYAML": "routeTableRanges", - "NameGoAPI": "RouteTableRanges", - "StringSchema": "Comma or space-delimited list of route table ranges of the form `n-m` where `n` and `m` are integers in [0,4294967295]. The sum of the sizes of all ranges may not exceed 65535.", - "StringSchemaHTML": "Comma or space-delimited list of route table ranges of the form n-m where n and m are integers in [0,4294967295]. The sum of the sizes of all ranges may not exceed 65535.", - "StringDefault": "", - "ParsedDefault": "[]", - "ParsedDefaultJSON": "null", - "ParsedType": "[]idalloc.IndexRange", - "YAMLType": "array", - "YAMLSchema": "List of route table ranges: `[{min:, max}, ...]`.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "List of route table ranges: [{min:<n>, max<m>}, ...].", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "Exit", - "AllowedConfigSources": "All", - "Description": "Calico programs additional Linux route tables for various purposes. RouteTableRanges specifies a set of table index ranges that Calico should use. Deprecates`RouteTableRange`, overrides `RouteTableRange`.", - "DescriptionHTML": "

    Calico programs additional Linux route tables for various purposes. RouteTableRanges specifies a set of table index ranges that Calico should use. DeprecatesRouteTableRange, overrides RouteTableRange.

    ", - "UserEditable": true, - "GoType": "*v3.RouteTableRanges" - }, - { - "Group": "Data plane: Common", - "GroupWithSortPrefix": "10 Dataplane: Common", - "NameConfigFile": "ServiceLoopPrevention", - "NameEnvVar": "FELIX_ServiceLoopPrevention", - "NameYAML": "serviceLoopPrevention", - "NameGoAPI": "ServiceLoopPrevention", - "StringSchema": "One of: `Disabled`, `Drop`, `Reject` (case insensitive)", - "StringSchemaHTML": "One of: Disabled, Drop, Reject (case insensitive)", - "StringDefault": "Drop", - "ParsedDefault": "Drop", - "ParsedDefaultJSON": "\"Drop\"", - "ParsedType": "string", - "YAMLType": "string", - "YAMLSchema": "One of: `Disabled`, `Drop`, `Reject`.", - "YAMLEnumValues": [ - "Disabled", - "Drop", - "Reject" - ], - "YAMLSchemaHTML": "One of: Disabled, Drop, Reject.", - "YAMLDefault": "Drop", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "When service IP advertisement is enabled, prevent routing loops to service IPs that are not in use, by dropping or rejecting packets that do not get DNAT'd by kube-proxy. Unless set to \"Disabled\", in which case such routing loops continue to be allowed.", - "DescriptionHTML": "

    When service IP advertisement is enabled, prevent routing loops to service IPs that are not in use, by dropping or rejecting packets that do not get DNAT'd by kube-proxy. Unless set to \"Disabled\", in which case such routing loops continue to be allowed.

    ", - "UserEditable": true, - "GoType": "string" - }, - { - "Group": "Data plane: Common", - "GroupWithSortPrefix": "10 Dataplane: Common", - "NameConfigFile": "SidecarAccelerationEnabled", - "NameEnvVar": "FELIX_SidecarAccelerationEnabled", - "NameYAML": "sidecarAccelerationEnabled", - "NameGoAPI": "SidecarAccelerationEnabled", - "StringSchema": "Boolean: `true`, `1`, `yes`, `y`, `t` accepted as True; `false`, `0`, `no`, `n`, `f` accepted (case insensitively) as False.", - "StringSchemaHTML": "Boolean: true, 1, yes, y, t accepted as True; false, 0, no, n, f accepted (case insensitively) as False.", - "StringDefault": "false", - "ParsedDefault": "false", - "ParsedDefaultJSON": "false", - "ParsedType": "bool", - "YAMLType": "boolean", - "YAMLSchema": "Boolean.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Boolean.", - "YAMLDefault": "false", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Enables experimental sidecar acceleration.", - "DescriptionHTML": "

    Enables experimental sidecar acceleration.

    ", - "UserEditable": true, - "GoType": "*bool" - }, - { - "Group": "Data plane: Common", - "GroupWithSortPrefix": "10 Dataplane: Common", - "NameConfigFile": "UseInternalDataplaneDriver", - "NameEnvVar": "FELIX_UseInternalDataplaneDriver", - "NameYAML": "useInternalDataplaneDriver", - "NameGoAPI": "UseInternalDataplaneDriver", - "StringSchema": "Boolean: `true`, `1`, `yes`, `y`, `t` accepted as True; `false`, `0`, `no`, `n`, `f` accepted (case insensitively) as False.", - "StringSchemaHTML": "Boolean: true, 1, yes, y, t accepted as True; false, 0, no, n, f accepted (case insensitively) as False.", - "StringDefault": "true", - "ParsedDefault": "true", - "ParsedDefaultJSON": "true", - "ParsedType": "bool", - "YAMLType": "boolean", - "YAMLSchema": "Boolean.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Boolean.", - "YAMLDefault": "true", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "If true, Felix will use its internal dataplane programming logic. If false, it will launch an external dataplane driver and communicate with it over protobuf.", - "DescriptionHTML": "

    If true, Felix will use its internal dataplane programming logic. If false, it will launch an external dataplane driver and communicate with it over protobuf.

    ", - "UserEditable": true, - "GoType": "*bool" - }, - { - "Group": "Data plane: Common", - "GroupWithSortPrefix": "10 Dataplane: Common", - "NameConfigFile": "WorkloadSourceSpoofing", - "NameEnvVar": "FELIX_WorkloadSourceSpoofing", - "NameYAML": "workloadSourceSpoofing", - "NameGoAPI": "WorkloadSourceSpoofing", - "StringSchema": "One of: `Any`, `Disabled` (case insensitive)", - "StringSchemaHTML": "One of: Any, Disabled (case insensitive)", - "StringDefault": "Disabled", - "ParsedDefault": "Disabled", - "ParsedDefaultJSON": "\"Disabled\"", - "ParsedType": "string", - "YAMLType": "string", - "YAMLSchema": "One of: `Any`, `Disabled`.", - "YAMLEnumValues": [ - "Any", - "Disabled" - ], - "YAMLSchemaHTML": "One of: Any, Disabled.", - "YAMLDefault": "Disabled", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Controls whether pods can use the allowedSourcePrefixes annotation to send traffic with a source IP address that is not theirs. This is disabled by default. When set to \"Any\", pods can request any prefix.", - "DescriptionHTML": "

    Controls whether pods can use the allowedSourcePrefixes annotation to send traffic with a source IP address that is not theirs. This is disabled by default. When set to \"Any\", pods can request any prefix.

    ", - "UserEditable": true, - "GoType": "string" - } - ] - }, - { - "Name": "Data plane: iptables", - "Fields": [ - { - "Group": "Data plane: iptables", - "GroupWithSortPrefix": "20 Dataplane: iptables", - "NameConfigFile": "IpsetsRefreshInterval", - "NameEnvVar": "FELIX_IpsetsRefreshInterval", - "NameYAML": "ipsetsRefreshInterval", - "NameGoAPI": "IpsetsRefreshInterval", - "StringSchema": "Seconds (floating point)", - "StringSchemaHTML": "Seconds (floating point)", - "StringDefault": "90", - "ParsedDefault": "1m30s", - "ParsedDefaultJSON": "90000000000", - "ParsedType": "time.Duration", - "YAMLType": "string", - "YAMLSchema": "Duration string, for example `1m30s123ms` or `1h5m`.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Duration string, for example 1m30s123ms or 1h5m.", - "YAMLDefault": "1m30s", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Controls the period at which Felix re-checks all IP sets to look for discrepancies. Set to 0 to disable the periodic refresh.", - "DescriptionHTML": "

    Controls the period at which Felix re-checks all IP sets to look for discrepancies. Set to 0 to disable the periodic refresh.

    ", - "UserEditable": true, - "GoType": "*v1.Duration" - }, - { - "Group": "Data plane: iptables", - "GroupWithSortPrefix": "20 Dataplane: iptables", - "NameConfigFile": "IptablesBackend", - "NameEnvVar": "FELIX_IptablesBackend", - "NameYAML": "iptablesBackend", - "NameGoAPI": "IptablesBackend", - "StringSchema": "One of: `auto`, `legacy`, `nft` (case insensitive)", - "StringSchemaHTML": "One of: auto, legacy, nft (case insensitive)", - "StringDefault": "auto", - "ParsedDefault": "auto", - "ParsedDefaultJSON": "\"auto\"", - "ParsedType": "string", - "YAMLType": "string", - "YAMLSchema": "One of: `Auto`, `Legacy`, `NFT`.", - "YAMLEnumValues": [ - "Auto", - "Legacy", - "NFT" - ], - "YAMLSchemaHTML": "One of: Auto, Legacy, NFT.", - "YAMLDefault": "Auto", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Controls which backend of iptables will be used. The default is `Auto`.\n\nWarning: changing this on a running system can leave \"orphaned\" rules in the \"other\" backend. These should be cleaned up to avoid confusing interactions.", - "DescriptionHTML": "

    Controls which backend of iptables will be used. The default is Auto.

    \n

    Warning: changing this on a running system can leave \"orphaned\" rules in the \"other\" backend. These should be cleaned up to avoid confusing interactions.

    ", - "UserEditable": true, - "GoType": "*v3.IptablesBackend" - }, - { - "Group": "Data plane: iptables", - "GroupWithSortPrefix": "20 Dataplane: iptables", - "NameConfigFile": "IptablesFilterAllowAction", - "NameEnvVar": "FELIX_IptablesFilterAllowAction", - "NameYAML": "iptablesFilterAllowAction", - "NameGoAPI": "IptablesFilterAllowAction", - "StringSchema": "One of: `ACCEPT`, `RETURN` (case insensitive)", - "StringSchemaHTML": "One of: ACCEPT, RETURN (case insensitive)", - "StringDefault": "ACCEPT", - "ParsedDefault": "ACCEPT", - "ParsedDefaultJSON": "\"ACCEPT\"", - "ParsedType": "string", - "YAMLType": "string", - "YAMLSchema": "One of: `Accept`, `Return`.", - "YAMLEnumValues": [ - "Accept", - "Return" - ], - "YAMLSchemaHTML": "One of: Accept, Return.", - "YAMLDefault": "Accept", - "Required": true, - "OnParseFailure": "Exit", - "AllowedConfigSources": "All", - "Description": "Controls what happens to traffic that is accepted by a Felix policy chain in the iptables filter table (which is used for \"normal\" policy). The default will immediately `Accept` the traffic. Use `Return` to send the traffic back up to the system chains for further processing.", - "DescriptionHTML": "

    Controls what happens to traffic that is accepted by a Felix policy chain in the iptables filter table (which is used for \"normal\" policy). The default will immediately Accept the traffic. Use Return to send the traffic back up to the system chains for further processing.

    ", - "UserEditable": true, - "GoType": "string" - }, - { - "Group": "Data plane: iptables", - "GroupWithSortPrefix": "20 Dataplane: iptables", - "NameConfigFile": "IptablesFilterDenyAction", - "NameEnvVar": "FELIX_IptablesFilterDenyAction", - "NameYAML": "iptablesFilterDenyAction", - "NameGoAPI": "IptablesFilterDenyAction", - "StringSchema": "One of: `DROP`, `REJECT` (case insensitive)", - "StringSchemaHTML": "One of: DROP, REJECT (case insensitive)", - "StringDefault": "DROP", - "ParsedDefault": "DROP", - "ParsedDefaultJSON": "\"DROP\"", - "ParsedType": "string", - "YAMLType": "string", - "YAMLSchema": "One of: `Drop`, `Reject`.", - "YAMLEnumValues": [ - "Drop", - "Reject" - ], - "YAMLSchemaHTML": "One of: Drop, Reject.", - "YAMLDefault": "Drop", - "Required": true, - "OnParseFailure": "Exit", - "AllowedConfigSources": "All", - "Description": "Controls what happens to traffic that is denied by network policy. By default Calico blocks traffic with an iptables \"DROP\" action. If you want to use \"REJECT\" action instead you can configure it in here.", - "DescriptionHTML": "

    Controls what happens to traffic that is denied by network policy. By default Calico blocks traffic with an iptables \"DROP\" action. If you want to use \"REJECT\" action instead you can configure it in here.

    ", - "UserEditable": true, - "GoType": "string" - }, - { - "Group": "Data plane: iptables", - "GroupWithSortPrefix": "20 Dataplane: iptables", - "NameConfigFile": "IptablesLockFilePath", - "NameEnvVar": "FELIX_IptablesLockFilePath", - "NameYAML": "iptablesLockFilePath", - "NameGoAPI": "IptablesLockFilePath", - "StringSchema": "Path to file", - "StringSchemaHTML": "Path to file", - "StringDefault": "/run/xtables.lock", - "ParsedDefault": "/run/xtables.lock", - "ParsedDefaultJSON": "\"/run/xtables.lock\"", - "ParsedType": "string", - "YAMLType": "string", - "YAMLSchema": "String.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "String.", - "YAMLDefault": "/run/xtables.lock", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "The location of the iptables lock file. You may need to change this if the lock file is not in its standard location (for example if you have mapped it into Felix's container at a different path).", - "DescriptionHTML": "

    The location of the iptables lock file. You may need to change this if the lock file is not in its standard location (for example if you have mapped it into Felix's container at a different path).

    ", - "UserEditable": true, - "GoType": "string" - }, - { - "Group": "Data plane: iptables", - "GroupWithSortPrefix": "20 Dataplane: iptables", - "NameConfigFile": "IptablesLockProbeIntervalMillis", - "NameEnvVar": "FELIX_IptablesLockProbeIntervalMillis", - "NameYAML": "iptablesLockProbeInterval", - "NameGoAPI": "IptablesLockProbeInterval", - "StringSchema": "Milliseconds (floating point)", - "StringSchemaHTML": "Milliseconds (floating point)", - "StringDefault": "50", - "ParsedDefault": "50ms", - "ParsedDefaultJSON": "50000000", - "ParsedType": "time.Duration", - "YAMLType": "string", - "YAMLSchema": "Duration string, for example `1m30s123ms` or `1h5m`.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Duration string, for example 1m30s123ms or 1h5m.", - "YAMLDefault": "50ms", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "When IptablesLockTimeout is enabled: the time that Felix will wait between attempts to acquire the iptables lock if it is not available. Lower values make Felix more responsive when the lock is contended, but use more CPU.", - "DescriptionHTML": "

    When IptablesLockTimeout is enabled: the time that Felix will wait between attempts to acquire the iptables lock if it is not available. Lower values make Felix more responsive when the lock is contended, but use more CPU.

    ", - "UserEditable": true, - "GoType": "*v1.Duration" - }, - { - "Group": "Data plane: iptables", - "GroupWithSortPrefix": "20 Dataplane: iptables", - "NameConfigFile": "IptablesLockTimeoutSecs", - "NameEnvVar": "FELIX_IptablesLockTimeoutSecs", - "NameYAML": "iptablesLockTimeout", - "NameGoAPI": "IptablesLockTimeout", - "StringSchema": "Seconds (floating point)", - "StringSchemaHTML": "Seconds (floating point)", - "StringDefault": "0", - "ParsedDefault": "0s", - "ParsedDefaultJSON": "0", - "ParsedType": "time.Duration", - "YAMLType": "string", - "YAMLSchema": "Duration string, for example `1m30s123ms` or `1h5m`.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Duration string, for example 1m30s123ms or 1h5m.", - "YAMLDefault": "0s", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "The time that Felix itself will wait for the iptables lock (rather than delegating the lock handling to the `iptables` command).\n\nDeprecated: `iptables-restore` v1.8+ always takes the lock, so enabling this feature results in deadlock.", - "DescriptionHTML": "

    The time that Felix itself will wait for the iptables lock (rather than delegating the lock handling to the iptables command).

    \n

    Deprecated: iptables-restore v1.8+ always takes the lock, so enabling this feature results in deadlock.

    ", - "UserEditable": true, - "GoType": "*v1.Duration" - }, - { - "Group": "Data plane: iptables", - "GroupWithSortPrefix": "20 Dataplane: iptables", - "NameConfigFile": "IptablesMangleAllowAction", - "NameEnvVar": "FELIX_IptablesMangleAllowAction", - "NameYAML": "iptablesMangleAllowAction", - "NameGoAPI": "IptablesMangleAllowAction", - "StringSchema": "One of: `ACCEPT`, `RETURN` (case insensitive)", - "StringSchemaHTML": "One of: ACCEPT, RETURN (case insensitive)", - "StringDefault": "ACCEPT", - "ParsedDefault": "ACCEPT", - "ParsedDefaultJSON": "\"ACCEPT\"", - "ParsedType": "string", - "YAMLType": "string", - "YAMLSchema": "One of: `Accept`, `Return`.", - "YAMLEnumValues": [ - "Accept", - "Return" - ], - "YAMLSchemaHTML": "One of: Accept, Return.", - "YAMLDefault": "Accept", - "Required": true, - "OnParseFailure": "Exit", - "AllowedConfigSources": "All", - "Description": "Controls what happens to traffic that is accepted by a Felix policy chain in the iptables mangle table (which is used for \"pre-DNAT\" policy). The default will immediately `Accept` the traffic. Use `Return` to send the traffic back up to the system chains for further processing.", - "DescriptionHTML": "

    Controls what happens to traffic that is accepted by a Felix policy chain in the iptables mangle table (which is used for \"pre-DNAT\" policy). The default will immediately Accept the traffic. Use Return to send the traffic back up to the system chains for further processing.

    ", - "UserEditable": true, - "GoType": "string" - }, - { - "Group": "Data plane: iptables", - "GroupWithSortPrefix": "20 Dataplane: iptables", - "NameConfigFile": "IptablesMarkMask", - "NameEnvVar": "FELIX_IptablesMarkMask", - "NameYAML": "iptablesMarkMask", - "NameGoAPI": "IptablesMarkMask", - "StringSchema": "32-bit bitmask (hex or deccimal allowed) with at least 2 bits set, example: `0xffff0000`", - "StringSchemaHTML": "32-bit bitmask (hex or deccimal allowed) with at least 2 bits set, example: 0xffff0000", - "StringDefault": "0xffff0000", - "ParsedDefault": "4294901760", - "ParsedDefaultJSON": "4294901760", - "ParsedType": "uint32", - "YAMLType": "integer", - "YAMLSchema": "Unsigned 32-bit integer.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Unsigned 32-bit integer.", - "YAMLDefault": "0xffff0000", - "Required": true, - "OnParseFailure": "Exit", - "AllowedConfigSources": "All", - "Description": "The mask that Felix selects its IPTables Mark bits from. Should be a 32 bit hexadecimal number with at least 8 bits set, none of which clash with any other mark bits in use on the system.", - "DescriptionHTML": "

    The mask that Felix selects its IPTables Mark bits from. Should be a 32 bit hexadecimal number with at least 8 bits set, none of which clash with any other mark bits in use on the system.

    ", - "UserEditable": true, - "GoType": "*uint32" - }, - { - "Group": "Data plane: iptables", - "GroupWithSortPrefix": "20 Dataplane: iptables", - "NameConfigFile": "IptablesNATOutgoingInterfaceFilter", - "NameEnvVar": "FELIX_IptablesNATOutgoingInterfaceFilter", - "NameYAML": "iptablesNATOutgoingInterfaceFilter", - "NameGoAPI": "IptablesNATOutgoingInterfaceFilter", - "StringSchema": "String matching regex `^[a-zA-Z0-9:._+-]{1,15}$`", - "StringSchemaHTML": "String matching regex ^[a-zA-Z0-9:._+-]{1,15}$", - "StringDefault": "", - "ParsedDefault": "", - "ParsedDefaultJSON": "\"\"", - "ParsedType": "string", - "YAMLType": "string", - "YAMLSchema": "String.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "String.", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "This parameter can be used to limit the host interfaces on which Calico will apply SNAT to traffic leaving a Calico IPAM pool with \"NAT outgoing\" enabled. This can be useful if you have a main data interface, where traffic should be SNATted and a secondary device (such as the docker bridge) which is local to the host and doesn't require SNAT. This parameter uses the iptables interface matching syntax, which allows + as a wildcard. Most users will not need to set this. Example: if your data interfaces are eth0 and eth1 and you want to exclude the docker bridge, you could set this to eth+.", - "DescriptionHTML": "

    This parameter can be used to limit the host interfaces on which Calico will apply SNAT to traffic leaving a Calico IPAM pool with \"NAT outgoing\" enabled. This can be useful if you have a main data interface, where traffic should be SNATted and a secondary device (such as the docker bridge) which is local to the host and doesn't require SNAT. This parameter uses the iptables interface matching syntax, which allows + as a wildcard. Most users will not need to set this. Example: if your data interfaces are eth0 and eth1 and you want to exclude the docker bridge, you could set this to eth+.

    ", - "UserEditable": true, - "GoType": "string" - }, - { - "Group": "Data plane: iptables", - "GroupWithSortPrefix": "20 Dataplane: iptables", - "NameConfigFile": "IptablesPostWriteCheckIntervalSecs", - "NameEnvVar": "FELIX_IptablesPostWriteCheckIntervalSecs", - "NameYAML": "iptablesPostWriteCheckInterval", - "NameGoAPI": "IptablesPostWriteCheckInterval", - "StringSchema": "Seconds (floating point)", - "StringSchemaHTML": "Seconds (floating point)", - "StringDefault": "5", - "ParsedDefault": "5s", - "ParsedDefaultJSON": "5000000000", - "ParsedType": "time.Duration", - "YAMLType": "string", - "YAMLSchema": "Duration string, for example `1m30s123ms` or `1h5m`.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Duration string, for example 1m30s123ms or 1h5m.", - "YAMLDefault": "5s", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "The period after Felix has done a write to the dataplane that it schedules an extra read back in order to check the write was not clobbered by another process. This should only occur if another application on the system doesn't respect the iptables lock.", - "DescriptionHTML": "

    The period after Felix has done a write to the dataplane that it schedules an extra read back in order to check the write was not clobbered by another process. This should only occur if another application on the system doesn't respect the iptables lock.

    ", - "UserEditable": true, - "GoType": "*v1.Duration" - }, - { - "Group": "Data plane: iptables", - "GroupWithSortPrefix": "20 Dataplane: iptables", - "NameConfigFile": "IptablesRefreshInterval", - "NameEnvVar": "FELIX_IptablesRefreshInterval", - "NameYAML": "iptablesRefreshInterval", - "NameGoAPI": "IptablesRefreshInterval", - "StringSchema": "Seconds (floating point)", - "StringSchemaHTML": "Seconds (floating point)", - "StringDefault": "180", - "ParsedDefault": "3m0s", - "ParsedDefaultJSON": "180000000000", - "ParsedType": "time.Duration", - "YAMLType": "string", - "YAMLSchema": "Duration string, for example `1m30s123ms` or `1h5m`.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Duration string, for example 1m30s123ms or 1h5m.", - "YAMLDefault": "3m0s", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "The period at which Felix re-checks the IP sets in the dataplane to ensure that no other process has accidentally broken Calico's rules. Set to 0 to disable IP sets refresh. Note: the default for this value is lower than the other refresh intervals as a workaround for a Linux kernel bug that was fixed in kernel version 4.11. If you are using v4.11 or greater you may want to set this to, a higher value to reduce Felix CPU usage.", - "DescriptionHTML": "

    The period at which Felix re-checks the IP sets in the dataplane to ensure that no other process has accidentally broken Calico's rules. Set to 0 to disable IP sets refresh. Note: the default for this value is lower than the other refresh intervals as a workaround for a Linux kernel bug that was fixed in kernel version 4.11. If you are using v4.11 or greater you may want to set this to, a higher value to reduce Felix CPU usage.

    ", - "UserEditable": true, - "GoType": "*v1.Duration" - }, - { - "Group": "Data plane: iptables", - "GroupWithSortPrefix": "20 Dataplane: iptables", - "NameConfigFile": "KubeNodePortRanges", - "NameEnvVar": "FELIX_KubeNodePortRanges", - "NameYAML": "kubeNodePortRanges", - "NameGoAPI": "KubeNodePortRanges", - "StringSchema": "List of port ranges: comma-delimited list of either single numbers in range [0,65535] or a ranges of numbers `n:m`", - "StringSchemaHTML": "List of port ranges: comma-delimited list of either single numbers in range [0,65535] or a ranges of numbers n:m", - "StringDefault": "30000:32767", - "ParsedDefault": "[30000:32767]", - "ParsedDefaultJSON": "[\"30000:32767\"]", - "ParsedType": "[]numorstring.Port", - "YAMLType": "array", - "YAMLSchema": "List of ports: `[, ...]` where `` is a port number (integer) or range (string), for example `80`, `8080:8089`.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "List of ports: [<port>, ...] where <port> is a port number (integer) or range (string), for example 80, 8080:8089.", - "YAMLDefault": "[\"30000:32767\"]", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Holds list of port ranges used for service node ports. Only used if felix detects kube-proxy running in ipvs mode. Felix uses these ranges to separate host and workload traffic. .", - "DescriptionHTML": "

    Holds list of port ranges used for service node ports. Only used if felix detects kube-proxy running in ipvs mode. Felix uses these ranges to separate host and workload traffic. .

    ", - "UserEditable": true, - "GoType": "*[]numorstring.Port" - }, - { - "Group": "Data plane: iptables", - "GroupWithSortPrefix": "20 Dataplane: iptables", - "NameConfigFile": "MaxIpsetSize", - "NameEnvVar": "FELIX_MaxIpsetSize", - "NameYAML": "maxIpsetSize", - "NameGoAPI": "MaxIpsetSize", - "StringSchema": "Integer", - "StringSchemaHTML": "Integer", - "StringDefault": "1048576", - "ParsedDefault": "1048576", - "ParsedDefaultJSON": "1048576", - "ParsedType": "int", - "YAMLType": "integer", - "YAMLSchema": "Integer", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Integer", - "YAMLDefault": "1048576", - "Required": true, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "The maximum number of IP addresses that can be stored in an IP set. Not applicable if using the nftables backend.", - "DescriptionHTML": "

    The maximum number of IP addresses that can be stored in an IP set. Not applicable if using the nftables backend.

    ", - "UserEditable": true, - "GoType": "*int" - } - ] - }, - { - "Name": "Data plane: nftables", - "Fields": [ - { - "Group": "Data plane: nftables", - "GroupWithSortPrefix": "21 Dataplane: nftables", - "NameConfigFile": "NftablesFilterAllowAction", - "NameEnvVar": "FELIX_NftablesFilterAllowAction", - "NameYAML": "nftablesFilterAllowAction", - "NameGoAPI": "NftablesFilterAllowAction", - "StringSchema": "One of: `ACCEPT`, `RETURN` (case insensitive)", - "StringSchemaHTML": "One of: ACCEPT, RETURN (case insensitive)", - "StringDefault": "ACCEPT", - "ParsedDefault": "ACCEPT", - "ParsedDefaultJSON": "\"ACCEPT\"", - "ParsedType": "string", - "YAMLType": "string", - "YAMLSchema": "One of: `Accept`, `Return`.", - "YAMLEnumValues": [ - "Accept", - "Return" - ], - "YAMLSchemaHTML": "One of: Accept, Return.", - "YAMLDefault": "Accept", - "Required": true, - "OnParseFailure": "Exit", - "AllowedConfigSources": "All", - "Description": "Controls the nftables action that Felix uses to represent the \"allow\" policy verdict in the filter table. The default is to `ACCEPT` the traffic, which is a terminal action. Alternatively, `RETURN` can be used to return the traffic back to the top-level chain for further processing by your rules.", - "DescriptionHTML": "

    Controls the nftables action that Felix uses to represent the \"allow\" policy verdict in the filter table. The default is to ACCEPT the traffic, which is a terminal action. Alternatively, RETURN can be used to return the traffic back to the top-level chain for further processing by your rules.

    ", - "UserEditable": true, - "GoType": "string" - }, - { - "Group": "Data plane: nftables", - "GroupWithSortPrefix": "21 Dataplane: nftables", - "NameConfigFile": "NftablesFilterDenyAction", - "NameEnvVar": "FELIX_NftablesFilterDenyAction", - "NameYAML": "nftablesFilterDenyAction", - "NameGoAPI": "NftablesFilterDenyAction", - "StringSchema": "One of: `DROP`, `REJECT` (case insensitive)", - "StringSchemaHTML": "One of: DROP, REJECT (case insensitive)", - "StringDefault": "DROP", - "ParsedDefault": "DROP", - "ParsedDefaultJSON": "\"DROP\"", - "ParsedType": "string", - "YAMLType": "string", - "YAMLSchema": "One of: `Drop`, `Reject`.", - "YAMLEnumValues": [ - "Drop", - "Reject" - ], - "YAMLSchemaHTML": "One of: Drop, Reject.", - "YAMLDefault": "Drop", - "Required": true, - "OnParseFailure": "Exit", - "AllowedConfigSources": "All", - "Description": "Controls what happens to traffic that is denied by network policy. By default, Calico blocks traffic with a \"drop\" action. If you want to use a \"reject\" action instead you can configure it here.", - "DescriptionHTML": "

    Controls what happens to traffic that is denied by network policy. By default, Calico blocks traffic with a \"drop\" action. If you want to use a \"reject\" action instead you can configure it here.

    ", - "UserEditable": true, - "GoType": "string" - }, - { - "Group": "Data plane: nftables", - "GroupWithSortPrefix": "21 Dataplane: nftables", - "NameConfigFile": "NftablesMangleAllowAction", - "NameEnvVar": "FELIX_NftablesMangleAllowAction", - "NameYAML": "nftablesMangleAllowAction", - "NameGoAPI": "NftablesMangleAllowAction", - "StringSchema": "One of: `ACCEPT`, `RETURN` (case insensitive)", - "StringSchemaHTML": "One of: ACCEPT, RETURN (case insensitive)", - "StringDefault": "ACCEPT", - "ParsedDefault": "ACCEPT", - "ParsedDefaultJSON": "\"ACCEPT\"", - "ParsedType": "string", - "YAMLType": "string", - "YAMLSchema": "One of: `Accept`, `Return`.", - "YAMLEnumValues": [ - "Accept", - "Return" - ], - "YAMLSchemaHTML": "One of: Accept, Return.", - "YAMLDefault": "Accept", - "Required": true, - "OnParseFailure": "Exit", - "AllowedConfigSources": "All", - "Description": "Controls the nftables action that Felix uses to represent the \"allow\" policy verdict in the mangle table. The default is to `ACCEPT` the traffic, which is a terminal action. Alternatively, `RETURN` can be used to return the traffic back to the top-level chain for further processing by your rules.", - "DescriptionHTML": "

    Controls the nftables action that Felix uses to represent the \"allow\" policy verdict in the mangle table. The default is to ACCEPT the traffic, which is a terminal action. Alternatively, RETURN can be used to return the traffic back to the top-level chain for further processing by your rules.

    ", - "UserEditable": true, - "GoType": "string" - }, - { - "Group": "Data plane: nftables", - "GroupWithSortPrefix": "21 Dataplane: nftables", - "NameConfigFile": "NftablesMarkMask", - "NameEnvVar": "FELIX_NftablesMarkMask", - "NameYAML": "nftablesMarkMask", - "NameGoAPI": "NftablesMarkMask", - "StringSchema": "32-bit bitmask (hex or deccimal allowed) with at least 2 bits set, example: `0xffff0000`", - "StringSchemaHTML": "32-bit bitmask (hex or deccimal allowed) with at least 2 bits set, example: 0xffff0000", - "StringDefault": "0xffff0000", - "ParsedDefault": "4294901760", - "ParsedDefaultJSON": "4294901760", - "ParsedType": "uint32", - "YAMLType": "integer", - "YAMLSchema": "Unsigned 32-bit integer.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Unsigned 32-bit integer.", - "YAMLDefault": "0xffff0000", - "Required": true, - "OnParseFailure": "Exit", - "AllowedConfigSources": "All", - "Description": "The mask that Felix selects its nftables Mark bits from. Should be a 32 bit hexadecimal number with at least 8 bits set, none of which clash with any other mark bits in use on the system.", - "DescriptionHTML": "

    The mask that Felix selects its nftables Mark bits from. Should be a 32 bit hexadecimal number with at least 8 bits set, none of which clash with any other mark bits in use on the system.

    ", - "UserEditable": true, - "GoType": "*uint32" - }, - { - "Group": "Data plane: nftables", - "GroupWithSortPrefix": "21 Dataplane: nftables", - "NameConfigFile": "NftablesRefreshInterval", - "NameEnvVar": "FELIX_NftablesRefreshInterval", - "NameYAML": "nftablesRefreshInterval", - "NameGoAPI": "NftablesRefreshInterval", - "StringSchema": "Seconds (floating point)", - "StringSchemaHTML": "Seconds (floating point)", - "StringDefault": "180", - "ParsedDefault": "3m0s", - "ParsedDefaultJSON": "180000000000", - "ParsedType": "time.Duration", - "YAMLType": "string", - "YAMLSchema": "Duration string, for example `1m30s123ms` or `1h5m`.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Duration string, for example 1m30s123ms or 1h5m.", - "YAMLDefault": "3m0s", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Controls the interval at which Felix periodically refreshes the nftables rules.", - "DescriptionHTML": "

    Controls the interval at which Felix periodically refreshes the nftables rules.

    ", - "UserEditable": true, - "GoType": "*v1.Duration" - } - ] - }, - { - "Name": "Data plane: eBPF", - "Fields": [ - { - "Group": "Data plane: eBPF", - "GroupWithSortPrefix": "22 Dataplane: eBPF", - "NameConfigFile": "BPFCTLBLogFilter", - "NameEnvVar": "FELIX_BPFCTLBLogFilter", - "NameYAML": "bpfCTLBLogFilter", - "NameGoAPI": "BPFCTLBLogFilter", - "StringSchema": "One of: `all` (case insensitive)", - "StringSchemaHTML": "One of: all (case insensitive)", - "StringDefault": "", - "ParsedDefault": "", - "ParsedDefaultJSON": "\"\"", - "ParsedType": "string", - "YAMLType": "string", - "YAMLSchema": "String.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "String.", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Specifies, what is logged by connect time load balancer when BPFLogLevel is debug. Currently has to be specified as 'all' when BPFLogFilters is set to see CTLB logs.", - "DescriptionHTML": "

    Specifies, what is logged by connect time load balancer when BPFLogLevel is debug. Currently has to be specified as 'all' when BPFLogFilters is set to see CTLB logs.

    ", - "UserEditable": true, - "GoType": "string" - }, - { - "Group": "Data plane: eBPF", - "GroupWithSortPrefix": "22 Dataplane: eBPF", - "NameConfigFile": "BPFConnectTimeLoadBalancing", - "NameEnvVar": "FELIX_BPFConnectTimeLoadBalancing", - "NameYAML": "bpfConnectTimeLoadBalancing", - "NameGoAPI": "BPFConnectTimeLoadBalancing", - "StringSchema": "One of: `Disabled`, `Enabled`, `TCP` (case insensitive)", - "StringSchemaHTML": "One of: Disabled, Enabled, TCP (case insensitive)", - "StringDefault": "TCP", - "ParsedDefault": "TCP", - "ParsedDefaultJSON": "\"TCP\"", - "ParsedType": "string", - "YAMLType": "string", - "YAMLSchema": "One of: `Disabled`, `Enabled`, `TCP`.", - "YAMLEnumValues": [ - "`Disabled`", - "`Enabled`", - "`TCP`" - ], - "YAMLSchemaHTML": "One of: Disabled, Enabled, TCP.", - "YAMLDefault": "TCP", - "Required": true, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "When in BPF mode, controls whether Felix installs the connect-time load balancer. The connect-time load balancer is required for the host to be able to reach Kubernetes services and it improves the performance of pod-to-service connections.When set to TCP, connect time load balancing is available only for services with TCP ports.", - "DescriptionHTML": "

    When in BPF mode, controls whether Felix installs the connect-time load balancer. The connect-time load balancer is required for the host to be able to reach Kubernetes services and it improves the performance of pod-to-service connections.When set to TCP, connect time load balancing is available only for services with TCP ports.

    ", - "UserEditable": true, - "GoType": "*v3.BPFConnectTimeLBType" - }, - { - "Group": "Data plane: eBPF", - "GroupWithSortPrefix": "22 Dataplane: eBPF", - "NameConfigFile": "BPFConnectTimeLoadBalancingEnabled", - "NameEnvVar": "FELIX_BPFConnectTimeLoadBalancingEnabled", - "NameYAML": "bpfConnectTimeLoadBalancingEnabled", - "NameGoAPI": "BPFConnectTimeLoadBalancingEnabled", - "StringSchema": "Boolean: `true`, `1`, `yes`, `y`, `t` accepted as True; `false`, `0`, `no`, `n`, `f` accepted (case insensitively) as False.", - "StringSchemaHTML": "Boolean: true, 1, yes, y, t accepted as True; false, 0, no, n, f accepted (case insensitively) as False.", - "StringDefault": "", - "ParsedDefault": "false", - "ParsedDefaultJSON": "false", - "ParsedType": "bool", - "YAMLType": "boolean", - "YAMLSchema": "Boolean.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Boolean.", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "When in BPF mode, controls whether Felix installs the connection-time load balancer. The connect-time load balancer is required for the host to be able to reach Kubernetes services and it improves the performance of pod-to-service connections. The only reason to disable it is for debugging purposes.\n\nDeprecated: Use BPFConnectTimeLoadBalancing.", - "DescriptionHTML": "

    When in BPF mode, controls whether Felix installs the connection-time load balancer. The connect-time load balancer is required for the host to be able to reach Kubernetes services and it improves the performance of pod-to-service connections. The only reason to disable it is for debugging purposes.

    \n

    Deprecated: Use BPFConnectTimeLoadBalancing.

    ", - "UserEditable": true, - "GoType": "*bool" - }, - { - "Group": "Data plane: eBPF", - "GroupWithSortPrefix": "22 Dataplane: eBPF", - "NameConfigFile": "BPFDSROptoutCIDRs", - "NameEnvVar": "FELIX_BPFDSROptoutCIDRs", - "NameYAML": "bpfDSROptoutCIDRs", - "NameGoAPI": "BPFDSROptoutCIDRs", - "StringSchema": "Comma-delimited list of CIDRs", - "StringSchemaHTML": "Comma-delimited list of CIDRs", - "StringDefault": "", - "ParsedDefault": "[]", - "ParsedDefaultJSON": "null", - "ParsedType": "[]string", - "YAMLType": "array", - "YAMLSchema": "List of CIDRs: `[\"\", ...]`.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "List of CIDRs: [\"<cidr>\", ...].", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "A list of CIDRs which are excluded from DSR. That is, clients in those CIDRs will access service node ports as if BPFExternalServiceMode was set to Tunnel.", - "DescriptionHTML": "

    A list of CIDRs which are excluded from DSR. That is, clients in those CIDRs will access service node ports as if BPFExternalServiceMode was set to Tunnel.

    ", - "UserEditable": true, - "GoType": "*[]string" - }, - { - "Group": "Data plane: eBPF", - "GroupWithSortPrefix": "22 Dataplane: eBPF", - "NameConfigFile": "BPFDataIfacePattern", - "NameEnvVar": "FELIX_BPFDataIfacePattern", - "NameYAML": "bpfDataIfacePattern", - "NameGoAPI": "BPFDataIfacePattern", - "StringSchema": "Regular expression", - "StringSchemaHTML": "Regular expression", - "StringDefault": "^((en|wl|ww|sl|ib)[Popsx].*|(eth|wlan|wwan|bond).*|tunl0$|vxlan.calico$|vxlan-v6.calico$|wireguard.cali$|wg-v6.cali$|egress.calico$)", - "ParsedDefault": "^((en|wl|ww|sl|ib)[Popsx].*|(eth|wlan|wwan|bond).*|tunl0$|vxlan.calico$|vxlan-v6.calico$|wireguard.cali$|wg-v6.cali$|egress.calico$)", - "ParsedDefaultJSON": "\"^((en|wl|ww|sl|ib)[Popsx].*|(eth|wlan|wwan|bond).*|tunl0$|vxlan.calico$|vxlan-v6.calico$|wireguard.cali$|wg-v6.cali$|egress.calico$)\"", - "ParsedType": "*regexp.Regexp", - "YAMLType": "string", - "YAMLSchema": "String.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "String.", - "YAMLDefault": "^((en|wl|ww|sl|ib)[Popsx].*|(eth|wlan|wwan|bond).*|tunl0$|vxlan.calico$|vxlan-v6.calico$|wireguard.cali$|wg-v6.cali$|egress.calico$)", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "A regular expression that controls which interfaces Felix should attach BPF programs to in order to catch traffic to/from the network. This needs to match the interfaces that Calico workload traffic flows over as well as any interfaces that handle incoming traffic to nodeports and services from outside the cluster. It should not match the workload interfaces (usually named cali...).", - "DescriptionHTML": "

    A regular expression that controls which interfaces Felix should attach BPF programs to in order to catch traffic to/from the network. This needs to match the interfaces that Calico workload traffic flows over as well as any interfaces that handle incoming traffic to nodeports and services from outside the cluster. It should not match the workload interfaces (usually named cali...).

    ", - "UserEditable": true, - "GoType": "string" - }, - { - "Group": "Data plane: eBPF", - "GroupWithSortPrefix": "22 Dataplane: eBPF", - "NameConfigFile": "BPFDisableGROForIfaces", - "NameEnvVar": "FELIX_BPFDisableGROForIfaces", - "NameYAML": "bpfDisableGROForIfaces", - "NameGoAPI": "BPFDisableGROForIfaces", - "StringSchema": "Regular expression", - "StringSchemaHTML": "Regular expression", - "StringDefault": "", - "ParsedDefault": "", - "ParsedDefaultJSON": "null", - "ParsedType": "*regexp.Regexp", - "YAMLType": "string", - "YAMLSchema": "String.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "String.", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "A regular expression that controls which interfaces Felix should disable the Generic Receive Offload [GRO] option. It should not match the workload interfaces (usually named cali...).", - "DescriptionHTML": "

    A regular expression that controls which interfaces Felix should disable the Generic Receive Offload [GRO] option. It should not match the workload interfaces (usually named cali...).

    ", - "UserEditable": true, - "GoType": "string" - }, - { - "Group": "Data plane: eBPF", - "GroupWithSortPrefix": "22 Dataplane: eBPF", - "NameConfigFile": "BPFDisableUnprivileged", - "NameEnvVar": "FELIX_BPFDisableUnprivileged", - "NameYAML": "bpfDisableUnprivileged", - "NameGoAPI": "BPFDisableUnprivileged", - "StringSchema": "Boolean: `true`, `1`, `yes`, `y`, `t` accepted as True; `false`, `0`, `no`, `n`, `f` accepted (case insensitively) as False.", - "StringSchemaHTML": "Boolean: true, 1, yes, y, t accepted as True; false, 0, no, n, f accepted (case insensitively) as False.", - "StringDefault": "true", - "ParsedDefault": "true", - "ParsedDefaultJSON": "true", - "ParsedType": "bool", - "YAMLType": "boolean", - "YAMLSchema": "Boolean.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Boolean.", - "YAMLDefault": "true", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "If enabled, Felix sets the kernel.unprivileged_bpf_disabled sysctl to disable unprivileged use of BPF. This ensures that unprivileged users cannot access Calico's BPF maps and cannot insert their own BPF programs to interfere with Calico's.", - "DescriptionHTML": "

    If enabled, Felix sets the kernel.unprivileged_bpf_disabled sysctl to disable unprivileged use of BPF. This ensures that unprivileged users cannot access Calico's BPF maps and cannot insert their own BPF programs to interfere with Calico's.

    ", - "UserEditable": true, - "GoType": "*bool" - }, - { - "Group": "Data plane: eBPF", - "GroupWithSortPrefix": "22 Dataplane: eBPF", - "NameConfigFile": "BPFEnabled", - "NameEnvVar": "FELIX_BPFEnabled", - "NameYAML": "bpfEnabled", - "NameGoAPI": "BPFEnabled", - "StringSchema": "Boolean: `true`, `1`, `yes`, `y`, `t` accepted as True; `false`, `0`, `no`, `n`, `f` accepted (case insensitively) as False.", - "StringSchemaHTML": "Boolean: true, 1, yes, y, t accepted as True; false, 0, no, n, f accepted (case insensitively) as False.", - "StringDefault": "false", - "ParsedDefault": "false", - "ParsedDefaultJSON": "false", - "ParsedType": "bool", - "YAMLType": "boolean", - "YAMLSchema": "Boolean.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Boolean.", - "YAMLDefault": "false", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "If enabled Felix will use the BPF dataplane.", - "DescriptionHTML": "

    If enabled Felix will use the BPF dataplane.

    ", - "UserEditable": true, - "GoType": "*bool" - }, - { - "Group": "Data plane: eBPF", - "GroupWithSortPrefix": "22 Dataplane: eBPF", - "NameConfigFile": "BPFEnforceRPF", - "NameEnvVar": "FELIX_BPFEnforceRPF", - "NameYAML": "bpfEnforceRPF", - "NameGoAPI": "BPFEnforceRPF", - "StringSchema": "One of: `Disabled`, `Loose`, `Strict` (case insensitive)", - "StringSchemaHTML": "One of: Disabled, Loose, Strict (case insensitive)", - "StringDefault": "Loose", - "ParsedDefault": "Loose", - "ParsedDefaultJSON": "\"Loose\"", - "ParsedType": "string", - "YAMLType": "string", - "YAMLSchema": "One of: `Disabled`, `Loose`, `Strict`.", - "YAMLEnumValues": [ - "Disabled", - "Loose", - "Strict" - ], - "YAMLSchemaHTML": "One of: Disabled, Loose, Strict.", - "YAMLDefault": "Loose", - "Required": true, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Enforce strict RPF on all host interfaces with BPF programs regardless of what is the per-interfaces or global setting. Possible values are Disabled, Strict or Loose.", - "DescriptionHTML": "

    Enforce strict RPF on all host interfaces with BPF programs regardless of what is the per-interfaces or global setting. Possible values are Disabled, Strict or Loose.

    ", - "UserEditable": true, - "GoType": "string" - }, - { - "Group": "Data plane: eBPF", - "GroupWithSortPrefix": "22 Dataplane: eBPF", - "NameConfigFile": "BPFExcludeCIDRsFromNAT", - "NameEnvVar": "FELIX_BPFExcludeCIDRsFromNAT", - "NameYAML": "bpfExcludeCIDRsFromNAT", - "NameGoAPI": "BPFExcludeCIDRsFromNAT", - "StringSchema": "Comma-delimited list of CIDRs", - "StringSchemaHTML": "Comma-delimited list of CIDRs", - "StringDefault": "", - "ParsedDefault": "[]", - "ParsedDefaultJSON": "null", - "ParsedType": "[]string", - "YAMLType": "array", - "YAMLSchema": "List of CIDRs: `[\"\", ...]`.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "List of CIDRs: [\"<cidr>\", ...].", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "A list of CIDRs that are to be excluded from NAT resolution so that host can handle them. A typical usecase is node local DNS cache.", - "DescriptionHTML": "

    A list of CIDRs that are to be excluded from NAT resolution so that host can handle them. A typical usecase is node local DNS cache.

    ", - "UserEditable": true, - "GoType": "*[]string" - }, - { - "Group": "Data plane: eBPF", - "GroupWithSortPrefix": "22 Dataplane: eBPF", - "NameConfigFile": "BPFExtToServiceConnmark", - "NameEnvVar": "FELIX_BPFExtToServiceConnmark", - "NameYAML": "bpfExtToServiceConnmark", - "NameGoAPI": "BPFExtToServiceConnmark", - "StringSchema": "Integer", - "StringSchemaHTML": "Integer", - "StringDefault": "0", - "ParsedDefault": "0", - "ParsedDefaultJSON": "0", - "ParsedType": "int", - "YAMLType": "integer", - "YAMLSchema": "Integer", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Integer", - "YAMLDefault": "0", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "In BPF mode, controls a 32bit mark that is set on connections from an external client to a local service. This mark allows us to control how packets of that connection are routed within the host and how is routing interpreted by RPF check.", - "DescriptionHTML": "

    In BPF mode, controls a 32bit mark that is set on connections from an external client to a local service. This mark allows us to control how packets of that connection are routed within the host and how is routing interpreted by RPF check.

    ", - "UserEditable": true, - "GoType": "*int" - }, - { - "Group": "Data plane: eBPF", - "GroupWithSortPrefix": "22 Dataplane: eBPF", - "NameConfigFile": "BPFExternalServiceMode", - "NameEnvVar": "FELIX_BPFExternalServiceMode", - "NameYAML": "bpfExternalServiceMode", - "NameGoAPI": "BPFExternalServiceMode", - "StringSchema": "One of: `dsr`, `tunnel` (case insensitive)", - "StringSchemaHTML": "One of: dsr, tunnel (case insensitive)", - "StringDefault": "tunnel", - "ParsedDefault": "tunnel", - "ParsedDefaultJSON": "\"tunnel\"", - "ParsedType": "string", - "YAMLType": "string", - "YAMLSchema": "One of: `DSR`, `Tunnel`.", - "YAMLEnumValues": [ - "DSR", - "Tunnel" - ], - "YAMLSchemaHTML": "One of: DSR, Tunnel.", - "YAMLDefault": "Tunnel", - "Required": true, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "In BPF mode, controls how connections from outside the cluster to services (node ports and cluster IPs) are forwarded to remote workloads. If set to \"Tunnel\" then both request and response traffic is tunneled to the remote node. If set to \"DSR\", the request traffic is tunneled but the response traffic is sent directly from the remote node. In \"DSR\" mode, the remote node appears to use the IP of the ingress node; this requires a permissive L2 network.", - "DescriptionHTML": "

    In BPF mode, controls how connections from outside the cluster to services (node ports and cluster IPs) are forwarded to remote workloads. If set to \"Tunnel\" then both request and response traffic is tunneled to the remote node. If set to \"DSR\", the request traffic is tunneled but the response traffic is sent directly from the remote node. In \"DSR\" mode, the remote node appears to use the IP of the ingress node; this requires a permissive L2 network.

    ", - "UserEditable": true, - "GoType": "string" - }, - { - "Group": "Data plane: eBPF", - "GroupWithSortPrefix": "22 Dataplane: eBPF", - "NameConfigFile": "BPFForceTrackPacketsFromIfaces", - "NameEnvVar": "FELIX_BPFForceTrackPacketsFromIfaces", - "NameYAML": "bpfForceTrackPacketsFromIfaces", - "NameGoAPI": "BPFForceTrackPacketsFromIfaces", - "StringSchema": "Comma-delimited list of strings, each matching the regex `^[a-zA-Z0-9:._+-]{1,15}$`", - "StringSchemaHTML": "Comma-delimited list of strings, each matching the regex ^[a-zA-Z0-9:._+-]{1,15}$", - "StringDefault": "docker+", - "ParsedDefault": "[docker+]", - "ParsedDefaultJSON": "[\"docker+\"]", - "ParsedType": "[]string", - "YAMLType": "array", - "YAMLSchema": "List of interface names (may use `+` as a wildcard: `[\"\", ...]`.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "List of interface names (may use + as a wildcard: [\"<name>\", ...].", - "YAMLDefault": "[\"docker+\"]", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "In BPF mode, forces traffic from these interfaces to skip Calico's iptables NOTRACK rule, allowing traffic from those interfaces to be tracked by Linux conntrack. Should only be used for interfaces that are not used for the Calico fabric. For example, a docker bridge device for non-Calico-networked containers.", - "DescriptionHTML": "

    In BPF mode, forces traffic from these interfaces to skip Calico's iptables NOTRACK rule, allowing traffic from those interfaces to be tracked by Linux conntrack. Should only be used for interfaces that are not used for the Calico fabric. For example, a docker bridge device for non-Calico-networked containers.

    ", - "UserEditable": true, - "GoType": "*[]string" - }, - { - "Group": "Data plane: eBPF", - "GroupWithSortPrefix": "22 Dataplane: eBPF", - "NameConfigFile": "BPFHostConntrackBypass", - "NameEnvVar": "FELIX_BPFHostConntrackBypass", - "NameYAML": "bpfHostConntrackBypass", - "NameGoAPI": "BPFHostConntrackBypass", - "StringSchema": "Boolean: `true`, `1`, `yes`, `y`, `t` accepted as True; `false`, `0`, `no`, `n`, `f` accepted (case insensitively) as False.", - "StringSchemaHTML": "Boolean: true, 1, yes, y, t accepted as True; false, 0, no, n, f accepted (case insensitively) as False.", - "StringDefault": "true", - "ParsedDefault": "true", - "ParsedDefaultJSON": "true", - "ParsedType": "bool", - "YAMLType": "boolean", - "YAMLSchema": "Boolean.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Boolean.", - "YAMLDefault": "true", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Controls whether to bypass Linux conntrack in BPF mode for workloads and services.", - "DescriptionHTML": "

    Controls whether to bypass Linux conntrack in BPF mode for workloads and services.

    ", - "UserEditable": true, - "GoType": "*bool" - }, - { - "Group": "Data plane: eBPF", - "GroupWithSortPrefix": "22 Dataplane: eBPF", - "NameConfigFile": "BPFHostNetworkedNATWithoutCTLB", - "NameEnvVar": "FELIX_BPFHostNetworkedNATWithoutCTLB", - "NameYAML": "bpfHostNetworkedNATWithoutCTLB", - "NameGoAPI": "BPFHostNetworkedNATWithoutCTLB", - "StringSchema": "One of: `Disabled`, `Enabled` (case insensitive)", - "StringSchemaHTML": "One of: Disabled, Enabled (case insensitive)", - "StringDefault": "Enabled", - "ParsedDefault": "Enabled", - "ParsedDefaultJSON": "\"Enabled\"", - "ParsedType": "string", - "YAMLType": "string", - "YAMLSchema": "One of: `Disabled`, `Enabled`.", - "YAMLEnumValues": [ - "`Disabled`", - "`Enabled`" - ], - "YAMLSchemaHTML": "One of: Disabled, Enabled.", - "YAMLDefault": "Enabled", - "Required": true, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "When in BPF mode, controls whether Felix does a NAT without CTLB. This along with BPFConnectTimeLoadBalancing determines the CTLB behavior.", - "DescriptionHTML": "

    When in BPF mode, controls whether Felix does a NAT without CTLB. This along with BPFConnectTimeLoadBalancing determines the CTLB behavior.

    ", - "UserEditable": true, - "GoType": "*v3.BPFHostNetworkedNATType" - }, - { - "Group": "Data plane: eBPF", - "GroupWithSortPrefix": "22 Dataplane: eBPF", - "NameConfigFile": "BPFKubeProxyEndpointSlicesEnabled", - "NameEnvVar": "FELIX_BPFKubeProxyEndpointSlicesEnabled", - "NameYAML": "bpfKubeProxyEndpointSlicesEnabled", - "NameGoAPI": "BPFKubeProxyEndpointSlicesEnabled", - "StringSchema": "Boolean: `true`, `1`, `yes`, `y`, `t` accepted as True; `false`, `0`, `no`, `n`, `f` accepted (case insensitively) as False.", - "StringSchemaHTML": "Boolean: true, 1, yes, y, t accepted as True; false, 0, no, n, f accepted (case insensitively) as False.", - "StringDefault": "true", - "ParsedDefault": "true", - "ParsedDefaultJSON": "true", - "ParsedType": "bool", - "YAMLType": "boolean", - "YAMLSchema": "Boolean.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Boolean.", - "YAMLDefault": "true", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Deprecated and has no effect. BPF kube-proxy always accepts endpoint slices. This option will be removed in the next release.", - "DescriptionHTML": "

    Deprecated and has no effect. BPF kube-proxy always accepts endpoint slices. This option will be removed in the next release.

    ", - "UserEditable": true, - "GoType": "*bool" - }, - { - "Group": "Data plane: eBPF", - "GroupWithSortPrefix": "22 Dataplane: eBPF", - "NameConfigFile": "BPFKubeProxyIptablesCleanupEnabled", - "NameEnvVar": "FELIX_BPFKubeProxyIptablesCleanupEnabled", - "NameYAML": "bpfKubeProxyIptablesCleanupEnabled", - "NameGoAPI": "BPFKubeProxyIptablesCleanupEnabled", - "StringSchema": "Boolean: `true`, `1`, `yes`, `y`, `t` accepted as True; `false`, `0`, `no`, `n`, `f` accepted (case insensitively) as False.", - "StringSchemaHTML": "Boolean: true, 1, yes, y, t accepted as True; false, 0, no, n, f accepted (case insensitively) as False.", - "StringDefault": "true", - "ParsedDefault": "true", - "ParsedDefaultJSON": "true", - "ParsedType": "bool", - "YAMLType": "boolean", - "YAMLSchema": "Boolean.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Boolean.", - "YAMLDefault": "true", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "If enabled in BPF mode, Felix will proactively clean up the upstream Kubernetes kube-proxy's iptables chains. Should only be enabled if kube-proxy is not running.", - "DescriptionHTML": "

    If enabled in BPF mode, Felix will proactively clean up the upstream Kubernetes kube-proxy's iptables chains. Should only be enabled if kube-proxy is not running.

    ", - "UserEditable": true, - "GoType": "*bool" - }, - { - "Group": "Data plane: eBPF", - "GroupWithSortPrefix": "22 Dataplane: eBPF", - "NameConfigFile": "BPFKubeProxyMinSyncPeriod", - "NameEnvVar": "FELIX_BPFKubeProxyMinSyncPeriod", - "NameYAML": "bpfKubeProxyMinSyncPeriod", - "NameGoAPI": "BPFKubeProxyMinSyncPeriod", - "StringSchema": "Seconds (floating point)", - "StringSchemaHTML": "Seconds (floating point)", - "StringDefault": "1", - "ParsedDefault": "1s", - "ParsedDefaultJSON": "1000000000", - "ParsedType": "time.Duration", - "YAMLType": "string", - "YAMLSchema": "Duration string, for example `1m30s123ms` or `1h5m`.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Duration string, for example 1m30s123ms or 1h5m.", - "YAMLDefault": "1s", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "In BPF mode, controls the minimum time between updates to the dataplane for Felix's embedded kube-proxy. Lower values give reduced set-up latency. Higher values reduce Felix CPU usage by batching up more work.", - "DescriptionHTML": "

    In BPF mode, controls the minimum time between updates to the dataplane for Felix's embedded kube-proxy. Lower values give reduced set-up latency. Higher values reduce Felix CPU usage by batching up more work.

    ", - "UserEditable": true, - "GoType": "*v1.Duration" - }, - { - "Group": "Data plane: eBPF", - "GroupWithSortPrefix": "22 Dataplane: eBPF", - "NameConfigFile": "BPFL3IfacePattern", - "NameEnvVar": "FELIX_BPFL3IfacePattern", - "NameYAML": "bpfL3IfacePattern", - "NameGoAPI": "BPFL3IfacePattern", - "StringSchema": "Regular expression", - "StringSchemaHTML": "Regular expression", - "StringDefault": "", - "ParsedDefault": "", - "ParsedDefaultJSON": "null", - "ParsedType": "*regexp.Regexp", - "YAMLType": "string", - "YAMLSchema": "String.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "String.", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "A regular expression that allows to list tunnel devices like WireGuard or vxlan (i.e., L3 devices) in addition to BPFDataIfacePattern. That is, tunnel interfaces not created by Calico, that Calico workload traffic flows over as well as any interfaces that handle incoming traffic to nodeports and services from outside the cluster.", - "DescriptionHTML": "

    A regular expression that allows to list tunnel devices like WireGuard or vxlan (i.e., L3 devices) in addition to BPFDataIfacePattern. That is, tunnel interfaces not created by Calico, that Calico workload traffic flows over as well as any interfaces that handle incoming traffic to nodeports and services from outside the cluster.

    ", - "UserEditable": true, - "GoType": "string" - }, - { - "Group": "Data plane: eBPF", - "GroupWithSortPrefix": "22 Dataplane: eBPF", - "NameConfigFile": "BPFLogFilters", - "NameEnvVar": "FELIX_BPFLogFilters", - "NameYAML": "bpfLogFilters", - "NameGoAPI": "BPFLogFilters", - "StringSchema": "Comma-delimited list of key=value pairs", - "StringSchemaHTML": "Comma-delimited list of key=value pairs", - "StringDefault": "", - "ParsedDefault": "map[]", - "ParsedDefaultJSON": "null", - "ParsedType": "map[string]string", - "YAMLType": "object", - "YAMLSchema": "", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "A map of key=values where the value is a pcap filter expression and the key is an interface name with 'all' denoting all interfaces, 'weps' all workload endpoints and 'heps' all host endpoints.\n\nWhen specified as an env var, it accepts a comma-separated list of key=values.", - "DescriptionHTML": "

    A map of key=values where the value is a pcap filter expression and the key is an interface name with 'all' denoting all interfaces, 'weps' all workload endpoints and 'heps' all host endpoints.

    \n

    When specified as an env var, it accepts a comma-separated list of key=values.

    ", - "UserEditable": true, - "GoType": "*map[string]string" - }, - { - "Group": "Data plane: eBPF", - "GroupWithSortPrefix": "22 Dataplane: eBPF", - "NameConfigFile": "BPFLogLevel", - "NameEnvVar": "FELIX_BPFLogLevel", - "NameYAML": "bpfLogLevel", - "NameGoAPI": "BPFLogLevel", - "StringSchema": "One of: `debug`, `info`, `off` (case insensitive)", - "StringSchemaHTML": "One of: debug, info, off (case insensitive)", - "StringDefault": "off", - "ParsedDefault": "off", - "ParsedDefaultJSON": "\"off\"", - "ParsedType": "string", - "YAMLType": "string", - "YAMLSchema": "One of: `Debug`, `Info`, `Off`.", - "YAMLEnumValues": [ - "Debug", - "Info", - "Off" - ], - "YAMLSchemaHTML": "One of: Debug, Info, Off.", - "YAMLDefault": "Off", - "Required": true, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Controls the log level of the BPF programs when in BPF dataplane mode. One of \"Off\", \"Info\", or \"Debug\". The logs are emitted to the BPF trace pipe, accessible with the command `tc exec bpf debug`. .", - "DescriptionHTML": "

    Controls the log level of the BPF programs when in BPF dataplane mode. One of \"Off\", \"Info\", or \"Debug\". The logs are emitted to the BPF trace pipe, accessible with the command tc exec bpf debug. .

    ", - "UserEditable": true, - "GoType": "string" - }, - { - "Group": "Data plane: eBPF", - "GroupWithSortPrefix": "22 Dataplane: eBPF", - "NameConfigFile": "BPFMapSizeConntrack", - "NameEnvVar": "FELIX_BPFMapSizeConntrack", - "NameYAML": "bpfMapSizeConntrack", - "NameGoAPI": "BPFMapSizeConntrack", - "StringSchema": "Integer", - "StringSchemaHTML": "Integer", - "StringDefault": "512000", - "ParsedDefault": "512000", - "ParsedDefaultJSON": "512000", - "ParsedType": "int", - "YAMLType": "integer", - "YAMLSchema": "Integer", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Integer", - "YAMLDefault": "512000", - "Required": true, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Sets the size for the conntrack map. This map must be large enough to hold an entry for each active connection. Warning: changing the size of the conntrack map can cause disruption.", - "DescriptionHTML": "

    Sets the size for the conntrack map. This map must be large enough to hold an entry for each active connection. Warning: changing the size of the conntrack map can cause disruption.

    ", - "UserEditable": true, - "GoType": "*int" - }, - { - "Group": "Data plane: eBPF", - "GroupWithSortPrefix": "22 Dataplane: eBPF", - "NameConfigFile": "BPFMapSizeIPSets", - "NameEnvVar": "FELIX_BPFMapSizeIPSets", - "NameYAML": "bpfMapSizeIPSets", - "NameGoAPI": "BPFMapSizeIPSets", - "StringSchema": "Integer", - "StringSchemaHTML": "Integer", - "StringDefault": "1048576", - "ParsedDefault": "1048576", - "ParsedDefaultJSON": "1048576", - "ParsedType": "int", - "YAMLType": "integer", - "YAMLSchema": "Integer", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Integer", - "YAMLDefault": "1048576", - "Required": true, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Sets the size for ipsets map. The IP sets map must be large enough to hold an entry for each endpoint matched by every selector in the source/destination matches in network policy. Selectors such as \"all()\" can result in large numbers of entries (one entry per endpoint in that case).", - "DescriptionHTML": "

    Sets the size for ipsets map. The IP sets map must be large enough to hold an entry for each endpoint matched by every selector in the source/destination matches in network policy. Selectors such as \"all()\" can result in large numbers of entries (one entry per endpoint in that case).

    ", - "UserEditable": true, - "GoType": "*int" - }, - { - "Group": "Data plane: eBPF", - "GroupWithSortPrefix": "22 Dataplane: eBPF", - "NameConfigFile": "BPFMapSizeIfState", - "NameEnvVar": "FELIX_BPFMapSizeIfState", - "NameYAML": "bpfMapSizeIfState", - "NameGoAPI": "BPFMapSizeIfState", - "StringSchema": "Integer", - "StringSchemaHTML": "Integer", - "StringDefault": "1000", - "ParsedDefault": "1000", - "ParsedDefaultJSON": "1000", - "ParsedType": "int", - "YAMLType": "integer", - "YAMLSchema": "Integer", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Integer", - "YAMLDefault": "1000", - "Required": true, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Sets the size for ifstate map. The ifstate map must be large enough to hold an entry for each device (host + workloads) on a host.", - "DescriptionHTML": "

    Sets the size for ifstate map. The ifstate map must be large enough to hold an entry for each device (host + workloads) on a host.

    ", - "UserEditable": true, - "GoType": "*int" - }, - { - "Group": "Data plane: eBPF", - "GroupWithSortPrefix": "22 Dataplane: eBPF", - "NameConfigFile": "BPFMapSizeNATAffinity", - "NameEnvVar": "FELIX_BPFMapSizeNATAffinity", - "NameYAML": "bpfMapSizeNATAffinity", - "NameGoAPI": "BPFMapSizeNATAffinity", - "StringSchema": "Integer", - "StringSchemaHTML": "Integer", - "StringDefault": "65536", - "ParsedDefault": "65536", - "ParsedDefaultJSON": "65536", - "ParsedType": "int", - "YAMLType": "integer", - "YAMLSchema": "Integer", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Integer", - "YAMLDefault": "65536", - "Required": true, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Sets the size of the BPF map that stores the affinity of a connection (for services that enable that feature.", - "DescriptionHTML": "

    Sets the size of the BPF map that stores the affinity of a connection (for services that enable that feature.

    ", - "UserEditable": true, - "GoType": "*int" - }, - { - "Group": "Data plane: eBPF", - "GroupWithSortPrefix": "22 Dataplane: eBPF", - "NameConfigFile": "BPFMapSizeNATBackend", - "NameEnvVar": "FELIX_BPFMapSizeNATBackend", - "NameYAML": "bpfMapSizeNATBackend", - "NameGoAPI": "BPFMapSizeNATBackend", - "StringSchema": "Integer", - "StringSchemaHTML": "Integer", - "StringDefault": "262144", - "ParsedDefault": "262144", - "ParsedDefaultJSON": "262144", - "ParsedType": "int", - "YAMLType": "integer", - "YAMLSchema": "Integer", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Integer", - "YAMLDefault": "262144", - "Required": true, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Sets the size for NAT back end map. This is the total number of endpoints. This is mostly more than the size of the number of services.", - "DescriptionHTML": "

    Sets the size for NAT back end map. This is the total number of endpoints. This is mostly more than the size of the number of services.

    ", - "UserEditable": true, - "GoType": "*int" - }, - { - "Group": "Data plane: eBPF", - "GroupWithSortPrefix": "22 Dataplane: eBPF", - "NameConfigFile": "BPFMapSizeNATFrontend", - "NameEnvVar": "FELIX_BPFMapSizeNATFrontend", - "NameYAML": "bpfMapSizeNATFrontend", - "NameGoAPI": "BPFMapSizeNATFrontend", - "StringSchema": "Integer", - "StringSchemaHTML": "Integer", - "StringDefault": "65536", - "ParsedDefault": "65536", - "ParsedDefaultJSON": "65536", - "ParsedType": "int", - "YAMLType": "integer", - "YAMLSchema": "Integer", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Integer", - "YAMLDefault": "65536", - "Required": true, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Sets the size for NAT front end map. FrontendMap should be large enough to hold an entry for each nodeport, external IP and each port in each service.", - "DescriptionHTML": "

    Sets the size for NAT front end map. FrontendMap should be large enough to hold an entry for each nodeport, external IP and each port in each service.

    ", - "UserEditable": true, - "GoType": "*int" - }, - { - "Group": "Data plane: eBPF", - "GroupWithSortPrefix": "22 Dataplane: eBPF", - "NameConfigFile": "BPFMapSizeRoute", - "NameEnvVar": "FELIX_BPFMapSizeRoute", - "NameYAML": "bpfMapSizeRoute", - "NameGoAPI": "BPFMapSizeRoute", - "StringSchema": "Integer", - "StringSchemaHTML": "Integer", - "StringDefault": "262144", - "ParsedDefault": "262144", - "ParsedDefaultJSON": "262144", - "ParsedType": "int", - "YAMLType": "integer", - "YAMLSchema": "Integer", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Integer", - "YAMLDefault": "262144", - "Required": true, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Sets the size for the routes map. The routes map should be large enough to hold one entry per workload and a handful of entries per host (enough to cover its own IPs and tunnel IPs).", - "DescriptionHTML": "

    Sets the size for the routes map. The routes map should be large enough to hold one entry per workload and a handful of entries per host (enough to cover its own IPs and tunnel IPs).

    ", - "UserEditable": true, - "GoType": "*int" - }, - { - "Group": "Data plane: eBPF", - "GroupWithSortPrefix": "22 Dataplane: eBPF", - "NameConfigFile": "BPFPSNATPorts", - "NameEnvVar": "FELIX_BPFPSNATPorts", - "NameYAML": "bpfPSNATPorts", - "NameGoAPI": "BPFPSNATPorts", - "StringSchema": "Port range: either a single number in [0,65535] or a range of numbers `n:m`", - "StringSchemaHTML": "Port range: either a single number in [0,65535] or a range of numbers n:m", - "StringDefault": "20000:29999", - "ParsedDefault": "20000:29999", - "ParsedDefaultJSON": "\"20000:29999\"", - "ParsedType": "numorstring.Port", - "YAMLType": "integer or string", - "YAMLSchema": "String.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "String.", - "YAMLDefault": "20000:29999", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Sets the range from which we randomly pick a port if there is a source port collision. This should be within the ephemeral range as defined by RFC 6056 (1024–65535) and preferably outside the ephemeral ranges used by common operating systems. Linux uses 32768–60999, while others mostly use the IANA defined range 49152–65535. It is not necessarily a problem if this range overlaps with the operating systems. Both ends of the range are inclusive.", - "DescriptionHTML": "

    Sets the range from which we randomly pick a port if there is a source port collision. This should be within the ephemeral range as defined by RFC 6056 (1024–65535) and preferably outside the ephemeral ranges used by common operating systems. Linux uses 32768–60999, while others mostly use the IANA defined range 49152–65535. It is not necessarily a problem if this range overlaps with the operating systems. Both ends of the range are inclusive.

    ", - "UserEditable": true, - "GoType": "*numorstring.Port" - }, - { - "Group": "Data plane: eBPF", - "GroupWithSortPrefix": "22 Dataplane: eBPF", - "NameConfigFile": "BPFPolicyDebugEnabled", - "NameEnvVar": "FELIX_BPFPolicyDebugEnabled", - "NameYAML": "bpfPolicyDebugEnabled", - "NameGoAPI": "BPFPolicyDebugEnabled", - "StringSchema": "Boolean: `true`, `1`, `yes`, `y`, `t` accepted as True; `false`, `0`, `no`, `n`, `f` accepted (case insensitively) as False.", - "StringSchemaHTML": "Boolean: true, 1, yes, y, t accepted as True; false, 0, no, n, f accepted (case insensitively) as False.", - "StringDefault": "true", - "ParsedDefault": "true", - "ParsedDefaultJSON": "true", - "ParsedType": "bool", - "YAMLType": "boolean", - "YAMLSchema": "Boolean.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Boolean.", - "YAMLDefault": "true", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "When true, Felix records detailed information about the BPF policy programs, which can be examined with the calico-bpf command-line tool.", - "DescriptionHTML": "

    When true, Felix records detailed information about the BPF policy programs, which can be examined with the calico-bpf command-line tool.

    ", - "UserEditable": true, - "GoType": "*bool" - }, - { - "Group": "Data plane: eBPF", - "GroupWithSortPrefix": "22 Dataplane: eBPF", - "NameConfigFile": "BPFRedirectToPeer", - "NameEnvVar": "FELIX_BPFRedirectToPeer", - "NameYAML": "bpfRedirectToPeer", - "NameGoAPI": "BPFRedirectToPeer", - "StringSchema": "One of: `Disabled`, `Enabled`, `L2Only` (case insensitive)", - "StringSchemaHTML": "One of: Disabled, Enabled, L2Only (case insensitive)", - "StringDefault": "L2Only", - "ParsedDefault": "L2Only", - "ParsedDefaultJSON": "\"L2Only\"", - "ParsedType": "string", - "YAMLType": "string", - "YAMLSchema": "String.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "String.", - "YAMLDefault": "L2Only", - "Required": true, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Controls which whether it is allowed to forward straight to the peer side of the workload devices. It is allowed for any host L2 devices by default (L2Only), but it breaks TCP dump on the host side of workload device as it bypasses it on ingress. Value of Enabled also allows redirection from L3 host devices like IPIP tunnel or Wireguard directly to the peer side of the workload's device. This makes redirection faster, however, it breaks tools like tcpdump on the peer side. Use Enabled with caution.", - "DescriptionHTML": "

    Controls which whether it is allowed to forward straight to the peer side of the workload devices. It is allowed for any host L2 devices by default (L2Only), but it breaks TCP dump on the host side of workload device as it bypasses it on ingress. Value of Enabled also allows redirection from L3 host devices like IPIP tunnel or Wireguard directly to the peer side of the workload's device. This makes redirection faster, however, it breaks tools like tcpdump on the peer side. Use Enabled with caution.

    ", - "UserEditable": true, - "GoType": "string" - } - ] - }, - { - "Name": "Data plane: Windows", - "Fields": [ - { - "Group": "Data plane: Windows", - "GroupWithSortPrefix": "23 Dataplane: Windows", - "NameConfigFile": "WindowsManageFirewallRules", - "NameEnvVar": "FELIX_WindowsManageFirewallRules", - "NameYAML": "windowsManageFirewallRules", - "NameGoAPI": "WindowsManageFirewallRules", - "StringSchema": "One of: `Disabled`, `Enabled` (case insensitive)", - "StringSchemaHTML": "One of: Disabled, Enabled (case insensitive)", - "StringDefault": "Disabled", - "ParsedDefault": "Disabled", - "ParsedDefaultJSON": "\"Disabled\"", - "ParsedType": "string", - "YAMLType": "string", - "YAMLSchema": "One of: `Disabled`, `Enabled`.", - "YAMLEnumValues": [ - "`Disabled`", - "`Enabled`" - ], - "YAMLSchemaHTML": "One of: Disabled, Enabled.", - "YAMLDefault": "Disabled", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Configures whether or not Felix will program Windows Firewall rules (to allow inbound access to its own metrics ports).", - "DescriptionHTML": "

    Configures whether or not Felix will program Windows Firewall rules (to allow inbound access to its own metrics ports).

    ", - "UserEditable": true, - "GoType": "*v3.WindowsManageFirewallRulesMode" - } - ] - }, - { - "Name": "Data plane: OpenStack support", - "Fields": [ - { - "Group": "Data plane: OpenStack support", - "GroupWithSortPrefix": "25 Dataplane: OpenStack support", - "NameConfigFile": "EndpointReportingDelaySecs", - "NameEnvVar": "FELIX_EndpointReportingDelaySecs", - "NameYAML": "endpointReportingDelay", - "NameGoAPI": "EndpointReportingDelay", - "StringSchema": "Seconds (floating point)", - "StringSchemaHTML": "Seconds (floating point)", - "StringDefault": "1", - "ParsedDefault": "1s", - "ParsedDefaultJSON": "1000000000", - "ParsedType": "time.Duration", - "YAMLType": "string", - "YAMLSchema": "Duration string, for example `1m30s123ms` or `1h5m`.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Duration string, for example 1m30s123ms or 1h5m.", - "YAMLDefault": "1s", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "The delay before Felix reports endpoint status to the datastore. This is only used by the OpenStack integration.", - "DescriptionHTML": "

    The delay before Felix reports endpoint status to the datastore. This is only used by the OpenStack integration.

    ", - "UserEditable": true, - "GoType": "*v1.Duration" - }, - { - "Group": "Data plane: OpenStack support", - "GroupWithSortPrefix": "25 Dataplane: OpenStack support", - "NameConfigFile": "EndpointReportingEnabled", - "NameEnvVar": "FELIX_EndpointReportingEnabled", - "NameYAML": "endpointReportingEnabled", - "NameGoAPI": "EndpointReportingEnabled", - "StringSchema": "Boolean: `true`, `1`, `yes`, `y`, `t` accepted as True; `false`, `0`, `no`, `n`, `f` accepted (case insensitively) as False.", - "StringSchemaHTML": "Boolean: true, 1, yes, y, t accepted as True; false, 0, no, n, f accepted (case insensitively) as False.", - "StringDefault": "false", - "ParsedDefault": "false", - "ParsedDefaultJSON": "false", - "ParsedType": "bool", - "YAMLType": "boolean", - "YAMLSchema": "Boolean.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Boolean.", - "YAMLDefault": "false", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Controls whether Felix reports endpoint status to the datastore. This is only used by the OpenStack integration.", - "DescriptionHTML": "

    Controls whether Felix reports endpoint status to the datastore. This is only used by the OpenStack integration.

    ", - "UserEditable": true, - "GoType": "*bool" - }, - { - "Group": "Data plane: OpenStack support", - "GroupWithSortPrefix": "25 Dataplane: OpenStack support", - "NameConfigFile": "MetadataAddr", - "NameEnvVar": "FELIX_MetadataAddr", - "NameYAML": "metadataAddr", - "NameGoAPI": "MetadataAddr", - "StringSchema": "String matching regex `^[a-zA-Z0-9_.-]+$`", - "StringSchemaHTML": "String matching regex ^[a-zA-Z0-9_.-]+$", - "StringDefault": "127.0.0.1", - "ParsedDefault": "127.0.0.1", - "ParsedDefaultJSON": "\"127.0.0.1\"", - "ParsedType": "string", - "YAMLType": "string", - "YAMLSchema": "String.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "String.", - "YAMLDefault": "127.0.0.1", - "Required": false, - "OnParseFailure": "Exit", - "AllowedConfigSources": "All", - "Description": "The IP address or domain name of the server that can answer VM queries for cloud-init metadata. In OpenStack, this corresponds to the machine running nova-api (or in Ubuntu, nova-api-metadata). A value of none (case-insensitive) means that Felix should not set up any NAT rule for the metadata path.", - "DescriptionHTML": "

    The IP address or domain name of the server that can answer VM queries for cloud-init metadata. In OpenStack, this corresponds to the machine running nova-api (or in Ubuntu, nova-api-metadata). A value of none (case-insensitive) means that Felix should not set up any NAT rule for the metadata path.

    ", - "UserEditable": true, - "GoType": "string" - }, - { - "Group": "Data plane: OpenStack support", - "GroupWithSortPrefix": "25 Dataplane: OpenStack support", - "NameConfigFile": "MetadataPort", - "NameEnvVar": "FELIX_MetadataPort", - "NameYAML": "metadataPort", - "NameGoAPI": "MetadataPort", - "StringSchema": "Integer: [0,65535]", - "StringSchemaHTML": "Integer: [0,65535]", - "StringDefault": "8775", - "ParsedDefault": "8775", - "ParsedDefaultJSON": "8775", - "ParsedType": "int", - "YAMLType": "integer", - "YAMLSchema": "Integer: [0,65535]", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Integer: [0,65535]", - "YAMLDefault": "8775", - "Required": false, - "OnParseFailure": "Exit", - "AllowedConfigSources": "All", - "Description": "The port of the metadata server. This, combined with global.MetadataAddr (if not 'None'), is used to set up a NAT rule, from 169.254.169.254:80 to MetadataAddr:MetadataPort. In most cases this should not need to be changed .", - "DescriptionHTML": "

    The port of the metadata server. This, combined with global.MetadataAddr (if not 'None'), is used to set up a NAT rule, from 169.254.169.254:80 to MetadataAddr:MetadataPort. In most cases this should not need to be changed .

    ", - "UserEditable": true, - "GoType": "*int" - }, - { - "Group": "Data plane: OpenStack support", - "GroupWithSortPrefix": "25 Dataplane: OpenStack support", - "NameConfigFile": "OpenstackRegion", - "NameEnvVar": "FELIX_OpenstackRegion", - "NameYAML": "openstackRegion", - "NameGoAPI": "OpenstackRegion", - "StringSchema": "OpenStack region name (must be a valid DNS label)", - "StringSchemaHTML": "OpenStack region name (must be a valid DNS label)", - "StringDefault": "", - "ParsedDefault": "", - "ParsedDefaultJSON": "\"\"", - "ParsedType": "string", - "YAMLType": "string", - "YAMLSchema": "String.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "String.", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "Exit", - "AllowedConfigSources": "All", - "Description": "The name of the region that a particular Felix belongs to. In a multi-region Calico/OpenStack deployment, this must be configured somehow for each Felix (here in the datamodel, or in felix.cfg or the environment on each compute node), and must match the [calico] openstack_region value configured in neutron.conf on each node.", - "DescriptionHTML": "

    The name of the region that a particular Felix belongs to. In a multi-region Calico/OpenStack deployment, this must be configured somehow for each Felix (here in the datamodel, or in felix.cfg or the environment on each compute node), and must match the [calico] openstack_region value configured in neutron.conf on each node.

    ", - "UserEditable": true, - "GoType": "string" - }, - { - "Group": "Data plane: OpenStack support", - "GroupWithSortPrefix": "25 Dataplane: OpenStack support", - "NameConfigFile": "ReportingIntervalSecs", - "NameEnvVar": "FELIX_ReportingIntervalSecs", - "NameYAML": "reportingInterval", - "NameGoAPI": "ReportingInterval", - "StringSchema": "Seconds (floating point)", - "StringSchemaHTML": "Seconds (floating point)", - "StringDefault": "30", - "ParsedDefault": "30s", - "ParsedDefaultJSON": "30000000000", - "ParsedType": "time.Duration", - "YAMLType": "string", - "YAMLSchema": "Duration string, for example `1m30s123ms` or `1h5m`.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Duration string, for example 1m30s123ms or 1h5m.", - "YAMLDefault": "30s", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "The interval at which Felix reports its status into the datastore or 0 to disable. Must be non-zero in OpenStack deployments.", - "DescriptionHTML": "

    The interval at which Felix reports its status into the datastore or 0 to disable. Must be non-zero in OpenStack deployments.

    ", - "UserEditable": true, - "GoType": "*v1.Duration" - }, - { - "Group": "Data plane: OpenStack support", - "GroupWithSortPrefix": "25 Dataplane: OpenStack support", - "NameConfigFile": "ReportingTTLSecs", - "NameEnvVar": "FELIX_ReportingTTLSecs", - "NameYAML": "reportingTTL", - "NameGoAPI": "ReportingTTL", - "StringSchema": "Seconds (floating point)", - "StringSchemaHTML": "Seconds (floating point)", - "StringDefault": "90", - "ParsedDefault": "1m30s", - "ParsedDefaultJSON": "90000000000", - "ParsedType": "time.Duration", - "YAMLType": "string", - "YAMLSchema": "Duration string, for example `1m30s123ms` or `1h5m`.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Duration string, for example 1m30s123ms or 1h5m.", - "YAMLDefault": "1m30s", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "The time-to-live setting for process-wide status reports.", - "DescriptionHTML": "

    The time-to-live setting for process-wide status reports.

    ", - "UserEditable": true, - "GoType": "*v1.Duration" - } - ] - }, - { - "Name": "Data plane: XDP acceleration for iptables data plane", - "Fields": [ - { - "Group": "Data plane: XDP acceleration for iptables data plane", - "GroupWithSortPrefix": "25 Dataplane: XDP acceleration for iptables data plane", - "NameConfigFile": "GenericXDPEnabled", - "NameEnvVar": "FELIX_GenericXDPEnabled", - "NameYAML": "genericXDPEnabled", - "NameGoAPI": "GenericXDPEnabled", - "StringSchema": "Boolean: `true`, `1`, `yes`, `y`, `t` accepted as True; `false`, `0`, `no`, `n`, `f` accepted (case insensitively) as False.", - "StringSchemaHTML": "Boolean: true, 1, yes, y, t accepted as True; false, 0, no, n, f accepted (case insensitively) as False.", - "StringDefault": "false", - "ParsedDefault": "false", - "ParsedDefaultJSON": "false", - "ParsedType": "bool", - "YAMLType": "boolean", - "YAMLSchema": "Boolean.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Boolean.", - "YAMLDefault": "false", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Enables Generic XDP so network cards that don't support XDP offload or driver modes can use XDP. This is not recommended since it doesn't provide better performance than iptables.", - "DescriptionHTML": "

    Enables Generic XDP so network cards that don't support XDP offload or driver modes can use XDP. This is not recommended since it doesn't provide better performance than iptables.

    ", - "UserEditable": true, - "GoType": "*bool" - }, - { - "Group": "Data plane: XDP acceleration for iptables data plane", - "GroupWithSortPrefix": "25 Dataplane: XDP acceleration for iptables data plane", - "NameConfigFile": "XDPEnabled", - "NameEnvVar": "FELIX_XDPEnabled", - "NameYAML": "xdpEnabled", - "NameGoAPI": "XDPEnabled", - "StringSchema": "Boolean: `true`, `1`, `yes`, `y`, `t` accepted as True; `false`, `0`, `no`, `n`, `f` accepted (case insensitively) as False.", - "StringSchemaHTML": "Boolean: true, 1, yes, y, t accepted as True; false, 0, no, n, f accepted (case insensitively) as False.", - "StringDefault": "true", - "ParsedDefault": "true", - "ParsedDefaultJSON": "true", - "ParsedType": "bool", - "YAMLType": "boolean", - "YAMLSchema": "Boolean.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Boolean.", - "YAMLDefault": "true", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Enables XDP acceleration for suitable untracked incoming deny rules.", - "DescriptionHTML": "

    Enables XDP acceleration for suitable untracked incoming deny rules.

    ", - "UserEditable": true, - "GoType": "*bool" - }, - { - "Group": "Data plane: XDP acceleration for iptables data plane", - "GroupWithSortPrefix": "25 Dataplane: XDP acceleration for iptables data plane", - "NameConfigFile": "XDPRefreshInterval", - "NameEnvVar": "FELIX_XDPRefreshInterval", - "NameYAML": "xdpRefreshInterval", - "NameGoAPI": "XDPRefreshInterval", - "StringSchema": "Seconds (floating point)", - "StringSchemaHTML": "Seconds (floating point)", - "StringDefault": "90", - "ParsedDefault": "1m30s", - "ParsedDefaultJSON": "90000000000", - "ParsedType": "time.Duration", - "YAMLType": "string", - "YAMLSchema": "Duration string, for example `1m30s123ms` or `1h5m`.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Duration string, for example 1m30s123ms or 1h5m.", - "YAMLDefault": "1m30s", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "The period at which Felix re-checks all XDP state to ensure that no other process has accidentally broken Calico's BPF maps or attached programs. Set to 0 to disable XDP refresh.", - "DescriptionHTML": "

    The period at which Felix re-checks all XDP state to ensure that no other process has accidentally broken Calico's BPF maps or attached programs. Set to 0 to disable XDP refresh.

    ", - "UserEditable": true, - "GoType": "*v1.Duration" - } - ] - }, - { - "Name": "Overlay: VXLAN overlay", - "Fields": [ - { - "Group": "Overlay: VXLAN overlay", - "GroupWithSortPrefix": "31 Overlay: VXLAN overlay", - "NameConfigFile": "VXLANEnabled", - "NameEnvVar": "FELIX_VXLANEnabled", - "NameYAML": "vxlanEnabled", - "NameGoAPI": "VXLANEnabled", - "StringSchema": "Boolean: `true`, `1`, `yes`, `y`, `t` accepted as True; `false`, `0`, `no`, `n`, `f` accepted (case insensitively) as False.", - "StringSchemaHTML": "Boolean: true, 1, yes, y, t accepted as True; false, 0, no, n, f accepted (case insensitively) as False.", - "StringDefault": "", - "ParsedDefault": "", - "ParsedDefaultJSON": "null", - "ParsedType": "*bool", - "YAMLType": "boolean", - "YAMLSchema": "Boolean.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Boolean.", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Overrides whether Felix should create the VXLAN tunnel device for IPv4 VXLAN networking. Optional as Felix determines this based on the existing IP pools.", - "DescriptionHTML": "

    Overrides whether Felix should create the VXLAN tunnel device for IPv4 VXLAN networking. Optional as Felix determines this based on the existing IP pools.

    ", - "UserEditable": true, - "GoType": "*bool" - }, - { - "Group": "Overlay: VXLAN overlay", - "GroupWithSortPrefix": "31 Overlay: VXLAN overlay", - "NameConfigFile": "VXLANMTU", - "NameEnvVar": "FELIX_VXLANMTU", - "NameYAML": "vxlanMTU", - "NameGoAPI": "VXLANMTU", - "StringSchema": "Integer", - "StringSchemaHTML": "Integer", - "StringDefault": "0", - "ParsedDefault": "0", - "ParsedDefaultJSON": "0", - "ParsedType": "int", - "YAMLType": "integer", - "YAMLSchema": "Integer", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Integer", - "YAMLDefault": "0", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "The MTU to set on the IPv4 VXLAN tunnel device. Optional as Felix auto-detects the MTU based on the MTU of the host's interfaces.", - "DescriptionHTML": "

    The MTU to set on the IPv4 VXLAN tunnel device. Optional as Felix auto-detects the MTU based on the MTU of the host's interfaces.

    ", - "UserEditable": true, - "GoType": "*int" - }, - { - "Group": "Overlay: VXLAN overlay", - "GroupWithSortPrefix": "31 Overlay: VXLAN overlay", - "NameConfigFile": "VXLANMTUV6", - "NameEnvVar": "FELIX_VXLANMTUV6", - "NameYAML": "vxlanMTUV6", - "NameGoAPI": "VXLANMTUV6", - "StringSchema": "Integer", - "StringSchemaHTML": "Integer", - "StringDefault": "0", - "ParsedDefault": "0", - "ParsedDefaultJSON": "0", - "ParsedType": "int", - "YAMLType": "integer", - "YAMLSchema": "Integer", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Integer", - "YAMLDefault": "0", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "The MTU to set on the IPv6 VXLAN tunnel device. Optional as Felix auto-detects the MTU based on the MTU of the host's interfaces.", - "DescriptionHTML": "

    The MTU to set on the IPv6 VXLAN tunnel device. Optional as Felix auto-detects the MTU based on the MTU of the host's interfaces.

    ", - "UserEditable": true, - "GoType": "*int" - }, - { - "Group": "Overlay: VXLAN overlay", - "GroupWithSortPrefix": "31 Overlay: VXLAN overlay", - "NameConfigFile": "VXLANPort", - "NameEnvVar": "FELIX_VXLANPort", - "NameYAML": "vxlanPort", - "NameGoAPI": "VXLANPort", - "StringSchema": "Integer", - "StringSchemaHTML": "Integer", - "StringDefault": "4789", - "ParsedDefault": "4789", - "ParsedDefaultJSON": "4789", - "ParsedType": "int", - "YAMLType": "integer", - "YAMLSchema": "Integer", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Integer", - "YAMLDefault": "4789", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "The UDP port number to use for VXLAN traffic.", - "DescriptionHTML": "

    The UDP port number to use for VXLAN traffic.

    ", - "UserEditable": true, - "GoType": "*int" - }, - { - "Group": "Overlay: VXLAN overlay", - "GroupWithSortPrefix": "31 Overlay: VXLAN overlay", - "NameConfigFile": "VXLANVNI", - "NameEnvVar": "FELIX_VXLANVNI", - "NameYAML": "vxlanVNI", - "NameGoAPI": "VXLANVNI", - "StringSchema": "Integer", - "StringSchemaHTML": "Integer", - "StringDefault": "4096", - "ParsedDefault": "4096", - "ParsedDefaultJSON": "4096", - "ParsedType": "int", - "YAMLType": "integer", - "YAMLSchema": "Integer", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Integer", - "YAMLDefault": "4096", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "The VXLAN VNI to use for VXLAN traffic. You may need to change this if the default value is in use on your system.", - "DescriptionHTML": "

    The VXLAN VNI to use for VXLAN traffic. You may need to change this if the default value is in use on your system.

    ", - "UserEditable": true, - "GoType": "*int" - } - ] - }, - { - "Name": "Overlay: IP-in-IP", - "Fields": [ - { - "Group": "Overlay: IP-in-IP", - "GroupWithSortPrefix": "32 Overlay: IP-in-IP", - "NameConfigFile": "IpInIpEnabled", - "NameEnvVar": "FELIX_IpInIpEnabled", - "NameYAML": "ipipEnabled", - "NameGoAPI": "IPIPEnabled", - "StringSchema": "Boolean: `true`, `1`, `yes`, `y`, `t` accepted as True; `false`, `0`, `no`, `n`, `f` accepted (case insensitively) as False.", - "StringSchemaHTML": "Boolean: true, 1, yes, y, t accepted as True; false, 0, no, n, f accepted (case insensitively) as False.", - "StringDefault": "", - "ParsedDefault": "", - "ParsedDefaultJSON": "null", - "ParsedType": "*bool", - "YAMLType": "boolean", - "YAMLSchema": "Boolean.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Boolean.", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Overrides whether Felix should configure an IPIP interface on the host. Optional as Felix determines this based on the existing IP pools.", - "DescriptionHTML": "

    Overrides whether Felix should configure an IPIP interface on the host. Optional as Felix determines this based on the existing IP pools.

    ", - "UserEditable": true, - "GoType": "*bool" - }, - { - "Group": "Overlay: IP-in-IP", - "GroupWithSortPrefix": "32 Overlay: IP-in-IP", - "NameConfigFile": "IpInIpMtu", - "NameEnvVar": "FELIX_IpInIpMtu", - "NameYAML": "ipipMTU", - "NameGoAPI": "IPIPMTU", - "StringSchema": "Integer", - "StringSchemaHTML": "Integer", - "StringDefault": "0", - "ParsedDefault": "0", - "ParsedDefaultJSON": "0", - "ParsedType": "int", - "YAMLType": "integer", - "YAMLSchema": "Integer", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Integer", - "YAMLDefault": "0", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Controls the MTU to set on the IPIP tunnel device. Optional as Felix auto-detects the MTU based on the MTU of the host's interfaces.", - "DescriptionHTML": "

    Controls the MTU to set on the IPIP tunnel device. Optional as Felix auto-detects the MTU based on the MTU of the host's interfaces.

    ", - "UserEditable": true, - "GoType": "*int" - } - ] - }, - { - "Name": "Overlay: Wireguard", - "Fields": [ - { - "Group": "Overlay: Wireguard", - "GroupWithSortPrefix": "33 Overlay: Wireguard", - "NameConfigFile": "WireguardEnabled", - "NameEnvVar": "FELIX_WireguardEnabled", - "NameYAML": "wireguardEnabled", - "NameGoAPI": "WireguardEnabled", - "StringSchema": "Boolean: `true`, `1`, `yes`, `y`, `t` accepted as True; `false`, `0`, `no`, `n`, `f` accepted (case insensitively) as False.", - "StringSchemaHTML": "Boolean: true, 1, yes, y, t accepted as True; false, 0, no, n, f accepted (case insensitively) as False.", - "StringDefault": "false", - "ParsedDefault": "false", - "ParsedDefaultJSON": "false", - "ParsedType": "bool", - "YAMLType": "boolean", - "YAMLSchema": "Boolean.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Boolean.", - "YAMLDefault": "false", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Controls whether Wireguard is enabled for IPv4 (encapsulating IPv4 traffic over an IPv4 underlay network).", - "DescriptionHTML": "

    Controls whether Wireguard is enabled for IPv4 (encapsulating IPv4 traffic over an IPv4 underlay network).

    ", - "UserEditable": true, - "GoType": "*bool" - }, - { - "Group": "Overlay: Wireguard", - "GroupWithSortPrefix": "33 Overlay: Wireguard", - "NameConfigFile": "WireguardEnabledV6", - "NameEnvVar": "FELIX_WireguardEnabledV6", - "NameYAML": "wireguardEnabledV6", - "NameGoAPI": "WireguardEnabledV6", - "StringSchema": "Boolean: `true`, `1`, `yes`, `y`, `t` accepted as True; `false`, `0`, `no`, `n`, `f` accepted (case insensitively) as False.", - "StringSchemaHTML": "Boolean: true, 1, yes, y, t accepted as True; false, 0, no, n, f accepted (case insensitively) as False.", - "StringDefault": "false", - "ParsedDefault": "false", - "ParsedDefaultJSON": "false", - "ParsedType": "bool", - "YAMLType": "boolean", - "YAMLSchema": "Boolean.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Boolean.", - "YAMLDefault": "false", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Controls whether Wireguard is enabled for IPv6 (encapsulating IPv6 traffic over an IPv6 underlay network).", - "DescriptionHTML": "

    Controls whether Wireguard is enabled for IPv6 (encapsulating IPv6 traffic over an IPv6 underlay network).

    ", - "UserEditable": true, - "GoType": "*bool" - }, - { - "Group": "Overlay: Wireguard", - "GroupWithSortPrefix": "33 Overlay: Wireguard", - "NameConfigFile": "WireguardHostEncryptionEnabled", - "NameEnvVar": "FELIX_WireguardHostEncryptionEnabled", - "NameYAML": "wireguardHostEncryptionEnabled", - "NameGoAPI": "WireguardHostEncryptionEnabled", - "StringSchema": "Boolean: `true`, `1`, `yes`, `y`, `t` accepted as True; `false`, `0`, `no`, `n`, `f` accepted (case insensitively) as False.", - "StringSchemaHTML": "Boolean: true, 1, yes, y, t accepted as True; false, 0, no, n, f accepted (case insensitively) as False.", - "StringDefault": "false", - "ParsedDefault": "false", - "ParsedDefaultJSON": "false", - "ParsedType": "bool", - "YAMLType": "boolean", - "YAMLSchema": "Boolean.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Boolean.", - "YAMLDefault": "false", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Controls whether Wireguard host-to-host encryption is enabled.", - "DescriptionHTML": "

    Controls whether Wireguard host-to-host encryption is enabled.

    ", - "UserEditable": true, - "GoType": "*bool" - }, - { - "Group": "Overlay: Wireguard", - "GroupWithSortPrefix": "33 Overlay: Wireguard", - "NameConfigFile": "WireguardInterfaceName", - "NameEnvVar": "FELIX_WireguardInterfaceName", - "NameYAML": "wireguardInterfaceName", - "NameGoAPI": "WireguardInterfaceName", - "StringSchema": "String matching regex `^[a-zA-Z0-9:._+-]{1,15}$`", - "StringSchemaHTML": "String matching regex ^[a-zA-Z0-9:._+-]{1,15}$", - "StringDefault": "wireguard.cali", - "ParsedDefault": "wireguard.cali", - "ParsedDefaultJSON": "\"wireguard.cali\"", - "ParsedType": "string", - "YAMLType": "string", - "YAMLSchema": "String.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "String.", - "YAMLDefault": "wireguard.cali", - "Required": true, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Specifies the name to use for the IPv4 Wireguard interface.", - "DescriptionHTML": "

    Specifies the name to use for the IPv4 Wireguard interface.

    ", - "UserEditable": true, - "GoType": "string" - }, - { - "Group": "Overlay: Wireguard", - "GroupWithSortPrefix": "33 Overlay: Wireguard", - "NameConfigFile": "WireguardInterfaceNameV6", - "NameEnvVar": "FELIX_WireguardInterfaceNameV6", - "NameYAML": "wireguardInterfaceNameV6", - "NameGoAPI": "WireguardInterfaceNameV6", - "StringSchema": "String matching regex `^[a-zA-Z0-9:._+-]{1,15}$`", - "StringSchemaHTML": "String matching regex ^[a-zA-Z0-9:._+-]{1,15}$", - "StringDefault": "wg-v6.cali", - "ParsedDefault": "wg-v6.cali", - "ParsedDefaultJSON": "\"wg-v6.cali\"", - "ParsedType": "string", - "YAMLType": "string", - "YAMLSchema": "String.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "String.", - "YAMLDefault": "wg-v6.cali", - "Required": true, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Specifies the name to use for the IPv6 Wireguard interface.", - "DescriptionHTML": "

    Specifies the name to use for the IPv6 Wireguard interface.

    ", - "UserEditable": true, - "GoType": "string" - }, - { - "Group": "Overlay: Wireguard", - "GroupWithSortPrefix": "33 Overlay: Wireguard", - "NameConfigFile": "WireguardListeningPort", - "NameEnvVar": "FELIX_WireguardListeningPort", - "NameYAML": "wireguardListeningPort", - "NameGoAPI": "WireguardListeningPort", - "StringSchema": "Integer", - "StringSchemaHTML": "Integer", - "StringDefault": "51820", - "ParsedDefault": "51820", - "ParsedDefaultJSON": "51820", - "ParsedType": "int", - "YAMLType": "integer", - "YAMLSchema": "Integer", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Integer", - "YAMLDefault": "51820", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Controls the listening port used by IPv4 Wireguard.", - "DescriptionHTML": "

    Controls the listening port used by IPv4 Wireguard.

    ", - "UserEditable": true, - "GoType": "*int" - }, - { - "Group": "Overlay: Wireguard", - "GroupWithSortPrefix": "33 Overlay: Wireguard", - "NameConfigFile": "WireguardListeningPortV6", - "NameEnvVar": "FELIX_WireguardListeningPortV6", - "NameYAML": "wireguardListeningPortV6", - "NameGoAPI": "WireguardListeningPortV6", - "StringSchema": "Integer", - "StringSchemaHTML": "Integer", - "StringDefault": "51821", - "ParsedDefault": "51821", - "ParsedDefaultJSON": "51821", - "ParsedType": "int", - "YAMLType": "integer", - "YAMLSchema": "Integer", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Integer", - "YAMLDefault": "51821", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Controls the listening port used by IPv6 Wireguard.", - "DescriptionHTML": "

    Controls the listening port used by IPv6 Wireguard.

    ", - "UserEditable": true, - "GoType": "*int" - }, - { - "Group": "Overlay: Wireguard", - "GroupWithSortPrefix": "33 Overlay: Wireguard", - "NameConfigFile": "WireguardMTU", - "NameEnvVar": "FELIX_WireguardMTU", - "NameYAML": "wireguardMTU", - "NameGoAPI": "WireguardMTU", - "StringSchema": "Integer", - "StringSchemaHTML": "Integer", - "StringDefault": "0", - "ParsedDefault": "0", - "ParsedDefaultJSON": "0", - "ParsedType": "int", - "YAMLType": "integer", - "YAMLSchema": "Integer", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Integer", - "YAMLDefault": "0", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Controls the MTU on the IPv4 Wireguard interface. See Configuring MTU.", - "DescriptionHTML": "

    Controls the MTU on the IPv4 Wireguard interface. See Configuring MTU.

    ", - "UserEditable": true, - "GoType": "*int" - }, - { - "Group": "Overlay: Wireguard", - "GroupWithSortPrefix": "33 Overlay: Wireguard", - "NameConfigFile": "WireguardMTUV6", - "NameEnvVar": "FELIX_WireguardMTUV6", - "NameYAML": "wireguardMTUV6", - "NameGoAPI": "WireguardMTUV6", - "StringSchema": "Integer", - "StringSchemaHTML": "Integer", - "StringDefault": "0", - "ParsedDefault": "0", - "ParsedDefaultJSON": "0", - "ParsedType": "int", - "YAMLType": "integer", - "YAMLSchema": "Integer", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Integer", - "YAMLDefault": "0", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Controls the MTU on the IPv6 Wireguard interface. See Configuring MTU.", - "DescriptionHTML": "

    Controls the MTU on the IPv6 Wireguard interface. See Configuring MTU.

    ", - "UserEditable": true, - "GoType": "*int" - }, - { - "Group": "Overlay: Wireguard", - "GroupWithSortPrefix": "33 Overlay: Wireguard", - "NameConfigFile": "WireguardPersistentKeepAlive", - "NameEnvVar": "FELIX_WireguardPersistentKeepAlive", - "NameYAML": "wireguardKeepAlive", - "NameGoAPI": "WireguardPersistentKeepAlive", - "StringSchema": "Seconds (floating point)", - "StringSchemaHTML": "Seconds (floating point)", - "StringDefault": "0", - "ParsedDefault": "0s", - "ParsedDefaultJSON": "0", - "ParsedType": "time.Duration", - "YAMLType": "string", - "YAMLSchema": "Duration string, for example `1m30s123ms` or `1h5m`.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Duration string, for example 1m30s123ms or 1h5m.", - "YAMLDefault": "0s", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Controls Wireguard PersistentKeepalive option. Set 0 to disable.", - "DescriptionHTML": "

    Controls Wireguard PersistentKeepalive option. Set 0 to disable.

    ", - "UserEditable": true, - "GoType": "*v1.Duration" - }, - { - "Group": "Overlay: Wireguard", - "GroupWithSortPrefix": "33 Overlay: Wireguard", - "NameConfigFile": "WireguardRoutingRulePriority", - "NameEnvVar": "FELIX_WireguardRoutingRulePriority", - "NameYAML": "wireguardRoutingRulePriority", - "NameGoAPI": "WireguardRoutingRulePriority", - "StringSchema": "Integer", - "StringSchemaHTML": "Integer", - "StringDefault": "99", - "ParsedDefault": "99", - "ParsedDefaultJSON": "99", - "ParsedType": "int", - "YAMLType": "integer", - "YAMLSchema": "Integer", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Integer", - "YAMLDefault": "99", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Controls the priority value to use for the Wireguard routing rule.", - "DescriptionHTML": "

    Controls the priority value to use for the Wireguard routing rule.

    ", - "UserEditable": true, - "GoType": "*int" - } - ] - }, - { - "Name": "AWS integration", - "Fields": [ - { - "Group": "AWS integration", - "GroupWithSortPrefix": "60 AWS integration", - "NameConfigFile": "AWSSrcDstCheck", - "NameEnvVar": "FELIX_AWSSrcDstCheck", - "NameYAML": "awsSrcDstCheck", - "NameGoAPI": "AWSSrcDstCheck", - "StringSchema": "One of: `Disable`, `DoNothing`, `Enable` (case insensitive)", - "StringSchemaHTML": "One of: Disable, DoNothing, Enable (case insensitive)", - "StringDefault": "DoNothing", - "ParsedDefault": "DoNothing", - "ParsedDefaultJSON": "\"DoNothing\"", - "ParsedType": "string", - "YAMLType": "string", - "YAMLSchema": "One of: `Disable`, `DoNothing`, `Enable`.", - "YAMLEnumValues": [ - "`Disable`", - "`DoNothing`", - "`Enable`" - ], - "YAMLSchemaHTML": "One of: Disable, DoNothing, Enable.", - "YAMLDefault": "DoNothing", - "Required": true, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Controls whether Felix will try to change the \"source/dest check\" setting on the EC2 instance on which it is running. A value of \"Disable\" will try to disable the source/dest check. Disabling the check allows for sending workload traffic without encapsulation within the same AWS subnet.", - "DescriptionHTML": "

    Controls whether Felix will try to change the \"source/dest check\" setting on the EC2 instance on which it is running. A value of \"Disable\" will try to disable the source/dest check. Disabling the check allows for sending workload traffic without encapsulation within the same AWS subnet.

    ", - "UserEditable": true, - "GoType": "*v3.AWSSrcDstCheckOption" - } - ] - }, - { - "Name": "Debug/test-only (generally unsupported)", - "Fields": [ - { - "Group": "Debug/test-only (generally unsupported)", - "GroupWithSortPrefix": "97 Debug/test-only (generally unsupported)", - "NameConfigFile": "DebugBPFCgroupV2", - "NameEnvVar": "FELIX_DebugBPFCgroupV2", - "NameYAML": "", - "NameGoAPI": "", - "StringSchema": "String", - "StringSchemaHTML": "String", - "StringDefault": "", - "ParsedDefault": "", - "ParsedDefaultJSON": "\"\"", - "ParsedType": "string", - "YAMLType": "", - "YAMLSchema": "", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "LocalOnly", - "Description": "Controls the cgroup v2 path that we apply the connect-time load balancer to. Most distros\nare configured for cgroup v1, which prevents all but the root cgroup v2 from working so this is only useful\nfor development right now.", - "DescriptionHTML": "

    Controls the cgroup v2 path that we apply the connect-time load balancer to. Most distros\nare configured for cgroup v1, which prevents all but the root cgroup v2 from working so this is only useful\nfor development right now.

    ", - "UserEditable": true, - "GoType": "" - }, - { - "Group": "Debug/test-only (generally unsupported)", - "GroupWithSortPrefix": "97 Debug/test-only (generally unsupported)", - "NameConfigFile": "DebugBPFMapRepinEnabled", - "NameEnvVar": "FELIX_DebugBPFMapRepinEnabled", - "NameYAML": "", - "NameGoAPI": "", - "StringSchema": "Boolean: `true`, `1`, `yes`, `y`, `t` accepted as True; `false`, `0`, `no`, `n`, `f` accepted (case insensitively) as False.", - "StringSchemaHTML": "Boolean: true, 1, yes, y, t accepted as True; false, 0, no, n, f accepted (case insensitively) as False.", - "StringDefault": "false", - "ParsedDefault": "false", - "ParsedDefaultJSON": "false", - "ParsedType": "bool", - "YAMLType": "", - "YAMLSchema": "", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "LocalOnly", - "Description": "Can be used to prevent Felix from repinning its BPF maps at startup. This is useful for\ntesting with multiple Felix instances running on one host.", - "DescriptionHTML": "

    Can be used to prevent Felix from repinning its BPF maps at startup. This is useful for\ntesting with multiple Felix instances running on one host.

    ", - "UserEditable": true, - "GoType": "" - }, - { - "Group": "Debug/test-only (generally unsupported)", - "GroupWithSortPrefix": "97 Debug/test-only (generally unsupported)", - "NameConfigFile": "DebugCPUProfilePath", - "NameEnvVar": "FELIX_DebugCPUProfilePath", - "NameYAML": "", - "NameGoAPI": "", - "StringSchema": "Path to file", - "StringSchemaHTML": "Path to file", - "StringDefault": "/tmp/felix-cpu-.pprof", - "ParsedDefault": "/tmp/felix-cpu-.pprof", - "ParsedDefaultJSON": "\"/tmp/felix-cpu-\\u003ctimestamp\\u003e.pprof\"", - "ParsedType": "string", - "YAMLType": "", - "YAMLSchema": "", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Unsupported diagnostic setting, used when testing Felix. Not exposed in `FelixConfiguration`.", - "DescriptionHTML": "

    Unsupported diagnostic setting, used when testing Felix. Not exposed in FelixConfiguration.

    ", - "UserEditable": true, - "GoType": "" - }, - { - "Group": "Debug/test-only (generally unsupported)", - "GroupWithSortPrefix": "97 Debug/test-only (generally unsupported)", - "NameConfigFile": "DebugDisableLogDropping", - "NameEnvVar": "FELIX_DebugDisableLogDropping", - "NameYAML": "debugDisableLogDropping", - "NameGoAPI": "DebugDisableLogDropping", - "StringSchema": "Boolean: `true`, `1`, `yes`, `y`, `t` accepted as True; `false`, `0`, `no`, `n`, `f` accepted (case insensitively) as False.", - "StringSchemaHTML": "Boolean: true, 1, yes, y, t accepted as True; false, 0, no, n, f accepted (case insensitively) as False.", - "StringDefault": "false", - "ParsedDefault": "false", - "ParsedDefaultJSON": "false", - "ParsedType": "bool", - "YAMLType": "boolean", - "YAMLSchema": "Boolean.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Boolean.", - "YAMLDefault": "false", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Disables the dropping of log messages when the log buffer is full. This can significantly impact performance if log write-out is a bottleneck.", - "DescriptionHTML": "

    Disables the dropping of log messages when the log buffer is full. This can significantly impact performance if log write-out is a bottleneck.

    ", - "UserEditable": true, - "GoType": "*bool" - }, - { - "Group": "Debug/test-only (generally unsupported)", - "GroupWithSortPrefix": "97 Debug/test-only (generally unsupported)", - "NameConfigFile": "DebugHost", - "NameEnvVar": "FELIX_DebugHost", - "NameYAML": "debugHost", - "NameGoAPI": "DebugHost", - "StringSchema": "String matching regex `^[a-zA-Z0-9:._+-]{1,64}$`", - "StringSchemaHTML": "String matching regex ^[a-zA-Z0-9:._+-]{1,64}$", - "StringDefault": "localhost", - "ParsedDefault": "localhost", - "ParsedDefaultJSON": "\"localhost\"", - "ParsedType": "string", - "YAMLType": "string", - "YAMLSchema": "String.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "String.", - "YAMLDefault": "localhost", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "The host IP or hostname to bind the debug port to. Only used if DebugPort is set.", - "DescriptionHTML": "

    The host IP or hostname to bind the debug port to. Only used if DebugPort is set.

    ", - "UserEditable": true, - "GoType": "*string" - }, - { - "Group": "Debug/test-only (generally unsupported)", - "GroupWithSortPrefix": "97 Debug/test-only (generally unsupported)", - "NameConfigFile": "DebugMemoryProfilePath", - "NameEnvVar": "FELIX_DebugMemoryProfilePath", - "NameYAML": "debugMemoryProfilePath", - "NameGoAPI": "DebugMemoryProfilePath", - "StringSchema": "Path to file", - "StringSchemaHTML": "Path to file", - "StringDefault": "", - "ParsedDefault": "", - "ParsedDefaultJSON": "\"\"", - "ParsedType": "string", - "YAMLType": "string", - "YAMLSchema": "String.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "String.", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "The path to write the memory profile to when triggered by signal.", - "DescriptionHTML": "

    The path to write the memory profile to when triggered by signal.

    ", - "UserEditable": true, - "GoType": "string" - }, - { - "Group": "Debug/test-only (generally unsupported)", - "GroupWithSortPrefix": "97 Debug/test-only (generally unsupported)", - "NameConfigFile": "DebugPanicAfter", - "NameEnvVar": "FELIX_DebugPanicAfter", - "NameYAML": "", - "NameGoAPI": "", - "StringSchema": "Seconds (floating point)", - "StringSchemaHTML": "Seconds (floating point)", - "StringDefault": "0", - "ParsedDefault": "0s", - "ParsedDefaultJSON": "0", - "ParsedType": "time.Duration", - "YAMLType": "", - "YAMLSchema": "", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Unsupported diagnostic setting, used when testing Felix. Not exposed in `FelixConfiguration`.", - "DescriptionHTML": "

    Unsupported diagnostic setting, used when testing Felix. Not exposed in FelixConfiguration.

    ", - "UserEditable": true, - "GoType": "" - }, - { - "Group": "Debug/test-only (generally unsupported)", - "GroupWithSortPrefix": "97 Debug/test-only (generally unsupported)", - "NameConfigFile": "DebugPort", - "NameEnvVar": "FELIX_DebugPort", - "NameYAML": "debugPort", - "NameGoAPI": "DebugPort", - "StringSchema": "Integer: [0,65535]", - "StringSchemaHTML": "Integer: [0,65535]", - "StringDefault": "", - "ParsedDefault": "0", - "ParsedDefaultJSON": "0", - "ParsedType": "int", - "YAMLType": "integer", - "YAMLSchema": "Integer: [0,65535]", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Integer: [0,65535]", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "If set, enables Felix's debug HTTP port, which allows memory and CPU profiles to be retrieved. The debug port is not secure, it should not be exposed to the internet.", - "DescriptionHTML": "

    If set, enables Felix's debug HTTP port, which allows memory and CPU profiles to be retrieved. The debug port is not secure, it should not be exposed to the internet.

    ", - "UserEditable": true, - "GoType": "*int" - }, - { - "Group": "Debug/test-only (generally unsupported)", - "GroupWithSortPrefix": "97 Debug/test-only (generally unsupported)", - "NameConfigFile": "DebugSimulateCalcGraphHangAfter", - "NameEnvVar": "FELIX_DebugSimulateCalcGraphHangAfter", - "NameYAML": "debugSimulateCalcGraphHangAfter", - "NameGoAPI": "DebugSimulateCalcGraphHangAfter", - "StringSchema": "Seconds (floating point)", - "StringSchemaHTML": "Seconds (floating point)", - "StringDefault": "0", - "ParsedDefault": "0s", - "ParsedDefaultJSON": "0", - "ParsedType": "time.Duration", - "YAMLType": "string", - "YAMLSchema": "Duration string, for example `1m30s123ms` or `1h5m`.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Duration string, for example 1m30s123ms or 1h5m.", - "YAMLDefault": "0s", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Used to simulate a hang in the calculation graph after the specified duration. This is useful in tests of the watchdog system only!", - "DescriptionHTML": "

    Used to simulate a hang in the calculation graph after the specified duration. This is useful in tests of the watchdog system only!

    ", - "UserEditable": true, - "GoType": "*v1.Duration" - }, - { - "Group": "Debug/test-only (generally unsupported)", - "GroupWithSortPrefix": "97 Debug/test-only (generally unsupported)", - "NameConfigFile": "DebugSimulateDataRace", - "NameEnvVar": "FELIX_DebugSimulateDataRace", - "NameYAML": "", - "NameGoAPI": "", - "StringSchema": "Boolean: `true`, `1`, `yes`, `y`, `t` accepted as True; `false`, `0`, `no`, `n`, `f` accepted (case insensitively) as False.", - "StringSchemaHTML": "Boolean: true, 1, yes, y, t accepted as True; false, 0, no, n, f accepted (case insensitively) as False.", - "StringDefault": "false", - "ParsedDefault": "false", - "ParsedDefaultJSON": "false", - "ParsedType": "bool", - "YAMLType": "", - "YAMLSchema": "", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "", - "YAMLDefault": "", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Unsupported diagnostic setting, used when testing Felix. Not exposed in `FelixConfiguration`.", - "DescriptionHTML": "

    Unsupported diagnostic setting, used when testing Felix. Not exposed in FelixConfiguration.

    ", - "UserEditable": true, - "GoType": "" - }, - { - "Group": "Debug/test-only (generally unsupported)", - "GroupWithSortPrefix": "97 Debug/test-only (generally unsupported)", - "NameConfigFile": "DebugSimulateDataplaneApplyDelay", - "NameEnvVar": "FELIX_DebugSimulateDataplaneApplyDelay", - "NameYAML": "debugSimulateDataplaneApplyDelay", - "NameGoAPI": "DebugSimulateDataplaneApplyDelay", - "StringSchema": "Seconds (floating point)", - "StringSchemaHTML": "Seconds (floating point)", - "StringDefault": "0", - "ParsedDefault": "0s", - "ParsedDefaultJSON": "0", - "ParsedType": "time.Duration", - "YAMLType": "string", - "YAMLSchema": "Duration string, for example `1m30s123ms` or `1h5m`.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Duration string, for example 1m30s123ms or 1h5m.", - "YAMLDefault": "0s", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Adds an artificial delay to every dataplane operation. This is useful for simulating a heavily loaded system for test purposes only.", - "DescriptionHTML": "

    Adds an artificial delay to every dataplane operation. This is useful for simulating a heavily loaded system for test purposes only.

    ", - "UserEditable": true, - "GoType": "*v1.Duration" - }, - { - "Group": "Debug/test-only (generally unsupported)", - "GroupWithSortPrefix": "97 Debug/test-only (generally unsupported)", - "NameConfigFile": "DebugSimulateDataplaneHangAfter", - "NameEnvVar": "FELIX_DebugSimulateDataplaneHangAfter", - "NameYAML": "debugSimulateDataplaneHangAfter", - "NameGoAPI": "DebugSimulateDataplaneHangAfter", - "StringSchema": "Seconds (floating point)", - "StringSchemaHTML": "Seconds (floating point)", - "StringDefault": "0", - "ParsedDefault": "0s", - "ParsedDefaultJSON": "0", - "ParsedType": "time.Duration", - "YAMLType": "string", - "YAMLSchema": "Duration string, for example `1m30s123ms` or `1h5m`.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Duration string, for example 1m30s123ms or 1h5m.", - "YAMLDefault": "0s", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Used to simulate a hang in the dataplane after the specified duration. This is useful in tests of the watchdog system only!", - "DescriptionHTML": "

    Used to simulate a hang in the dataplane after the specified duration. This is useful in tests of the watchdog system only!

    ", - "UserEditable": true, - "GoType": "*v1.Duration" - } - ] - }, - { - "Name": "Usage reporting", - "Fields": [ - { - "Group": "Usage reporting", - "GroupWithSortPrefix": "99 Usage reporting", - "NameConfigFile": "UsageReportingEnabled", - "NameEnvVar": "FELIX_UsageReportingEnabled", - "NameYAML": "usageReportingEnabled", - "NameGoAPI": "UsageReportingEnabled", - "StringSchema": "Boolean: `true`, `1`, `yes`, `y`, `t` accepted as True; `false`, `0`, `no`, `n`, `f` accepted (case insensitively) as False.", - "StringSchemaHTML": "Boolean: true, 1, yes, y, t accepted as True; false, 0, no, n, f accepted (case insensitively) as False.", - "StringDefault": "true", - "ParsedDefault": "true", - "ParsedDefaultJSON": "true", - "ParsedType": "bool", - "YAMLType": "boolean", - "YAMLSchema": "Boolean.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Boolean.", - "YAMLDefault": "true", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Reports anonymous Calico version number and cluster size to projectcalico.org. Logs warnings returned by the usage server. For example, if a significant security vulnerability has been discovered in the version of Calico being used.", - "DescriptionHTML": "

    Reports anonymous Calico version number and cluster size to projectcalico.org. Logs warnings returned by the usage server. For example, if a significant security vulnerability has been discovered in the version of Calico being used.

    ", - "UserEditable": true, - "GoType": "*bool" - }, - { - "Group": "Usage reporting", - "GroupWithSortPrefix": "99 Usage reporting", - "NameConfigFile": "UsageReportingInitialDelaySecs", - "NameEnvVar": "FELIX_UsageReportingInitialDelaySecs", - "NameYAML": "usageReportingInitialDelay", - "NameGoAPI": "UsageReportingInitialDelay", - "StringSchema": "Seconds (floating point)", - "StringSchemaHTML": "Seconds (floating point)", - "StringDefault": "300", - "ParsedDefault": "5m0s", - "ParsedDefaultJSON": "300000000000", - "ParsedType": "time.Duration", - "YAMLType": "string", - "YAMLSchema": "Duration string, for example `1m30s123ms` or `1h5m`.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Duration string, for example 1m30s123ms or 1h5m.", - "YAMLDefault": "5m0s", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Controls the minimum delay before Felix makes a report.", - "DescriptionHTML": "

    Controls the minimum delay before Felix makes a report.

    ", - "UserEditable": true, - "GoType": "*v1.Duration" - }, - { - "Group": "Usage reporting", - "GroupWithSortPrefix": "99 Usage reporting", - "NameConfigFile": "UsageReportingIntervalSecs", - "NameEnvVar": "FELIX_UsageReportingIntervalSecs", - "NameYAML": "usageReportingInterval", - "NameGoAPI": "UsageReportingInterval", - "StringSchema": "Seconds (floating point)", - "StringSchemaHTML": "Seconds (floating point)", - "StringDefault": "86400", - "ParsedDefault": "24h0m0s", - "ParsedDefaultJSON": "86400000000000", - "ParsedType": "time.Duration", - "YAMLType": "string", - "YAMLSchema": "Duration string, for example `1m30s123ms` or `1h5m`.", - "YAMLEnumValues": null, - "YAMLSchemaHTML": "Duration string, for example 1m30s123ms or 1h5m.", - "YAMLDefault": "24h0m0s", - "Required": false, - "OnParseFailure": "ReplaceWithDefault", - "AllowedConfigSources": "All", - "Description": "Controls the interval at which Felix makes reports.", - "DescriptionHTML": "

    Controls the interval at which Felix makes reports.

    ", - "UserEditable": true, - "GoType": "*v1.Duration" - } - ] - } - ] -} \ No newline at end of file diff --git a/calico_versioned_docs/version-3.29/_includes/components/FelixConfig/index.js b/calico_versioned_docs/version-3.29/_includes/components/FelixConfig/index.js deleted file mode 100644 index 2c2ca6e2c7..0000000000 --- a/calico_versioned_docs/version-3.29/_includes/components/FelixConfig/index.js +++ /dev/null @@ -1,108 +0,0 @@ -import React, { useState, useEffect } from 'react'; -import jsonData from './config-params.json'; -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; -import TableResource from './TableResource'; -import TableConfig from './TableConfig'; -import TableEnv from './TableEnv'; -import styles from './styles.module.css'; - -const FelixConfigTable = ({ configType, fieldData }) => { - let table; - - switch (configType) { - case 'yaml': - table = ; - break; - case 'config': - table = ; - break; - case 'env': - table = ; - break; - default: - table =

    Unknown config type

    ; - } - - return
    {table}
    ; -}; - -const FelixConfig = ({ configType, name }) => { - const matchedGroup = jsonData.Groups.find((group) => group.Name === name); - // Debugging logs - - if (!matchedGroup) { - // Fail the build loudly rather than silently dropping the group's fields. - // `name` must exactly match a group Name in config-params.json, which is - // auto-synced from the Felix source repos. A prose/casing sweep once - // restyled these lookup keys and silently dropped fields (DOCS-2970). - throw new Error( - `FelixConfig: no group named '${name}' in config-params.json. The 'name' ` - + `prop must exactly match a group Name in config-params.json; do not ` - + `restyle it as prose.` - ); - } - - let content; - - if (configType === 'yaml') { - content = ( -
    - {matchedGroup.Fields.map((field, index) => ( - field.NameYAML ? ( -
    -
    - {field.NameYAML} -
    - -
    - ) : null - ))} -
    - ); - } else if (configType === 'configenv') { - content = ( -
    - {matchedGroup.Fields.map((field, index) => ( -
    -

    {field.NameConfigFile}

    - - - - - - - - -
    - ))} -
    - ); - } else { - content = ( -
    -

    You got it wrong

    -
    - ); - } - return
    {content}
    ; -}; - -export default FelixConfig; diff --git a/calico_versioned_docs/version-3.29/_includes/components/FelixConfig/styles.module.css b/calico_versioned_docs/version-3.29/_includes/components/FelixConfig/styles.module.css deleted file mode 100644 index d831a8ed05..0000000000 --- a/calico_versioned_docs/version-3.29/_includes/components/FelixConfig/styles.module.css +++ /dev/null @@ -1,12 +0,0 @@ -.felixTable { - width: 100%; - display: table; -} - -.felixTable td p:last-child { - margin-bottom: 0; -} - -.tabsContainer { - margin-bottom: 60px; -} diff --git a/calico_versioned_docs/version-3.29/_includes/components/HostEndpointsUpgrade.js b/calico_versioned_docs/version-3.29/_includes/components/HostEndpointsUpgrade.js deleted file mode 100644 index 9917435247..0000000000 --- a/calico_versioned_docs/version-3.29/_includes/components/HostEndpointsUpgrade.js +++ /dev/null @@ -1,84 +0,0 @@ -import React from 'react'; -import Admonition from '@theme/Admonition'; -import CodeBlock from '@theme/CodeBlock'; -import Heading from '@theme/Heading'; - -import { prodname, version } from '../../variables'; - -export default function HostEndpointsUpgrade(props) { - return ( - <> - - Host endpoints - - - If your cluster has host endpoints with interfaceName: * you must prepare your cluster before - upgrading. Failure to do so will result in an outage. - -

    - In versions of {prodname} prior to v3.14, all-interfaces host endpoints (host endpoints with{' '} - interfaceName: *) only supported pre-DNAT policy. The default behavior of all-interfaces host - endpoints, in the absence of any policy, was to allow all traffic. -

    -

    - Beginning from v3.14, all-interfaces host endpoints support normal policy in addition to pre-DNAT policy. The - support for normal policy includes a change in default behavior for all-interfaces host endpoints: in the - absence of policy the default behavior is to drop traffic. This default behavior is consistent - with "named" host endpoints (which specify a named interface such as "eth0"); named host - endpoints drop traffic in the absence of policy. -

    -

    - Before upgrading to {version}, you must ensure that global network policies are in place that select existing - all-interfaces host endpoints and explicitly allow existing traffic flows. As a starting point, you can create - an allow-all policy that selects existing all-interfaces host endpoints. First, we'll add a label to the - existing host endpoints. Get a list of the nodes that have an all-interfaces host endpoint: -

    - calicoctl get hep -owide | grep | awk '"{'print $1'}"' -

    - With the names of the all-interfaces host endpoints, we can label each host endpoint with a new label (for - example, host-endpoint-upgrade: ""): -

    - - calicoctl get hep -owide | grep '*' | awk '"{'print $1'}"' \ -
    - {props.orch === 'OpenShift' - ? '| xargs -I {} oc exec -i -n kube-system calicoctl -- calicoctl label hostendpoint {} host-endpoint-upgrade=' - : '| xargs -I {} kubectl exec -i -n kube-system calicoctl -- calicoctl label hostendpoint {} host-endpoint-upgrade= '} -     -

    - Now that the nodes with an all-interfaces host endpoint are labeled with host-endpoint-upgrade, - we can create a policy to log and allow all traffic going into or out of the host endpoints temporarily: -

    - - {`cat > allow-all-upgrade.yaml < -

    Apply the policy:

    - calicoctl apply -f - {'<'} allow-all-upgrade.yaml -

    - After applying this policy, all-interfaces host endpoints will log and allow all traffic through them. This - policy will allow all traffic not accounted for by other policies. After upgrading, please review syslog logs - for traffic going through the host endpoints and update the policy as needed to secure traffic to the host - endpoints. -

    - - ); -} diff --git a/calico_versioned_docs/version-3.29/_includes/components/InstallOpenShiftManifests.js b/calico_versioned_docs/version-3.29/_includes/components/InstallOpenShiftManifests.js deleted file mode 100644 index 9a34a4307f..0000000000 --- a/calico_versioned_docs/version-3.29/_includes/components/InstallOpenShiftManifests.js +++ /dev/null @@ -1,18 +0,0 @@ -import React from 'react'; - -import CodeBlock from '@theme/CodeBlock'; - -import { prodname, releaseTitle, calicoReleasesURL } from '../../variables'; - -export default function InstallOpenShiftManifests() { - return ( - <> -

    Download the {prodname} manifests for OpenShift and add them to the generated manifests directory:

    - - {`mkdir calico -wget -qO- ${calicoReleasesURL}/${releaseTitle}/ocp.tgz | tar xvz --strip-components=1 -C calico -cp calico/* manifests/`} - - - ); -} diff --git a/calico_versioned_docs/version-3.29/_includes/components/MaintenanceImageOptionsAlternateRegistry.js b/calico_versioned_docs/version-3.29/_includes/components/MaintenanceImageOptionsAlternateRegistry.js deleted file mode 100644 index 498b90bc4f..0000000000 --- a/calico_versioned_docs/version-3.29/_includes/components/MaintenanceImageOptionsAlternateRegistry.js +++ /dev/null @@ -1,87 +0,0 @@ -// Temporary component for "calico\maintenance\image-options\alternate-registry.mdx" - -import React from 'react'; - -import CodeBlock from '@theme/CodeBlock'; - -import { imageNames, prodname, registry, releases, tigeraOperator } from '../../variables'; - -export default function MaintenanceImageOptionsAlternateRegistry() { - const pullCmds = renderRetagCommands( - (componentData, reg, componentNames, i) => `docker pull ${reg}${componentNames[i]}:${componentData.version}`, - (c) => imageNames[c] && !c.includes('flannel') && !c.includes('-windows') - ); - - const tagCmds = renderRetagCommands( - (componentData, reg, componentNames, i) => - `docker tag ${reg}${componentNames[i]}:${componentData.version} $REGISTRY/${componentNames[i]}:${componentData.version}`, - (c) => imageNames[c] && !c.includes('flannel') && !c.includes('-windows') - ); - - const pushCmds = renderRetagCommands( - (componentData, reg, componentNames, i) => `docker push $REGISTRY/${componentNames[i]}:${componentData.version}`, - (c) => imageNames[c] && !c.includes('flannel') && !c.includes('-windows') - ); - - const craneCmds = renderRetagCommands( - (componentData, reg, componentNames, i) => `crane cp ${reg}${componentNames[i]}:${componentData.version} $REGISTRY/${componentNames[i]}:${componentData.version}`, - (c) => imageNames[c] && c.includes('-windows') - ); - - return ( -
      -
    1. -

      Use the following commands to pull the required {prodname} images.

      -
      2. - - docker pull {tigeraOperator.registry}/{tigeraOperator.image}:{tigeraOperator.version} - {'\n'} - {pullCmds} - -
    2. -

      - Retag the images with the name of your registry $REGISTRY. -

      -
      3. - - docker tag {tigeraOperator.registry}/{tigeraOperator.image}:{tigeraOperator.version} $REGISTRY/ - {tigeraOperator.image}:{tigeraOperator.version} - {'\n'} - {tagCmds} - -
    3. -

      Push the images to your registry.

      -
      4. - - docker push $REGISTRY/{tigeraOperator.image}:{tigeraOperator.version} - {'\n'} - {pushCmds} - -
    4. -

      Use crane cp to copy the Windows images to your private registry.

      -
      5. -

      For hybrid Linux + Windows clusters, use crane cp on the following Windows images to copy them to your private registry.

      - - {craneCmds} - -
    - ); -} - -function renderRetagCommands(renderCommand, filterFunc) { - const releaseComponents = releases[0].components; - const components = Object.keys(releaseComponents); - const filteredComponents = components.filter(filterFunc); - const componentNames = filteredComponents.map((c) => imageNames[c]); - - const result = filteredComponents - .map((c, i) => { - const componentData = releaseComponents[c]; - const reg = componentData.registry ? `${componentData.registry}/` : registry; - - return renderCommand(componentData, reg, componentNames, i); - }) - .join('\n'); - - return result; -} diff --git a/calico_versioned_docs/version-3.29/_includes/content/_calicoctl-version.mdx b/calico_versioned_docs/version-3.29/_includes/content/_calicoctl-version.mdx deleted file mode 100644 index 5ae136c92d..0000000000 --- a/calico_versioned_docs/version-3.29/_includes/content/_calicoctl-version.mdx +++ /dev/null @@ -1,7 +0,0 @@ -| Field | Value | -| ------------------- | ------------------------------------------------------ | -| `Client Version` | Version of `calicoctl` | -| `Build date` | Time and date of `calicoctl` build | -| `Git commit` | Git commit number of `calicoctl` | -| `Cluster Version`\* | Version number of `$[nodecontainer]` and $[prodname] | -| `Cluster Type`\* | Other details about the cluster | diff --git a/calico_versioned_docs/version-3.29/_includes/content/_determine-ipam.mdx b/calico_versioned_docs/version-3.29/_includes/content/_determine-ipam.mdx deleted file mode 100644 index 5ca7d51a6c..0000000000 --- a/calico_versioned_docs/version-3.29/_includes/content/_determine-ipam.mdx +++ /dev/null @@ -1,37 +0,0 @@ -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - -If you are not sure which IPAM your cluster is using, the way to tell depends on install method. - - - - -The IPAM plugin can be queried on the default Installation resource. - -```bash -kubectl get installation default -o go-template --template {{.spec.cni.ipam.type}} -``` - -If your cluster is using Calico IPAM, the above command should return a result of `Calico`. - - - - -SSH to one of your Kubernetes nodes and examine the CNI configuration. - -```bash -cat /etc/cni/net.d/10-calico.conflist -``` - -Look for the entry: - -``` - "ipam": { - "type": "calico-ipam" - }, -``` - -If it is present, you are using the $[prodname] IPAM. If the IPAM is not $[prodname], or the 10-calico.conflist file does not exist, you cannot use these features in your cluster. - - - diff --git a/calico_versioned_docs/version-3.29/_includes/content/_docker-container-service.mdx b/calico_versioned_docs/version-3.29/_includes/content/_docker-container-service.mdx deleted file mode 100644 index deb3f80a44..0000000000 --- a/calico_versioned_docs/version-3.29/_includes/content/_docker-container-service.mdx +++ /dev/null @@ -1,82 +0,0 @@ -import EnvironmentFile from '@site/calico_versioned_docs/version-3.29/_includes/components/EnvironmentFile'; - -This section describes how to run `$[nodecontainer]` as a Docker container. - -:::note - -We include examples for systemd, but the commands can be -applied to other init daemons such as upstart. - -::: - -### Step 1: Create environment file - - - -### Step 2: Configure the init system - -Use an init daemon (like systemd or upstart) to start the $[nodecontainer] image as a service using the EnvironmentFile values. - -Sample systemd service file: `$[noderunning].service` - -```shell -[Unit] -Description=$[noderunning] -After=docker.service -Requires=docker.service - -[Service] -EnvironmentFile=/etc/calico/calico.env -ExecStartPre=-/usr/bin/docker rm -f $[noderunning] -ExecStart=/usr/bin/docker run --net=host --privileged \ - --name=$[noderunning] \ - -e NODENAME=${CALICO_NODENAME} \ - -e IP=${CALICO_IP} \ - -e IP6=${CALICO_IP6} \ - -e CALICO_NETWORKING_BACKEND=${CALICO_NETWORKING_BACKEND} \ - -e AS=${CALICO_AS} \ - -e NO_DEFAULT_POOLS=${NO_DEFAULT_POOLS} \ - -e DATASTORE_TYPE=${DATASTORE_TYPE} \ - -e ETCD_ENDPOINTS=${ETCD_ENDPOINTS} \ - -e ETCD_CA_CERT_FILE=${ETCD_CA_CERT_FILE} \ - -e ETCD_CERT_FILE=${ETCD_CERT_FILE} \ - -e ETCD_KEY_FILE=${ETCD_KEY_FILE} \ - -e KUBECONFIG=${KUBECONFIG} \ - -v /var/log/calico:/var/log/calico \ - -v /var/lib/calico:/var/lib/calico \ - -v /var/run/calico:/var/run/calico \ - -v /run/docker/plugins:/run/docker/plugins \ - -v /lib/modules:/lib/modules \ - -v /etc/pki:/pki \ - $[registry]$[imageNames.calico/node]:$[releaseTitle] /bin/calico-node -felix - -ExecStop=-/usr/bin/docker stop $[noderunning] - -Restart=on-failure -StartLimitBurst=3 -StartLimitInterval=60s - -[Install] -WantedBy=multi-user.target -``` - -Upon start, the systemd service: - -- Confirms Docker is installed under the `[Unit]` section -- Gets environment variables from the environment file above -- Removes existing `$[nodecontainer]` container (if it exists) -- Starts `$[nodecontainer]` - -The script also stops the `$[nodecontainer]` container when the service is stopped. - -:::note - -Depending on how you've installed Docker, the name of the Docker service -under the `[Unit]` section may be different (such as `docker-engine.service`). -Be sure to check this before starting the service. - -::: diff --git a/calico_versioned_docs/version-3.29/_includes/content/_ebpf-value.mdx b/calico_versioned_docs/version-3.29/_includes/content/_ebpf-value.mdx deleted file mode 100644 index fe2072d88f..0000000000 --- a/calico_versioned_docs/version-3.29/_includes/content/_ebpf-value.mdx +++ /dev/null @@ -1,12 +0,0 @@ -The eBPF data plane mode has several advantages over standard Linux networking pipeline mode: - -- It scales to higher throughput. -- It uses less CPU per GBit. -- It has native support for Kubernetes services (without needing kube-proxy) that: - - - Reduces first packet latency for packets to services. - - Preserves external client source IP addresses all the way to the pod. - - Supports DSR (Direct Server Return) for more efficient service routing. - - Uses less CPU than kube-proxy to keep the data plane in sync. - -To learn more and see performance metrics from our test environment, see the blog, [Introducing the Calico eBPF data plane](https://www.projectcalico.org/introducing-the-calico-ebpf-dataplane/). diff --git a/calico_versioned_docs/version-3.29/_includes/content/_endpointport.mdx b/calico_versioned_docs/version-3.29/_includes/content/_endpointport.mdx deleted file mode 100644 index 05dde33612..0000000000 --- a/calico_versioned_docs/version-3.29/_includes/content/_endpointport.mdx +++ /dev/null @@ -1,15 +0,0 @@ -An EndpointPort associates a name with a particular TCP/UDP/SCTP port of the endpoint, allowing it to -be referenced as a named port in [policy rules](../../reference/resources/networkpolicy.mdx#entityrule). - -| Field | Description | Accepted Values | Schema | Default | -| -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------- | ------ | ------- | -| name | The name to attach to this port, allowing it to be referred to in [policy rules](../../reference/resources/networkpolicy.mdx#entityrule). Names must be unique within an endpoint. | | string | | -| protocol | The protocol of this named port. | `TCP`, `UDP`, `SCTP` | string | | -| port | The workload port number. | `1`-`65535` | int | | - -:::note - -On their own, EndpointPort entries don't result in any change to the connectivity of the port. -They only have an effect if they are referred to in policy. - -::: diff --git a/calico_versioned_docs/version-3.29/_includes/content/_entityrule.mdx b/calico_versioned_docs/version-3.29/_includes/content/_entityrule.mdx deleted file mode 100644 index a7272d94a2..0000000000 --- a/calico_versioned_docs/version-3.29/_includes/content/_entityrule.mdx +++ /dev/null @@ -1,68 +0,0 @@ -Entity rules specify the attributes of the source or destination of a packet that must match for the rule as a whole -to match. Packets can be matched on combinations of: - -- Identity of the source/destination, by using [Selectors](#selectors) or by specifying a particular - Kubernetes `Service`. Selectors can match [workload endpoints](../../reference/resources/workloadendpoint.mdx), - [host endpoints](../../reference/resources/hostendpoint.mdx) and ([namespaced](../../reference/resources/networkset.mdx) or - [global](../../reference/resources/globalnetworkset.mdx)) network sets. -- Source/destination IP address, protocol and port. - -If the rule contains multiple match criteria (for example, an IP and a port) then all match criteria must match -for the rule as a whole to match a packet. - -| Field | Description | Accepted Values | Schema | Default | -| ----------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | ------------------------------------------- | ------- | -| nets | Match packets with IP in any of the listed CIDRs. | List of valid IPv4 CIDRs or list of valid IPv6 CIDRs (IPv4 and IPv6 CIDRs shouldn't be mixed in one rule) | list of cidrs | -| notNets | Negative match on CIDRs. Match packets with IP not in any of the listed CIDRs. | List of valid IPv4 CIDRs or list of valid IPv6 CIDRs (IPv4 and IPv6 CIDRs shouldn't be mixed in one rule) | list of cidrs | -| selector | Positive match on selected endpoints. If a `namespaceSelector` is also defined, the set of endpoints this applies to is limited to the endpoints in the selected namespaces. | Valid selector | [selector](#selectors) | | -| notSelector | Negative match on selected endpoints. If a `namespaceSelector` is also defined, the set of endpoints this applies to is limited to the endpoints in the selected namespaces. | Valid selector | [selector](#selectors) | | -| namespaceSelector | Positive match on selected namespaces. If specified, only workload endpoints in the selected Kubernetes namespaces are matched. Matches namespaces based on the labels that have been applied to the namespaces. Defines the scope that selectors will apply to, if not defined then selectors apply to the NetworkPolicy's namespace. Match a specific namespace by name using the `projectcalico.org/name` label. Select the non-namespaced resources like GlobalNetworkSet(s), host endpoints to which this policy applies by using `global()` selector. | Valid selector | [selector](#selectors) | | -| ports | Positive match on the specified ports | | list of [ports](#ports) | | -| notPorts | Negative match on the specified ports | | list of [ports](#ports) | | -| serviceAccounts | Match endpoints running under service accounts. If a `namespaceSelector` is also defined, the set of service accounts this applies to is limited to the service accounts in the selected namespaces. | | [ServiceAccountMatch](#serviceaccountmatch) | | -| services | _Only supported when using the Kubernetes datastore driver, ignored by the etcd datastore driver_. Match the specified service(s). If specified on egress rule destinations, no other selection criteria can be set. If specified on ingress rule sources, only positive or negative matches on ports can be specified. | | [ServiceMatch](#servicematch) | | - -When using selectors in network policy, remember that selectors only match (known) resources, but _rules_ match -packets. A rule with a selector `all()` won't match "all packets", it will match "packets from all in-scope -endpoints and network sets". To match all packets, do not include a selector in the rule at all. - -#### Understanding `notSelector` - -`notSelector` is somewhat subtle because the `not` in `notSelector` negates the packet match -rather than the selector: - -- `selector: !has(foo)` matches packets from/to endpoints and network sets that do not have the label "foo". -- `notSelector: has(foo)` matches packets from/to **anywhere** (including outside the cluster), **except** traffic from/to endpoints and network sets that have the label "foo". - -#### Selector performance in EntityRules - -When rendering policy into the data plane, $[prodname] must identify the endpoints that match the selectors -in all active rules. This calculation is optimized for certain common selector types. -Using the optimized selector types reduces CPU usage (and policy rendering time) by orders of magnitude. -This becomes important at high scale (hundreds of active rules, hundreds of thousands of endpoints). - -The optimized operators are as follows: - -- `label == "value"` -- `label in { 'v1', 'v2' }` -- `has(label)` -- ` && ` is optimized if **either** `` or `` is - optimized. - -The following perform like `has(label)`. All endpoints with the label will be scanned to find matches: - -- `label contains 's'` -- `label starts with 's'` -- `label ends with 's'` - -The other operators, and in particular, `all()`, `!`, `||` and `!=` are not optimized. - -Examples: - -- `a == 'b'` - optimized -- `a == 'b' && has(c)` - optimized -- `a == 'b' || has(c)` - **not** optimized due to use of `||` -- `c != 'd'` - **not** optimized due to use of `!=` -- `!has(a)` - **not** optimized due to use of `!` -- `a == 'b' && c != 'd'` - optimized, `a =='b'` is optimized so `a == 'b' && ` is optimized. -- `c != 'd' && a == 'b'` - optimized, `a =='b'` is optimized so ` && a == 'b'` is optimized. diff --git a/calico_versioned_docs/version-3.29/_includes/content/_felix-init-datastore.mdx b/calico_versioned_docs/version-3.29/_includes/content/_felix-init-datastore.mdx deleted file mode 100644 index 3fecfc53cb..0000000000 --- a/calico_versioned_docs/version-3.29/_includes/content/_felix-init-datastore.mdx +++ /dev/null @@ -1,19 +0,0 @@ -You should configure a `node` resource for each -host running Felix. In this case, the database is initialized after -creating the first `node` resource. For a deployment that does not include -the $[prodname]/BGP integration, the specification of a node resource just -requires the name of the node; for most deployments this will be the same as the -hostname. - -```bash -calicoctl create -f - < -EOF -``` - -The Felix logs should transition from periodic notifications -that Felix is in the state `wait-for-ready` to a stream of initialization -messages. diff --git a/calico_versioned_docs/version-3.29/_includes/content/_httpmatch.mdx b/calico_versioned_docs/version-3.29/_includes/content/_httpmatch.mdx deleted file mode 100644 index 613bb97c3d..0000000000 --- a/calico_versioned_docs/version-3.29/_includes/content/_httpmatch.mdx +++ /dev/null @@ -1,23 +0,0 @@ -An HTTPMatch matches attributes of an HTTP request. The presence of an HTTPMatch clause on a Rule will cause that rule to only match HTTP traffic. Other application layer protocols will not match the rule. - -Example: - -```yaml -http: - methods: ['GET', 'PUT'] - paths: - - exact: '/projects/calico' - - prefix: '/users' -``` - -| Field | Description | Schema | -| ------- | -------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------- | -| methods | Match HTTP methods. Case sensitive. [Standard HTTP method descriptions.](https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html) | list of strings | -| paths | Match HTTP paths. Case sensitive. | list of [HTTPPathMatch](#httppathmatch) | - -### HTTPPathMatch - -| Syntax | Example | Description | -| ------ | ------------------- | ------------------------------------------------------------------------------- | -| exact | `exact: "/foo/bar"` | Matches the exact path as written, not including the query string or fragments. | -| prefix | `prefix: "/keys"` | Matches any path that begins with the given prefix. | diff --git a/calico_versioned_docs/version-3.29/_includes/content/_icmp.mdx b/calico_versioned_docs/version-3.29/_includes/content/_icmp.mdx deleted file mode 100644 index 1adb456472..0000000000 --- a/calico_versioned_docs/version-3.29/_includes/content/_icmp.mdx +++ /dev/null @@ -1,4 +0,0 @@ -| Field | Description | Accepted Values | Schema | Default | -| ----- | ------------------- | -------------------- | ------- | ------- | -| type | Match on ICMP type. | Can be integer 0-254 | integer | -| code | Match on ICMP code. | Can be integer 0-255 | integer | diff --git a/calico_versioned_docs/version-3.29/_includes/content/_ipnat.mdx b/calico_versioned_docs/version-3.29/_includes/content/_ipnat.mdx deleted file mode 100644 index 9cfa2fb904..0000000000 --- a/calico_versioned_docs/version-3.29/_includes/content/_ipnat.mdx +++ /dev/null @@ -1,6 +0,0 @@ -IPNAT contains a single NAT mapping for a WorkloadEndpoint resource. - -| Field | Description | Accepted Values | Schema | Default | -| ---------- | ------------------------------------------- | ------------------ | ------ | ------- | -| internalIP | The internal IP address of the NAT mapping. | A valid IP address | string | | -| externalIP | The external IP address. | A valid IP address | string | | diff --git a/calico_versioned_docs/version-3.29/_includes/content/_openstack-etcd-auth.mdx b/calico_versioned_docs/version-3.29/_includes/content/_openstack-etcd-auth.mdx deleted file mode 100644 index 2af5c79262..0000000000 --- a/calico_versioned_docs/version-3.29/_includes/content/_openstack-etcd-auth.mdx +++ /dev/null @@ -1,16 +0,0 @@ -## Configuration for etcd authentication - -If your etcd cluster has authentication enabled, you must also configure the -relevant $[prodname] components with an etcd user name and password. You -can create a single etcd user for $[prodname] that has permission to read -and write any key beginning with `/calico/`, or you can create specific etcd -users for each component, with more precise permissions. - -This table sets out where to configure each component of $[prodname] for -OpenStack, and the detailed access permissions that each component needs: - -| Component | Configuration | Access | -| -------------- | -------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -| Felix | `CALICO_ETCD_USERNAME` and `CALICO_ETCD_PASSWORD` variables in Felix's environment on each compute node. | [See here](../../reference/etcd-rbac/calico-etcdv3-paths.mdx#felix-as-a-stand-alone-process) | -| Neutron driver | `etcd_username` and `etcd_password` in `[calico]` section of `/etc/neutron/neutron.conf` on each control node. | [See here](../../reference/etcd-rbac/calico-etcdv3-paths.mdx#openstack-calico-driver-for-neutron) | -| DHCP agent | `etcd_username` and `etcd_password` in `[calico]` section of `/etc/neutron/neutron.conf` on each compute node. | [See here](../../reference/etcd-rbac/calico-etcdv3-paths.mdx#openstack-calico-dhcp-agent) | diff --git a/calico_versioned_docs/version-3.29/_includes/content/_ports.mdx b/calico_versioned_docs/version-3.29/_includes/content/_ports.mdx deleted file mode 100644 index 4517f59290..0000000000 --- a/calico_versioned_docs/version-3.29/_includes/content/_ports.mdx +++ /dev/null @@ -1,33 +0,0 @@ -$[prodname] supports the following syntaxes for expressing ports. - -| Syntax | Example | Description | -| --------- | ---------- | ------------------------------------------------------------------- | -| int | 80 | The exact (numeric) port specified | -| start:end | 6040:6050 | All (numeric) ports within the range start ≤ x ≤ end | -| string | named-port | A named port, as defined in the ports list of one or more endpoints | - -An individual numeric port may be specified as a YAML/JSON integer. A port range or -named port must be represented as a string. For example, this would be a valid list of ports: - -```yaml -ports: [8080, '1234:5678', 'named-port'] -``` - -#### Named ports - -Using a named port in an `EntityRule`, instead of a numeric port, gives a layer of indirection, -allowing for the named port to map to different numeric values for each endpoint. - -For example, suppose you have multiple HTTP servers running as workloads; some exposing their HTTP -port on port 80 and others on port 8080. In each workload, you could create a named port called -`http-port` that maps to the correct local port. Then, in a rule, you could refer to the name -`http-port` instead of writing a different rule for each type of server. - -:::note - -Since each named port may refer to many endpoints (and $[prodname] has to expand a named port into -a set of endpoint/port combinations), using a named port is considerably more expensive in terms -of CPU than using a simple numeric port. We recommend that they are used sparingly, only where -the extra indirection is required. - -::: diff --git a/calico_versioned_docs/version-3.29/_includes/content/_rule.mdx b/calico_versioned_docs/version-3.29/_includes/content/_rule.mdx deleted file mode 100644 index 54a04d392e..0000000000 --- a/calico_versioned_docs/version-3.29/_includes/content/_rule.mdx +++ /dev/null @@ -1,46 +0,0 @@ -A single rule matches a set of packets and applies some action to them. When multiple rules are specified, they -are executed in order. - -| Field | Description | Accepted Values | Schema | Default | -| ----------- | ------------------------------------------------------------------------------------------ | ------------------------------------------------------------ | ----------------------------- | ------- | -| metadata | Per-rule metadata. | | [RuleMetadata](#rulemetadata) | | -| action | Action to perform when matching this rule. | `Allow`, `Deny`, `Log`, `Pass` | string | | -| protocol | Positive protocol match. | `TCP`, `UDP`, `ICMP`, `ICMPv6`, `SCTP`, `UDPLite`, `1`-`255` | string \| integer | | -| notProtocol | Negative protocol match. | `TCP`, `UDP`, `ICMP`, `ICMPv6`, `SCTP`, `UDPLite`, `1`-`255` | string \| integer | | -| icmp | ICMP match criteria. | | [ICMP](#icmp) | | -| notICMP | Negative match on ICMP. | | [ICMP](#icmp) | | -| ipVersion | Positive IP version match. | `4`, `6` | integer | | -| source | Source match parameters. | | [EntityRule](#entityrule) | | -| destination | Destination match parameters. | | [EntityRule](#entityrule) | | -| http | Match HTTP request parameters. Application layer policy must be enabled to use this field. | | [HTTPMatch](#httpmatch) | | - -After a `Log` action, processing continues with the next rule; `Allow` and `Deny` are immediate -and final and no further rules are processed. - -An `action` of `Pass` in a `NetworkPolicy` or `GlobalNetworkPolicy` will skip over the remaining policies and jump to the -first [profile](../../reference/resources/profile.mdx) assigned to the endpoint, applying the policy configured in the -profile; if there are no Profiles configured for the endpoint the default applied action is `Deny`. - -### RuleMetadata - -Metadata associated with a specific rule (rather than the policy as a whole). The contents of the metadata does not affect how a rule is interpreted or enforced; it is -simply a way to store additional information for use by operators or applications that interact with $[prodname]. - -| Field | Description | Schema | Default | -| ----------- | ----------------------------------- | ----------------------- | ------- | -| annotations | Arbitrary non-identifying metadata. | map of string to string | | - -Example: - -```yaml -metadata: - annotations: - app: database - owner: devops -``` - -Annotations follow the -[same rules as Kubernetes for valid syntax and character set](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/#syntax-and-character-set). - -On Linux with the iptables data plane, rule annotations are rendered as comments in the form `-m comment --comment "="` on the iptables rule(s) that correspond -to the $[prodname] rule. diff --git a/calico_versioned_docs/version-3.29/_includes/content/_selector-scopes.mdx b/calico_versioned_docs/version-3.29/_includes/content/_selector-scopes.mdx deleted file mode 100644 index 9d9fbc8c54..0000000000 --- a/calico_versioned_docs/version-3.29/_includes/content/_selector-scopes.mdx +++ /dev/null @@ -1,20 +0,0 @@ -Understanding scopes and the `all()` and `global()` operators: selectors have a scope of resources -that they are matched against, which depends on the context in which they are used. For example: - -- The `nodeSelector` in an `IPPool` selects over `Node` resources. - -- The top-level selector in a `NetworkPolicy` selects over the workloads _in the same namespace_ as the - `NetworkPolicy`. -- The top-level selector in a `GlobalNetworkPolicy` doesn't have the same restriction, it selects over all endpoints - including namespaced `WorkloadEndpoint`s and non-namespaced `HostEndpoint`s. - -- The `namespaceSelector` in a `NetworkPolicy` (or `GlobalNetworkPolicy`) _rule_ selects over the labels on namespaces - rather than workloads. - -- The `namespaceSelector` determines the scope of the accompanying `selector` in the entity rule. If no `namespaceSelector` - is present then the rule's `selector` matches the default scope for that type of policy. (This is the same namespace - for `NetworkPolicy` and all endpoints/network sets for `GlobalNetworkPolicy`) -- The `global()` operator can be used (only) in a `namespaceSelector` to change the scope of the main `selector` to - include non-namespaced resources such as [GlobalNetworkSet](../../reference/resources/globalnetworkset.mdx). - This allows namespaced `NetworkPolicy` resources to refer to global non-namespaced resources, which would otherwise - be impossible. diff --git a/calico_versioned_docs/version-3.29/_includes/content/_selectors.mdx b/calico_versioned_docs/version-3.29/_includes/content/_selectors.mdx deleted file mode 100644 index 52baf960ae..0000000000 --- a/calico_versioned_docs/version-3.29/_includes/content/_selectors.mdx +++ /dev/null @@ -1,50 +0,0 @@ -A label selector is an expression which either matches or does not match a resource based on its labels. - -$[prodname] label selectors support a number of operators, which can be combined into larger expressions -using the boolean operators and parentheses. - -| Expression | Meaning | -| ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| **Logical operators** | -| `( )` | Matches if and only if `` matches. (Parentheses are used for grouping expressions.) | -| `! ` | Matches if and only if `` does not match. **Tip:** `!` is a special character at the start of a YAML string, if you need to use `!` at the start of a YAML string, enclose the string in quotes. | -| ` && ` | "And": matches if and only if both ``, and, `` matches | -| \ || \ | "Or": matches if and only if either ``, or, `` matches. | -| **Match operators** | -| `all()` | Match all in-scope resources. To match _no_ resources, combine this operator with `!` to form `!all()`. | -| `global()` | Match all non-namespaced resources. Useful in a `namespaceSelector` to select global resources such as global network sets. | -| `k == 'v'` | Matches resources with the label 'k' and value 'v'. | -| `k != 'v'` | Matches resources without label 'k' or with label 'k' and value _not_ equal to `v` | -| `has(k)` | Matches resources with label 'k', independent of value. To match pods that do not have label `k`, combine this operator with `!` to form `!has(k)` | -| `k in { 'v1', 'v2' }` | Matches resources with label 'k' and value in the given set | -| `k not in { 'v1', 'v2' }` | Matches resources without label 'k' or with label 'k' and value _not_ in the given set | -| `k contains 's'` | Matches resources with label 'k' and value containing the substring 's' | -| `k starts with 's'` | Matches resources with label 'k' and value starting with the substring 's' | -| `k ends with 's'` | Matches resources with label 'k' and value ending with the substring 's' | - -Operators have the following precedence: - -- **Highest**: all the match operators -- Parentheses `( ... )` -- Negation with `!` -- Conjunction with `&&` -- **Lowest**: Disjunction with `||` - -For example, the expression - -``` -! has(my-label) || my-label starts with 'prod' && role in {'frontend','business'} -``` - -Would be "bracketed" like this: - -``` -((!(has(my-label)) || ((my-label starts with 'prod') && (role in {'frontend','business'})) -``` - -It would match: - -- Any resource that did not have label "my-label". -- Any resource that both: - - Has a value for `my-label` that starts with "prod", and, - - Has a role label with value either "frontend", or "business". diff --git a/calico_versioned_docs/version-3.29/_includes/content/_serviceaccountmatch.mdx b/calico_versioned_docs/version-3.29/_includes/content/_serviceaccountmatch.mdx deleted file mode 100644 index 66cd92ee7c..0000000000 --- a/calico_versioned_docs/version-3.29/_includes/content/_serviceaccountmatch.mdx +++ /dev/null @@ -1,6 +0,0 @@ -A ServiceAccountMatch matches service accounts in an EntityRule. - -| Field | Description | Schema | -| -------- | ------------------------------- | ---------------------- | -| names | Match service accounts by name | list of strings | -| selector | Match service accounts by label | [selector](#selectors) | diff --git a/calico_versioned_docs/version-3.29/_includes/content/_servicematch.mdx b/calico_versioned_docs/version-3.29/_includes/content/_servicematch.mdx deleted file mode 100644 index 1fbfb8c7e8..0000000000 --- a/calico_versioned_docs/version-3.29/_includes/content/_servicematch.mdx +++ /dev/null @@ -1,9 +0,0 @@ -A ServiceMatch matches a service in an EntityRule. - -| Field | Description | Schema | -| --------- | ------------------------ | ------ | -| name | The service's name. | string | -| namespace | The service's namespace. | string | - -Service matches are only supported when using the Kubernetes datastore driver. -They are not supported by the etcd datastore driver. diff --git a/calico_versioned_docs/version-3.29/_includes/partials/_system-requirements.mdx b/calico_versioned_docs/version-3.29/_includes/partials/_system-requirements.mdx deleted file mode 100644 index 2efd0a1763..0000000000 --- a/calico_versioned_docs/version-3.29/_includes/partials/_system-requirements.mdx +++ /dev/null @@ -1,259 +0,0 @@ -import If from '@site/src/___new___/components/If'; -import Link from '@docusaurus/Link'; - -## Node requirements - -* x86-64, arm64, ppc64le, or s390x processor - - -* Calico must be able to manage `cali*` interfaces on the host. - When IPIP is enabled (the default), Calico also needs to be able to manage `tunl*` interfaces. - When VXLAN is enabled, Calico also needs to be able to manage the `vxlan.calico` interface. - - -* Calico must be able to manage `tap*` interfaces on the host. - - -* Linux kernel 5.10 or later with [required dependencies](#kernel-dependencies). - The following distributions have the required kernel, its dependencies, and are known to work well with $[prodname]. - - * Ubuntu 20.04 or later - * RHEL 8 or later - * Debian 10 or later - * BottleRocket 1.47 or later - * Talos 1.6 or later - - - * RHEL 8 or later - - - * Ubuntu 20.04 or later - * RHEL 8 or later - * Debian 10 or later - * BottleRocket 1.47 or later - * Talos 1.6 or later - - - * Ubuntu 20.04 or later - * RHEL 8 or later - - -:::note - -Many Linux distributions, such as most of the above, include NetworkManager. -By default, NetworkManager does not allow Calico to manage interfaces. -If your nodes have NetworkManager, complete the steps in [Preventing NetworkManager from controlling Calico interfaces](../../operations/troubleshoot/troubleshooting.mdx#configure-networkmanager) before installing Calico. - -::: - -* If your Linux distribution comes with installed Firewalld or another iptables manager it should be disabled. - These may interfere with rules added by Calico and result in unexpected behavior. - -:::note - -If a host firewall is needed, it can be configured by Calico HostEndpoint and GlobalNetworkPolicy. -More information about configuration at [Policy for hosts and VMs](../../network-policy/hosts/index.mdx). - -::: - -## Key/value store - -Calico requires a key/value store accessible by all Calico components. -On Kubernetes, you can configure Calico to access an etcdv3 cluster directly or to use the Kubernetes API datastore. -For production you will likely want multiple nodes for greater performance and reliability. If you don’t already have an etcdv3 cluster to connect to, please refer to the [upstream etcd docs](https://coreos.com/etcd/) for detailed advice and setup. -The key/value store must be etcdv3. -With OpenShift, the Kubernetes API datastore is used for the key/value store. -## Network requirements - -Ensure that your hosts and firewalls allow the necessary traffic based on your configuration. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ConfigurationHost(s)Connection typePort/protocol
    $[prodname] networking (BGP)AllBidirectionalTCP 179
    $[prodname] networking with IP-in-IP enabled (default)AllBidirectional - IP-in-IP, often represented by its protocol number 4 -
    $[prodname] networking with VXLAN enabledAllBidirectionalUDP 4789
    $[prodname] networking with Typha enabledTypha agent hostsIncomingTCP 5473 (default)
    $[prodname] networking with IPv4 WireGuard enabledAllBidirectionalUDP 51820 (default)
    $[prodname] networking with IPv6 WireGuard enabledAllBidirectionalUDP 51821 (default)
    flannel networking (VXLAN)AllBidirectionalUDP 4789
    Allkube-apiserver hostIncomingOften TCP 443 or 6443*
    etcd datastoreAlletcd hostsIncoming - - Officially - {' '} - TCP 2379 but can vary -
    - - -\* *The value passed to kube-apiserver using the `--secure-port` flag. -If you cannot locate this, check the `targetPort` value returned by `kubectl get svc kubernetes -o yaml`.* - - -\* *If your compute hosts connect directly and don’t use IP-in-IP, you don’t need to allow IP-in-IP traffic.* - -## Privileges - -Ensure that Calico has the `CAP_SYS_ADMIN` privilege. - -The simplest way to provide the necessary privilege is to run Calico as root or in a privileged container. - - -When installed as a Kubernetes daemon set, Calico meets this requirement by running as a privileged container. -This requires that the kubelet be allowed to run privileged containers. -There are two ways this can be achieved. - -* Specify `--allow-privileged` on the kubelet (deprecated). -* Use a [pod security policy](https://kubernetes.io/docs/concepts/policy/pod-security-policy/). - - - -## Kubernetes requirements - -#### Supported versions - -We test $[prodname] $[version] against the following Kubernetes versions. Other versions may work, but we are not actively testing them. - -- v1.29 -- v1.30 -- v1.31 -- v1.32 - -Due to changes in the Kubernetes API, $[prodname] $[version] will not work -on Kubernetes v1.20 or below. v1.21 may work, but is no longer tested. -Newer versions may also work, but we recommend upgrading to a version of $[prodname] -that is tested against the newer Kubernetes version. - -#### CNI plug-in enabled - -$[prodname] must be installed as a CNI plugin in the container runtime. - -This installation must use the Kubernetes default CNI configuration directory (`/etc/cni/net.d`) and binary directory (`/opt/cni/bin`). - -#### Other network providers - -Generally, you cannot use $[prodname] together with another network provider. - -Notable exceptions include the following: - -* [flannel](../../getting-started/kubernetes/flannel/index.mdx) -* Platform-specific CNIs, such as the [AWS VPC CNI](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/README.md) and [Azure VNet CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md) plugins. - -If you're working with a cluster that already uses another CNI, you cannot migrate to $[prodname]. - -#### Supported kube-proxy modes - -$[prodname] supports the following kube-proxy modes: - -- `iptables` (default) -- `ipvs`: Requires Kubernetes ≥ v1.9.3. Refer to [Use IPVS kube-proxy](../../networking/configuring/use-ipvs.mdx) for more details. -- `nftables`: Requires Kubernetes ≥ v1.31.0. Refer to [Calico nftables data plane](../../getting-started/kubernetes/nftables.mdx) for more details. - -#### IP pool configuration - -The IP range selected for pod IP addresses cannot overlap with any other -IP ranges in your network, including: - -- The Kubernetes service cluster IP range -- The range from which host IPs are allocated - - - -## OpenShift requirements - -$[prodname] supports the [OpenShift Container Platform](https://docs.openshift.com/). - - - -## OpenStack requirements - -The Calico Neutron driver is written in Python 3 and so requires an OpenStack release that runs with Python 3. -Subject to that, we aim to develop and maintain the Neutron driver for Calico so that its master code works with OpenStack master or any previous Python 3 release, on any operating system, independently of the deployment mechanism that is used to install it. - -However, we recommend using OpenStack Yoga or later, and our active support and testing of Calico $[version] with OpenStack is with Yoga. - - -## Kernel dependencies - -:::tip - -If you are using one of the recommended distributions, you will already satisfy these. - -::: - -Due to the large number of distributions and kernel version out there, it’s hard to be precise about the names of the particular kernel modules that are required to run Calico. -However, in general, you’ll need: - -* The `iptables` modules (both the “legacy” and “nft” variants are supported). These are typically broken up into many small modules, one for each type of match criteria and one for each type of action. Calico requires: - * The “base” modules (including the IPv6 versions if IPv6 is enabled in your cluster). - * At least the following match criteria: `set`, `rpfilter`, `addrtype`, `comment`, `conntrack`, `icmp`, `tcp`, `udp`, `ipvs`, `icmpv6` (if IPv6 is enabled in your kernel), `mark`, `multiport`, `rpfilter`, `sctp`, `ipvs` (if using `kube-proxy` in IPVS mode). - * At least the following actions: `REJECT`, `ACCEPT`, `DROP`, `LOG`. -* IP sets support. -* Netfilter Conntrack support compiled in (with SCTP support if using SCTP). -* IPVS support if using `kube-proxy` in IPVS mode. -* IPIP, VXLAN, WireGuard support, if using Calico networking in one of those modes. -* eBPF (including the `tc` hook support) and XDP (if you want to use the eBPF data plane). diff --git a/calico_versioned_docs/version-3.29/about/calico-product-editions.mdx b/calico_versioned_docs/version-3.29/about/calico-product-editions.mdx deleted file mode 100644 index df34863a2a..0000000000 --- a/calico_versioned_docs/version-3.29/about/calico-product-editions.mdx +++ /dev/null @@ -1,92 +0,0 @@ ---- -description: Describes Tigera products and provides a feature comparison table. ---- - -import { CheckIcon } from '@chakra-ui/icons'; - -# Tigera product comparison - -## Calico Open Source - -The base product that comprises both Calico Enterprise and Calico Cloud. It provides the core networking and network policy features. - -![Calico Open Source logo](/img/calico/calico-open-source.svg "Calico Open Source") - -## Calico Enterprise - -Includes the Calico Open Source core networking and network policy, but adds advanced features for networking, network policy, visibility and troubleshooting, threat defense, and compliance reports. - -![Calico Enterprise logo](/img/calico/calico-enterprise.svg "Calico Enterprise") - -## Calico Cloud - -The SaaS version of Calico Enterprise. It adds Image Assurance to scan and detect vulnerabilities in images, and container threat defense to detect malware. It also adds onboarding tutorials, and eliminates the cost to manage Elasticsearch logs and storage that comes with Calico Enterprise. - -![Calico Cloud logo](/img/calico/calico-cloud.svg "Calico Cloud") - -What is the best fit for you? It depends on your needs. The following table provides a high-level comparison. - -| Product | Cost and support | Best fit | -| ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Calico Open Source | Free, community-supported | **Users** who want best-in-class networking and network policy capabilities for Kubernetes without any costs. | -| Calico Enterprise | Paid subscription | **Enterprise teams** who need full control to customize their networking security deployment to meet regulatory and compliance requirements for Kubernetes at scale. Teams who want Tigera Customer Support for day-zero to production best practices, custom training and workshops, and Solution Architects to customize solutions. | -| Calico Cloud | Free trial with hands-on training from Customer Support, then pay-as-you-go with self-service training. Also offered as an annual subscription. | **Small teams** who need to manage the full spectrum of compliance in a web-based console for novice users:
    - Secure clusters, pods, and applications
    - Scan images for vulnerabilities
    - Web-based UI for visibility to troubleshoot Kubernetes
    - Detect and mitigate threats
    - Run compliance reports

    **Enterprise teams** who want to scale their Calico Enterprise on-premises deployments by providing more self-service to developers. | - -## Product comparison by feature - -| | Calico Open Source | Calico Cloud | Calico Enterprise | -| --------------------------------------------------------------------------- | ------------------------ | ------------------------ | ------------------------ | -| **Networking** | | | | -| High-performance, scalable pod networking |
    |
    |
    | -| Advanced IP address management |
    |
    |
    | -| Direct infrastructure peering without the overlay |
    |
    |
    | -| Dual ToR peering | |
    |
    | -| Egress gateway | |
    |
    | -| Multiple Calico networks on a pod | |
    |
    | -| **Apps, pods, clusters** | | | | -| Seamless support with Kubernetes network policy |
    |
    |
    | -| Label-based (identity-aware) policy |
    |
    |
    | -| Namespace and cluster-wide scope |
    |
    |
    | -| Global default deny policy design |
    |
    |
    | -| Application layer policy |
    |
    |
    | -| Policy for services |
    |
    |
    | -| Web UI | |
    |
    | -| Onboarding tutorials and lab cluster | |
    | | -| DNS/FQDN-based policy | |
    |
    | -| Hierarchical tiered network policy |
    |
    |
    | -| Policy recommendations | |
    |
    | -| Preview and staged network policy | |
    |
    | -| Policy integration for third-party firewalls | |
    |
    | -| Network sets to limit IP ranges for egress and ingress traffic to workloads |
    |
    |
    | -| **Data** | | | | -| Data-in-transit encryption for pod traffic using WireGuard |
    |
    |
    | -| SIEM integration | |
    |
    | -| **Non-cluster hosts** |
    |
    |
    | -| Restrict traffic to/from hosts and VMs using network policy |
    | |
    | -| Automatic host endpoints |
    | |
    | -| Secure Kubernetes nodes with host endpoints managed by Calico |
    |
    |
    | -| Apply policy to host-forwarded traffic |
    |
    |
    | -| **Data plane** | | | | -| eBPF |
    |
    |
    | -| iptables |
    |
    |
    | -| Windows HNS |
    |
    |
    | -| VPP |
    | | | -| **Observability and troubleshooting** | | | | -| Application level observability and troubleshooting | |
    |
    | -| Service Graph | |
    |
    | -| Packet capture | |
    |
    | -| Elasticsearch logs (flow, l7, audit, bgp, dns, events) | |
    |
    | -| Alerts | |
    |
    | -| Kibana DNS dashboards | |
    |
    | -| Traffic Flow Visualizer | |
    |
    | -| **Multi-cluster management** | |
    |
    | -| Multi-cluster management | | |
    | -| Federated identity and services | |
    |
    | -| **Threat defense** | | | | -| Workload-centric Web Application Firewall (WAF) | |
    |
    | -| Add threatfeeds to trace suspicious network flows | |
    |
    | -| **Reports** | | | | -| Compliance reports | |
    |
    | -| CIS benchmark reports | |
    |
    | -| **Monitor Calico components** | | | | -| Prometheus |
    |
    |
    | diff --git a/calico_versioned_docs/version-3.29/about/index.mdx b/calico_versioned_docs/version-3.29/about/index.mdx deleted file mode 100644 index 951d2cfc85..0000000000 --- a/calico_versioned_docs/version-3.29/about/index.mdx +++ /dev/null @@ -1,62 +0,0 @@ ---- -description: A brief description of Calico, deployment options, and features. ---- - -# About Calico - -## What is $[prodname]? - -$[prodname] is a networking and security solution that enables Kubernetes workloads and non-Kubernetes/legacy workloads to communicate seamlessly and securely. - -## Components and features - -In Kubernetes, the default for networking traffic to/from pods is default-allow. If you do not lock down network connectivity using network policy, then all pods can communicate freely with other pods. - -$[prodname] consists of **networking** to secure network communication, and advanced **network policy** to secure cloud-native microservices/applications at scale. - -| Component | **Description** | Main features | -| -------------------------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | -| **$[prodname] CNI** for networking | $[prodname] CNI is a control plane that programs several data planes. It is an L3/L4 networking solution that secure containers, Kubernetes clusters, virtual machines, and native host-based workloads. | • Built-in data encryption
    • Advanced IPAM management
    • Overlay and non-overlay networking options
    • Choice of data planes: iptables, eBPF, Windows HNS, or VPP | -| **$[prodname] network policy suite** for network policy | $[prodname] network policy suite is an interface to the $[prodname] CNI that contains rules for the data plane to execute.

    $[prodname] network policy:
    • Is designed with a zero-trust security model (deny-all, allow only where needed)
    • Integrates with the Kubernetes API server (so you can still use Kubernetes network policy)
    •  Supports legacy systems (bare metal, non-cluster hosts) using the same network policy model. | • **Namespace** and **global** policy to allow/deny traffic within a cluster, between pods and the outside world, and for non-cluster hosts.

    • **Network sets** (an arbitrary set of IP subnetworks, CIDRs, or domains) to limit IP ranges for egress and ingress traffic to workloads.

    • **Application layer (L7) policy** to enforce traffic using attributes like HTTP methods, paths, and cryptographically-secure identities. | - -## $[prodname] deployment options - -$[prodname] **networking** and **network policy** are most powerful when used together, but they are both offered separately for the widest adoption across platforms. Here are common $[prodname] deployments. - -| Deployment options | Examples | -| --------------------------------------- | ---------------------------------------------------------- | -| Self-managed Kubernetes, on-premises | Kubernetes/kubeadm cluster | -| Managed Kubernetes on public cloud | EKS, GKE, IKS, AKS | -| Self-managed Kubernetes on public cloud | AWS, GCE, Azure, Digital Ocean | -| Self-managed Kubernetes distributions | OpenShift, AKS on Azure stack, Mirantis (MKE), RKE, VMware | -| Integrations | OpenStack, Flannel | -| Bare metal, non-cluster hosts | | -| Windows Kubernetes clusters | | - -For a list of platforms used by Calico community members, see [Community-tested Kubernetes versions](../getting-started/kubernetes/community-tested). - -## Feature summary - -The following table summarizes the main $[prodname] features. To search for specific features, see [Product comparison](calico-product-editions.mdx). - -| Feature | Description | -| ---------------------------- | ------------------------------------------------------------ | -| Data planes | eBPF, standard Linux iptables, Windows HNS, VPP. | -| Networking | • Scalable pod networking using BGP or overlay networking
    • Advanced IP address management that is customizable | -| Security | • Network policy enforcement for workload and host endpoints
    • Data-in-transit encryption using WireGuard | -| Monitor $[prodname] components | Uses Prometheus to monitor $[prodname] component metrics. | -| User interfaces | CLIs: `kubectl` and `calicoctl` | -| APIs | • Calico API for $[prodname] resources
    • Installation API for operator installation and configuration | -| Support and maintenance | Community-driven. $[prodname] powers 2M+ nodes daily across 166 countries. | - -## Install $[prodname] - -You can install $[prodname] using a single operator/Helm chart or manifests. - -To get start with $[prodname] in 15 minutes: - -- [Quickstart for Calico on Kubernetes](../getting-started/kubernetes/quickstart.mdx) -- [Quickstart for Calico on K3s](../getting-started/kubernetes/k3s/quickstart.mdx) -- [Quickstart for Calico on minikube](../getting-started/kubernetes/minikube.mdx) -- [Quickstart for Calico on MicroK8s](../getting-started/kubernetes/microk8s.mdx) -- [Quickstart for Calico on Kind](../getting-started/kubernetes/kind.mdx) diff --git a/calico_versioned_docs/version-3.29/about/kubernetes-training/about-ebpf.mdx b/calico_versioned_docs/version-3.29/about/kubernetes-training/about-ebpf.mdx deleted file mode 100644 index 54369013ef..0000000000 --- a/calico_versioned_docs/version-3.29/about/kubernetes-training/about-ebpf.mdx +++ /dev/null @@ -1,163 +0,0 @@ ---- -description: Learn about eBPF! ---- - -# About eBPF - -{/* Do not change the canonical_url above *or the title*. Content is shared with Marketing and is used for SEO purposes. If you change the title, it will mess up Marketing metrics. */} - -:::note - -This guide provides optional background education, including -education that is not specific to $[prodname]. - -::: - -eBPF is a Linux kernel feature that allows fast yet safe mini-programs to be loaded into the kernel to -customise its operation. - -In this guide you will learn: - -- General background on eBPF. -- Various uses of eBPF. -- How $[prodname] uses eBPF in the eBPF data plane. - -## What is eBPF? - -eBPF is a virtual machine embedded within the Linux kernel. It allows small programs to be loaded into the kernel, -and attached to hooks, which are triggered when some event occurs. This allows the behaviour of the kernel to be -(sometimes heavily) customised. While the eBPF virtual machine is the same for each type of hook, the capabilities -of the hooks vary considerably. Since loading programs into the kernel could be dangerous; the kernel runs all -programs through a very strict static verifier; the verifier sandboxes the program, ensuring it can only access -allowed parts of memory and ensuring that it must terminate quickly. - -## Why is it called eBPF? - -eBPF stands for "extended Berkeley Packet Filter". The Berkeley Packet Filter was an earlier, more specialised -virtual machine that was tailored for filtering packets. Tools such as `tcpdump` use this "classic" BPF VM to select -packets that should be sent to userspace for analysis. eBPF is a considerably extended version of BPF that -is suitable for general purpose use inside the kernel. While the name has stuck, eBPF can be used for a lot more -than just packet filtering. - -## What can eBPF do? - -### Types of eBPF program - -There are several classes of hooks to which eBPF programs can be attached within the kernel. The capabilities of an -eBPF program depend hugely on the hook to which it is attached: - -- **Tracing** programs can be attached to a significant proportion of the functions in the kernel. Tracing - programs are useful for collecting statistics and deep-dive debugging of the kernel. _Most_ tracing hooks only allow - read-only access to the data that the function is processing but there are some that allow data to be modified. - The $[prodname] team use tracing programs to help debug $[prodname] during development; for example, - to figure out why the kernel unexpectedly dropped a packet. - -- **Traffic Control** (`tc`) programs can be attached at ingress and egress to a given network device. The kernel - executes the programs once for each packet. Since the hooks are for packet processing, the kernel allows - the programs to modify or extend the packet, drop the packet, mark it for queueing, or redirect the packet to - another interface. $[prodname]'s eBPF data plane is based on this type of hook; we use tc programs to load - balance Kubernetes services, to implement network policy, and, to create a fast-path for traffic of established - connections. - -- **XDP**, or "eXpress Data Path", is actually the name of an eBPF hook. Each network device has an XDP ingress hook - that is triggered once for each incoming packet before the kernel allocates a socket buffer for the packet. XDP - can give outstanding performance for use cases such as DoS protection (as supported in $[prodname]'s standard Linux - data plane) and ingress load balancing (as used in facebook's Katran). The downside of XDP is that it requires - network device driver support to get good performance. XDP isn't sufficient on its own to implement all of the logic - needed for Kubernetes pod networking, but a combination of XDP and Traffic Control hooks works well. - -- Several types of **socket** programs hook into various operations on sockets, allowing the eBPF program to, for - example, change the destination IP of a newly-created socket, or force a socket to bind to the "correct" source - IP address. $[prodname] uses such programs to do connect-time load balancing of Kubernetes Services; this - reduces overhead because there is no [DNAT](about-networking.mdx#nat) on the packet processing path. - -- There are various security-related hooks that allow for program behaviour to be policed in various ways. For - example, the **seccomp** hooks allow for syscalls to be policed in fine-grained ways. - -- And... probably a few more hooks by the time you read this; eBPF is under heavy development in the kernel. - -The kernel exposes the capabilities of each hook via "helper functions". For example, the `tc` hook has a helper -function to resize the packet, but that helper would not be available in a tracing hook. One of the challenges of -working with eBPF is that different kernel versions support different helpers and lack of a helper can make it -impossible to implement a particular feature. - -### BPF maps - -Programs attached to eBPF hooks are able to access BPF "maps". BPF maps have two main uses: - -- They allow BPF programs to store and retrieve long-lived data. - -- They allow communication between BPF programs and user-space programs. BPF programs can read data that was written - by userspace and vice versa. - -There are many types of BPF maps, including some special types that allow jumping between programs, and, some that act -as queues and stacks rather than strictly as key/value maps. $[prodname] uses maps to keep track of active -connections, and, to configure the BPF programs with policy and service NAT information. Since map accesses can be -relatively expensive, $[prodname] aims to do a single map lookup only for each packet on an established flow. - -The contents of bpf maps can be inspected using the command-line tool, `bpftool`, which is provided with the kernel. - -## $[prodname]'s eBPF data plane - -$[prodname]'s eBPF data plane is an alternative to our standard Linux data plane (which is iptables based). -While the standard data plane focuses on compatibility by inter-working with kube-proxy, and your own iptables rules, -the eBPF data plane focuses on performance, latency and improving user experience with features that aren't possible -in the standard data plane. As part of that, the eBPF data plane replaces kube-proxy with an eBPF implementation. -The main "user experience" feature is to preserve the source IP of traffic from outside the cluster when traffic hits a -NodePort; this makes your server-side logs and network policy much more useful on that path. - -### Feature comparison - -While the eBPF data plane has some features that the standard Linux data plane lacks, the reverse is also true: - -| Factor | Standard Linux data plane | eBPF data plane | -| ------------------------------------ | ----------------------------------------------------- | -------------------------------------------------------------- | -| Throughput | Designed for 10GBit+ | Designed for 40GBit+ | -| First packet latency | Low (kube-proxy service latency is bigger factor) | Lower | -| Subsequent packet latency | Low | Lower | -| Preserves source IP within cluster | Yes | Yes | -| Preserves external source IP | Only with `externalTrafficPolicy: Local` | Yes | -| Direct Server Return | Not supported | Supported (requires compatible underlying network) | -| Connection tracking | Linux kernel's conntrack table (size can be adjusted) | BPF map (fixed size) | -| Policy rules | Mapped to iptables rules | Mapped to BPF instructions | -| Policy selectors | Mapped to IP sets | Mapped to BPF maps | -| Kubernetes services | kube-proxy iptables or IPVS mode | BPF program and maps | -| IPIP | Supported | Supported (no performance advantage due to kernel limitations) | -| VXLAN | Supported | Supported | -| WireGuard | Supported (IPv4 and IPv6) | Supported (IPv4) | -| Other routing | Supported | Supported | -| Supports third party CNI plugins | Yes (compatible plugins only) | Yes (compatible plugins only) | -| Compatible with other iptables rules | Yes (can write rules above or below other rules) | Partial; iptables bypassed for workload traffic | -| Host endpoint policy | Supported | Supported | -| Enterprise version | Available | Available | -| XDP DoS Protection | Supported | Supported | -| IPv6 | Supported | Not supported (yet) | - -### Architecture overview - -$[prodname]'s eBPF data plane attaches eBPF programs to the `tc` hooks on each $[prodname] interface as -well as your data and tunnel interfaces. This allows $[prodname] to spot workload packets early and handle them -through a fast-path that bypasses iptables and other packet processing that the kernel would normally do. - -![Diagram showing the packet path for pod-to-pod networking; a BPF program is attached to the client pod's veth interface; it does a conntrack lookup in a BPF map, and forwards the packet to the second pod directly, bypassing iptables](/img/calico/bpf-pod-to-pod.svg 'Pod-to-pod packet path with eBPF enabled') - -The logic to implement load balancing and packet parsing is pre-compiled ahead of time and relies on a set of BPF -maps to store the NAT frontend and backend information. One map stores the metadata of the service, allowing -for `externalTrafficPolicy` and "sticky" services to be honoured. A second map stores the IPs of the backing pods. - -In eBPF mode, $[prodname] converts your policy into optimised eBPF bytecode, using BPF maps to store the IP sets -matched by policy selectors. - -![Detail of BPF program showing that packets are sent to a separate (generated) policy program,](/img/calico/bpf-policy.svg 'Expanded view of tc program showing policy.') - -To improve performance for services, $[prodname] also does connect-time load balancing by hooking into the -socket BPF hooks. When a program tries to connect to a Kubernetes service, $[prodname] intercepts the connection -attempt and configures the socket to connect directly to the backend pod's IP instead. This removes _all_ -NAT overhead from service connections. - -![Diagram showing BPF program attached to socket connect call; it does NAT at connect time,](/img/calico/bpf-connect-time.svg 'BPF program attached to socket connect call.') - -## Additional resources - -- For more information and performance metrics for the eBPF data plane, see the [announcement blog post](https://www.projectcalico.org/introducing-the-calico-ebpf-dataplane/). -- If you'd like to try eBPF mode in your Kubernetes cluster, follow the [Enable the eBPF data plane](/operations/ebpf/enabling-ebpf.mdx) guide. diff --git a/calico_versioned_docs/version-3.29/about/kubernetes-training/about-k8s-networking.mdx b/calico_versioned_docs/version-3.29/about/kubernetes-training/about-k8s-networking.mdx deleted file mode 100644 index a579ba41dd..0000000000 --- a/calico_versioned_docs/version-3.29/about/kubernetes-training/about-k8s-networking.mdx +++ /dev/null @@ -1,129 +0,0 @@ ---- -description: Learn about Kubernetes networking! ---- - -# About Kubernetes Networking - -{/* Do not change the canonical_url above *or the title*. Content is shared with Marketing and is used for SEO purposes. If you change the title, it will mess up Marketing metrics. */} - -:::note - -This guide provides optional background education, not specific to $[prodname]. - -::: - -Kubernetes defines a network model that helps provide simplicity and consistency across a range of networking -environments and network implementations. The Kubernetes network model provides the foundation for understanding how -containers, pods, and services within Kubernetes communicate with each other. This guide explains the key concepts and -how they fit together. - -In this guide you will learn: - -- The fundamental network behaviors the Kubernetes network model defines. -- How Kubernetes works with a variety of different network implementations. -- What Kubernetes Services are. -- How DNS works within Kubernetes. -- What "NAT outgoing" is and when you would want to use it. -- What "dual stack" is. - -## The Kubernetes network model - -The Kubernetes network model specifies: - -- Every pod gets its own IP address -- Containers within a pod share the pod IP address and can communicate freely with each other -- Pods can communicate with all other pods in the cluster using pod IP addresses (without - [NAT](about-networking.mdx#nat)) -- Isolation (restricting what each pod can communicate with) is defined using network policies - -As a result, pods can be treated much like VMs or hosts (they all have unique IP addresses), and the containers within -pods very much like processes running within a VM or host (they run in the same network namespace and share an IP -address). This model makes it easier for applications to be migrated from VMs and hosts to pods managed by Kubernetes. -In addition, because isolation is defined using network policies rather than the structure of the network, the network -remains simple to understand. This style of network is sometimes referred to as a "flat network". - -Note that, although very rarely needed, Kubernetes does also support the ability to map host ports through to pods, or -to run pods directly within the host network namespace sharing the host's IP address. - -## Kubernetes network implementations - -Kubernetes built in network support, kubenet, can provide some basic network connectivity. However, it is more common to -use third party network implementations which plug into Kubernetes using the CNI (Container Network Interface) API. - -There are lots of different kinds of CNI plugins, but the two main ones are: - -- network plugins, which are responsible for connecting pod to the network -- IPAM (IP Address Management) plugins, which are responsible for allocating pod IP addresses. - -$[prodname] provides both network and IPAM plugins, but can also integrate and work seamlessly with some other CNI -plugins, including AWS, Azure, and Google network CNI plugins, and the host local IPAM plugin. This flexibility allows -you to choose the best networking options for your specific needs and deployment environment. You can read more about -this in the $[prodname] [determine best networking option](/networking/determine-best-networking.mdx) -guide. - -## Kubernetes Services - -Kubernetes [Services](https://kubernetes.io/docs/concepts/services-networking/service/) provide a way of abstracting access to a group of pods as a network service. -The group of pods is usually defined using a [label selector](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels). -Within the cluster the network service is usually represented as virtual IP address, and kube-proxy load balances connections to the virtual IP across the group of pods backing the service. -The virtual IP is discoverable through Kubernetes DNS. -The DNS name and virtual IP address remain constant for the life time of the service, even though the pods backing the service may be created or destroyed, and the number of pods backing the service may change over time. - -Kubernetes Services can also define how a service is accessed from outside of the cluster, for example using - -- a node port, where the service can be accessed via a specific port on every node -- or a load balancer, whether a network load balancer provides a virtual IP address that the service can be accessed via - from outside the cluster. - -Note that when using $[prodname] in on-prem deployments you can also [advertise service IP addresses](/networking/configuring/advertise-service-ips.mdx) -, allowing services to be conveniently accessed without -going via a node port or load balancer. - -## Kubernetes DNS - -Each Kubernetes cluster provides a DNS service. Every pod and every service is discoverable through the Kubernetes DNS -service. - -For example: - -- Service: `my-svc.my-namespace.svc.cluster-domain.example` -- Pod: `pod-ip-address.my-namespace.pod.cluster-domain.example` -- Pod created by a deployment exposed as a service: - `pod-ip-address.deployment-name.my-namespace.svc.cluster-domain.example`. - -The DNS service is implemented as Kubernetes Service that maps to one or more DNS server pods (usually CoreDNS), that -are scheduled just like any other pod. Pods in the cluster are configured to use the DNS service, with a DNS search list -that includes the pod's own namespace and the cluster's default domain. - -This means that if there is a service named `foo` in Kubernetes namespace `bar`, then pods in the same namespace can -access the service as `foo`, and pods in other namespaces can access the service as `foo.bar` - -Kubernetes supports a rich set of options for controlling DNS in different scenarios. You can read more about these in -the Kubernetes guide [DNS for Services and Pods](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/). - -## NAT outgoing - -The Kubernetes network model specifies that pods must be able to communicate with each other directly using pod IP -addresses. But it does not mandate that pod IP addresses are routable beyond the boundaries of the cluster. Many -Kubernetes network implementations use [overlay networks](about-networking.mdx#overlay-networks). -Typically for these deployments, when a pod initiates a connection to an IP address outside of the cluster, the node -hosting the pod will SNAT (Source Network Address Translation) map the source address of the packet from the pod IP to -the node IP. This enables the connection to be routed across the rest of the network to the destination (because the -node IP is routable). Return packets on the connection are automatically mapped back by the node replacing the node IP -with the pod IP before forwarding the packet to the pod. - -When using $[prodname], depending on your environment, you can generally choose whether you prefer to run an -overlay network, or prefer to have fully routable pod IPs. You can read more about this in the $[prodname] -[determine best networking option](/networking/determine-best-networking.mdx) guide. $[prodname] also -allows you to [configure outgoing NAT](/networking/configuring/workloads-outside-cluster.mdx) for specific IP address -ranges if more granularity is desired. - -## Dual stack - -If you want to use a mix of IPv4 and IPv6 then you can enable Kubernetes [dual-stack](https://kubernetes.io/docs/concepts/services-networking/dual-stack/) mode. When enabled, all -pods will be assigned both an IPv4 and IPv6 address, and Kubernetes Services can specify whether they should be exposed -as IPv4 or IPv6 addresses. - -## Additional resources - -- [The Kubernetes Network Model](https://kubernetes.io/docs/concepts/cluster-administration/networking/#the-kubernetes-network-model) diff --git a/calico_versioned_docs/version-3.29/about/kubernetes-training/about-kubernetes-egress.mdx b/calico_versioned_docs/version-3.29/about/kubernetes-training/about-kubernetes-egress.mdx deleted file mode 100644 index 05a9ca38fb..0000000000 --- a/calico_versioned_docs/version-3.29/about/kubernetes-training/about-kubernetes-egress.mdx +++ /dev/null @@ -1,103 +0,0 @@ ---- -description: Learn why you should restrict egress traffic and how to do it. ---- - -# Kubernetes egress - -:::note - -This guide provides educational material that is not specific to $[prodname]. - -::: - -In this guide you will learn: - -- What is Kubernetes egress? -- Why should you restrict egress traffic and how can you do it? -- What is "NAT outgoing" and when is it used? -- What is an egress gateway, and why might you want to use one? - -## What is Kubernetes egress? - -In this guide we are using the term Kubernetes egress to describe connections being made from pods to anything outside of the cluster. - -In contrast to ingress traffic, where Kubernetes has the [Ingress](about-kubernetes-ingress.mdx) -resource type to help manage the traffic, there is no Kubernetes Egress resource. Instead, how the egress traffic is -handled at a networking level is determined by the Kubernetes network implementation / CNI plugin being used by the -cluster. In addition, if a service mesh is being used, this can add egress behaviors on top of those the -network implementation provides. - -There are three areas of behavior worth understanding for egress traffic, so you can choose a networking and/or service -mesh setup that best suits your needs: - -- Restricting egress traffic -- Outgoing NAT behavior -- Egress gateways - -## Restricting egress traffic - -It's a common security requirement and best practice to restrict outgoing connections from the cluster. This is normally -achieved using [Network Policy](about-network-policy.mdx) to define egress rules for each -microservice, often in conjunction with a [default deny](about-network-policy.mdx#default-deny) -policy that ensures outgoing connections are denied by default, until a policy is defined to explicitly allow specific -traffic. - -One limitation when using Kubernetes Network Policy to restrict access to specific external resources, is that the external -resources need to be specified as IP addresses (or IP address ranges) within the policy rules. If the IP addresses -associated with an external resource change, then every policy that referenced those IP addresses needs to be updated with -the new IP addresses. This limitation can be circumvented using $[prodname] [Use external IPs or networks rules in policy](network-policy/policy-rules/external-ips-policy.mdx), or Calico Enterprise's support for domain names in policy rules.. - -Note in addition to everything mentioned so far, perimeter firewalls can also be used to restrict outgoing connections, -for example to allow connections only to particular external IP address ranges, or external services. However, since -perimeter firewalls typically cannot distinguish individual pods, the rules apply equally to all pods in the cluster. -This provides some defense in depth, but cannot replace the requirement for network policy. - -## NAT outgoing - -Network Address Translation ([NAT](https://en.wikipedia.org/wiki/Network_address_translation)) is the process of mapping an IP address in a packet -to a different IP address as the packet passes through the device performing the NAT. Depending on the use case, NAT can -apply to the source or destination IP address, or to both addresses. - -In the context of Kubernetes egress, NAT is used to allow pods to connect to services outside of the cluster if the pods -have IP addresses that are not routable outside of the cluster (for example, if the pod network is an overlay). - -For example, if a pod in an overlay network attempts to connect to an IP address outside of the cluster, then the -node hosting the pod uses SNAT (Source Network Address Translation) to map the non-routable source IP address of the -packet to the node's IP address before forwarding on the packet. The node then maps response packets coming in the -opposite direction back to the original pod IP address, so packets flow end-to-end in both directions, with neither -pod or external service being aware the mapping is happening. - -In most clusters this NAT behavior is configured statically across the whole of the cluster. When using -$[prodname], the NAT behavior can be configured at a more granular level for particular address ranges using [IP pools](../../reference/resources/ippool.mdx) -. This effectively allows the scope of "non-routable" to be more -tightly defined than just "inside the cluster vs outside the cluster", which can be useful in some enterprise deployment -scenarios. - -## Egress gateways - -Another approach to Kubernetes egress is to route all outbound connections via one or more egress gateways. The gateways -SNAT (Source Network Address Translation) the connections so the external service being connected to sees the connection -as coming from the egress gateway. The main use case is to improve security, either with the egress gateway performing a -direct security role in terms of what connections it allows, or in conjunction with perimeter firewalls (or other -external entities). For example, so that perimeter firewalls see the connections coming from well known IP -addresses (the egress gateways) rather than from dynamic pod IP addresses they don't understand. - -Egress gateways are not a native concept in Kubernetes itself, but are implemented by some Kubernetes network -implementations and some service meshes. For example, $[prodname] provides egress gateway functionality, plus the -ability to map namespaces (or even individual pods) to specific egress gateways. Perimeter firewalls (or other external -security entities) can then effectively provide per namespace security controls, even though they do not have visibility -to dynamic pod IP addresses. - -As an alternative approach to egress gateways, $[prodname] allows you to control pod IP address ranges based on -namespace, or node, or even at the individual pod level. Assuming no outgoing NAT is required, this provides a very -simple way for perimeter firewalls (or other external security entities) to integrate with Kubernetes for both ingress -and egress traffic. (Note that this approach relies on having enough address space available to sensibly assign IP -address ranges, for example to each namespace, so it can lead to IP address range exhaustion challenges for large scale -deployments. In these scenarios, using egress gateways is likely to be a better option.) - -## Additional resources - -- [Use external IPs or networks rules in policy](/network-policy/policy-rules/external-ips-policy.mdx) -- [Restrict a pod to use an IP address in a specific range](../../networking/ipam/legacy-firewalls.mdx) -- [Assign IP addresses based on topology](../../networking/ipam/assign-ip-addresses-topology.mdx) -- [Egress gateways for Calico Enterprise](/calico-enterprise/latest/networking/egress/) diff --git a/calico_versioned_docs/version-3.29/about/kubernetes-training/about-kubernetes-ingress.mdx b/calico_versioned_docs/version-3.29/about/kubernetes-training/about-kubernetes-ingress.mdx deleted file mode 100644 index c56a3660e9..0000000000 --- a/calico_versioned_docs/version-3.29/about/kubernetes-training/about-kubernetes-ingress.mdx +++ /dev/null @@ -1,131 +0,0 @@ ---- -description: Learn the different ingress implementations and how ingress and policy interact. ---- - -# Kubernetes ingress - -:::note - -This guide provides education material -that is not specific to $[prodname]. - -::: - -In this guide you will learn: - -- What is Kubernetes ingress? -- Why use ingress? -- What are the differences between different ingress implementations? -- How does ingress and network policy interact? -- How does ingress and services fit together under the covers? - -## What is Kubernetes ingress? - -Kubernetes Ingress builds on top of Kubernetes [Services](about-kubernetes-services.mdx) to provide -load balancing at the application layer, mapping HTTP and HTTPS requests with particular domains or URLs to Kubernetes -services. Ingress can also be used to terminate SSL / TLS before load balancing to the service. - -The details of how Ingress is implemented depend on which [Ingress Controller](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/) you are using. The Ingress -Controller is responsible for monitoring Kubernetes [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) resources and provisioning / configuring one -or more ingress load balancers to implement the desired load balancing behavior. - -Unlike Kubernetes services, which are handled at the network layer (L3-4), ingress load balancers operate at the -application layer (L5-7). Incoming connections are terminated at the load balancer so it can inspect the individual HTTP / -HTTPS requests. The requests are then forwarded via separate connections from the load balancer to the chosen service -backing pods. As a result, network policy applied to the backing pods can restrict access to only allow connections from the load -balancer, but cannot restrict access to specific original clients. - -## Why use Kubernetes Ingress? - -Given that Kubernetes [Services](about-kubernetes-services.mdx) already provide a mechanism for load -balancing access to services from outside of the cluster, why might you want to use Kubernetes Ingress? - -The mainline use case is if you have multiple HTTP / HTTPS services that you want to expose through a single external IP -address, perhaps with each service having a different URL path, or perhaps as multiple different domains. This is lot -simpler from a client configuration point of view than exposing each service outside of the cluster using Kubernetes -Services, which would give each service a separate external IP address. - -If on the other hand, your application architecture is fronted by a single "front end" microservice then Kubernetes -Services likely already meet your needs. In this case you might prefer to not add Ingress to the picture, both from a -simplicity point of view, and potentially also so you can more easily restrict access to specific clients using network -policy. In effect, your "front end" microservice already plays the role of Kubernetes Ingress, in a way that is not that -dissimilar to [in-cluster ingress](#in-cluster-ingress-solutions) solutions discussed below. - -## Types of Ingress solutions - -Broadly speaking there are two types of ingress solutions: - -- In-cluster ingress - where ingress load balancing is performed by pods within the cluster itself. -- External ingress - where ingress load balancing is implemented outside of the cluster by - appliances or cloud provider capabilities. - -### In-cluster ingress solutions - -In-cluster ingress solutions use software load balancers running in pods within the cluster itself. There are many -different ingress controllers to consider that follow this pattern, including for example the NGINX ingress controller. - -The advantages of this approach are that you can: - -- horizontally scale your ingress solution up to the limits of Kubernetes -- choose the ingress controller that best suits your specific needs, for example, with particular load balancing - algorithms, or security options. - -To get your ingress traffic to the in-cluster ingress pods, the ingress pods are normally exposed externally as a -Kubernetes service, so you can use any of the standard ways of accessing the service from outside of the cluster. A -common approach is use an external network load balancer or service IP advertisement, with `externalTrafficPolicy:local`. -This minimizes the number of network hops, and retains the client source IP address, which allows network policy to be used -to restrict access to the ingress pods to particular clients if desired. - -![In-cluster ingress](/img/calico-enterprise/ingress-in-cluster.svg) - -### External ingress solutions - -External ingress solutions use application load balancers outside of the cluster. The exact details and -features depend on which ingress controller you are using, but most cloud providers include an ingress controller that -automates the provisioning and management of the cloud provider's application load balancers to provide ingress. - -The advantages of this type of ingress solution is that your cloud provider handles the operational complexity of the -ingress for you. The downsides are a potentially more limited set of features compared to the rich range of in-cluster -ingress solutions, and the maximum number of services exposed by ingress being constrained by cloud provider specific -limits. - -![External ingress](/img/calico-enterprise/ingres-external.svg) - -Note that most application load balancers support a basic mode of operation of forwarding traffic to the chosen service -backing pods via the [node port](about-kubernetes-services.mdx#node-port-services) of the -corresponding service. - -In addition to this basic approach of load balancing to service node ports, some cloud providers support a second mode -of application layer load balancing, which load balances directly to the pods backing each service, without going via -node-ports or other kube-proxy service handling. This has the advantage of eliminating the potential second network hop -associated with node ports load balancing to a pod on a different node. The potential disadvantage is that if you are -operating at very high scales, for example with hundreds of pods backing a service, you may exceed the application layer -load balancers maximum limit of IPs it can load balance to in this mode. In this case switching to an in-cluster ingress -solution is likely the better fit for you. - -## Show me everything! - -All the above diagrams focus on connection level (L5-7) representation of ingress and services. You can learn more about -the network level (L3-4) interactions involved in handling the connections, including which scenarios client source IP -addresses are maintained, in the [About Kubernetes Services](about-kubernetes-services.mdx) guide. - -If you are already up to speed on how services work under the covers, here are some more complete diagrams that show details of how services are load balanced at the network layer (L3-4). - -:::note - -You can successfully use ingress without needing to understand this next level of detail! So feel free to skip -over these diagrams if you don't want to dig deeper into how services and ingress interact under the covers. - -::: - -**In-cluster ingress solution exposed as service type `LoadBalancer` with `externalTrafficPolicy:local`** - -![In-cluster ingress with NLB local](/img/calico-enterprise/ingress-in-cluster-nlb-local.svg) - -**External ingress solution via node ports** - -![External ingress via node port](/img/calico-enterprise/ingress-external-node-ports.svg) - -**External ingress solution direct to pods** - -![External ingress direct to pods](/img/calico-enterprise/ingress-external-direct-to-pods.svg) diff --git a/calico_versioned_docs/version-3.29/about/kubernetes-training/about-kubernetes-services.mdx b/calico_versioned_docs/version-3.29/about/kubernetes-training/about-kubernetes-services.mdx deleted file mode 100644 index 2f55197da9..0000000000 --- a/calico_versioned_docs/version-3.29/about/kubernetes-training/about-kubernetes-services.mdx +++ /dev/null @@ -1,140 +0,0 @@ ---- -description: Learn the three main service types and how to use them. ---- - -# Kubernetes services - -:::note - -This guide provides educational material that is not specific to $[prodname]. - -::: - -In this guide you will learn: - -- What are Kubernetes services? -- What are the differences between the three main service types and what do you use them for? -- How do services and network policy interact? -- Some options for optimizing how services are handled. - -## What are Kubernetes services? - -Kubernetes [Services](https://kubernetes.io/docs/concepts/services-networking/service/) provide a way of abstracting access to a group -of pods as a network service. The group of pods backing each service is usually defined using a [label selector](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels). - -When a client connects to a Kubernetes service, the connection is load balanced to one of the pods backing the service, -as illustrated in this conceptual diagram: - -![Kubernetes Service conceptual diagram](/img/calico-enterprise/k8s-service-concept.svg) - -There are three main types of Kubernetes services: - -- Cluster IP - which is the usual way of accessing a service from inside the cluster -- Node port - which is the most basic way of accessing a service from outside the cluster -- Load balancer - which uses an external load balancer as a more sophisticated way to access a service from outside the - cluster. - -## Cluster IP services - -The default service type is `ClusterIP`. This allows a service to be accessed within the cluster via a virtual IP -address, known as the service Cluster IP. The Cluster IP for a service is discoverable through Kubernetes DNS. For -example, `my-svc.my-namespace.svc.cluster-domain.example`. The DNS name and Cluster IP address remain constant for the -life time of the service, even though the pods backing the service may be created or destroyed, and the number of pods -backing the service may change over time. - -In a typical Kubernetes deployment, kube-proxy runs on every node and is responsible for intercepting connections to -Cluster IP addresses and load balancing across the group of pods backing each service. As part of this process -[DNAT](about-networking#nat) is used to map the destination IP address from the Cluster IP to the -chosen backing pod. Response packets on the connection then have the NAT reverse on their way back to the pod that -initiated the connection. - -![kube-proxy cluster IP](/img/calico-enterprise/kube-proxy-cluster-ip.svg) - -Importantly, network policy is enforced based on the pods, not the service Cluster IP. (i.e. Egress network policy is -enforced for the client pod after the DNAT has changed the connection's destination IP to the chosen service backing -pod. And because only the destination IP for the connection is changed, ingress network policy for the backing pod sees the -original client pod as the source of the connection.) - -## Node port services - -The most basic way to access a service from outside the cluster is to use a service of type `NodePort`. A Node Port is a -port reserved on each node in the cluster through which the service can be accessed. In a typical Kubernetes deployment, -kube-proxy is responsible for intercepting connections to Node Ports and load balancing them across the pods backing -each service. - -As part of this process [NAT](about-networking#nat) is used to map the destination IP address and -port from the node IP and Node Port, to the chosen backing pod and service port. In addition the source IP address is -mapped from the client IP to the node IP, so that response packets on the connection flow back via the original node, -where the NAT can be reversed. (It's the node which performed the NAT that has the connection tracking state needed to -reverse the NAT.) - -![kube-proxy node port](/img/calico-enterprise/kube-proxy-node-port.svg) - -Note that because the connection source IP address is SNATed to the node IP address, ingress network policy for the -service backing pod does not see the original client IP address. Typically this means that any such policy is limited to -restricting the destination protocol and port, and cannot restrict based on the client / source IP. This limitation can -be circumvented in some scenarios by using [externalTrafficPolicy](#externaltrafficpolicy) or by using -$[prodname]'s eBPF data plane [native service handling](#calico-ebpf-native-service-handling) (rather than kube-proxy) which preserves source IP address. - -## Load balancer services - -Services of type `LoadBalancer` expose the service via an external network load balancer (NLB). The exact type of -network load balancer depends on which public cloud provider or, if on-prem, which specific hardware load balancer integration is -integrated with your cluster. - -The service can be accessed from outside of the cluster via a specific IP address on the network load balancer, which by -default will load balance evenly across the nodes using the service node port. - -![kube-proxy load balancer](/img/calico-enterprise/kube-proxy-load-balancer.svg) - -Most network load balancers preserve the client source IP address, but because the service then goes via a node port, -the backing pods themselves do not see the client IP, with the same implications for network policy. As with node -ports, this limitation can be circumvented in some scenarios by using [externalTrafficPolicy](#externaltrafficpolicy) -or by using $[prodname]'s eBPF data plane [native service handling](#calico-ebpf-native-service-handling) (rather -than kube-proxy) which preserves source IP address. - -## Advertising service IPs - -One alternative to using node ports or network load balancers is to advertise service IP addresses over BGP. This -requires the cluster to be running on an underlying network that supports BGP, which typically means an on-prem -deployment with standard Top of Rack routers. - -$[prodname] supports advertising service Cluster IPs, or External IPs for services configured with one. If you are -not using Calico as your network plugin then [MetalLB](https://github.com/metallb/metallb) provides similar capabilities that work with a variety of different network -plugins. - -![kube-proxy service advertisement](/img/calico-enterprise/kube-proxy-service-advertisement.svg) - -## externalTrafficPolicy:local - -By default, whether using service type `NodePort` or `LoadBalancer` or advertising service IP addresses over BGP, -accessing a service from outside the cluster load balances evenly across all the pods backing the service, independent -of which node the pods are on. This behavior can be changed by configuring the service with -`externalTrafficPolicy:local` which specifies that connections should only be load balanced to pods backing the service -on the local node. - -When combined with services of type `LoadBalancer` or with $[prodname] service IP address advertising, traffic is -only directed to nodes that host at least one pod backing the service. This reduces the potential extra network hop -between nodes, and perhaps more importantly, to maintain the source IP address all the way to the pod, so network policy -can restrict specific external clients if desired. - -![kube-proxy service advertisement](/img/calico-enterprise/kube-proxy-service-local.svg) - -Note that in the case of services of type `LoadBalancer`, not all Load Balancers support this mode. And in the case of -service IP advertisement, the evenness of the load balancing becomes topology dependent. In this case, pod anti-affinity -rules can be used to ensure even distribution of backing pods across your topology, but this does add some complexity to -deploying the service. - -## Calico eBPF native service handling - -As an alternative to using Kubernetes standard kube-proxy, $[prodname]'s [eBPF data plane](../../operations/ebpf/enabling-ebpf.mdx) - supports native service handling. This preserves source IP to -simplify network policy, offers DSR (Direct Server Return) to reduce the number of network hops for return traffic, and -provides even load balancing independent of topology, with reduced CPU and latency compared to kube-proxy. - -![kube-proxy service advertisement](/img/calico-enterprise/calico-native-service-handling.svg) - -# Additional resources - -- [Blog: Introducing the Calico eBPF data plane](https://www.projectcalico.org/introducing-the-calico-ebpf-dataplane/) -- [Blog: Hands on with Calico eBPF native service handling](https://www.projectcalico.org/hands-on-with-calicos-ebpf-service-handling/) diff --git a/calico_versioned_docs/version-3.29/about/kubernetes-training/about-network-policy.mdx b/calico_versioned_docs/version-3.29/about/kubernetes-training/about-network-policy.mdx deleted file mode 100644 index 0562817db5..0000000000 --- a/calico_versioned_docs/version-3.29/about/kubernetes-training/about-network-policy.mdx +++ /dev/null @@ -1,234 +0,0 @@ ---- -description: Learn the basics of Kubernetes and Calico Enterprise network policy ---- - -# What is network policy? - -:::note - -This guide provides educational material that is not specific to $[prodname]. - -::: - -Kubernetes and $[prodname] provide network policy APIs to help you secure your workloads. - -In this guide you will learn: - -- What network policy is and why it is important. -- The differences between Kubernetes and $[prodname] network policies and when you might want to use each. -- Some best practices for using network policy. - -## What is network policy? - -Network policy is the primary tool for securing a Kubernetes network. It allows you to easily restrict the network -traffic in your cluster so only the traffic that you want to flow is allowed. - -To understand the significance of network policy, let's briefly explore how network security was typically achieved -prior to network policy. Historically in enterprise networks, network security was provided by designing a physical -topology of network devices (switches, routers, firewalls) and their associated configuration. The physical topology -defined the security boundaries of the network. In the first phase of virtualization, the same network and network -device constructs were virtualized in the cloud, and the same techniques for creating specific network topologies of -(virtual) network devices were used to provide network security. Adding new applications or services often required -additional network design to update the network topology and network device configuration to provide the desired -security. - -In contrast, the [Kubernetes network model](about-k8s-networking.mdx) defines a "flat" -network in which every pod can communicate with all other pods in the cluster using pod IP addresses. This approach -massively simplifies network design and allows new workloads to be scheduled dynamically anywhere in the cluster with no -dependencies on the network design. - -In this model, rather than network security being defined by network topology boundaries, it is defined using network -policies that are independent of the network topology. Network policies are further abstracted from the network by using -label selectors as their primary mechanism for defining which workloads can talk to which workloads, rather than IP -addresses or IP address ranges. - -## Why is network policy important? - -In an age where attackers are becoming more and more sophisticated, network security as a line of defense is more important -than ever. - -While you can (and should) use firewalls to restrict traffic at the perimeters of your network (commonly referred to as -north-south traffic), their ability to police Kubernetes traffic is often limited to a granularity of the cluster as a -whole, rather than to specific groups of pods, due to the dynamic nature of pod scheduling and pod IP addresses. In -addition, the goal of most attackers once they gain a small foothold inside the perimeter is to move laterally (commonly -referred to as east-west) to gain access to higher value targets, which perimeter based firewalls can't police against. - -Network policy on the other hand is designed for the dynamic nature of Kubernetes by following the standard Kubernetes -paradigm of using label selectors to define groups of pods, rather than IP addresses. And because network policy is -enforced within the cluster itself it can police both north-south and east-west traffic. - -Network policy represents an important evolution of network security, not just because it handles the dynamic nature of -modern microservices, but because it empowers dev and DevOps engineers to easily define network security themselves, -rather than needing to learn low-level networking details or raise tickets with a separate team responsible for managing -firewalls. Network policy makes it easy to define intent, such as "only this microservice gets to connect to the -database", write that intent as code (typically in YAML files), and integrate authoring of network policies into git -workflows and CI/CD processes. - -:::note - -Note: $[prodname] offers capabilities that can help perimeter firewalls integrate -more tightly with Kubernetes. However, this does not remove the need or value of network policies within the cluster itself.) - -::: - -## Kubernetes network policy - -Kubernetes network policies are defined using the Kubernetes [NetworkPolicy](https://kubernetes.io/docs/reference/kubernetes-api/policy-resources/network-policy-v1/) resource. - -The main features of Kubernetes network policies are: - -- Policies are namespace scoped (i.e. you create them within the context of a specific namespace just like, for example, pods) -- Policies are applied to pods using label selectors -- Policy rules can specify the traffic that is allowed to/from other pods, namespaces, or CIDRs -- Policy rules can specify protocols (TCP, UDP, SCTP), named ports or port numbers - -Kubernetes itself does not enforce network policies, and instead delegates their enforcement to network plugins. Most -network plugins implement the mainline elements of Kubernetes network policies, though not all implement every feature -of the specification. ($[prodname] does implement every feature, and was the original reference implementation of Kubernetes -network policies.) - -To learn more about Kubernetes network policies, read the [Get started with Kubernetes network policy](../../network-policy/get-started/kubernetes-policy/kubernetes-network-policy.mdx) - guide. - -## $[prodname] network policy - -In addition to enforcing Kubernetes network policy, $[prodname] supports its own -namespaced [NetworkPolicy](../../reference/resources/networkpolicy.mdx) and non-namespaced -[GlobalNetworkPolicy](../../reference/resources/globalnetworkpolicy.mdx) resources, which provide additional -features beyond those supported by Kubernetes network policy. This includes support for: - -- policy ordering/priority -- deny and log actions in rules -- more flexible match criteria for applying policies and in policy rules, including matching on Kubernetes ServiceAccounts -- ability to reference non-Kubernetes workloads in polices, including matching on - [NetworkSets](../../reference/resources/networkset.mdx) in policy rules - -While Kubernetes network policy applies only to pods, $[prodname] network policy can be applied to multiple types of -endpoints including pods, VMs, and host interfaces. - -To learn more about $[prodname] network policies, see [Calico network policy](network-policy/get-started/calico-policy/calico-network-policy.mdx) guide. - -## Benefits of using $[prodname] for network policy - -### Full Kubernetes network policy support - -Unlike some other network policy implementations, $[prodname] implements the full set of Kubernetes network policy features. - -### Richer network policy - -$[prodname] network policies allow even richer traffic control than Kubernetes network policies if you need it. In addition, -$[prodname] network policies allow you to create policy that applies across multiple namespaces using GlobalNetworkPolicy -resources. - -### Mix Kubernetes and $[prodname] network policy - -Kubernetes and $[prodname] network policies can be mixed together seamlessly. One common use case for this is to split -responsibilities between security / cluster ops teams and developer / service teams. For example, giving the security / -cluster ops team RBAC permissions to define $[prodname] policies, and giving developer / service teams RBAC permissions to -define Kubernetes network policies in their specific namespaces. As $[prodname] policy rules can be ordered to be enforced -either before or after Kubernetes network policies, and can include actions such as deny and log, this allows the -security / cluster ops team to define basic higher-level more-general purpose rules, while empowering the developer / -service teams to define their own fine-grained constraints on the apps and services they are responsible for. - -For more flexible control and delegation of responsibilities between two or more teams, $[prodname] Enterprise extends this -model to provide [hierarchical policy](#hierarchical-policy). - -![Example mix of network policy types](/img/calico-enterprise/example-k8s-calico-policy-mix.svg) - -### Ability to protect hosts and VMs - -As $[prodname] policies can be enforce on host interfaces, you can use them to protect your Kubernetes nodes (not -just your pods), including for example, limiting access to node ports from outside of the cluster. To learn more, check -out the $[prodname] [policy for hosts](network-policy/hosts/index.mdx) guides. - -### Extendable with $[prodname] - -Calico Enterprise adds even richer network policy capabilities, with the ability -to specify hierarchical policies, with each team have particular boundaries of trust, and FQDN / domain names in policy -rules for restricting access to specific external services. - -## Best practices for network policies - -### Ingress and egress - -At a minimum we recommend that every pod is protected by network policy ingress rules that restrict what is allowed -to connect to the pod and on which ports. The best practice is also to define network policy egress rules that restrict -the outgoing connections that are allowed by pods themselves. Ingress rules protect your pod from attacks outside of the -pod. Egress rules help protect everything outside of the pod if the pod gets compromised, reducing the attack surface to -make moving laterally (east-west) or to prevent an attacker from exfiltrating compromised data from your cluster (north-south). - -### Policy schemas - -Due to the flexibility of network policy and labelling, there are often multiple different ways of labelling and writing -policies that can achieve the same particular goal. One of the most common approaches is to have a small number of -global policies that apply to all pods, and then a single pod specific policy that defines all the ingress and egress -rules that are particular to that pod. - -For example: - -```yaml -kind: NetworkPolicy -apiVersion: networking.k8s.io/v1 -metadata: - name: front-end - namespace: staging -spec: - podSelector: - matchLabels: - app: back-end - ingress: - - from: - - podSelector: - matchLabels: - app: front-end - ports: - - protocol: TCP - port: 443 - egress: - - to: - - podSelector: - matchLabels: - app: database - ports: - - protocol: TCP - port: 27017 - -``` - -### Default deny - -One approach to ensuring these best practices are being followed is to define [default deny](network-policy/get-started/kubernetes-default-deny.mdx) - network policies. These ensure that if no other policy is -defined that explicitly allows traffic to/from a pod, then the traffic will be denied. As a result, anytime a team -deploys a new pod, they are forced to also define network policy for the pod. It can be useful to use a $[prodname] -GlobalNetworkPolicy for this (rather than needing to define a policy every time a new namespace is created) and to -include some exceptions to the default deny (for example to allow pods to access DNS). - -For example, you might use the following policy to default-deny all (non-system) pod traffic except for DNS queries to kube-dns/core-dns. - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: default-app-policy -spec: - namespaceSelector: has(projectcalico.org/name) && projectcalico.org/name not in {"kube-system", "calico-system", "calico-apiserver"} - types: - - Ingress - - Egress - egress: - - action: Allow - protocol: UDP - destination: - selector: k8s-app == "kube-dns" - ports: - - 53 -``` - -### Hierarchical policy - -[Calico Enterprise](/calico-enterprise/latest/network-policy/policy-tiers/tiered-policy) supports hierarchical network policy using policy tiers. RBAC -for each tier can be defined to restrict who can interact with each tier. This can be used to delegate trust across -multiple teams. - -![Example tiers](/img/calico-enterprise/example-tiers.svg) diff --git a/calico_versioned_docs/version-3.29/about/kubernetes-training/about-networking.mdx b/calico_versioned_docs/version-3.29/about/kubernetes-training/about-networking.mdx deleted file mode 100644 index 85a32a74e8..0000000000 --- a/calico_versioned_docs/version-3.29/about/kubernetes-training/about-networking.mdx +++ /dev/null @@ -1,166 +0,0 @@ ---- -description: Learn about networking! ---- - -# About networking - -:::note - -This guide provides optional background education, not specific to $[prodname]. - -::: - -You can get up and running with Calico by following any of the $[prodname] [install guides](/getting-started/index.mdx) - without needing to be a networking expert. Calico hides the complexities for -you. However, if you would like to learn more about networking so you can better understand what is happening under the -covers, this guide provides a short introduction to some of the key fundamental networking concepts for anyone who is -not already familiar with them. - -In this guide you will learn: - -- The terms used to described different layers of the network. -- The anatomy of a network packet. -- What MTU is and why it makes a difference. -- How IP addressing, subnets, and IP routing works. -- What an overlay network is. -- What DNS and NAT are. - -## Network layers - -The process of sending and receiving data over a network is commonly categorized into 7 layers (referred to as the [OSI model](https://en.wikipedia.org/wiki/OSI_model)). The layers are -typically abbreviated as L1 - L7. You can think of data as passing through each of these layers in turn as it is sent or -received from an application, with each layer being responsible for a particular part of the processing required to -send or receive the data over the network. - -![OSI network layers diagram](/img/calico/osi-network-layers.svg) - -In a modern enterprise or public cloud network, the layers commonly map as follows: - -- L5-7: all the protocols most application developers are familiar with. e.g. HTTP, FTP, SSH, SSL, DNS. -- L4: TCP or UDP, including source and destination ports. -- L3: IP packets and IP routing. -- L2: Ethernet packets and Ethernet switching. - -## Anatomy of a network packet - -When sending data over the network, each layer in the network stack adds its own header containing the control/metadata -the layer needs to process the packet as it traverses the network, passing the resulting packet on to the next -layer of the stack. In this way the complete packet is produced, which includes all the control/metadata required by -every layer of the stack, without any layer understanding the data or needing to process the control/metadata of -adjacent network layers. - -![Anatomy of a network packet](/img/calico/anatomy-of-a-packet.svg) - -## IP addressing, subnets and IP routing - -The L3 network layer introduces IP addresses and typically marks the boundary between the part of networking that -application developers care about, and the part of networking that network engineers care about. In particular -application developers typically regard IP addresses as the source and destination of the network traffic, but have much -less of a need to understand L3 routing or anything lower in the network stack, which is more the domain of network -engineers. - -There are two variants of IP addresses: IPv4 and IPv6. - -- IPv4 addresses are 32 bits long and the most commonly used. They are typically represented as 4 bytes in decimal (each - 0-255) separated by dots. e.g. `192.168.27.64`. There are several ranges of IP addresses that are reserved as - "private", that can only be used within local private networks, are not routable across the internet. These can be - reused by enterprises as often as they want to. In contrast "public" IP addresses are globally unique across the whole - of the internet. As the number of network devices and networks connected to the internet has grown, public IPv4 - addresses are now in short supply. -- IPv6 addresses are 128 bits long and designed to overcome the shortage of IPv4 address space. They are typically - represented by 8 groups of 4 digit hexadecimal numbers. e.g. `1203:8fe0:fe80:b897:8990:8a7c:99bf:323d`. Due to the 128 - bit length, there's no shortage of IPv6 addresses. However, many enterprises have been slow to adopt IPv6, so for now - at least, IPv4 remains the default for many enterprise and data center networks. - -Groups of IP addresses are typically represented using [CIDR notation](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) that consists of an IP address and number of -significant bits on the IP address separated by a `/`. For example, `192.168.27.0/24` represents the group of 256 IP -addresses from `192.168.27.0` to `192.168.27.255`. - -A group of IP addresses within a single L2 network is referred to as a subnet. Within a subnet, packets can be sent -between any pair of devices as a single network hop, based solely on the L2 header (and footer). - -To send packets beyond a single subnet requires L3 routing, with each L3 network device (router) being responsible for -making decisions on the path to send the packet based on L3 routing rules. Each network device acting as a router has -routes that determine where a packet for a particular CIDR should be sent next. So for example, in a Linux system, a -route of `10.48.0.128/26 via 10.0.0.12 dev eth0` indicates that packets with destination IP address in `10.48.0.128/26` -should be routed to a next network hop of `10.0.0.12` over the `eth0` interface. - -Routes can be configured statically by an administrator, or programmed dynamically using routing protocols. When using -routing protocols each network device typically needs to be configured to tell it which other network devices it should -be exchanging routes with. The routing protocol then handles programming the right routes across the whole of the -network as devices are added or removed, or network links come in or out of service. - -One common routing protocol used in large enterprise and data center networks is [BGP](https://en.wikipedia.org/wiki/Border_Gateway_Protocol). BGP is one of the main protocols that powers -the internet, so scales incredibly well, and is very widely supported by modern routers. - -## Overlay networks - -An overlay network allows network devices to communicate across an underlying network (referred to as the underlay) -without the underlay network having any knowledge of the devices connected to the overlay network. From the point of -view of the devices connected to the overlay network, it looks just like a normal network. There are many different -kinds of overlay networks that use different protocols to make this happen, but in general they share the same common -characteristic of taking a network packet, referred to as the inner packet, and encapsulating it inside an outer network -packet. In this way the underlay sees the outer packets without needing to understand how to handle the inner packets. - -How the overlay knows where to send packets varies by overlay type and the protocols they use. Similarly exactly how the -packet is wrapped varies between different overlay types. In the case of VXLAN for example, the inner packet is wrapped -and sent as UDP in the outer packet. - -![Anatomy of an overlay network packet](/img/calico/anatomy-of-an-overlay-packet.svg) - -Overlay networks have the advantage of having minimal dependencies on the underlying network infrastructure, but have -the downsides of: - -- having a small performance impact compared to non-overlay networking, which you might want to avoid if running - network intensive workloads -- workloads on the overlay are not easily addressable from the rest of the network. so NAT gateways or load balancers - are required to bridge between the overlay and the underlay network for any ingress to, or egress from, the overlay. - -$[prodname] networking options are exceptionally flexible, so in general you can choose whether you prefer -$[prodname] to provide an overlay network, or non-overlay network. You can read more about this in the $[prodname] -[determine best networking option](/networking/determine-best-networking.mdx) guide. - -## DNS - -While the underlying network packet flow across the network is determined using IP addresses, users and applications -typically want to use well known names to identify network destinations that remain consistent over time, even if the -underlying IP addresses change. For example, to map `google.com` to `216.58.210.46`. This translation from name to IP -address is handled by [DNS](https://en.wikipedia.org/wiki/Domain_Name_System). DNS runs on top of the base networking described so far. Each device connected to a network is typically configured -with the IP addresses of one or more DNS servers. When an application wants to connect to a domain name, a DNS message is -sent to the DNS server, which then responds with information about which IP address(es) the domain name maps to. The -application can then initiate its connection to the chosen IP address. - -## NAT - -Network Address Translation ([NAT](https://en.wikipedia.org/wiki/Network_address_translation)) is the process of mapping an IP address in a packet -to a different IP address as the packet passes through the device performing the NAT. Depending on the use case, NAT can -apply to the source or destination IP address, or to both addresses. - -One common use case for NAT is to allow devices with private IP address to talk to devices with public IP address across -the internet. For example, if a device with a private IP address attempts to connect to a public IP address, then the -router at the border of the private network will typically use SNAT (Source Network Address Translation) to map the -private source IP address of the packet to the router's own public IP address before forwarding it on to the internet. -The router then maps response packets coming in the opposite direction back to the original private IP address, so -packets flow end-to-end in both directions, with neither source or destination being aware the mapping is happening. The -same technique is commonly used to allow devices connected to an overlay network to connect with devices outside of the -overlay network. - -Another common use case for NAT is load balancing. In this case the load balancer performs DNAT (Destination Network -Address Translation) to change the destination IP address of the incoming connection to the IP address of the chosen -device it is load balancing to. The load balancer then reverses this NAT on response packets so neither source or -destination device is aware the mapping is happening. - -## MTU - -The Maximum Transmission Unit ([MTU](https://en.wikipedia.org/wiki/Maximum_transmission_unit)) of a network link is the maximum size of packet that -can be sent across that network link. It is common for all links in a network to be configured with the same MTU to -reduce the need to fragment packets as they traverse the network, which can significantly lower the performance of the -network. In addition, TCP tries to learn path MTUs, and adjust packet sizes for each network path based on the smallest -MTU of any of the links in the network path. When an application tries to send more data than can fit in a single -packet, TCP will fragment the data into multiple TCP segments, so the MTU is not exceeded. - -Most networks have links with an MTU of 1,500 bytes, but some networks support MTUs of 9,000 bytes. In a Linux system, -larger MTU sizes can result in lower CPU being used by the Linux networking stack when sending large amounts of data, -because it has to process fewer packets for the same amount of data. Depending on the network interface hardware being -used, some of this overhead may be offloaded to the network interface hardware, so the impact of small vs large MTU -sizes varies from device to device. diff --git a/calico_versioned_docs/version-3.29/about/kubernetes-training/index.mdx b/calico_versioned_docs/version-3.29/about/kubernetes-training/index.mdx deleted file mode 100644 index e789bf3f83..0000000000 --- a/calico_versioned_docs/version-3.29/about/kubernetes-training/index.mdx +++ /dev/null @@ -1,10 +0,0 @@ ---- -description: Introduction to Kubernetes networking and network policy for beginners. ---- - -# Kubernetes networking and policy - -import DocCardList from '@theme/DocCardList'; -import { useCurrentSidebarCategory } from '@docusaurus/theme-common'; - - diff --git a/calico_versioned_docs/version-3.29/about/training-resources.mdx b/calico_versioned_docs/version-3.29/about/training-resources.mdx deleted file mode 100644 index 8cc89ef7ac..0000000000 --- a/calico_versioned_docs/version-3.29/about/training-resources.mdx +++ /dev/null @@ -1,16 +0,0 @@ ---- -description: Links to Calico resources for onboarding and training. ---- - -# Training and resources - -| Resource | URL | -| --------------------------------------------------------- | ------------------------------------------------------------ | -| Get a $[prodname] cluster up and running in 15 minutes | • [Quickstart for $[prodname] on Kubernetes](../getting-started/kubernetes/quickstart.mdx)
    • [Quickstart for $[prodname] on K3s](../getting-started/kubernetes/k3s/quickstart.mdx)
    • [Quickstart for $[prodname] on minikube](../getting-started/kubernetes/minikube.mdx)
    • [Quickstart for $[prodname] on MicroK8s](../getting-started/kubernetes/microk8s.mdx) | -| eBook: Introduction to Kubernetes Networking and Security | [Download ebook](https://www.tigera.io/lp/kubernetes-networking-ebook/) | -| Certified $[prodname] Operator training | • [Level 1](https://academy.tigera.io/course/certified-calico-operator-level-1/)
    • [AWS Expert](https://academy.tigera.io/course/certified-calico-operator-aws-expert/)
    • [eBPF](https://academy.tigera.io/course/certified-calico-operator-ebpf/)
    • [Azure](https://academy.tigera.io/course/certified-calico-operator-azure-expert/) | -| Workshops | [Workshops and events](https://www.tigera.io/events/) | -| Videos, datasheets | [Videos, case studies, datasheets, etc.](https://www.tigera.io/resources/) | -| Blog | [Technical blog](https://www.tigera.io/blog/?_sft_post_tag=project-calico) | -| Stay connected | • [GitHub](https://github.com/projectcalico/calico)
    • [$[prodname] slack channel](https://calicousers.slack.com/)
    • [$[prodname] YouTube channel](https://www.youtube.com/channel/UCFpTnXDNcBoXI4gqCDmegFA)
    • [Security bulletin of vulnerabilities](https://www.tigera.io/security-bulletins/)
    • [Twitter](https://twitter.com/projectcalico)
    • [Mailing list](https://www.tigera.io/project-calico/) | -| Report a bug | • [Report an issue](https://github.com/projectcalico/calico/blob/master/CONTRIBUTING.md)
    • [Report a docs bug](https://github.com/tigera/docs/issues) | diff --git a/calico_versioned_docs/version-3.29/get-help/support.mdx b/calico_versioned_docs/version-3.29/get-help/support.mdx deleted file mode 100644 index 87de4d3e72..0000000000 --- a/calico_versioned_docs/version-3.29/get-help/support.mdx +++ /dev/null @@ -1,18 +0,0 @@ ---- -description: How to get help and provide feedback. ---- - -# Support and feedback - -## Slack - -Got questions? We have a thriving community to help you. - -- [$[prodname] slack channel](https://calicousers.slack.com/) -- [Community events](https://github.com/projectcalico/community) - -## GitHub - -- [Project Calico on GitHub](https://github.com/projectcalico/calico) -- [Contribute and report issues](https://github.com/projectcalico/calico/blob/master/CONTRIBUTING.md) -- [Contribute to docs](https://github.com/tigera/docs) \ No newline at end of file diff --git a/calico_versioned_docs/version-3.29/getting-started/bare-metal/about.mdx b/calico_versioned_docs/version-3.29/getting-started/bare-metal/about.mdx deleted file mode 100644 index 6f91bc16d4..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/bare-metal/about.mdx +++ /dev/null @@ -1,58 +0,0 @@ ---- -description: Install Calico on hosts not in a cluster with network policy, or networking and network policy. ---- - -# About non-cluster hosts - -## Big picture - -Secure non-cluster hosts and VMs by installing $[prodname] for networking and/or networking policy. - -## Value - -Not all hosts in your environment run pods/workloads. You may have physical machines or legacy applications that you cannot move into a Kubernetes cluster, but still need to securely communicate with pods in your cluster. $[prodname] lets you enforce policy on these **non-cluster hosts** using the same robust $[prodname] network policy that you use for pods. - -## Concepts - -### Non-cluster hosts and host endpoints - -A **non-cluster host** is a computer that is running an application that is _not part of a Kubernetes cluster_. Using $[prodname] network policy, you can secure these host interfaces using **host endpoints**. Host endpoints can have labels, and work the same as labels on pods/workload endpoints. - -The advantage is, you can write network policy rules to apply to both workload endpoints and host endpoints using label selectors; where each selector can refer to the either type (or be a mix of the two). For example, you can write a cluster-wide policy for non-cluster hosts that is immediately applied to every host. To learn how to restrict traffic to/from hosts and VMs using $[prodname] network policy, see [Protect hosts](../../network-policy/hosts/protect-hosts.mdx). - -If you are using the etcd3 database, you can also install $[prodname] with networking as described below. - -### Install options for non-cluster hosts - -| Install $[prodname] with... | Requires | Use case | Supported install methods | -| ----------------------------- | -------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------- | -| Policy only | An etcd3 or Kubernetes datastore | Use $[prodname] network policy to control firewalls on non-cluster hosts. | Binary install with/ without a package manager | -| Networking and network policy | An etcd3 datastore | **Networking**
    Use $[prodname] networking (BGP, or overlay with VXLAN or IP-in-IP) to handle these communications:
    - pod ↔ pod
    - pod ↔ host

    **Note**: $[prodname] does not handle host ↔ host networking; your underlying network must already be set up to handle this.

    **Policy**
    Use $[prodname] network policy to control firewalls on your non-cluster hosts. | Docker container | - -## Before you begin - -**Supported** - -- All platforms in this release, except Windows - -**Required** - -- Non-cluster host meets [system requirements](requirements.mdx) for $[prodname]. If you want to use a package manager for installation, the non-cluster host must be a system derived from Ubuntu or RedHat. -- Set up a datastore; if $[prodname] is installed on a cluster, you already have a datastore -- Install `kubectl` or [`calicoctl`](../../operations/calicoctl/index.mdx). (`kubectl` works only with the Kubernetes datastore.) - -## Next steps - -Select an install method. - -:::note - -$[prodname] must be installed on each non-cluster host that you want to control with networking and/or policy. - -::: - -| Install method | Networking | Policy | -| ------------------------------------------------------------------ | ---------- | ------ | -| [Docker container](installation/container.mdx) | ✓ | ✓ | -| [Binary install with package manager](installation/binary-mgr.mdx) | | ✓ | -| [Binary install without package manager](installation/binary.mdx) | | ✓ | diff --git a/calico_versioned_docs/version-3.29/getting-started/bare-metal/index.mdx b/calico_versioned_docs/version-3.29/getting-started/bare-metal/index.mdx deleted file mode 100644 index c854afe88d..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/bare-metal/index.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: Install Calico on hosts to secure host communications. -hide_table_of_contents: true ---- - -# Non-cluster hosts - -import DocCardList from '@theme/DocCardList'; -import { useCurrentSidebarCategory } from '@docusaurus/theme-common'; - - diff --git a/calico_versioned_docs/version-3.29/getting-started/bare-metal/installation/binary-mgr.mdx b/calico_versioned_docs/version-3.29/getting-started/bare-metal/installation/binary-mgr.mdx deleted file mode 100644 index afa51322ac..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/bare-metal/installation/binary-mgr.mdx +++ /dev/null @@ -1,77 +0,0 @@ ---- -description: Install Calico on non-cluster host using a package manager. ---- - -import EnvironmentFile from '@site/calico_versioned_docs/version-3.29/_includes/components/EnvironmentFile'; -import FelixInitDatastore from '@site/calico_versioned_docs/version-3.29/_includes/content/_felix-init-datastore.mdx'; - -# Binary install with package manager - -## Big picture - -Install $[prodname] on non-cluster hosts using a package manager. - -## Value - -Packaged binaries of $[prodname] are easy to consume and upgrade. This method automatically configures the init system to keep Felix running. - -## Before you begin... - -1. Ensure the $[prodname] datastore is up and accessible from the host -1. Ensure the host meets the minimum [system requirements](../requirements.mdx) -1. If your system is not an Ubuntu- or RedHat-derived system, you will need to choose a different install method. -1. If you want to install $[prodname] with networking (so that you can communicate with cluster workloads), you should choose the [container install method](container.mdx) -1. Install `kubectl` (for Kubernetes datastore) or [Install and configure `calicoctl`](../../../operations/calicoctl/index.mdx) for etcd3 datastore. - -## How to - -This guide covers installing Felix, the $[prodname] daemon that handles network policy. - -### Step 1: Install binaries - -_PPA requires_: Ubuntu 14.04 or 16.04 - -```bash -sudo add-apt-repository ppa:project-calico/$[ppa_repo_name] -sudo apt-get update -sudo apt-get upgrade -sudo apt-get install calico-felix -``` - -_RPM requires_: RedHat 7-derived distribution - -```bash -cat > /etc/yum.repos.d/calico.repo < - -Modify the included init system unit to include the `EnvironmentFile`. For example, on systemd, add the following line to the `[Service]` section of the `calico-felix` unit. - -```bash -EnvironmentFile=/etc/calico/calico.env -``` - -### Step 3: Initialize the datastore - - diff --git a/calico_versioned_docs/version-3.29/getting-started/bare-metal/installation/binary.mdx b/calico_versioned_docs/version-3.29/getting-started/bare-metal/installation/binary.mdx deleted file mode 100644 index bc8f506ab3..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/bare-metal/installation/binary.mdx +++ /dev/null @@ -1,118 +0,0 @@ ---- -description: Install Calico binary on non-cluster hosts without a package manager. ---- - -import EnvironmentFile from '@site/calico_versioned_docs/version-3.29/_includes/components/EnvironmentFile'; -import FelixInitDatastore from '@site/calico_versioned_docs/version-3.29/_includes/content/_felix-init-datastore.mdx'; - -# Binary install without package manager - -## Big picture - -Install $[prodname] binary on non-cluster hosts without a package manager. - -## Value - -Install $[prodname] directly when a package manager isn't available, or your provisioning system can easily handle copying binaries to hosts. - -## Before you begin... - -1. Ensure the $[prodname] datastore is up and accessible from the host -1. Ensure the host meets the minimum [system requirements](../requirements.mdx) -1. If you want to install $[prodname] with networking (so that you can communicate with cluster workloads), you should choose the [container install method](container.mdx) -1. Install `kubectl` (for Kubernetes datastore) or [Install and configure `calicoctl`](../../../operations/calicoctl/index.mdx) for etcd3 datastore. - -## How to - -This guide covers installing Felix, the $[prodname] daemon that handles network policy. - -### Step 1: Download and extract the binary - -This step requires Docker, but it can be run from any machine with Docker installed. It doesn't have to be the host you will run it on (i.e your laptop is fine). - -1. Use the following command to download the $[nodecontainer] image. - - ```bash - docker pull $[nodecontainer]:$[releases.0.components.calico/node.version] - ``` - -1. Confirm that the image has loaded by typing `docker images`. - - ```bash - REPOSITORY TAG IMAGE ID CREATED SIZE - $[nodecontainer] $[releases.0.components.calico/node.version] e07d59b0eb8a 2 minutes ago 42MB - ``` - -1. Create a temporary $[nodecontainer] container. - - ```bash - docker create --name container $[nodecontainer]:$[releases.0.components.calico/node.version] - ``` - -1. Copy the calico-node binary from the container to the local file system. - - ```bash - docker cp container:/bin/calico-node calico-node - ``` - -1. Delete the temporary container. - - ```bash - docker rm container - ``` - -1. Set the extracted binary file to be executable. - - ``` - chmod +x calico-node - chown root:root calico-node - ``` - -### Step 2: Copy the `calico-node` binary - -Copy the binary from Step 1 to the target machine, using any means (`scp`, `ftp`, USB stick, etc.). - -### Step 3: Create environment file - - - -### Step 4: Create a start-up script - -Felix should be started at boot by your init system and the init system -**must** be configured to restart Felix if it stops. Felix relies on -that behavior for certain configuration changes. - -If your distribution uses systemd, then you could use the following unit -file: - -```bash -[Unit] -Description=Calico Felix agent -After=syslog.target network.target - -[Service] -User=root -EnvironmentFile=/etc/calico/calico.env -ExecStartPre=/usr/bin/mkdir -p /var/run/calico -ExecStart=/usr/local/bin/calico-node -felix -KillMode=process -Restart=on-failure -LimitNOFILE=32000 - -[Install] -WantedBy=multi-user.target -``` - -Once you've configured Felix, start it up via your init system. - -```bash -service calico-felix start -``` - -### Step 5: Initialize the datastore - - diff --git a/calico_versioned_docs/version-3.29/getting-started/bare-metal/installation/container.mdx b/calico_versioned_docs/version-3.29/getting-started/bare-metal/installation/container.mdx deleted file mode 100644 index 10aabc0e7b..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/bare-metal/installation/container.mdx +++ /dev/null @@ -1,27 +0,0 @@ ---- -description: Install Calico on non-cluster hosts using a Docker container. ---- - -# Docker container install - -import DockerContainerService from '@site/calico_versioned_docs/version-3.29/_includes/content/_docker-container-service.mdx'; - -## Big picture - -Install $[prodname] on non-cluster hosts using a Docker container for both networking and policy. - -## Value - -Installing $[prodname] with a Docker container includes everything you need for both networking and policy. It also automatically adds the appropriate per-node configuration to the datastore. - -## Before you begin... - -1. Ensure Docker is installed -1. Ensure the $[prodname] datastore is up and accessible from the host -1. Ensure the host meets the minimum [system requirements](../requirements.mdx) - -## How to - -The `$[nodecontainer]` container should be started at boot time by your init system and the init system must be configured to restart it if stopped. $[prodname] relies on that behavior for certain configuration changes. - - diff --git a/calico_versioned_docs/version-3.29/getting-started/bare-metal/installation/index.mdx b/calico_versioned_docs/version-3.29/getting-started/bare-metal/installation/index.mdx deleted file mode 100644 index ae7bd06532..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/bare-metal/installation/index.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: Install Calico on hosts to secure host communications. -hide_table_of_contents: true ---- - -# Install on non-cluster hosts - -import DocCardList from '@theme/DocCardList'; -import { useCurrentSidebarCategory } from '@docusaurus/theme-common'; - - diff --git a/calico_versioned_docs/version-3.29/getting-started/bare-metal/requirements.mdx b/calico_versioned_docs/version-3.29/getting-started/bare-metal/requirements.mdx deleted file mode 100644 index 12f01c95c7..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/bare-metal/requirements.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: Review node requirements for installing Calico. -title: System requirements ---- - -import SystemRequirements from '../../_includes/partials/_system-requirements.mdx'; -export const platform='host'; - -# System requirements for Kubernetes - - diff --git a/calico_versioned_docs/version-3.29/getting-started/index.mdx b/calico_versioned_docs/version-3.29/getting-started/index.mdx deleted file mode 100644 index 56f0bb94b0..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/index.mdx +++ /dev/null @@ -1,76 +0,0 @@ ---- -description: Install Calico on nodes and hosts for popular orchestrators, and install the calicoctl command line interface (CLI) tool. ---- - -import { DocCardLink, DocCardLinkLayout } from '/src/___new___/components'; - -# Install Calico - -Quickstart tutorials and guides for installing Calico on Kubernetes, OpenStack, and non-cluster hosts. - -## Getting started - - - - - - - -## Installing - - - - - - - - - - - -## Installing on cloud infrastructure - - - - - - - - - - - - -## Calico for Windows - - - - - - - - - - -## OpenStack - - - - - - - - - - - -## Non-cluster hosts - - - - - - - - - diff --git a/calico_versioned_docs/version-3.29/getting-started/kubernetes/community-tested.mdx b/calico_versioned_docs/version-3.29/getting-started/kubernetes/community-tested.mdx deleted file mode 100644 index b1aaa92302..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/kubernetes/community-tested.mdx +++ /dev/null @@ -1,59 +0,0 @@ ---- -description: Provides community inputs on what versions of Kubernetes and platforms work with Calico. ---- - -# Community-tested Kubernetes versions - -## About $[prodname] testing - -$[prodname] is tested each release against the Kubernetes versions listed in [System requirements](requirements.mdx). - -$[prodname] works on many different platforms. The following are common platforms that $[prodname] tests with some regularity. - -- [AKS](managed-public-cloud/aks.mdx) -- [Azure](self-managed-public-cloud/azure.mdx) -- [DigitalOcean](self-managed-public-cloud/do.mdx) -- [EKS](managed-public-cloud/eks.mdx) -- [Flannel](flannel/install-for-flannel.mdx) -- [GCE](self-managed-public-cloud/gce.mdx) -- [GKE](managed-public-cloud/gke.mdx) -- [IKS](managed-public-cloud/iks.mdx) -- [K3s](k3s/index.mdx) -- [kOps on AWS](self-managed-public-cloud/aws) -- [Kubernetes-kubeadm](self-managed-onprem/onpremises) -- [MicroK8s](microk8s) -- [minikube](minikube) -- [OpenShift](openshift/installation.mdx) -- [OpenStack](../openstack/overview.mdx) -- [RKE](rancher.mdx) -- [Calico for Windows](windows-calico/operator.mdx) - -## Community-tested versions and platforms - -This section is updated by $[prodname] community members. Please share what versions and platforms work for you. - -**To add an entry to "Works for me!"** - -1. Click **Edit this page** at the bottom of this page. -1. Submit a PR by adding a row to an existing table, or adding a new table for a different version. Note that **Community Member** is optional. - -:::note -- If your $[prodname] setup is not working, the best place to start is the Calico Users Slack channel (calicousers.slack.com) -- To report a doc bug: [tigera docs](https://github.com/tigera/docs/issues) -::: - -### Works for me! - -#### Calico 3.23 - -| Kubernetes version | Implementation | Date | Community member | -| -------------------------- | ------------------------------------ | ----------------- | ----------------------------------- | -| Kubespray 1.20.0 and later | Calico CNI and Calico network policy | November 22, 2022 | [yankay](https://github.com/yankay) | -| | | | | - -#### Calico 3.22 - -| Kubernetes version | Implementation | Date | Community member | -| -------------------------- | ------------------------------------ | ----------------- | ----------------------------------- | -| Kubespray 1.19.0 and later | Calico CNI and Calico network policy | November 22, 2022 | [yankay](https://github.com/yankay) | -| | | | | diff --git a/calico_versioned_docs/version-3.29/getting-started/kubernetes/flannel/index.mdx b/calico_versioned_docs/version-3.29/getting-started/kubernetes/flannel/index.mdx deleted file mode 100644 index 16fa32322f..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/kubernetes/flannel/index.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: Use Calico network policy on top of flannel networking. -hide_table_of_contents: true ---- - -# Flannel - -import DocCardList from '@theme/DocCardList'; -import { useCurrentSidebarCategory } from '@docusaurus/theme-common'; - - diff --git a/calico_versioned_docs/version-3.29/getting-started/kubernetes/flannel/install-for-flannel.mdx b/calico_versioned_docs/version-3.29/getting-started/kubernetes/flannel/install-for-flannel.mdx deleted file mode 100644 index 898d108434..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/kubernetes/flannel/install-for-flannel.mdx +++ /dev/null @@ -1,105 +0,0 @@ ---- -description: If you use flannel for networking, you can install Calico network policy to secure cluster communications. ---- - -# Install Calico for policy and flannel (aka Canal) for networking - -## Before you begin - -:::note - -Calico includes native VXLAN capabilities without the need for flannel. If you're planning on using flannel for VXLAN, we recommend instead installing Calico using IP-in-IP or VXLAN mode. See how to [determine the best networking option](../../../networking/determine-best-networking.mdx) for your cluster. -If you're already using flannel for networking, you can [migrate your existing clusters to Calico networking](migration-from-flannel.mdx). - -::: - -Ensure that you have a Kubernetes cluster that meets the -$[prodname] [system requirements](../requirements.mdx). If you don't, -follow the steps in [Installing kubeadm](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/). - -## Installing $[prodname] for policy and flannel (aka Canal) for networking - -### Selecting a datastore type - -The procedure differs according to your datastore type. Refer to the section that matches your type. - -- [Kubernetes API datastore](#installing-with-the-kubernetes-api-datastore-recommended) (recommended) - -- [etcd datastore](#installing-with-the-etcd-datastore) - -### Installing with the Kubernetes API datastore (recommended) - -1. Ensure that the Kubernetes controller manager has the following flags - set:
    - `--cluster-cidr=` and `--allocate-node-cidrs=true`. - - :::tip - - On kubeadm, you can pass `--pod-network-cidr=` - to kubeadm to set both Kubernetes controller flags. - - ::: - -1. Download the flannel networking manifest for the Kubernetes API datastore. - - ```bash - curl $[manifestsUrl]/manifests/canal.yaml -O - ``` - -1. If your cluster is configured to use pod CIDR `10.244.0.0/16`, skip to the next step. - If your cluster is configured to use a different pod CIDR, replace `10.244.0.0/16` in the downloaded manifest with the correct pod CIDR. - -1. Issue the following command to install $[prodname]. - - ```bash - kubectl apply -f canal.yaml - ``` - -1. If you wish to enforce application layer policies and secure workload-to-workload - communications with mutual TLS authentication, continue to [Enable application layer policy](../../../network-policy/istio/app-layer-policy.mdx) (optional). - -The geeky details of what you get: - - - -### Installing with the etcd datastore - -We strongly recommend using the Kubernetes API datastore, but if you prefer to use -etcd, complete the following steps. - -1. Download the $[prodname] networking manifest. - - ```bash - curl $[manifestsUrl]/manifests/canal-etcd.yaml -O - ``` - -1. If your cluster is configured to use pod CIDR `10.244.0.0/16`, skip to the next step. - If your cluster is configured to use a different pod CIDR, replace `10.244.0.0/16` in the downloaded manifest with the correct pod CIDR. - -1. In the `ConfigMap` named `calico-config`, set the value of - `etcd_endpoints` to the IP address and port of your etcd server. - - :::tip - - You can specify more than one using commas as delimiters. - - ::: - -1. Apply the manifest using the following command. - - ```bash - kubectl apply -f canal-etcd.yaml - ``` - -1. If you wish to enforce application layer policies and secure workload-to-workload - communications with mutual TLS authentication, continue to [Enable application layer policy](../../../network-policy/istio/app-layer-policy.mdx) (optional). - -The geeky details of what you get: - - diff --git a/calico_versioned_docs/version-3.29/getting-started/kubernetes/flannel/migration-from-flannel.mdx b/calico_versioned_docs/version-3.29/getting-started/kubernetes/flannel/migration-from-flannel.mdx deleted file mode 100644 index 1e90be7edc..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/kubernetes/flannel/migration-from-flannel.mdx +++ /dev/null @@ -1,218 +0,0 @@ ---- -description: Preserve your existing VXLAN networking in Calico, but take full advantage of Calico IP address management (IPAM) and advanced network policy features. ---- - -# Migrate a Kubernetes cluster from flannel/Canal to Calico - -## Big picture - -Migrate an existing Kubernetes cluster with flannel/Canal to $[prodname] networking. - -## Value - -If you are already using flannel for networking, it is easy to migrate to $[prodname]'s native VXLAN networking. $[prodname] VXLAN is fully equivalent to flannel vxlan, but you get the benefits of the broader range of features offered by $[prodname] with an active maintainer community. - -## Concepts - -### Limitations of host-local IPAM in flannel - -Flannel networking uses the host-local IPAM (IP address management) CNI plugin, which provides simple IP address management for your cluster. Although simple, it has limitations: - -- When you create a node, it is pre-allocated a CIDR. If the number of pods per-node exceeds the number of IP addresses available per node, you must recreate the cluster. Conversely, if the number of pods is much smaller than the number of addresses available per node, IP address space is not efficiently used; as you scale out and IP addresses are depleted, inefficiencies become a pain point. - -- Because each node has a pre-allocated CIDR, pods must always have an IP address assigned based on the node it is running on. Being able to allocate IP addresses based on other attributes (for example, the pod’s namespace), provides flexibility to meet use cases that arise. - -Migrating to $[prodname] IPAM solves these use cases and more. For advantages of Calico IPAM, see [Blog: Live Migration from Flannel to Calico](https://www.projectcalico.org/live-migration-from-flannel-to-calico/). - -### Methods for migrating to $[prodname] networking - -There are two ways to switch your cluster to use $[prodname] networking. Both methods give you a fully-functional $[prodname] cluster using VXLAN networking between pods. - -- **Create a new cluster using $[prodname] and migrate existing workloads** - - If you have the ability to migrate workloads from one cluster to the next without caring about downtime, this is the easiest method: [create a new cluster using $[prodname]](../quickstart.mdx). - -- **Live migration on an existing cluster** - - If your workloads are already in production, or downtime is not an option, use the live migration tool that performs a rolling update of each node in the cluster. - -## Before you begin... - -**Required** - -- A cluster with flannel for networking using the VXLAN backend. -- Flannel version v0.9.1 or higher (Canal version v3.7.0 or greater). -- Flannel must have been installed using a **Kubernetes daemon set** and configured: - - To use the Kubernetes API for storing its configuration (as opposed to etcd) - - With `DirectRouting` disabled (default) -- Cluster must allow for: - - Adding/deleting/modifying node labels - - Modifying and deleting of the flannel daemon set. For example, it must not be installed using the Kubernetes add-on manager. - -## How to - -- [Migrate from flannel networking to Calico networking, live migration](#migrate-from-flannel-networking-to-calico-networking-live-migration) -- [Modify flannel configuration](#modify-flannel-configuration) -- [View migration status](#view-migration-status) -- [View migration logs](#view-migration-logs) -- [Revert migration](#revert-migration) - -### Migrate from flannel networking to Calico networking, live migration - -1. Install $[prodname]. - - ```bash - kubectl apply -f $[manifestsUrl]/manifests/flannel-migration/calico.yaml - ``` - -1. Start the migration controller. - - ```bash - kubectl apply -f $[manifestsUrl]/manifests/flannel-migration/migration-job.yaml - ``` - - You will see nodes begin to update one at a time. - -1. Monitor the migration. - - ```bash - kubectl get jobs -n kube-system flannel-migration - ``` - - When the host node is upgraded, the migration controller may be rescheduled several times. The installation is complete when the output of the above command shows 1/1 completions. For example: - - ```bash - NAME COMPLETIONS DURATION AGE - flannel-migration 1/1 2m59s 5m9s - ``` - -1. Delete the migration controller. - - ```bash - kubectl delete -f $[manifestsUrl]/manifests/flannel-migration/migration-job.yaml - ``` - -1. Remove leftover flannel `iptables` rules from each node. - - The migration controller deletes the flannel network devices but leaves flannel's `iptables` chains (`FLANNEL-POSTRTG` in `nat`, `FLANNEL-FWD` in `filter`) in place. Their masquerade rule SNATs cross-node pod traffic, which breaks Kubernetes `NetworkPolicy` for policy-selected pods. Because flannel is no longer running, you only need to clear the chains once. Use either method: - - **Method 1: Reboot or replace nodes** - - Perform a rolling reboot (drain, reboot, uncordon each node in turn), or replace the nodes if you use immutable or managed node pools. The rules do not persist across a reboot, so no work on the nodes is needed. - - **Method 2: Remove the chains in place** - - Run the following on every node. It takes effect immediately without disrupting workloads, covers both the legacy and nft backends, and is safe to re-run: - - ```bash - for ipt in iptables-legacy iptables-nft ip6tables-legacy ip6tables-nft; do - command -v "$ipt" >/dev/null 2>&1 || continue - "$ipt" -w -t nat -D POSTROUTING -j FLANNEL-POSTRTG 2>/dev/null - "$ipt" -w -t nat -F FLANNEL-POSTRTG 2>/dev/null - "$ipt" -w -t nat -X FLANNEL-POSTRTG 2>/dev/null - "$ipt" -w -t filter -D FORWARD -j FLANNEL-FWD 2>/dev/null - "$ipt" -w -t filter -F FLANNEL-FWD 2>/dev/null - "$ipt" -w -t filter -X FLANNEL-FWD 2>/dev/null - done - ``` - -### Modify flannel configuration - -The migration controller autodetects your flannel configuration, and in most cases, does not require -additional configuration. If you require special configuration, the migration tool provides the following options, -which can be set as environment variables within the pod. - -| Configuration options | Description | Default | -| --------------------------- | ---------------------------------------------------------------- | ------------------------ | -| FLANNEL_NETWORK | IPv4 network CIDR used by flannel for the cluster. | Automatically detected | -| FLANNEL_IPV6_NETWORK | IPv6 network CIDR used by flannel for the cluster. | Automatically detected | -| FLANNEL_DAEMONSET_NAME | Name of the flannel daemon set. | kube-flannel-ds | -| FLANNEL_DAEMONSET_NAMESPACE | Namespace containing the flannel daemon. | kube-flannel | -| FLANNEL_MTU | MTU for the flannel VXLAN device. | Automatically detected | -| FLANNEL_IP_MASQ | Whether masquerading is enabled for outbound traffic. | Automatically detected | -| FLANNEL_SUBNET_LEN | Per-node IPv4 subnet length used by flannel. | 24 | -| FLANNEL_IPV6_SUBNET_LEN | Per-node IPv6 subnet length used by flannel. | 64 | -| FLANNEL_ANNOTATION_PREFIX | Value provided via the kube-annotation-prefix option to flannel. | flannel.alpha.coreos.com | -| FLANNEL_VNI | The VNI used for the flannel network. | 1 | -| FLANNEL_PORT | UDP port used for VXLAN. | 8472 | -| CALICO_DAEMONSET_NAME | Name of the calico daemon set in the kube-system namespace. | calico-node | -| CNI_CONFIG_DIR | Full path on the host in which to search for CNI config files. | /etc/cni/net.d | - -### View migration status - -View the controller's current status. - -```bash -kubectl get pods -n kube-system -l k8s-app=flannel-migration-controller -``` - -### View migration logs - -View migration logs to see if any actions are required. - -```bash -kubectl logs -n kube-system -l k8s-app=flannel-migration-controller -``` - -### Revert migration - -If you need to revert a cluster from $[prodname] back to flannel, follow these steps. - -1. Remove the migration controller and $[prodname]. - - ```bash - kubectl delete -f $[manifestsUrl]/manifests/flannel-migration/migration-job.yaml - kubectl delete -f $[manifestsUrl]/manifests/flannel-migration/calico.yaml - ``` - -1. Determine the nodes that were migrated to $[prodname]. - - ```bash - kubectl get nodes -l projectcalico.org/node-network-during-migration=calico - ``` - -Then, for each node found above, run the following commands to delete Calico. - -1. Cordon and drain the node. - - ```bash - kubectl drain - ``` - -1. Log in to the node and remove the CNI configuration. - - ```bash - rm /etc/cni/net.d/10-calico.conflist - ``` - -1. Reboot the node. - -1. Enable flannel on the node. - - ```bash - kubectl label node projectcalico.org/node-network-during-migration=flannel --overwrite - ``` - -1. Uncordon the node. - - ```bash - kubectl uncordon - ``` - -After the above steps have been completed on each node, perform the following steps. - -1. Remove the `nodeSelector` from the flannel daemonset. - - ```bash - kubectl patch ds/kube-flannel-ds -n kube-system -p '{"spec": {"template": {"spec": {"nodeSelector": null}}}}' - ``` - -1. Remove the migration label from all nodes. - - ```bash - kubectl label node --all projectcalico.org/node-network-during-migration- - ``` - -## Next steps - -Learn about [$[prodname] IP address management](../../../networking/ipam/index.mdx) diff --git a/calico_versioned_docs/version-3.29/getting-started/kubernetes/hardway/configure-bgp-peering.mdx b/calico_versioned_docs/version-3.29/getting-started/kubernetes/hardway/configure-bgp-peering.mdx deleted file mode 100644 index 959cd8c11c..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/kubernetes/hardway/configure-bgp-peering.mdx +++ /dev/null @@ -1,160 +0,0 @@ ---- -description: Quick review of BGP peering options. ---- - -# Configure BGP peering - -We have configured $[prodname] to distribute routing information over the -Border Gateway Protocol (BGP). This scalable protocol powers routing on the global -public Internet. - -In many on-premise data centers, each server connects to a top-of-rack (ToR) router -operating at the IP layer (layer 3). In that situation, we would need to peer each node -with its corresponding ToR router, so that the ToR learns routes to the containers. That -configuration is beyond the scope of this guide. - -Since we are running in an AWS VPC within a single subnet, the hosts have Ethernet (layer 2) -connectivity with one another, meaning there are no routers between them. Thus, they can peer -directly with each other. - -On one of the nodes in your cluster where you have `calicoctl` installed, check the status. - -```bash -sudo calicoctl node status -``` - -Result - -``` -Calico process is running. - -IPv4 BGP status -+---------------+-------------------+-------+----------+-------------+ -| PEER ADDRESS | PEER TYPE | STATE | SINCE | INFO | -+---------------+-------------------+-------+----------+-------------+ -| 172.31.40.217 | node-to-node mesh | up | 17:38:47 | Established | -| 172.31.40.30 | node-to-node mesh | up | 17:40:09 | Established | -| 172.31.45.29 | node-to-node mesh | up | 17:40:20 | Established | -| 172.31.37.123 | node-to-node mesh | up | 17:40:29 | Established | -+---------------+-------------------+-------+----------+-------------+ - -IPv6 BGP status -No IPv6 peers found. -``` - -Alternatively, you can create a [`CalicoNodeStatus` resource](../../../reference/resources/caliconodestatus.mdx) to get BGP session status for the node. - -Notice there are four BGP sessions, one to each other node in the cluster. In a small cluster, this -works well and is highly resilient. However, the total number of BGP sessions scales as the square -of the number of nodes, and in a large cluster this creates a lot of overhead. - -In this lab we will configure a fixed number of _route reflectors_. Route reflectors announce their -own routes and the routes they receive from other peers. This means nodes only need to peer with the -route reflectors to get all the routes in the cluster. This peering arrangement means that the number -of BGP sessions scales linearly with the number of nodes. - -## Choose and label nodes - -We will establish three route reflectors, which means we avoid a single point of failure even if we take down -a route reflector node for maintenance. In a five node cluster that means that only one BGP session is not -needed, since the two non-reflector nodes don't need to peer with one another, but it will save lots of overhead -in a large cluster. - -Choose three nodes and perform the following for each of them. - -Save the node YAML. - -```bash -calicoctl get node -o yaml --export > node.yaml -``` - -Edit the YAML to add - -```yaml -metadata: - labels: - calico-route-reflector: '' -spec: - bgp: - routeReflectorClusterID: 224.0.0.1 -``` - -Reapply the YAML - -```bash -calicoctl apply -f node.yaml -``` - -## Configure peering - -Configure all non-reflector nodes to peer with all route reflectors - -```bash -calicoctl apply -f - < pool1.yaml < pool2.yaml < diff --git a/calico_versioned_docs/version-3.29/getting-started/kubernetes/hardway/install-cni-plugin.mdx b/calico_versioned_docs/version-3.29/getting-started/kubernetes/hardway/install-cni-plugin.mdx deleted file mode 100644 index abe423b2ea..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/kubernetes/hardway/install-cni-plugin.mdx +++ /dev/null @@ -1,197 +0,0 @@ ---- -description: Steps to install the Calico Container Network Interface (CNI) ---- - -# Install CNI plugin - -Kubernetes uses the Container Network Interface (CNI) to interact with networking providers like $[prodname]. -The $[prodname] binary that presents this API to Kubernetes is called the **CNI plugin** and must be installed -on every node in the Kubernetes cluster. - -To understand how the Container Network Interface (CNI) works with Kubernetes, and how it enhances Kubernetes networking, read our [Kubernetes CNI guide](https://www.tigera.io/learn/guides/kubernetes-networking/kubernetes-cni/). - -## Provision Kubernetes user account for the plugin - -The CNI plugin interacts with the Kubernetes API server while creating pods, both to obtain additional information -and to update the datastore with information about the pod. - -On the Kubernetes control plane node, create a key for the CNI plugin to authenticate with and certificate signing request. - -```bash -openssl req -newkey rsa:4096 \ - -keyout cni.key \ - -nodes \ - -out cni.csr \ - -subj "/CN=calico-cni" -``` - -We will sign this certificate using the main Kubernetes CA. - -```bash -sudo openssl x509 -req -in cni.csr \ - -CA /etc/kubernetes/pki/ca.crt \ - -CAkey /etc/kubernetes/pki/ca.key \ - -CAcreateserial \ - -out cni.crt \ - -days 365 -sudo chown $(id -u):$(id -g) cni.crt -``` - -Next, we create a kubeconfig file for the CNI plugin to use to access Kubernetes. Copy this `cni.kubeconfig` file **to every node** in the cluster. - -```bash -APISERVER=$(kubectl config view -o jsonpath='{.clusters[0].cluster.server}') -kubectl config set-cluster kubernetes \ - --certificate-authority=/etc/kubernetes/pki/ca.crt \ - --embed-certs=true \ - --server=$APISERVER \ - --kubeconfig=cni.kubeconfig - -kubectl config set-credentials calico-cni \ - --client-certificate=cni.crt \ - --client-key=cni.key \ - --embed-certs=true \ - --kubeconfig=cni.kubeconfig - -kubectl config set-context default \ - --cluster=kubernetes \ - --user=calico-cni \ - --kubeconfig=cni.kubeconfig - -kubectl config use-context default --kubeconfig=cni.kubeconfig -``` - -## Provision RBAC - -Define a cluster role the CNI plugin will use to access Kubernetes. - -```bash -kubectl apply -f - < /etc/cni/net.d/10-calico.conflist < GET / HTTP/1.1 -> Host: calico-typha:5473 -> User-Agent: curl/7.81.0 -> Accept: */* -> -* TLSv1.2 (IN), TLS header, Unknown (21): -* TLSv1.2 (IN), TLS alert, close notify (256): -* Empty reply from server -* Closing connection 0 -* TLSv1.2 (OUT), TLS header, Unknown (21): -* TLSv1.2 (OUT), TLS alert, close notify (256): -curl: (52) Empty reply from server -``` - -This demonstrates that Typha is presenting its TLS certificate and accepting our connection when we presented with the `calico/node` certificate and key. - -## Provision RBAC - -Create the ServiceAccount that `calico/node` will run as - -```bash -kubectl create serviceaccount -n kube-system calico-node -``` - -Provision a cluster role with permissions to read and modify $[prodname] datastore objects - -```bash -kubectl apply -f - <` -1. Copy admin credentials -1. Test Access - - 1. Run - - `kubectl get nodes` - - Verify all nodes have joined. At this point nodes have joined but they are in `NotReady` state, because Kubernetes can't find a networking provider and configuration. - -## Next - -[The Calico datastore](the-calico-datastore.mdx) diff --git a/calico_versioned_docs/version-3.29/getting-started/kubernetes/hardway/test-network-policy.mdx b/calico_versioned_docs/version-3.29/getting-started/kubernetes/hardway/test-network-policy.mdx deleted file mode 100644 index 3d260dadd4..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/kubernetes/hardway/test-network-policy.mdx +++ /dev/null @@ -1,13 +0,0 @@ ---- -description: Verify that network policy works correctly. ---- - -# Test network policy - -In this lab we will test network policy. - -Follow the instructions in the [Simple policy tutorial](../../../network-policy/get-started/kubernetes-policy/kubernetes-policy-basic.mdx) to verify policy works correctly. - -## Next - -[End user RBAC](end-user-rbac.mdx) diff --git a/calico_versioned_docs/version-3.29/getting-started/kubernetes/hardway/test-networking.mdx b/calico_versioned_docs/version-3.29/getting-started/kubernetes/hardway/test-networking.mdx deleted file mode 100644 index 94b96b6144..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/kubernetes/hardway/test-networking.mdx +++ /dev/null @@ -1,172 +0,0 @@ ---- -description: Test that networking works correctly. ---- - -# Test networking - -In this lab we will test the $[prodname] cluster to demonstrate networking is working correctly. - -## Pod to pod pings - -Create three busybox instances - -```bash -kubectl create deployment pingtest --image=busybox --replicas=3 -- sleep infinity -``` - -Check their IP addresses - -```bash -kubectl get pods --selector=app=pingtest --output=wide -``` - -Result - -``` -NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES -pingtest-b4b6f8cf-b5z78 1/1 Running 0 3m28s 192.168.38.128 ip-172-31-37-123 -pingtest-b4b6f8cf-jmzq6 1/1 Running 0 3m28s 192.168.45.193 ip-172-31-40-217 -pingtest-b4b6f8cf-rn9nm 1/1 Running 0 3m28s 192.168.60.64 ip-172-31-45-29 -``` - -Note the IP addresses of the second two pods, then exec into the first one. For example - -```bash -kubectl exec -ti pingtest-b4b6f8cf-b5z78 -- sh -``` - -From inside the pod, ping the other two pod IP addresses. For example - -```bash -ping 192.168.45.193 -c 4 -``` - -Result - -``` -PING 192.168.45.193 (192.168.45.193): 56 data bytes -64 bytes from 192.168.45.193: seq=0 ttl=62 time=1.847 ms -64 bytes from 192.168.45.193: seq=1 ttl=62 time=0.684 ms -64 bytes from 192.168.45.193: seq=2 ttl=62 time=0.488 ms -64 bytes from 192.168.45.193: seq=3 ttl=62 time=0.442 ms - ---- 192.168.45.193 ping statistics --- -4 packets transmitted, 4 packets received, 0% packet loss -round-trip min/avg/max = 0.442/0.865/1.847 ms -``` - -## Check routes - -From one of the nodes, verify that routes exist to each of the `pingtest` pods' IP addresses. For example - -```bash -ip route get 192.168.38.128 -``` - -Result - -``` -192.168.38.128 via 172.31.37.123 dev eth0 src 172.31.42.47 uid 1000 - cache -``` - -The `via 172.31.37.123` in this example indicates the next-hop for this pod IP, which matches the IP address of the node the -pod is scheduled on, as expected. - -## IPAM allocations from different pools - -Recall that we created two IP pools, but left one disabled. - -```bash -calicoctl get ippools -o wide -``` - -Result - -``` -NAME CIDR NAT IPIPMODE VXLANMODE DISABLED SELECTOR -pool1 192.168.0.0/18 true Never Never false all() -pool2 192.168.192.0/19 true Never Never true all() -``` - -Enable the second pool. - -```bash -calicoctl apply -f - < -``` - -From one of the original pingtest pods, ping the IP address. - -```bash -ping 192.168.219.0 -c 4 -``` - -Result - -``` -PING 192.168.219.0 (192.168.219.0): 56 data bytes -64 bytes from 192.168.219.0: seq=0 ttl=62 time=0.524 ms -64 bytes from 192.168.219.0: seq=1 ttl=62 time=0.459 ms -64 bytes from 192.168.219.0: seq=2 ttl=62 time=0.505 ms -64 bytes from 192.168.219.0: seq=3 ttl=62 time=0.492 ms - ---- 192.168.219.0 ping statistics --- -4 packets transmitted, 4 packets received, 0% packet loss -round-trip min/avg/max = 0.459/0.495/0.524 ms -``` - -## Clean up - -```bash -kubectl delete deployments.apps pingtest -kubectl delete pod pingtest-pool2 -``` - -## Next - -[Test network policy](test-network-policy.mdx) diff --git a/calico_versioned_docs/version-3.29/getting-started/kubernetes/hardway/the-calico-datastore.mdx b/calico_versioned_docs/version-3.29/getting-started/kubernetes/hardway/the-calico-datastore.mdx deleted file mode 100644 index 45a802a4e5..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/kubernetes/hardway/the-calico-datastore.mdx +++ /dev/null @@ -1,109 +0,0 @@ ---- -description: The central datastore for your clusters' operational and configuration state. ---- - -# The Calico datastore - -$[prodname] stores the data about the operational and configuration state of your cluster in a central datastore. If the datastore is unavailable -your $[prodname] network continues operating, but cannot be updated (no new pods can be networked, no policy changes can be applied, etc.). - -$[prodname] has two datastore drivers you can choose from - -- **etcd** - for direct connection to an etcd cluster -- **Kubernetes** - for connection to a Kubernetes API server - -## Using Kubernetes as the datastore - -This guide uses the Kubernetes API datastore driver. The advantages of this driver when using $[prodname] on Kubernetes are - -- Doesn't require an extra datastore, so is simpler to manage -- You can use Kubernetes RBAC to control access to $[prodname] resources -- You can use Kubernetes audit logging to generate audit logs of changes to $[prodname] resources - -For completeness, the advantages of the etcd driver are - -- Allows you to run $[prodname] on non-Kubernetes platforms (e.g. OpenStack) -- Allows separation of concerns between Kubernetes and $[prodname] resources, for example allowing you to scale the datastores independently -- Allows you to run a $[prodname] cluster that contains more than just a single Kubernetes cluster, for example, bare metal servers with $[prodname] - host protection interworking with a Kubernetes cluster; or multiple Kubernetes clusters. - -## Custom Resources - -When using the Kubernetes API datastore driver, most $[prodname] resources are stored as [Kubernetes custom resources](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/). - -A few $[prodname] resources are not stored as custom resources and instead are backed by corresponding native Kubernetes resources. For example, [workload endpoints](../../../reference/resources/workloadendpoint.mdx) are Kubernetes pods. - -To use Kubernetes as the $[prodname] datastore, we need to define the custom resources $[prodname] uses. - -Download and examine the list of $[prodname] custom resource definitions, and open it in a file editor. - -```bash -wget $[manifestsUrl]/manifests/crds.yaml -``` - -Create the custom resource definitions in Kubernetes. - -```bash -kubectl apply -f crds.yaml -``` - -## calicoctl - -To interact directly with the $[prodname] datastore, use the `calicoctl` client tool. - -### Install - -1. Download the `calicoctl` binary to a Linux host with access to Kubernetes. - - ```bash - wget -O calicoctl https://github.com/projectcalico/calico/releases/latest/download/calicoctl-linux-amd64 - chmod +x calicoctl - sudo mv calicoctl /usr/local/bin/ - ``` - -1. Configure `calicoctl` to access Kubernetes. - - ```bash - export KUBECONFIG=/path/to/your/kubeconfig - export DATASTORE_TYPE=kubernetes - ``` - - On most systems, kubeconfig is located at `~/.kube/config`. You may wish to add the `export` lines to your `~/.bashrc` so they will persist when you log in next time. - -### Test - -Verify `calicoctl` can reach your datastore by running - -```bash -calicoctl get nodes -``` - -You should see output similar to - -```bash -NAME -ip-172-31-37-123 -ip-172-31-40-217 -ip-172-31-40-30 -ip-172-31-42-47 -ip-172-31-45-29 -``` - -Nodes are backed by the Kubernetes node object, so you should see names that match `kubectl get nodes`. - -Try to get an object backed by a custom resource - -```bash -calicoctl get ippools -``` - -You should see an empty result - -```bash -NAME CIDR SELECTOR - -``` - -## Next - -[Configure IP pools](configure-ip-pools.mdx) diff --git a/calico_versioned_docs/version-3.29/getting-started/kubernetes/helm.mdx b/calico_versioned_docs/version-3.29/getting-started/kubernetes/helm.mdx deleted file mode 100644 index 5427220ca4..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/kubernetes/helm.mdx +++ /dev/null @@ -1,121 +0,0 @@ ---- -description: Install Calico on a Kubernetes cluster using Helm 3. -title: Installing with Helm ---- - -# Install using Helm - -## Big picture - -Install $[prodname] on a Kubernetes cluster using Helm 3. - -## Value - -Helm charts are a way to package up an application for Kubernetes (similar to `apt` or `yum` for operating systems). Helm is also used by tools like ArgoCD to manage applications in a cluster, taking care of install, upgrade (and rollback if needed), etc. - -## Before you begin - -**Required** - -- Install Helm 3 -- Kubernetes cluster meets these requirements: - - Kubernetes is installed _without_ a CNI plugin **OR** cluster is running a compatible CNI for $[prodname] to run in policy-only mode - - x86-64, arm64, ppc64le, or s390x processors - - RedHat Enterprise Linux 7.x+, CentOS 7.x+, Ubuntu 18.04+, or Debian 9.x+ -- `kubeconfig` is configured to work with your cluster (check by running `kubectl get nodes`) -- $[prodname] can manage `cali` and `tunl` interfaces on the hosts. - If NetworkManager is present on the hosts, refer to - [Configure NetworkManager](../../operations/troubleshoot/troubleshooting.mdx#configure-networkmanager). - -## Concepts - -### Operator based installation - -In this guide, you install the Tigera Operator and custom resource definitions using the Helm 3 chart. The Tigera Operator provides lifecycle management for $[prodname] exposed via the Kubernetes API defined as a custom resource definition. - -## How to - -### Download the Helm chart - -1. Add the $[prodname] Helm repo: - -```bash -helm repo add projectcalico https://docs.tigera.io/calico/charts -``` - -### Customize the Helm chart - -If you are installing on a cluster installed by EKS, GKE, AKS or Mirantis Kubernetes Engine (MKE), or you need to customize TLS certificates, you **must** customize this Helm chart by creating a `values.yaml` file. Otherwise, you can skip this step. - -1. If you are installing on a cluster installed by EKS, GKE, AKS or Mirantis Kubernetes Engine (MKE), set the `kubernetesProvider` as described in the [Installation reference](../../reference/installation/api.mdx#provider). For example: - - ``` - echo '{ installation: {kubernetesProvider: EKS }}' > values.yaml - ``` - - For Azure AKS cluster with no Kubernetes CNI pre-installed, create `values.yaml` with the following command: - - ``` - cat > values.yaml < diff --git a/calico_versioned_docs/version-3.29/getting-started/kubernetes/k3s/multi-node-install.mdx b/calico_versioned_docs/version-3.29/getting-started/kubernetes/k3s/multi-node-install.mdx deleted file mode 100644 index bf6afa8584..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/kubernetes/k3s/multi-node-install.mdx +++ /dev/null @@ -1,222 +0,0 @@ ---- -description: Install Calico on a multi node K3s cluster for testing or development. ---- - -# K3s multi-node install - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - -## Big picture - -This tutorial gets you a multi node K3s cluster with $[prodname] in approximately 10 minutes. - -## Value - -K3s is a lightweight implementation of Kubernetes packaged as a single binary. - -The geeky details of what you get: - - - -## Before you begin - -- Make sure you have a linux host that meets the following requirements - - x86-64 processor - - 1CPU - - 1GB Ram - - 10GB free disk space - - Ubuntu 18.04 (amd64), Ubuntu 20.04 (amd64) - -:::note - -K3s supports ARM processors too, this tutorial was tested against x86-64 processor environment. -For more detail please visit [this link](https://rancher.com/docs/k3s/latest/en/installation/installation-requirements/#operating-systems). - -::: - -## How to - -### Initializing control plane instance - -K3s installation script can be modified by [environment variables](https://rancher.com/docs/k3s/latest/en/installation/install-options/#options-for-installation-with-script). Here you are providing some extra arguments to disable `flannel`, disable k3s default network policy and change the pod ip CIDR. - -:::note - -Full list of arguments can be viewed [at this link](https://rancher.com/docs/k3s/latest/en/installation/install-options/server-config/). - -::: - - curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="--flannel-backend=none --disable-network-policy --cluster-cidr=192.168.0.0/16" sh - - -:::caution - -If 192.168.0.0/16 is already in use within your network you must select a different pod network -CIDR by replacing 192.168.0.0/16 in the above command. - -::: - -### Enable remote access to your K3s instance - -To set up remote access to your cluster first ensure you have installed `kubectl` on your system. - -:::note - -If you are not sure how to install kubectl in your OS [visit this link](https://kubernetes.io/docs/tasks/tools/install-kubectl/). - -::: - -K3s stores a kubeconfig file in your server at `/etc/rancher/k3s/k3s.yaml`, copy all the content of `k3s.yaml` from your server into `~/.kube/config` on the system that you like to have remote access to the cluster. - -### Add extra nodes to K3s cluster - -To add additional nodes to your cluster you need two piece of information. - -- `K3S_URL` which is going to be your main node ip address. -- `K3S_TOKEN` which is stored in `/var/lib/rancher/k3s/server/node-token` file in main Node [(Step 1)](#initializing-control-plane-instance). - Execute following command in your node instance and join it to the cluster. - -:::note - -Remember to change `serverip` and `mytoken`. - -::: - -```bash -curl -sfL https://get.k3s.io | K3S_URL=https://serverip:6443 K3S_TOKEN=mytoken sh - -``` - -### Install $[prodname] - - - - -Install the $[prodname] operator and custom resource definitions. - -```bash -kubectl create -f $[manifestsUrl]/manifests/tigera-operator.yaml -``` - -:::note - -Due to the large size of the CRD bundle, `kubectl apply` might exceed request limits. Instead, use `kubectl create` or `kubectl replace`. - -::: - -Install $[prodname] by creating the necessary custom resource. For more information on configuration options available in this manifest, see [the installation reference](../../../reference/installation/api.mdx). - -```bash -kubectl create -f $[manifestsUrl]/manifests/custom-resources.yaml -``` - -:::note - -Before creating this manifest, read its contents and make sure its settings are correct for your environment. For example, -you may need to change the default IP pool CIDR to match your pod network CIDR. - -::: - - - - -Install $[prodname] by using the following command. - -```bash -kubectl apply -f $[manifestsUrl]/manifests/calico.yaml -``` - -:::note - -You can also -[view the YAML in a new tab]($[manifestsUrl]/manifests/calico.yaml). - -::: - -You should see the following output. - -``` - configmap/calico-config created - customresourcedefinition.apiextensions.k8s.io/bgpconfigurations.crd.projectcalico.org created - customresourcedefinition.apiextensions.k8s.io/bgppeers.crd.projectcalico.org created - customresourcedefinition.apiextensions.k8s.io/blockaffinities.crd.projectcalico.org created - customresourcedefinition.apiextensions.k8s.io/clusterinformations.crd.projectcalico.org created - customresourcedefinition.apiextensions.k8s.io/felixconfigurations.crd.projectcalico.org created - customresourcedefinition.apiextensions.k8s.io/globalnetworkpolicies.crd.projectcalico.org created - customresourcedefinition.apiextensions.k8s.io/globalnetworksets.crd.projectcalico.org created - customresourcedefinition.apiextensions.k8s.io/hostendpoints.crd.projectcalico.org created - customresourcedefinition.apiextensions.k8s.io/ipamblocks.crd.projectcalico.org created - customresourcedefinition.apiextensions.k8s.io/ipamconfigs.crd.projectcalico.org created - customresourcedefinition.apiextensions.k8s.io/ipamhandles.crd.projectcalico.org created - customresourcedefinition.apiextensions.k8s.io/ippools.crd.projectcalico.org created - customresourcedefinition.apiextensions.k8s.io/kubecontrollersconfigurations.crd.projectcalico.org created - customresourcedefinition.apiextensions.k8s.io/networkpolicies.crd.projectcalico.org created - customresourcedefinition.apiextensions.k8s.io/networksets.crd.projectcalico.org created - clusterrole.rbac.authorization.k8s.io/calico-kube-controllers created - clusterrolebinding.rbac.authorization.k8s.io/calico-kube-controllers created - clusterrole.rbac.authorization.k8s.io/calico-node created - clusterrolebinding.rbac.authorization.k8s.io/calico-node created - daemonset.apps/calico-node created - serviceaccount/calico-node created - deployment.apps/calico-kube-controllers created - serviceaccount/calico-kube-controllers created -``` - - - - -### Check the installation - -1. Confirm that all of the pods are running using the following command. - - - - -``` -NAMESPACE NAME READY STATUS RESTARTS AGE -tigera-operator tigera-operator-c9cf5b94d-gj9qp 1/1 Running 0 107s -calico-system calico-typha-7dcd87597-npqsf 1/1 Running 0 88s -calico-system calico-node-rdwwz 1/1 Running 0 88s -kube-system local-path-provisioner-6d59f47c7-4q8l2 1/1 Running 0 2m14s -kube-system metrics-server-7566d596c8-xf66d 1/1 Running 0 2m14s -kube-system coredns-8655855d6-wfdbm 1/1 Running 0 2m14s -calico-system calico-kube-controllers-89df8c6f8-7hxc5 1/1 Running 0 87s -``` - - - - -``` -NAMESPACE NAME READY STATUS RESTARTS AGE -kube-system $[noderunning]-9hn9z 1/1 Running 0 23m -kube-system local-path-provisioner-6d59f47c7-drznc 1/1 Running 0 38m -kube-system calico-kube-controllers-789f6df884-928lt 1/1 Running 0 23m -kube-system metrics-server-7566d596c8-qxlfz 1/1 Running 0 38m -kube-system coredns-8655855d6-blzl5 1/1 Running 0 38m -``` - - - - -1. Confirm that you now have two nodes in your cluster with the following command. - - ```bash - kubectl get nodes -o wide - ``` - - It should return something like the following. - - ``` - NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME - k3s-master Ready master 40m v1.18.2+k3s1 172.16.2.128 Ubuntu 18.04.3 LTS 4.15.0-101-generic containerd://1.3.3-k3s2 - k3s-node1 Ready 30m v1.18.2+k3s1 172.16.2.129 Ubuntu 18.04.3 LTS 4.15.0-101-generic containerd://1.3.3-k3s2 - ``` - -Congratulations! You now have a multi node K3s cluster -equipped with $[prodname] and Traefik. - -## Next steps - -- Try running the [Kubernetes Network policy demo](../../../network-policy/get-started/kubernetes-policy/kubernetes-demo.mdx) to see live graphical view of network policy in action diff --git a/calico_versioned_docs/version-3.29/getting-started/kubernetes/k3s/quickstart.mdx b/calico_versioned_docs/version-3.29/getting-started/kubernetes/k3s/quickstart.mdx deleted file mode 100644 index f947d3cc81..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/kubernetes/k3s/quickstart.mdx +++ /dev/null @@ -1,201 +0,0 @@ ---- -description: Install Calico on a single-node K3s cluster for testing or development in under 5 minutes. ---- - -# Quickstart for Calico on K3s - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - -## Big picture - -This quickstart gets you a single-node K3s cluster with $[prodname] -in approximately 5 minutes. You can use this cluster for testing and -development. - -## Value - -Use this quickstart to quickly and easily try $[prodname] features. To deploy a cluster suitable for production, refer to [Multi-node install](multi-node-install.mdx). - -The geeky details of what you get: - - - -## Before you begin - -- Make sure you have a linux host that meets the following requirements - - x86-64 processor - - 1CPU - - 1GB Ram - - 10GB free disk space - - Ubuntu 18.04 (amd64), Ubuntu 20.04 (amd64) - -:::note - -K3s supports ARM processors too, this quickstart was tested against x86-64 processor environment. -For more detail please visit [this link](https://rancher.com/docs/k3s/latest/en/installation/installation-requirements/#operating-systems). - -::: - -## How to - -### Create a single-node K3s cluster - -- Initialize the control plane using the following command: - -```bash -curl -sfL https://get.k3s.io | K3S_KUBECONFIG_MODE="644" INSTALL_K3S_EXEC="--flannel-backend=none --cluster-cidr=192.168.0.0/16 --disable-network-policy --disable=traefik" sh - -``` - -:::note - -- If 192.168.0.0/16 is already in use within your network you must select a different pod network -CIDR by replacing 192.168.0.0/16 in the above command. - -- K3s installer generates `kubeconfig` file in `etc` directory with limited permissions, using `K3S_KUBECONFIG_MODE` environment -you are assigning necessary permissions to the file and make it accessible for other users. - -::: - -### Install $[prodname] - - - - -1. Install the $[prodname] operator and custom resource definitions. - -```bash -kubectl create -f $[manifestsUrl]/manifests/tigera-operator.yaml -``` - -:::note - -Due to the large size of the CRD bundle, `kubectl apply` might exceed request limits. Therefore, it is recommended to use `kubectl create` or `kubectl replace`. - -::: - -2. Install $[prodname] by creating the necessary custom resource. For more information on configuration options available in this manifest, see [the installation reference](../../../reference/installation/api.mdx). - -```bash -kubectl create -f $[manifestsUrl]/manifests/custom-resources.yaml -``` - -:::note - -Before creating this manifest, read its contents and make sure its settings are correct for your environment. For example, -you may need to change the default IP pool CIDR to match your pod network CIDR. - -::: - - - - -Install $[prodname] by using the following command. - -```bash -kubectl apply -f $[manifestsUrl]/manifests/calico.yaml -``` - -:::note - -You can also -[view the YAML in a new tab]($[manifestsUrl]/manifests/calico.yaml). - -::: - -You should see the following output. - -``` - configmap/calico-config created - customresourcedefinition.apiextensions.k8s.io/bgpconfigurations.crd.projectcalico.org created - customresourcedefinition.apiextensions.k8s.io/bgppeers.crd.projectcalico.org created - customresourcedefinition.apiextensions.k8s.io/blockaffinities.crd.projectcalico.org created - customresourcedefinition.apiextensions.k8s.io/clusterinformations.crd.projectcalico.org created - customresourcedefinition.apiextensions.k8s.io/felixconfigurations.crd.projectcalico.org created - customresourcedefinition.apiextensions.k8s.io/globalnetworkpolicies.crd.projectcalico.org created - customresourcedefinition.apiextensions.k8s.io/globalnetworksets.crd.projectcalico.org created - customresourcedefinition.apiextensions.k8s.io/hostendpoints.crd.projectcalico.org created - customresourcedefinition.apiextensions.k8s.io/ipamblocks.crd.projectcalico.org created - customresourcedefinition.apiextensions.k8s.io/ipamconfigs.crd.projectcalico.org created - customresourcedefinition.apiextensions.k8s.io/ipamhandles.crd.projectcalico.org created - customresourcedefinition.apiextensions.k8s.io/ippools.crd.projectcalico.org created - customresourcedefinition.apiextensions.k8s.io/kubecontrollersconfigurations.crd.projectcalico.org created - customresourcedefinition.apiextensions.k8s.io/networkpolicies.crd.projectcalico.org created - customresourcedefinition.apiextensions.k8s.io/networksets.crd.projectcalico.org created - clusterrole.rbac.authorization.k8s.io/calico-kube-controllers created - clusterrolebinding.rbac.authorization.k8s.io/calico-kube-controllers created - clusterrole.rbac.authorization.k8s.io/calico-node created - clusterrolebinding.rbac.authorization.k8s.io/calico-node created - daemonset.apps/calico-node created - serviceaccount/calico-node created - deployment.apps/calico-kube-controllers created - serviceaccount/calico-kube-controllers created -``` - - - - -### Final checks - -1. Confirm that all of the pods are running using the following command. - -```bash -watch kubectl get pods --all-namespaces -``` - -2. Wait until each pod shows the `STATUS` of `Running`. - - - - -``` -NAMESPACE NAME READY STATUS RESTARTS AGE -tigera-operator tigera-operator-c9cf5b94d-gj9qp 1/1 Running 0 107s -calico-system calico-typha-7dcd87597-npqsf 1/1 Running 0 88s -calico-system calico-node-rdwwz 1/1 Running 0 88s -kube-system local-path-provisioner-6d59f47c7-4q8l2 1/1 Running 0 2m14s -kube-system metrics-server-7566d596c8-xf66d 1/1 Running 0 2m14s -kube-system coredns-8655855d6-wfdbm 1/1 Running 0 2m14s -calico-system calico-kube-controllers-89df8c6f8-7hxc5 1/1 Running 0 87s -``` - - - - -``` -NAMESPACE NAME READY STATUS RESTARTS AGE -kube-system $[noderunning]-9hn9z 1/1 Running 0 23m -kube-system local-path-provisioner-6d59f47c7-drznc 1/1 Running 0 38m -kube-system calico-kube-controllers-789f6df884-928lt 1/1 Running 0 23m -kube-system metrics-server-7566d596c8-qxlfz 1/1 Running 0 38m -kube-system coredns-8655855d6-blzl5 1/1 Running 0 38m -``` - - - - -3. Press CTRL+C to exit `watch`. - -4. Confirm that you now have a node in your cluster with the - following command. - -```bash -kubectl get nodes -o wide -``` - -It should return something like the following. - -``` -NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME -k3s-master Ready master 40m v1.18.2+k3s1 172.16.2.128 Ubuntu 18.04.3 LTS 4.15.0-101-generic containerd://1.3.3-k3s2 -``` - -Congratulations! You now have a single-node K3s cluster -equipped with $[prodname]. - -## Next steps - -- Try running the [Kubernetes Network policy demo](../../../network-policy/get-started/kubernetes-policy/kubernetes-demo.mdx) to see live graphical view of network policy in action diff --git a/calico_versioned_docs/version-3.29/getting-started/kubernetes/kind.mdx b/calico_versioned_docs/version-3.29/getting-started/kubernetes/kind.mdx deleted file mode 100644 index 255007b36f..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/kubernetes/kind.mdx +++ /dev/null @@ -1,195 +0,0 @@ ---- -description: Enable Calico on a single/multi-node Kind cluster for testing or development in approximately 10 minutes. -title: Installing on kind ---- - -# Kind multi-node install - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - -## Big picture - -This tutorial gets you a multi node Kind cluster with Calico in approximately 10 minutes. - -## Value - -kind is a tool for running local Kubernetes clusters using Docker container "nodes". - -The geeky details of what you get: - - - -## Before you begin - -- Ensure Docker is installed -- Install, but do not create cluster, kind. [How to install Kind](https://kind.sigs.k8s.io/docs/user/quick-start/#installation) -- Install kubectl.[How to install kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) - -## How to - -### Create a multi-node kind cluster - -KIND ships with a simple networking implementation ("kindnetd") based around standard CNI plugins (`ptp`, `host-local`, …) and simple netlink routes. You need to disable the default CNI to use Calico CNI. - -Kind cluster creation can be modified by [configuration file](https://kind.sigs.k8s.io/docs/user/quick-start/#creating-a-cluster). Here you are providing kind configuration to disable simple networking implementation (default CNI) and change the pod ip CIDR. - -1. Disable the default CNI to use Calico CNI by running the following command: - -```bash -cat > values.yaml < Ubuntu 22.04.1 LTS 5.10.0-17-amd64 containerd://1.6.7 -dev-worker NotReady 4m v1.25.0 172.18.0.4 Ubuntu 22.04.1 LTS 5.10.0-17-amd64 containerd://1.6.7 -dev-worker2 NotReady 4m v1.25.0 172.18.0.3 Ubuntu 22.04.1 LTS 5.10.0-17-amd64 containerd://1.6.7 -``` - -### Install $[prodname] - - - - -1. Install the $[prodname] operator and custom resource definitions. - -```bash -kubectl create -f $[manifestsUrl]/manifests/tigera-operator.yaml -``` - -2. Install $[prodname] by creating the necessary custom resource. For more information on configuration options available in this manifest, see [the installation reference](../../reference/installation/api.mdx). - -:::note - -Before creating this manifest, read its contents and make sure its settings are correct for your environment. For example, -if you have replaced `pod-network-cidr` you must change it in this file as well. - -::: - -```bash -kubectl create -f $[manifestsUrl]/manifests/custom-resources.yaml -``` - - - - -Install $[prodname] by using the following command. - -```bash -kubectl apply -f $[manifestsUrl]/manifests/calico.yaml -``` - -:::note - -Due to the large size of the CRD bundle, `kubectl apply` might exceed request limits. Instead, use `kubectl create` or `kubectl replace`. - -::: - -:::note - -You can also -[view the YAML in a new tab]($[manifestsUrl]/manifests/calico.yaml). - -::: - -You should see the following output. - -``` -configmap/calico-config created -customresourcedefinition.apiextensions.k8s.io/bgpconfigurations.crd.projectcalico.org created -customresourcedefinition.apiextensions.k8s.io/bgppeers.crd.projectcalico.org created -customresourcedefinition.apiextensions.k8s.io/blockaffinities.crd.projectcalico.org created -customresourcedefinition.apiextensions.k8s.io/clusterinformations.crd.projectcalico.org created -customresourcedefinition.apiextensions.k8s.io/felixconfigurations.crd.projectcalico.org created -customresourcedefinition.apiextensions.k8s.io/globalnetworkpolicies.crd.projectcalico.org created -customresourcedefinition.apiextensions.k8s.io/globalnetworksets.crd.projectcalico.org created -customresourcedefinition.apiextensions.k8s.io/hostendpoints.crd.projectcalico.org created -customresourcedefinition.apiextensions.k8s.io/ipamblocks.crd.projectcalico.org created -customresourcedefinition.apiextensions.k8s.io/ipamconfigs.crd.projectcalico.org created -customresourcedefinition.apiextensions.k8s.io/ipamhandles.crd.projectcalico.org created -customresourcedefinition.apiextensions.k8s.io/ippools.crd.projectcalico.org created -customresourcedefinition.apiextensions.k8s.io/kubecontrollersconfigurations.crd.projectcalico.org created -customresourcedefinition.apiextensions.k8s.io/networkpolicies.crd.projectcalico.org created -customresourcedefinition.apiextensions.k8s.io/networksets.crd.projectcalico.org created -clusterrole.rbac.authorization.k8s.io/calico-kube-controllers created -clusterrolebinding.rbac.authorization.k8s.io/calico-kube-controllers created -clusterrole.rbac.authorization.k8s.io/calico-node created -clusterrolebinding.rbac.authorization.k8s.io/calico-node created -daemonset.apps/calico-node created -serviceaccount/calico-node created -deployment.apps/calico-kube-controllers created -serviceaccount/calico-kube-controllers created -``` - - - - -### Verify $[prodname] installation - -You can verify $[prodname] installation in your cluster by issuing the following command. - -```bash -watch kubectl get pods -l k8s-app=calico-node -A -``` - -You should see a result similar to the below. Note that the namespace might be different, depending on the method you followed. - -``` -NAMESPACE NAME READY STATUS RESTARTS AGE -kube-system calico-node-2xcf4 1/1 Running 0 57s -kube-system calico-node-gkqkg 1/1 Running 0 57s -kube-system calico-node-j44hp 1/1 Running 0 57s - -``` - -Use `ctrl+c` to break out of watch. - -Congratulations you now have a Kind cluster equipped with $[prodname] - -### Clean up - -Issuing a delete command will destroy the cluster that you created in this tutorial. - -```bash -kind delete cluster --name dev -``` - -## Next steps - -**Required** - -- [Install and configure calicoctl](../../operations/calicoctl/install.mdx) - -**Recommended tutorials** - -- [Secure a simple application using the Kubernetes NetworkPolicy API](../../network-policy/get-started/kubernetes-policy/kubernetes-policy-basic.mdx) -- [Control ingress and egress traffic using the Kubernetes NetworkPolicy API](../../network-policy/get-started/kubernetes-policy/kubernetes-policy-advanced.mdx) -- [Run a tutorial that shows blocked and allowed connections in real time](../../network-policy/get-started/kubernetes-policy/kubernetes-demo.mdx) diff --git a/calico_versioned_docs/version-3.29/getting-started/kubernetes/managed-public-cloud/aks-migrate.mdx b/calico_versioned_docs/version-3.29/getting-started/kubernetes/managed-public-cloud/aks-migrate.mdx deleted file mode 100644 index d574d3b311..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/kubernetes/managed-public-cloud/aks-migrate.mdx +++ /dev/null @@ -1,161 +0,0 @@ ---- -description: Switch AKS clusters between Azure-managed and self-managed Calico -title: Migrating AKS clusters to self-managed Calico ---- - -# Migrate from Azure-managed Calico to self-managed Calico - -This page describes how to migrate your AKS cluster from using Azure-managed Calico for network policy to using self-managed Calico for network policy. Doing this gives you access to the all of Calico's network policy features, including global network policy, staged network policy, and policy tiers. - -## Understanding Azure- and self-managed Calico for policy on AKS - -### Azure-managed Calico on AKS - -Azure offers Calico as a managed option for network policy enforcement. -When you create an AKS cluster with `--network-policy calico`, Azure handles the installation and lifecycle of Calico's policy enforcement components. -This managed version provides a robust, supported implementation of the standard Kubernetes Network Policy API. -This is for users who need to enforce basic pod-to-pod communication rules, such as ingress and egress traffic based on pod labels and namespaces. -However, this managed service is limited to the features within that standard API. -You cannot change the Calico version, and you don't get access to Calico-specific custom resources or advanced features. - -## Self-managed Calico on AKS - -To access all of Calico's policy features, you must install it yourself on an AKS cluster. -You can do this on an existing AKS cluster by changing the network policy configuration (--network-policy none) and then deploying Calico using the Tigera Operator. -This approach gives you access to the Calico Network Policy API, which offers a richer set of features beyond the standard Kubernetes policies, including: - -- Global network policies: Rules that apply to all pods and endpoints across all namespaces, which is not possible with the standard Kubernetes Network Policy. -- Order and priority: The ability to order policies and apply explicit deny rules, giving you more granular control over traffic flow. -- Extended endpoint types: Calico policies can be applied to endpoints beyond just pods, such as host interfaces and VMs. - -The key distinction is that the managed Azure version gives you a simple, hands-off experience for basic policy, while a self-managed installation gives you complete control and access to all of Calico's advanced network security features. - -## Prerequisites - -You have an AKS cluster that uses Azure-managed Calico for network policy. -To confirm that your cluster has this configuration, run the following command: - -```bash -az aks show --name my-calico-cluster --resource-group my-calico-rg \ - --query "networkProfile.networkPlugin, networkProfile.networkPolicy" -``` - -```bash title='Expected output' -[ - "azure", - "calico" -] -``` - -:::warning -Application connectivity may be disrupted during the migration - -Network policy will be removed during the migration and must be re-applied after the migration. -::: - -## Migrate from Azure-managed Calico to self-managed Calico - -During this migration, you will save your current network policies, remove the Azure-managed Calico, install a self-managed Calico, and then reapply your network policies. - -1. Get all existing network policies from all namespaces and write them out to a file: - - ```bash - kubectl get netpol -A -o yaml > network-policy.yaml - ``` - - Review the file to make sure it contains all the policies you expect to be there. - -1. Remove the Azure-managed Calico by modifying the AKS cluster configuration: - - ```bash - az aks update \ - --name my-calico-cluster \ - --resource-group my-calico-rg \ - --network-policy=none - ``` - -1. Verify the new configuration: - - ```bash - az aks show --name my-calico-cluster --resource-group my-calico-rg \ - --query "networkProfile.networkPlugin, networkProfile.networkPolicy" - ``` - - ```bash title='Expected output' - [ - "azure", - "none" - ] - ``` - -1. Install $[prodname]. - Note that, unlike most Calico installs, we do not install CRDs here because they may already exist. Operator will check and create any missing ones. - - ```bash - kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.30.3/manifests/tigera-operator.yaml - ``` - -1. Complete the installation by providing the configuration for $[prodname] - - ```bash - kubectl create -f - < - -1. To create a cluster with Azure-managed Calico for policy, run the following command: - ```bash - # Create a resource group - az group create --name my-calico-rg --location westcentralus - az aks create \ - --resource-group my-calico-rg \ - --name my-calico-cluster \ - --location westcentralus \ - --pod-cidr 192.168.0.0/16 \ - --network-plugin azure \ - --network-policy calico - ``` - -## Install AKS with Azure CNI for networking and self-managed Calico for network policy - -The geeky details of what you get: - - - -1. Create an Azure AKS cluster with Azure CNI for networking and no configuration for network policy: - - ```bash - # Create a resource group - az group create --name my-calico-rg --location westcentralus - az aks create \ - --resource-group my-calico-rg \ - --name my-calico-cluster \ - --location westcentralus \ - --pod-cidr 192.168.0.0/16 \ - --network-plugin azure \ - --network-policy none - ``` - -1. Get credentials to allow you to access the cluster with `kubectl`: - - ```bash - az aks get-credentials --resource-group my-calico-rg --name my-calico-cluster - ``` - - Now that you have a cluster configured, you can install $[prodname]. - -1. Install the Tigera Operator and custom resource definitions: - - ```bash - kubectl create -f $[manifestsUrl]/manifests/operator-crds.yaml - kubectl create -f $[manifestsUrl]/manifests/tigera-operator.yaml - ``` - -1. Complete the installation by providing the configuration for $[prodname] - - ```bash - kubectl create -f - < - -1. Create an Azure AKS cluster with no Kubernetes CNI pre-installed. Please refer to [Bring your own CNI with AKS](https://docs.microsoft.com/en-us/azure/aks/use-byo-cni?tabs=azure-cli) for details. - - ```bash - # Create a resource group - az group create --name my-calico-rg --location westcentralus - az aks create \ - --resource-group my-calico-rg \ - --name my-calico-cluster \ - --location westcentralus \ - --pod-cidr 192.168.0.0/16 \ - --network-plugin none - ``` - -1. Get credentials to allow you to access the cluster with `kubectl`: - - ```bash - az aks get-credentials --resource-group my-calico-rg --name my-calico-cluster - ``` - -1. Now that you have a cluster configured, you can install $[prodname]. - -1. Install the Tigera Operator and custom resource definitions. - - ```bash - kubectl create -f $[manifestsUrl]/manifests/operator-crds.yaml - kubectl create -f $[manifestsUrl]/manifests/tigera-operator.yaml - ``` - -1. Complete the installation by providing the configuration for $[prodname] - - ```bash - kubectl create -f - < - -:::note - -When using the Amazon VPC CNI plugin, $[prodname] does not support enforcement of network policy on IPv6 pods with `ENABLE_V4_EGRESS` set to `true`. - -::: - - -1. First, create an Amazon EKS cluster. - - ```bash - eksctl create cluster --name - ``` - - Do **not** enable [network policy for the AWS VPC CNI](https://docs.aws.amazon.com/eks/latest/userguide/network-policy-disable.html); it conflicts with $[prodname]. - -1. Configure AWS VPC CNI to [annotate Pods with their IPs](https://github.com/aws/amazon-vpc-cni-k8s?tab=readme-ov-file#annotate_pod_ip-v193). - Note the requirement to grant the "patch" permission to the `aws-node` daemon set to avoid permission errors. - This setting ensures that pod IPs propagate quickly from AWS VPC CNI to $[prodname]. - - ```bash - cat << EOF > append.yaml - - apiGroups: - - "" - resources: - - pods - verbs: - - patch - EOF - kubectl apply -f <(cat <(kubectl get clusterrole aws-node -o yaml) append.yaml) - kubectl set env -n kube-system daemonset/aws-node ANNOTATE_POD_IP=true - ``` - -1. Install the operator. - - ```bash - kubectl create -f $[manifestsUrl]/manifests/tigera-operator.yaml - ``` - -1. Configure the $[prodname] installation. - - ```bash - kubectl create -f - < Ready master 52m v1.12.2 10.128.0.28 Ubuntu 18.04.1 LTS 4.15.0-1023-gcp docker://18.6.1 - ``` - -### Install EKS with $[prodname] networking - -The geeky details of what you get: - - - -:::note - -$[prodname] networking cannot currently be installed on the EKS control plane nodes. As a result the control plane nodes -will not be able to initiate network connections to $[prodname] pods. (This is a general limitation of EKS's custom networking support, -not specific to $[prodname].) As a workaround, trusted pods that require control plane nodes to connect to them, such as those implementing -admission controller webhooks, can include `hostNetwork:true` in their pod spec. See the Kubernetes API -[pod spec](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec) -definition for more information on this setting. - -::: - -For these instructions, we will use `eksctl` to provision the cluster. However, you can use any of the methods in [Getting Started with Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html) - -Before you get started, make sure you have downloaded and configured the [necessary prerequisites](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html#eksctl-prereqs) - -1. First, create an Amazon EKS cluster without any nodes. - - ```bash - eksctl create cluster --name my-calico-cluster --without-nodegroup - ``` - -1. Since this cluster will use $[prodname] for networking, you must delete the `aws-node` daemon set to disable AWS VPC networking for pods. - - ```bash - kubectl delete daemonset -n kube-system aws-node - ``` - -1. Now that you have a cluster configured, you can install $[prodname]. - - - - -1. Install the operator. - - ```bash - kubectl create -f $[manifestsUrl]/manifests/tigera-operator.yaml - ``` - -1. Configure the $[prodname] installation. - - ```bash - kubectl create -f - < --node-type t3.medium --max-pods-per-node 100 - ``` - - - - -1. Install the $[prodname] manifest. - - ```bash - kubectl apply -f $[manifestsUrl]/manifests/calico-vxlan.yaml - ``` - -1. Configure $[prodname] to disable AWS src/dst checks. - - ```bash - kubectl -n kube-system set env daemonset/calico-node FELIX_AWSSRCDSTCHECK=Disable - ``` - -1. Finally, add nodes to the cluster. - - ```bash - eksctl create nodegroup --cluster my-calico-cluster --node-type t3.medium --max-pods-per-node 100 - ``` - - - - -1. Add $[prodname] into your Helm repository. - - ```batch - helm repo add projectcalico https://docs.tigera.io/calico/charts - ``` - -1. If $[prodname] is already added, update it to get the latest released version. - - ```batch - helm repo update - ``` - -1. Create the `tigera-operator` namespace. - - ```bash - kubectl create namespace tigera-operator - ``` - -1. Install version $[releaseTitle] of the $[prodname] operator and custom resource definitions. - - ```batch - helm install calico projectcalico/tigera-operator --version $[releaseTitle] --namespace tigera-operator - ``` - -1. Patch the CNI type with value `Calico`. - - ```batch - kubectl patch installation default --type='json' -p='[{"op": "replace", "path": "/spec/cni", "value": {"type":"Calico"} }]' - ``` - -1. Finally, add nodes to the cluster. - - ```batch - eksctl create nodegroup --cluster my-calico-cluster --node-type t3.medium --max-pods-per-node 100 - ``` - - - - -:::tip - - Without the `--max-pods-per-node` option above, EKS will limit the [number of pods based on node-type](https://github.com/awslabs/amazon-eks-ami/blob/main/nodeadm/internal/kubelet/eni-max-pods.txt). See `eksctl create nodegroup --help` for the full set of node group options. - -::: - -## Next steps - -**Required** - -- [Install calicoctl command line tool](../../../operations/calicoctl/install.mdx) - -**Recommended** - -- [Get started with Kubernetes network policy](../../../network-policy/get-started/kubernetes-policy/kubernetes-network-policy.mdx) -- [Get started with $[prodname] network policy](../../../network-policy/get-started/calico-policy/calico-network-policy.mdx) -- [Enable default deny for Kubernetes pods](../../../network-policy/get-started/kubernetes-default-deny.mdx) diff --git a/calico_versioned_docs/version-3.29/getting-started/kubernetes/managed-public-cloud/gke.mdx b/calico_versioned_docs/version-3.29/getting-started/kubernetes/managed-public-cloud/gke.mdx deleted file mode 100644 index 425ca2ad53..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/kubernetes/managed-public-cloud/gke.mdx +++ /dev/null @@ -1,77 +0,0 @@ ---- -description: Enable Calico network policy in GKE. -title: Installing on GKE ---- - -# Install Calico network policy on a Google Kubernetes Engine cluster - -Google Kubernetes Engine (GKE) has built-in support for $[prodname], providing a robust implementation of the full Kubernetes Network Policy API. -GKE users wanting to go beyond Kubernetes network policy capabilities can make full use of the $[prodname] Network Policy API. - -You can install Calico network policy by enabling it as you create a new GKE cluster. - -The geeky details of what you get: - - - -## Prerequisites - -* You have a Google Cloud account, an active project, and permissions for creating clusters. -* You installed and configured the gcloud and kubectl CLIs on your workstation. - -## Create a GKE cluster with Calico enabled for network policy - -1. Create a new GKE cluster with network policy by running the following command: - - ```bash - gcloud container clusters create --enable-network-policy - ``` - - This may take several minutes to complete. - -1. Verify that the Calico pods are running in your cluster by entering the following command: - - ```bash - kubectl get pods -n kube-system - ``` - Example output: - ```bash - NAME READY STATUS RESTARTS AGE - calico-node-hjnt5 1/1 Running 0 13m - calico-node-phcjw 1/1 Running 0 13m - calico-node-pmrkm 1/1 Running 0 12m - calico-node-vertical-autoscaler-8c79c8dc-q7z7c 1/1 Running 0 15m - calico-typha-547bf5ddbd-8jlnt 1/1 Running 0 13m - calico-typha-547bf5ddbd-d2qjd 1/1 Running 0 13m - calico-typha-horizontal-autoscaler-7d99b54d8b-f9fq6 1/1 Running 0 15m - calico-typha-vertical-autoscaler-bbdb9bc58-wsd6v 1/1 Running 0 15m - event-exporter-gke-545bc64577-rmgkn 2/2 Running 0 15m - fluentbit-gke-8p8tc 3/3 Running 0 14m - ... - ``` - -## Additional resources - -For complete GKE requirements, limitations, and other installation methods, see [Enable network policy enforcement](https://docs.cloud.google.com/kubernetes-engine/docs/how-to/network-policy#enabling_network_policy_enforcement). - -:::note - -GKE documentation does not always refer to Calico by name. -For clusters using Dataplane V1, references to "network policy" often describe integrated Calico network policy. - -::: - -## Next steps - -**Required** - -- [Install calicoctl command line tool](../../../operations/calicoctl/install.mdx) - -**Recommended** - -- [Get started with Kubernetes network policy](../../../network-policy/get-started/kubernetes-policy/kubernetes-network-policy.mdx) -- [Get started with Calico network policy](../../../network-policy/get-started/calico-policy/calico-network-policy.mdx) -- [Enable default deny for Kubernetes pods](../../../network-policy/get-started/kubernetes-default-deny.mdx) diff --git a/calico_versioned_docs/version-3.29/getting-started/kubernetes/managed-public-cloud/iks.mdx b/calico_versioned_docs/version-3.29/getting-started/kubernetes/managed-public-cloud/iks.mdx deleted file mode 100644 index 286a04aef1..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/kubernetes/managed-public-cloud/iks.mdx +++ /dev/null @@ -1,37 +0,0 @@ ---- -description: Use IKS with built-in support for Calico networking and network policy. -title: Installing on IKS ---- - -# IBM Cloud Kubernetes Service (IKS) - -## Big picture - -Enable $[prodname] in IKS managed Kubernetes service. - -## Value - -IKS has built-in support for $[prodname], providing a robust implementation of the full Kubernetes Network Policy API. IKS users wanting to go beyond Kubernetes network policy capabilities can make full use of the $[prodname] Network Policy API. In addition to using $[prodname] to secure Kubernetes pods, IKS also uses $[prodname] host endpoint capabilities to provide additional security for the nodes in your cluster. - -## How to - -$[prodname] networking and network policy are automatically installed and configured in your [IBM Cloud Kubernetes Service](https://www.ibm.com/products/kubernetes-service/). Default policies are created to protect your Kubernetes cluster, with the option to create your own policies to protect specific services. - -The geeky details of what you get: - - - -## Next steps - -**Required** - -- [Install calicoctl command line tool](../../../operations/calicoctl/install.mdx) - -**Recommended** - -- [Controlling traffic with network policies for IKS](https://cloud.ibm.com/docs/containers?topic=containers-network_policies) -- [Get started with Kubernetes network policy](../../../network-policy/get-started/kubernetes-policy/kubernetes-network-policy.mdx) -- [Get started with Calico network policy](../../../network-policy/get-started/calico-policy/calico-network-policy.mdx) diff --git a/calico_versioned_docs/version-3.29/getting-started/kubernetes/microk8s.mdx b/calico_versioned_docs/version-3.29/getting-started/kubernetes/microk8s.mdx deleted file mode 100644 index 0fcc4f8eb4..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/kubernetes/microk8s.mdx +++ /dev/null @@ -1,81 +0,0 @@ ---- -description: Install Calico on a single-host MicroK8s cluster for testing or development in under 5 minutes. -title: "Tutorial: Quickstart on Microk8s" ---- - -# Quickstart for Calico on MicroK8s - -## Big picture - -Install a single node MicroK8s cluster with $[prodname] in approximately 5 minutes. - -## Value - -MicroK8s is a lightweight upstream Kubernetes distribution package to run as an immutable container. - -Use this quickstart to quickly and easily try $[prodname] features with MicroK8s. - -## Before you begin - -- Make sure you have a linux host that meets the following requirements: - - 4GB RAM - - 20GB free disk space - - Ubuntu 20.04 LTS, 18.04 LTS or 16.04 LTS (or another operating system that supports `snapd`) - -## How to - -1. Initialize the node using the following command. - - ``` - snap install microk8s --classic - ``` - - :::note - - You can check out other versions of Kubernetes MicroK8s implementation published in snap using `snap info microk8s` command. - - ::: - -1. Enable dns services. - - ``` - microk8s enable dns - ``` - -1. Check your cluster status - - ``` - microk8s kubectl get pods -A - ``` - - You should see a result similar to - - ``` - NAMESPACE NAME READY STATUS RESTARTS AGE - kube-system calico-node-b82zp 1/1 Running 0 64s - kube-system calico-kube-controllers-555fc8cc5c-b7cp6 1/1 Running 0 64s - kube-system coredns-588fd544bf-mbc7n 1/1 Running 0 39s - ``` - -The geeky details of what you get: - - - -## Next steps - -**Required** - -- [Install and configure calicoctl](../../operations/calicoctl/install.mdx) - -**Optional** - -- [Add another node to form a multi-node cluster](https://microk8s.io/docs/clustering) - -**Recommended tutorials** - -- [Secure a simple application using the Kubernetes NetworkPolicy API](../../network-policy/get-started/kubernetes-policy/kubernetes-policy-basic.mdx) -- [Control ingress and egress traffic using the Kubernetes NetworkPolicy API](../../network-policy/get-started/kubernetes-policy/kubernetes-policy-advanced.mdx) -- [Run a tutorial that shows blocked and allowed connections in real time](../../network-policy/get-started/kubernetes-policy/kubernetes-demo.mdx) diff --git a/calico_versioned_docs/version-3.29/getting-started/kubernetes/minikube.mdx b/calico_versioned_docs/version-3.29/getting-started/kubernetes/minikube.mdx deleted file mode 100644 index bf974ebb59..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/kubernetes/minikube.mdx +++ /dev/null @@ -1,159 +0,0 @@ ---- -description: Enable Calico on a single/multi-node minikube cluster for testing or development in under 1 minute. -title: "Tutorial: Quickstart on minikube" ---- - -# Quickstart for Calico on minikube - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - -## Big picture - -This quickstart gets you a single-node minikube cluster with $[prodname] -in approximately 1 minute. You can use this cluster for testing and -development. - -## Value - -Use this quickstart to quickly and easily try $[prodname] features. - -## Before you begin - -- Install, but do not start, minikube. [How to install minikube](https://minikube.sigs.k8s.io/docs/start/#what-youll-need) -- Install kubectl.[How to install kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) -- Install a minikube driver. For example Docker. A full List of available drivers can be [found here.](https://minikube.sigs.k8s.io/docs/drivers/) - -## How to - -### Create a single-node minikube cluster - - - - -Minikube offers a built-in $[prodname] implementation, this is a quick way to checkout $[prodname] features. - -:::note - -Enabling preinstalled $[prodname] might be the quickest way for testing. However, if you like to checkout a more recent version or features of $[prodname] you should consider using Manifest or Operator approach. - -::: - -```bash -minikube start --cni=calico -``` - - - - -1. Start your minikube cluster with one control plane node using the following command. - - :::note - - If `192.168.0.0/16` is already in use within your network you must select a different pod network CIDR, by replacing `192.168.0.0/16` in the following command. - - ::: - - ```bash - minikube start --cni=false --network-plugin=cni --extra-config=kubeadm.pod-network-cidr=192.168.0.0/16 --subnet=172.16.0.0/24 - ``` - -2. Install the Tigera Operator and custom resource definitions. - - ```bash - kubectl create -f $[manifestsUrl]/manifests/tigera-operator.yaml - ``` - - :::note - - Due to the large size of the CRD bundle, `kubectl apply` might exceed request limits. Instead, use `kubectl create` or `kubectl replace`. - - ::: - -3. Install $[prodname] by creating the necessary custom resource. For more information on configuration options available in this manifest, see [the installation reference](../../reference/installation/api.mdx). - - :::note - - Before creating this manifest, read its contents and make sure its settings are correct for your environment. For example, - if you have replaced `pod-network-cidr` you must change it in this file as well. - - ::: - - ```bash - kubectl create -f $[manifestsUrl]/manifests/custom-resources.yaml - ``` - - - - -Start your minikube cluster with one control plane node using the following command: - -```bash -minikube start --network-plugin=cni -``` - -Install $[prodname]. - -```bash -kubectl apply -f $[manifestsUrl]/manifests/calico.yaml -``` - - - - -### Verify $[prodname] installation - -Verify $[prodname] installation in your cluster using the following command: - -```bash -watch kubectl get pods -l k8s-app=calico-node -A -``` - -You should see a result similar to the below. Note that the namespace might be different, depending on the method you followed. - -``` -NAMESPACE NAME READY STATUS RESTARTS AGE -kube-system calico-node-mlqvs 1/1 Running 0 5m18s -``` - -Use `ctrl+c` to break out of watch. - -Congratulations you now have a minikube cluster equipped with $[prodname] - -### Add an additional worker node - -:::note - -This as an optional step, you can safely skip this step if you do not require an additional worker node. - -::: - -```bash -minikube node add -``` - -Verify nodes using the following command: - -```bash -kubectl get nodes -``` - -### Clean up - -Delete the cluster using the following command: - -```bash -minikube delete -``` - -## Next steps - -**Required** - -- [Install and configure calicoctl](../../operations/calicoctl/install.mdx) - -**Recommended tutorials** - -- [Secure a simple application using the Kubernetes NetworkPolicy API](../../network-policy/get-started/kubernetes-policy/kubernetes-policy-basic.mdx) -- [Control ingress and egress traffic using the Kubernetes NetworkPolicy API](../../network-policy/get-started/kubernetes-policy/kubernetes-policy-advanced.mdx) -- [Run a tutorial that shows blocked and allowed connections in real time](../../network-policy/get-started/kubernetes-policy/kubernetes-demo.mdx) diff --git a/calico_versioned_docs/version-3.29/getting-started/kubernetes/nftables.mdx b/calico_versioned_docs/version-3.29/getting-started/kubernetes/nftables.mdx deleted file mode 100644 index efa9f5cc49..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/kubernetes/nftables.mdx +++ /dev/null @@ -1,212 +0,0 @@ ---- -description: Install Calico using the nftables data plane. -title: "Data plane guide: nftables" ---- - -# Calico nftables data plane - -:::note - -This feature is tech preview. Tech preview features may be subject to significant changes before they become GA. - -::: - -## Big picture - -Install $[prodname] using the nftables data plane. - -## Value - -Kubernetes introduced a beta status [kube-proxy Service implementation based on nftables](https://kubernetes.io/docs/reference/networking/virtual-ips/#proxy-mode-nftables) -in Kubernetes v1.31 which promises better performance than the default iptables implementation. -Installing $[prodname] in nftables mode provides a networking and network policy implementation that is compatible with the upstream nftables kube-proxy. - -:::important - -To use Calico in nftables mode, your cluster's kube-proxy must also be in nftables mode. -```yaml title="Example KubeProxyConfiguration resource" -apiVersion: kubeproxy.config.k8s.io/v1alpha1 -kind: KubeProxyConfiguration -mode: nftables -``` -::: - - -## Before you begin - -**Required** - -- A Linux host that meets the following requirements: - - - x86-64, arm64, ppc64le, or s390x processor - - 2CPU - - 2GB RAM - - 10GB free disk space - - Linux kernel version 5.13 or later with `nft` >= 1.0.1 - -- $[prodname] can manage `cali` and `tunl` interfaces on the host - - If NetworkManager is present on the host, see [Configure NetworkManager](../../operations/troubleshoot/troubleshooting.mdx#configure-networkmanager). - -## How to - -### Create a single-host Kubernetes cluster with the nftables kube-proxy enabled. - -1. [Follow the Kubernetes instructions to install kubeadm](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/) - - :::note - - After installing kubeadm, do not power down or restart - the host. Instead, continue directly to the next step. - - ::: - -1. As a regular user with sudo privileges, open a terminal on the host that you installed kubeadm on. - -1. Create a kubeadm configuration file that enables the nftables kube-proxy mode. - - ```bash - cat > config.yaml < custom-resources.yaml < untainted - ``` - -1. Confirm that you now have a node in your cluster with the following command. - - ```bash - kubectl get nodes -o wide - ``` - - It should return something like the following. - - ``` - NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME - Ready master 52m v1.12.2 10.128.0.28 Ubuntu 18.04.1 LTS 4.15.0-1023-gcp docker://18.6.1 - ``` - -Congratulations! You now have a single-host Kubernetes cluster with $[prodname] in nftables mode. - -## Next steps - -**Required** - -- [Install and configure calicoctl](../../operations/calicoctl/install.mdx) - -**Recommended tutorials** - -- [Secure a simple application using the Kubernetes NetworkPolicy API](../../network-policy/get-started/kubernetes-policy/kubernetes-policy-basic.mdx) -- [Control ingress and egress traffic using the Kubernetes NetworkPolicy API](../../network-policy/get-started/kubernetes-policy/kubernetes-policy-advanced.mdx) -- [Run a tutorial that shows blocked and allowed connections in real time](../../network-policy/get-started/kubernetes-policy/kubernetes-demo.mdx) -- [Hands-on workshop: Learn the basics of Calico, and Kubernetes.](https://www.tigera.io/tutorials/?_sf_s=Calico%20Basics) diff --git a/calico_versioned_docs/version-3.29/getting-started/kubernetes/openshift/hostedcontrolplanes.mdx b/calico_versioned_docs/version-3.29/getting-started/kubernetes/openshift/hostedcontrolplanes.mdx deleted file mode 100644 index a8dc56c0f0..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/kubernetes/openshift/hostedcontrolplanes.mdx +++ /dev/null @@ -1,188 +0,0 @@ ---- -description: Install Calico on an OpenShift Hosted Control Planes (HCP) cluster. ---- - -# Install Calico on an OpenShift HCP cluster - -import DownloadOpenShiftManifests from '@site/calico_versioned_docs/version-3.29/_includes/components/DownloadOpenShiftManifests.js'; - -## Big picture - -Install $[prodname] on an OpenShift Hosted Control Planes (HCP) cluster. - -## Value - -Provides steps to install $[prodname] in [OpenShift Hosted Control Planes (HCP)](https://docs.openshift.com/container-platform/latest/hosted_control_planes/index.html) clusters using the [HyperShift](https://github.com/openshift/hypershift) middleware, augmenting the steps in the [HyperShift documentation](https://hypershift-docs.netlify.app) where appropriate. - -## How to - -### Before you begin - -- Ensure that your environment meets the $[prodname] [system requirements](requirements.mdx). - -- Ensure that you have a [RedHat account](https://cloud.redhat.com/). A RedHat account is required to get the pull secret necessary to provision an OpenShift cluster. Note that the OpenShift installer supports a subset of AWS regions. - -- If installing on AWS, ensure that you have: - - - Configured an AWS account appropriate for OpenShift 4 - - [Set up your AWS credentials](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/setup-credentials.html) - - Generated a local SSH private key and added it to your ssh-agent - -- Install the HyperShift CLI and fulfill all the other [Prerequisites from the HyperShift documentation](https://hypershift-docs.netlify.app/getting-started/#prerequisites). - -### Create the hosting cluster - -Deploy an [OpenShift cluster](./installation.mdx) with $[prodname]. This will be the hosting cluster with control-plane nodes for all hosted clusters you deploy with the steps below. Set up your `KUBECONFIG` environment variable to your hosting cluster's kubeconfig file: - -``` -export KUBECONFIG=/path/to/kubeconfig -``` - -### Install the HyperShift operator in the hosting cluster - -Follow the steps from the HyperShift documentation to [Install the HyperShift Operator](https://hypershift-docs.netlify.app/getting-started/#install-hypershift-operator). - -### Create a hosted cluster - -Create a hosted cluster with $[prodname] by going through the following steps (slightly modified from the [HyperShift docs](https://hypershift-docs.netlify.app/how-to/aws/other-sdn-providers/#calico)). - -1. Create a HostedCluster and set its HostedCluster.spec.networking.networkType to Other: - - -:::note -Make sure to adjust the variables for the command below to the correct values for your cluster, credentials and environment. -::: - -``` -HOSTED_CLUSTER_NAME=my-os-hosted-cluster -REGION=us-west-2 -BASE_DOMAIN=www.example.com -AWS_CREDS="$HOME/.aws/credentials" -PULL_SECRET="$HOME/.secrets/redhat-pull-secret.txt" - -hypershift create cluster aws \ - --name $HOSTED_CLUSTER_NAME \ - --node-pool-replicas=3 \ - --base-domain $BASE_DOMAIN \ - --pull-secret $PULL_SECRET \ - --aws-creds $AWS_CREDS \ - --region $REGION \ - --generate-ssh \ - --network-type Other -``` - -:::note -If your hosted cluster is having authorization problems with your Red Hat pull secret (`unauthorized: authentication required` in the HyperShift operator pod logs), make sure it is using a stable release image for the OpenShift Container Platform (OCP). -You can find them in [https://amd64.ocp.releases.ci.openshift.org], for example `--release-image quay.io/openshift-release-dev/ocp-release:4.16.4-x86_64` -::: - -:::note -If you face an [issue](https://github.com/openshift/hypershift/issues/3927) with the HyperShift middleware that results in the hosted cluster installation not progressing due to a missing `OVNSbDb` service, patch the hosted cluster resource in order to add it: -``` -HOSTED_CLUSTER_NAME=my-os-hosted-cluster -CLUSTER_NS="clusters" -oc patch -n ${CLUSTER_NS} hostedcluster ${HOSTED_CLUSTER_NAME} --type='json' -p '[{"op": "add", "path": "/spec/services/-", "value": {"service":"OVNSbDb","servicePublishingStrategy": {"type": "Route"}}}]' -``` -::: - -Once the hosted cluster is up, use the `hypershift` CLI tool to generate the `kubeconfig` file. We strongly recommend you create a separate directory for the hosted cluster, it is very important to not mix up configuration and manifests from the hosting and hosted clusters: - -``` -mkdir my_hosted_cluster && cd my_hosted_cluster -hypershift create kubeconfig > hosted_kubeconfig && export KUBECONFIG=$(pwd)/hosted_kubeconfig -``` - -Then, copy the `aws-creds` secret from the hosting cluster to the hosted cluster. Run this using the hosting cluster kubeconfig to extract the secret to a `yaml` file: - -``` -oc get secrets --kubeconfig /path/to/hosting/kubeconfig -n kube-system aws-creds -o yaml > aws-creds.yaml -``` - -Then import it in the hosted cluster: - -``` -oc apply --kubeconfig /path/to/hosted/kubeconfig -f aws-creds.yaml -``` - -:::note -There is no need to specify the `--kubeconfig` CLI argument if the hosted cluster's kubeconfig file is configured as the `KUBECONFIG` environment variable in your shell. -::: - - -### Download the $[prodname] install manifests - -Now download and apply the $[prodname] manifests according to the [HyperShift docs](https://hypershift-docs.netlify.app/how-to/aws/other-sdn-providers/#calico). - - - -### Optionally provide additional configuration - -You may want to provide Calico with additional configuration at install-time. For example, BGP configuration or peers. -You can use a Kubernetes ConfigMap with your desired Calico resources to set configuration as part of the installation. -If you do not need to provide additional configuration, you can skip this section. - -To include [Calico resources](../../../reference/resources/index.mdx) during installation, edit `calico/02-configmap-calico-resources.yaml` to add your own configuration. - -:::note -If you have a directory with the Calico resources, you can create the file with the command: - -``` -oc create configmap -n tigera-operator calico-resources \ ---from-file= --dry-run -o yaml \ -calico/02-configmap-calico-resources.yaml -``` - -With recent versions of oc it is necessary to have a kubeconfig configured or add `--server='127.0.0.1:443'` -even though it is not used. -::: - -:::note -If you have provided a `calico-resources` configmap and the tigera-operator pod fails to come up with `Init:CrashLoopBackOff`, -check the output of the init-container with `oc logs -n tigera-operator -l k8s-app=tigera-operator -c create-initial-resources`. -::: - -### Apply the $[prodname] install manifests - -Apply the install manifests paying attention to the required order. First apply all necessary manifests to install the Tigera Operator: - -``` -cd calico/ -ls 00* | xargs -n1 oc apply -f -ls 01* | xargs -n1 oc apply -f -ls 02* | xargs -n1 oc apply -f -``` - -Then wait until the Tigera Operator creates the necessary CustomResourceDefinitions (CRDs) before applying the CustomResources to install $[prodname] on your cluster: - -``` -timeout --foreground 600 bash -c "while ! kubectl get crd installations.operator.tigera.io; do sleep 5; done" # wait until CRDs are created by the operator -ls 03* | xargs -n1 oc apply -f -``` - -:::note -You can safely ignore any `ls: cannot access '0X*': No such file or directory` errors if there's no yaml files with that prefix to be applied. -::: - -Once the above commands are complete, you can verify $[prodname] is installed by verifying the components are available with the following command. - -``` -oc get tigerastatus -``` - -:::note -To get more information, add `-o yaml` to the above command. -::: - -## Next steps - -**Recommended - Networking** - -- If you are using the default BGP networking with full-mesh node-to-node peering with no encapsulation, go to [Configure BGP peering](../../../networking/configuring/bgp.mdx) to get traffic flowing between pods. -- If you are unsure about networking options, or want to implement encapsulation (overlay networking), see [Determine best networking option](../../../networking/determine-best-networking.mdx). - -**Recommended - Security** - -- [Secure Calico component communications](../../../network-policy/comms/crypto-auth.mdx) -- [Secure hosts by installing Calico on hosts](../../bare-metal/about.mdx) -- [Secure pods with Calico network policy](../../../network-policy/get-started/calico-policy/calico-network-policy.mdx) -- If you are using $[prodname] with Istio service mesh, get started here: [Enable application layer policy](../../../network-policy/istio/app-layer-policy.mdx) diff --git a/calico_versioned_docs/version-3.29/getting-started/kubernetes/openshift/index.mdx b/calico_versioned_docs/version-3.29/getting-started/kubernetes/openshift/index.mdx deleted file mode 100644 index 440f694d9b..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/kubernetes/openshift/index.mdx +++ /dev/null @@ -1,12 +0,0 @@ ---- -description: Install Calico on OpenShift for networking and network policy. -hide_table_of_contents: true -title: Installing on OpenShift ---- - -# OpenShift - -import DocCardList from '@theme/DocCardList'; -import { useCurrentSidebarCategory } from '@docusaurus/theme-common'; - - diff --git a/calico_versioned_docs/version-3.29/getting-started/kubernetes/openshift/installation.mdx b/calico_versioned_docs/version-3.29/getting-started/kubernetes/openshift/installation.mdx deleted file mode 100644 index d329cb1309..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/kubernetes/openshift/installation.mdx +++ /dev/null @@ -1,210 +0,0 @@ ---- -description: Install Calico on an OpenShift 4 cluster. ---- - -import InstallOpenShiftManifests from '@site/calico_versioned_docs/version-3.29/_includes/components/InstallOpenShiftManifests'; - -# Install an OpenShift 4 cluster with Calico - -## Big picture - -Install an OpenShift 4 cluster with $[prodname]. - -## Value - -Augments the applicable steps in the [OpenShift documentation](https://docs.redhat.com/en/documentation/openshift_container_platform/) -to install $[prodname]. - -## How to - -### Before you begin - -- Ensure that your environment meets the $[prodname] [system requirements](requirements.mdx). - -- Ensure that you have a [RedHat account](https://cloud.redhat.com/). A RedHat account is required to get the pull secret necessary to provision an OpenShift cluster. Note that the OpenShift installer supports a subset of AWS regions. - -- If installing on AWS, ensure that you have: - - - Configured an AWS account appropriate for OpenShift 4 - - [Set up your AWS credentials](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/setup-credentials.html) - - Generated a local SSH private key and added it to your ssh-agent - -### Create a configuration file for the OpenShift installer - -First, create a staging directory for the installation. This directory will contain the configuration file, along with cluster state files, that OpenShift installer will create: - -``` -mkdir openshift-tigera-install && cd openshift-tigera-install -``` - -Now run OpenShift installer to create a default configuration file: - -``` -openshift-install create install-config -``` - -:::note - -Refer to the [OpenShift installer documentation](https://docs.redhat.com/en/documentation/openshift_container_platform/) for more information -about the installer and any configuration changes required for your platform. - -::: - -Once the installer has finished, your staging directory will contain the configuration file `install-config.yaml`. - -### Update the configuration file to use $[prodname] - -Override the OpenShift networking to use Calico and update the AWS instance types to meet the [system requirements](requirements.mdx): - -```bash -sed -i 's/\(OpenShiftSDN\|OVNKubernetes\)/Calico/' install-config.yaml -``` - -### Generate the install manifests - -Now generate the Kubernetes manifests using your configuration file: - -```bash -openshift-install create manifests -``` - -:::note - -For OpenShift **v4.16 or newer** on **AWS**, configure AWS security groups to allow BGP, typha and IP-in-IP encapsulation traffic by editing the OpenShift cluster-api manifests. - -Edit `spec.network.cni.cniIngressRules` in the `cluster-api/02_infra-cluster.yaml` file to add the following rules: - -```yaml - cniIngressRules: - (...) - - description: BGP (calico) - fromPort: 179 - protocol: tcp - toPort: 179 - - description: IP-in-IP (calico) - fromPort: -1 - protocol: "4" - toPort: -1 - - description: Typha (calico) - fromPort: 5473 - protocol: tcp - toPort: 5473 -``` - -::: - - - -### Optionally provide additional configuration - -You may want to provide Calico with additional configuration at install-time. For example, BGP configuration or peers. -You can use a Kubernetes ConfigMap with your desired Calico resources to set configuration as part of the installation. -If you do not need to provide additional configuration, you can skip this section. - -To include [Calico resources](../../../reference/resources/index.mdx) during installation, edit `manifests/02-configmap-calico-resources.yaml` to add your own configuration. - -:::note - -If you have a directory with the Calico resources, you can create the file with the command: - -``` -oc create configmap -n tigera-operator calico-resources \ ---from-file= --dry-run -o yaml \ -manifests/02-configmap-calico-resources.yaml -``` - -With recent versions of oc it is necessary to have a kubeconfig configured or add `--server='127.0.0.1:443'` -even though it is not used. - -::: - -:::note - -If you have provided a `calico-resources` configmap and the tigera-operator pod fails to come up with `Init:CrashLoopBackOff`, -check the output of the init-container with `oc logs -n tigera-operator -l k8s-app=tigera-operator -c create-initial-resources`. - -::: - -### Create the cluster - -Start the cluster creation with the following command and wait for it to complete. - -```bash -openshift-install create cluster -``` - -Once the above command is complete, you can verify $[prodname] is installed by verifying the components are available with the following command. - -``` -oc get tigerastatus -``` - -:::note - -To get more information, add `-o yaml` to the above command. - -::: - -### Optionally integrate with Operator Lifecycle Manager (OLM) - -In OpenShift Container Platform, the [Operator Lifecycle Manager](https://docs.openshift.com/container-platform/4.4/operators/understanding_olm/olm-understanding-olm.html#olm-overview_olm-understanding-olm) helps -cluster administrators manage the lifecycle of operators in their cluster. Managing the $[prodname] -operator with OLM gives administrators a single place to manage operators. - -To register the running $[prodname] operator with OLM, first you will need to create an OperatorGroup for the operator: - -```bash -oc apply -f - < diff --git a/calico_versioned_docs/version-3.29/getting-started/kubernetes/quickstart.mdx b/calico_versioned_docs/version-3.29/getting-started/kubernetes/quickstart.mdx deleted file mode 100644 index fc1569b206..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/kubernetes/quickstart.mdx +++ /dev/null @@ -1,170 +0,0 @@ ---- -description: Install Calico on a single-host Kubernetes cluster for testing or development in under 15 minutes. -title: "Tutorial: Quickstart on Kubernetes" ---- - -# Quickstart for Calico on Kubernetes - -## Big picture - -This quickstart gets you a single-host Kubernetes cluster with $[prodname] in approximately 15 minutes. - -## Value - -Use this quickstart to quickly and easily try $[prodname] features. To deploy a cluster suitable for production, refer to [$[prodname] on Kubernetes](../index.mdx). - -## Before you begin - -**Required** - -- A Linux host that meets the following requirements: - - - x86-64, arm64, ppc64le, or s390x processor - - 2CPU - - 2GB RAM - - 10GB free disk space - - RedHat Enterprise Linux 7.x+, CentOS 7.x+, Ubuntu 18.04+, or Debian 9.x+ - -- $[prodname] can manage `cali` and `tunl` interfaces on the host - - If NetworkManager is present on the host, see [Configure NetworkManager](../../operations/troubleshoot/troubleshooting.mdx#configure-networkmanager). - -## Concepts - -### Operator based installation - -This quickstart guide uses the Tigera Operator to install $[prodname]. The operator provides lifecycle management for Calico -exposed via the Kubernetes API defined as a custom resource definition. - -:::note - -It is also possible to install Calico without an operator using Kubernetes manifests directly. -For platforms and guides that do not use the Tigera Operator, you may notice some differences in the steps and Kubernetes -resources compared to those presented in this guide. - -::: - -## How to - -The geeky details of what you get: - - - -### Create a single-host Kubernetes cluster - -1. [Follow the Kubernetes instructions to install kubeadm](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/) - - :::note - - After installing kubeadm, do not power down or restart - the host. Instead, continue directly to the next step. - - ::: - -1. As a regular user with sudo privileges, open a terminal on the host that you installed kubeadm on. - -1. Initialize the control plane using the following command. - - ``` - sudo kubeadm init --pod-network-cidr=192.168.0.0/16 - ``` - - :::note - - If 192.168.0.0/16 is already in use within your network you must select a different pod network - CIDR, replacing 192.168.0.0/16 in the above command. - - ::: - -1. Execute the following commands to configure kubectl (also returned by `kubeadm init`). - - ``` - mkdir -p $HOME/.kube - sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config - sudo chown $(id -u):$(id -g) $HOME/.kube/config - ``` - -### Install $[prodname] - -1. Install the Tigera Operator and custom resource definitions. - - ``` - kubectl create -f $[manifestsUrl]/manifests/tigera-operator.yaml - ``` - - :::note - - Due to the large size of the CRD bundle, `kubectl apply` might exceed request limits. Instead, use `kubectl create` or `kubectl replace`. - - ::: - -1. Install $[prodname] by creating the necessary custom resource. For more information on configuration options available in this manifest, see [the installation reference](../../reference/installation/api.mdx). - - ``` - kubectl create -f $[manifestsUrl]/manifests/custom-resources.yaml - ``` - - :::note - - Before creating this manifest, read its contents and make sure its settings are correct for your environment. For example, - you may need to change the default IP pool CIDR to match your pod network CIDR. - - ::: - -1. Confirm that all of the pods are running with the following command. - - ``` - watch kubectl get pods -n calico-system - ``` - - Wait until each pod has the `STATUS` of `Running`. - - :::note - - The Tigera Operator installs resources in the `calico-system` namespace. Other install methods may use - the `kube-system` namespace instead. - - ::: - -1. Remove the taints on the control plane so that you can schedule pods on it. - - ```bash - kubectl taint nodes --all node-role.kubernetes.io/control-plane- - ``` - - It should return the following. - - ``` - node/ untainted - ``` - -1. Confirm that you now have a node in your cluster with the following command. - - ``` - kubectl get nodes -o wide - ``` - - It should return something like the following. - - ``` - NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME - Ready master 52m v1.12.2 10.128.0.28 Ubuntu 18.04.1 LTS 4.15.0-1023-gcp docker://18.6.1 - ``` - -Congratulations! You now have a single-host Kubernetes cluster with $[prodname]. - -## Next steps - -**Required** - -- [Install and configure calicoctl](../../operations/calicoctl/install.mdx) - -**Recommended tutorials** - -- [Secure a simple application using the Kubernetes NetworkPolicy API](../../network-policy/get-started/kubernetes-policy/kubernetes-policy-basic.mdx) -- [Control ingress and egress traffic using the Kubernetes NetworkPolicy API](../../network-policy/get-started/kubernetes-policy/kubernetes-policy-advanced.mdx) -- [Run a tutorial that shows blocked and allowed connections in real time](../../network-policy/get-started/kubernetes-policy/kubernetes-demo.mdx) -- [Hands-on workshop: Learn the basics of Calico, and Kubernetes.](https://www.tigera.io/tutorials/?_sf_s=Calico%20Basics) diff --git a/calico_versioned_docs/version-3.29/getting-started/kubernetes/rancher.mdx b/calico_versioned_docs/version-3.29/getting-started/kubernetes/rancher.mdx deleted file mode 100644 index 4546de974d..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/kubernetes/rancher.mdx +++ /dev/null @@ -1,97 +0,0 @@ ---- -description: Install Calico on a Rancher Kubernetes Engine cluster. -title: Installing on RKE ---- - -# Rancher Kubernetes Engine (RKE) - -## Big picture - -Install $[prodname] as the required CNI for networking and/or network policy on Rancher-deployed clusters. - -## Concepts - -$[prodname] supports the Calico CNI with Calico network policy: - -The geeky details of what you get: - - - -## Before you begin - -**Required** - -- A compatible [Rancher Kubernetes Engine cluster](https://rancher.com/docs/rke/latest/en/) with version 1.3 - - - Configure your cluster with a [Cluster Config File](https://rke.docs.rancher.com/installation#creating-the-cluster-configuration-file) and specify [no network plugin](https://rancher.com/docs/rke/latest/en/config-options/add-ons/network-plugins/) by setting `plugin: none` under `network` in your configuration file. - -- RKE cluster meets the [$[prodname] requirements](requirements.mdx) - -- A `kubectl` environment with access to your cluster - - - Use [Rancher kubectl Shell](https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig#accessing-clusters-with-kubectl-shell-in-the-rancher-ui) for access - - Ensure you have the [kubeconfig file that was generated when you created the cluster](https://rancher.com/docs/rke/latest/en/installation/#save-your-files). - -- If using a kubeconfig file locally, [install and set up the Kubectl CLI tool](https://kubernetes.io/docs/tasks/tools/install-kubectl/). - -## How to - -- [Install $[prodname]](#install-calico) - -### Install $[prodname] - -1. Install the Tigera Operator and custom resource definitions. - - ``` - kubectl create -f $[manifestsUrl]/manifests/tigera-operator.yaml - ``` - - :::note - - Due to the large size of the CRD bundle, `kubectl apply` might exceed request limits. Instead, use `kubectl create` or `kubectl replace`. - - ::: - -1. Install $[prodname] by creating the necessary custom resource. For more information on configuration options available in this manifest, see [the installation reference](../../reference/installation/api.mdx). - - ``` - kubectl create -f $[manifestsUrl]/manifests/custom-resources.yaml - ``` - - :::note - - Before creating this manifest, read its contents and make sure its settings are correct for your environment. For example, - you may need to change the default IP pool CIDR to match your pod network CIDR. Rancher uses `10.42.0.0/16` by default. - - ::: - - :::note - - If you are installing $[prodname] on Windows nodes in this cluster, please see the [$[prodnameWindows] for RKE](windows-calico/rancher.mdx) installation instructions. - - ::: - -1. Confirm that all of the pods are running with the following command. - - ``` - watch kubectl get pods -n calico-system - ``` - - Wait until each pod has the `STATUS` of `Running`. - -Congratulations! You now have an RKE cluster running $[prodname] - -## Next steps - -**Required** - -- [Install and configure calicoctl](../../operations/calicoctl/install.mdx) - -**Recommended tutorials** - -- [Secure a simple application using the Kubernetes NetworkPolicy API](../../network-policy/get-started/kubernetes-policy/kubernetes-policy-basic.mdx) -- [Control ingress and egress traffic using the Kubernetes NetworkPolicy API](../../network-policy/get-started/kubernetes-policy/kubernetes-policy-advanced.mdx) -- [Run a tutorial that shows blocked and allowed connections in real time](../../network-policy/get-started/kubernetes-policy/kubernetes-demo.mdx) diff --git a/calico_versioned_docs/version-3.29/getting-started/kubernetes/requirements.mdx b/calico_versioned_docs/version-3.29/getting-started/kubernetes/requirements.mdx deleted file mode 100644 index c7381b96fa..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/kubernetes/requirements.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: Review requirements before installing Calico to ensure success. -title: System requirements ---- - -import SystemRequirements from '../../_includes/partials/_system-requirements.mdx'; -export const platform='kubernetes'; - -# System requirements for Kubernetes - - \ No newline at end of file diff --git a/calico_versioned_docs/version-3.29/getting-started/kubernetes/self-managed-onprem/config-options.mdx b/calico_versioned_docs/version-3.29/getting-started/kubernetes/self-managed-onprem/config-options.mdx deleted file mode 100644 index 0291eed1dc..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/kubernetes/self-managed-onprem/config-options.mdx +++ /dev/null @@ -1,351 +0,0 @@ ---- -description: Optionally customize Calico prior to installation. -title: Customizing your installation ---- - -# Customize Calico configuration - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - -## Big picture - -Perform common customizations of a $[prodname] installation. - -## Concepts - -### $[prodname] operator - -$[prodname] is installed by an operator which manages the installation, upgrade, and general lifecycle of a $[prodname] cluster. The operator is -installed directly on the cluster as a Deployment, and is configured through one or more custom Kubernetes API resources. - -### $[prodname] manifests - -$[prodname] can also be installed using raw manifests as an alternative to the operator. The manifests contain the necessary resources for installing $[prodname] on each node in your Kubernetes cluster. Using manifests is not recommended as they cannot automatically manage the lifecycle of the $[prodname] as the operator does. However, manifests may be useful for clusters that require highly specific modifications to the underlying Kubernetes resources. - -## How to - - - - -### About customizing an operator install - -Operator installations read their configuration from a specific set of Kubernetes APIs. These APIs are installed on the cluster -as part of `tigera-operator.yaml` in the `operator.tigera.io/v1` API group. - -- [Installation](../../../reference/installation/api.mdx#installation): a singleton resource with name "default" that - configures common installation parameters for a $[prodname] cluster. -- [APIServer](../../../reference/installation/api.mdx#installation): a singleton resource with name "default" that - configures installation of the $[prodname] API server extension. - -### Configure the pod IP range - -For many environments, $[prodname] will auto-detect the correct pod IP range to use, or select an unused range on the cluster. - -You can select a specific pod IP range by modifying the `spec.calicoNetwork.ipPools` array in the Installation API resource. - -```yaml -kind: Installation -apiVersion: operator.tigera.io/v1 -metadata: - name: default -spec: - calicoNetwork: - ipPools: - - cidr: 198.51.100.0/24 -``` - -::: - -### Use VXLAN - -You can enable VXLAN in a cluster by setting the option on your IPv4 pool. You can also disable BGP via the `spec.calicoNetwork.bgp` field. - -```yaml -kind: Installation -apiVersion: operator.tigera.io/v1 -metadata: - name: default -spec: - calicoNetwork: - bgp: Disabled - ipPools: - - cidr: 198.51.100.0/24 - encapsulation: VXLAN -``` - - - - -We provide a number of manifests to make deployment of $[prodname] easy. You can optionally -modify the manifests before applying them. Or you can modify the manifest and reapply it to change -settings as needed. - -### About customizing $[prodname] manifests - -Each manifest contains all the necessary resources for installing $[prodname] -on each node in your Kubernetes cluster. - -It installs the following Kubernetes resources: - -- Installs the `$[nodecontainer]` container on each host using a DaemonSet. -- Installs the $[prodname] CNI binaries and network config on each host using a DaemonSet. -- Runs `calico/kube-controllers` as a deployment. -- The `calico-etcd-secrets` secret, which optionally allows for providing etcd TLS assets. -- The `calico-config` ConfigMap, which contains parameters for configuring the install. - -The sections that follow discuss the configurable parameters in greater depth. - -### Configure the pod IP range - -$[prodname] IPAM assigns IP addresses from [IP pools](../../../reference/resources/ippool.mdx). - -To change the default IP range used for pods, modify the `CALICO_IPV4POOL_CIDR` -section of the `calico.yaml` manifest. For more information, see -[Configuring $[nodecontainer]](../../../reference/configure-calico-node.mdx). - -## Configuring IP-in-IP - -By default, the manifests enable IP-in-IP encapsulation across subnets. Many users may -want to disable IP-in-IP encapsulation, such as under the following circumstances. - -- Their cluster is [running in a properly configured AWS VPC](../../../reference/public-cloud/aws.mdx). -- All their Kubernetes nodes are connected to the same layer 2 network. -- They intend to use BGP peering to make their underlying infrastructure aware of - pod IP addresses. - -To disable IP-in-IP encapsulation, modify the `CALICO_IPV4POOL_IPIP` section of the -manifest. For more information, see [Configuring $[nodecontainer]](../../../reference/configure-calico-node.mdx). - -## Switching from IP-in-IP to VXLAN - -By default, the Calico manifests enable IP-in-IP encapsulation. If you are on a network that blocks IP-in-IP, such -as Azure, you may wish to switch to [Calico's VXLAN encapsulation mode](../../../networking/configuring/vxlan-ipip.mdx). -To do this at install time (so that Calico creates the default IP pool with VXLAN and no IP-in-IP configuration has to -be undone): - -- Start with one of the [Calico for policy and networking](config-options.mdx) manifests. -- Replace environment variable name `CALICO_IPV4POOL_IPIP` with`CALICO_IPV4POOL_VXLAN`. Leave the value of the new variable as "Always". -- Optionally, (to save some resources if you're running a VXLAN-only cluster) completely disable Calico's BGP-based - networking: - - Replace `calico_backend: "bird"` with `calico_backend: "vxlan"`. This disables BIRD. - - Comment out the line `- -bird-ready` and `- -bird-live` from the calico/node readiness/liveness check (otherwise disabling BIRD will cause the - readiness/liveness check to fail on every node): - -```yaml -livenessProbe: - exec: - command: - - /bin/calico-node - - -felix-live - - -bird-live -readinessProbe: - exec: - command: - - /bin/calico-node - - -bird-ready - - -felix-ready -``` - -For more information on $[nodecontainer]'s configuration variables, including additional VXLAN settings, see -[Configuring $[nodecontainer]](../../../reference/configure-calico-node.mdx). - -:::note - -The `CALICO_IPV4POOL_VXLAN` environment variable only takes effect when the first $[nodecontainer] to start -creates the default IP pool. It has no effect after the pool has already been created. To switch to VXLAN mode -after installation time, use calicoctl to modify the [IPPool](../../../reference/resources/ippool.mdx) resource. - -::: - -## Configuring etcd - -By default, these manifests do not configure secure access to etcd and assume an -etcd proxy is running on each host. The following configuration options let you -specify custom etcd cluster endpoints as well as TLS. - -The following table outlines the supported `ConfigMap` options for etcd: - -| Option | Description | Default | -| -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------- | -| etcd_endpoints | Comma-delimited list of etcd endpoints to connect to. | http://127.0.0.1:2379 | -| etcd_ca | The file containing the root certificate of the CA that issued the etcd server certificate. Configures `$[nodecontainer]`, the CNI plugin, and the Kubernetes controllers to trust the signature on the certificates provided by the etcd server. | None | -| etcd_key | The file containing the private key of the `$[nodecontainer]`, the CNI plugin, and the Kubernetes controllers client certificate. Enables these components to participate in mutual TLS authentication and identify themselves to the etcd server. | None | -| etcd_cert | The file containing the client certificate issued to `$[nodecontainer]`, the CNI plugin, and the Kubernetes controllers. Enables these components to participate in mutual TLS authentication and identify themselves to the etcd server. | None | - -To use these manifests with a TLS-enabled etcd cluster you must do the following: - -1. Download the $[version] manifest that corresponds to your installation method. - - **$[prodname] for policy and networking** - - ```bash - curl $[manifestsUrl]/manifests/calico-etcd.yaml -O - ``` - - **$[prodname] for policy and flannel for networking** - - ```bash - curl $[manifestsUrl]/manifests/canal.yaml -O - ``` - -1. Within the `ConfigMap` section, uncomment the `etcd_ca`, `etcd_key`, and `etcd_cert` - lines so that they look as follows. - - ```yaml - etcd_ca: '/calico-secrets/etcd-ca' - etcd_cert: '/calico-secrets/etcd-cert' - etcd_key: '/calico-secrets/etcd-key' - ``` - -1. Ensure that you have three files, one containing the `etcd_ca` value, another containing - the `etcd_key` value, and a third containing the `etcd_cert` value. - -1. Using a command like the following to strip the newlines from the files and - base64-encode their contents. - - ```bash - cat | base64 -w 0 - ``` - -1. In the `Secret` named `calico-etcd-secrets`, uncomment `etcd_ca`, `etcd_key`, and `etcd_cert` - and paste in the appropriate base64-encoded values. - - ```yaml - apiVersion: v1 - kind: Secret - type: Opaque - metadata: - name: calico-etcd-secrets - namespace: kube-system - data: - # Populate the following files with etcd TLS configuration if desired, but leave blank if - # not using TLS for etcd. - # This self-hosted install expects three files with the following names. The values - # should be base64 encoded strings of the entire contents of each file. - etcd-key: LS0tLS1CRUdJTiB...VZBVEUgS0VZLS0tLS0= - etcd-cert: LS0tLS1...ElGSUNBVEUtLS0tLQ== - etcd-ca: LS0tLS1CRUdJTiBD...JRklDQVRFLS0tLS0= - ``` - -1. Apply the manifest. - - **$[prodname] for policy and networking** - - ```bash - kubectl apply -f calico.yaml - ``` - - **$[prodname] for policy and flannel for networking** - - ```bash - kubectl apply -f canal.yaml - ``` - -## Authorization options - -$[prodname]'s manifests assign its components one of two service accounts. -Depending on your cluster's authorization mode, you'll want to back these -service accounts with the necessary permissions. - -## Other configuration options - -The following table outlines the remaining supported `ConfigMap` options. - -| Option | Description | Default | -| ------------------ | --------------------------------------------------------------------------------------- | ------- | -| calico_backend | The backend to use. | `bird` | -| cni_network_config | The CNI Network config to install on each node. Supports templating as described below. | - -## CNI network configuration template - -The `cni_network_config` configuration option supports the following template fields, which will -be filled in automatically by the `calico/cni` container: - -| Field | Substituted with | -| ----------------------------- | -------------------------------------------------------------------------------------------------------------------- | -| `__KUBERNETES_SERVICE_HOST__` | The Kubernetes service Cluster IP, e.g `10.0.0.1` | -| `__KUBERNETES_SERVICE_PORT__` | The Kubernetes service port, e.g., `443` | -| `__SERVICEACCOUNT_TOKEN__` | The service account token for the namespace, if one exists. | -| `__ETCD_ENDPOINTS__` | The etcd endpoints specified in `etcd_endpoints`. | -| `__KUBECONFIG_FILEPATH__` | The path to the automatically generated kubeconfig file in the same directory as the CNI network configuration file. | -| `__ETCD_KEY_FILE__` | The path to the etcd key file installed to the host. Empty if no key is present. | -| `__ETCD_CERT_FILE__` | The path to the etcd certificate file installed to the host, empty if no cert present. | -| `__ETCD_CA_CERT_FILE__` | The path to the etcd certificate authority file installed to the host. Empty if no certificate authority is present. | - -## About customizing application layer policy manifests - -Instead of installing from our pre-modified Istio manifests, you may wish to -customize your Istio install or use a different Istio version. This section -walks you through the necessary changes to a generic Istio install manifest to -allow application layer policy to operate. - -The standard Istio manifests for the sidecar injector include a ConfigMap that -contains the template used when adding pods to the cluster. The template adds an -init container and the Envoy sidecar. Application layer policy requires -an additional lightweight sidecar called Dikastes which receives $[prodname] policy -from Felix and applies it to incoming connections and requests. - -If you haven't already done so, download an -[Istio release](https://github.com/istio/istio/releases) and untar it to a -working directory. - -Open the `install/kubernetes/istio-demo-auth.yaml` file in an -editor, and locate the `istio-sidecar-injector` ConfigMap. In the existing `istio-proxy` container, add a new `volumeMount`. - -```yaml -- mountPath: /var/run/dikastes - name: dikastes-sock -``` - -Add a new container to the template. - -```yaml - - name: dikastes - image: $[registry]$[imageNames.calico/dikastes]:$[releases.0.components.calico/dikastes.version] - args: ["server", "-l", "/var/run/dikastes/dikastes.sock", "-d", "/var/run/felix/nodeagent/socket"] - securityContext: - allowPrivilegeEscalation: false - livenessProbe: - exec: - command: - - /healthz - - liveness - initialDelaySeconds: 3 - periodSeconds: 3 - readinessProbe: - exec: - command: - - /healthz - - readiness - initialDelaySeconds: 3 - periodSeconds: 3 - volumeMounts: - - mountPath: /var/run/dikastes - name: dikastes-sock - - mountPath: /var/run/felix - name: felix-sync -``` - -Add two new volumes. - -```yaml -- name: dikastes-sock - emptyDir: - medium: Memory -- name: felix-sync - csi: - driver: 'csi.tigera.io' -``` - -The volumes you added are used to create Unix domain sockets that allow -communication between Envoy and Dikastes and between Dikastes and -Felix. Once created, a Unix domain socket is an in-memory communications -channel. The volumes are not used for any kind of stateful storage on disk. - -Refer to the -[Calico ConfigMap manifest]($[manifestsUrl]/manifests/alp/istio-inject-configmap-1.4.2.yaml) for an -example with the above changes. - - - diff --git a/calico_versioned_docs/version-3.29/getting-started/kubernetes/self-managed-onprem/onpremises.mdx b/calico_versioned_docs/version-3.29/getting-started/kubernetes/self-managed-onprem/onpremises.mdx deleted file mode 100644 index 48357be88c..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/kubernetes/self-managed-onprem/onpremises.mdx +++ /dev/null @@ -1,257 +0,0 @@ ---- -description: Install Calico networking and network policy for on-premises deployments. -title: Installing on on-premises deployments ---- - -# Install Calico networking and network policy for on-premises deployments - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - -## Big picture - -Install $[prodname] to provide both networking and network policy for self-managed on-premises deployments. - -## Value - -**$[prodname] networking** and **network policy** are a powerful choice for a CaaS implementation. If you have the networking infrastructure and resources to manage Kubernetes on-premises, installing the full $[prodname] product provides the most customization and control. - -## Concepts - -### Recommended: Tigera Operator - -$[prodname] is installed by an operator which manages the installation, upgrade, and general lifecycle of a $[prodname] cluster. The operator is -installed directly on the cluster as a Deployment, and is configured through one or more custom Kubernetes API resources. - -### $[prodname] manifests - -$[prodname] can also be installed using raw manifests as an alternative to the operator. The manifests contain the necessary resources for installing $[prodname] on each node in your Kubernetes cluster. Using manifests is not recommended as they cannot automatically manage the lifecycle of the $[prodname] as the operator does. However, manifests may be useful for clusters that require highly specific modifications to the underlying Kubernetes resources. - -## Before you begin... - -- Ensure that your Kubernetes cluster meets [requirements](../requirements.mdx). - If you do not have a cluster, see [Installing kubeadm](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/). - -## How to - -- [Install Calico](#install-calico) - -### Install Calico - - - - -1. Install the operator on your cluster. - - ``` - kubectl create -f $[manifestsUrl]/manifests/tigera-operator.yaml - ``` - -1. Download the custom resources necessary to configure $[prodname]. - - ``` - curl $[manifestsUrl]/manifests/custom-resources.yaml -O - ``` - - If you wish to customize the $[prodname] install, customize the downloaded custom-resources.yaml manifest locally. - -1. Create the manifest to install $[prodname]. - - ``` - kubectl create -f custom-resources.yaml - ``` - -1. Verify $[prodname] installation in your cluster. - - ``` - watch kubectl get pods -n calico-system - ``` - - You should see a result similar to the below. - - ``` - NAMESPACE NAME READY STATUS RESTARTS AGE - kube-system calico-node-txngh 1/1 Running 0 54s - ``` - - - - - - -Based on your datastore and number of nodes, select a link below to install $[prodname]. - -:::note - -The option, **Kubernetes API datastore, more than 50 nodes** provides scaling using [Typha daemon](../../../reference/typha/index.mdx). Typha is not included for etcd because etcd already handles many clients so using Typha is redundant and not recommended. - -::: - -- [Install Calico with Kubernetes API datastore, 50 nodes or less](#install-calico-with-kubernetes-api-datastore-50-nodes-or-less) -- [Install Calico with Kubernetes API datastore, more than 50 nodes](#install-calico-with-kubernetes-api-datastore-more-than-50-nodes) -- [Install Calico with etcd datastore](#install-calico-with-etcd-datastore) - -#### Install Calico with Kubernetes API datastore, 50 nodes or less - -:::note - -This option is maintained for upgrade compatibility, but we recommend that new clusters use the operator, which -will automatically configure $[prodname] correctly for your cluster size (including deploying the Typha scale-out -proxy and securing it when necessary). - -::: - -1. Download the $[prodname] networking manifest for the Kubernetes API datastore. - - ```bash - curl $[manifestsUrl]/manifests/calico.yaml -O - ``` - -1. If you are using pod CIDR `192.168.0.0/16`, skip to the next step. - If you are using a different pod CIDR with kubeadm, no changes are required — Calico will automatically detect the CIDR based on the running configuration. - For other platforms, make sure you uncomment the CALICO_IPV4POOL_CIDR variable in the manifest and set it to the same value as your chosen pod CIDR. -1. Customize the manifest as necessary. -1. Apply the manifest using the following command. - - ```bash - kubectl apply -f calico.yaml - ``` - -The geeky details of what you get: - - - -#### Install Calico with Kubernetes API datastore, more than 50 nodes - -:::note - -This option is maintained for upgrade compatibility but we recommend that new clusters use the operator to deploy -Typha (the extra scale-out component included in this manifest) instead of using this method. The operator deploys -Typha, autoscales it, and auto-configures mTLS between the per-host agent and Typha for maximum security. This -manifest option leaves scaling up to you and, by default, it does not secure Typha's port. - -::: - -1. Download the $[prodname] networking manifest for the Kubernetes API datastore. - - ```bash - curl $[manifestsUrl]/manifests/calico-typha.yaml -o calico.yaml - ``` - -1. If you are using pod CIDR `192.168.0.0/16`, skip to the next step. - If you are using a different pod CIDR with kubeadm, no changes are required — Calico will automatically detect the CIDR based on the running configuration. - For other platforms, make sure you uncomment the CALICO_IPV4POOL_CIDR variable in the manifest and set it to the same value as your chosen pod CIDR. -1. Modify the replica count to the desired number in the `Deployment` named, `calico-typha`. - - ```yaml noValidation - apiVersion: apps/v1beta1 - kind: Deployment - metadata: - name: calico-typha - ... - spec: - ... - replicas: - ``` - - We recommend at least one replica for every 200 nodes, and no more than - 20 replicas. In production, we recommend a minimum of three replicas to reduce - the impact of rolling upgrades and failures. The number of replicas should - always be less than the number of nodes, otherwise rolling upgrades will stall. - In addition, Typha only helps with scale if there are fewer Typha instances than - there are nodes. - - :::note - - If you set `typha_service_name` and set the Typha deployment replica - count to 0, Felix will not start. - - ::: - -1. Customize the manifest if desired. -1. Apply the manifest. - - ```bash - kubectl apply -f calico.yaml - ``` - -The geeky details of what you get: - - - -#### Install Calico with etcd datastore - -:::note - -The etcd datastore is not recommended for new Kubernetes installs: - -* etcd is another component to manage and maintain. -* Some newer Kubernetes-targeted features (such as service matches in policy) are not supported with the etcd datastore. -* eBPF data plane mode is not supported with the etcd datastore. It relies on watching services to implement some features, - which is not supported with the etcd datastore. -* The Cloud/Enterprise versions of $[prodname] do not support etcd mode at all so using this manifest prevents - you from upgrading. - -However, it is the only option that supports running both OpenStack and Kubernetes nodes in the same cluster. - -::: - -1. Download the $[prodname] networking manifest for etcd. - - ```bash - curl $[manifestsUrl]/manifests/calico-etcd.yaml -o calico.yaml - ``` - -1. If you are using pod CIDR `192.168.0.0/16`, skip to the next step. - If you are using a different pod CIDR with kubeadm, no changes are required — Calico will automatically detect the CIDR based on the running configuration. - For other platforms, make sure you uncomment the CALICO_IPV4POOL_CIDR variable in the manifest and set it to the same value as your chosen pod CIDR. -1. In the `ConfigMap` named, `calico-config`, set the value of `etcd_endpoints` to the IP address and port of your etcd server. - :::note - - You can specify more than one `etcd_endpoint` using commas as delimiters. - - ::: - -1. Customize the manifest if desired. -1. Apply the manifest using the following command. - - ```bash - kubectl apply -f calico.yaml - ``` - -The geeky details of what you get: - - - - - - -## Next steps - -**Required** - -- [Install and configure calicoctl](../../../operations/calicoctl/install.mdx) - -**Recommended - Networking** - -- If you are using the default BGP networking with full-mesh node-to-node peering with no encapsulation, go to [Configure BGP peering](../../../networking/configuring/bgp.mdx) to get traffic flowing between pods. -- If you are unsure about networking options, or want to implement encapsulation (overlay networking), see [Determine best networking option](../../../networking/determine-best-networking.mdx). - -**Recommended - Security** - -- [Secure Calico component communications](../../../network-policy/comms/crypto-auth.mdx) -- [Secure hosts by installing Calico on hosts](../../bare-metal/about.mdx) -- [Secure pods with Calico network policy](../../../network-policy/get-started/calico-policy/calico-network-policy.mdx) -- If you are using $[prodname] with Istio service mesh, get started here: [Enable application layer policy](../../../network-policy/istio/app-layer-policy.mdx) diff --git a/calico_versioned_docs/version-3.29/getting-started/kubernetes/self-managed-public-cloud/aws.mdx b/calico_versioned_docs/version-3.29/getting-started/kubernetes/self-managed-public-cloud/aws.mdx deleted file mode 100644 index 37473fd88c..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/kubernetes/self-managed-public-cloud/aws.mdx +++ /dev/null @@ -1,115 +0,0 @@ ---- -description: Use Calico with a self-managed Kubernetes cluster in Amazon Web Services (AWS). -title: Installing on AWS ---- - -# Self-managed Kubernetes in Amazon Web Services (AWS) - -## Big picture - -Use $[prodname] with a self-managed Kubernetes cluster in Amazon Web Services (AWS). - -## Value - -Managing your own Kubernetes cluster (as opposed to using a managed-Kubernetes service like EKS), gives you the most flexibility in configuring $[prodname] and Kubernetes. $[prodname] combines flexible networking capabilities with "run-anywhere" security enforcement to provide a solution with native Linux kernel performance and true cloud-native scalability. - -## Concepts - -Kubernetes Operations (kOps) is a cluster management tool that handles provisioning cluster VMs and installing Kubernetes. It has built-in support for using $[prodname] as the Kubernetes networking provider. - -## Before you begin... - -- Install [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) -- Install [AWS CLI tools](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) - -:::note - -$[prodname] makes use of the Kubernetes Container Storage Interface (CSI) to support various types of volumes. The necessary drivers required for CSI -to function correctly in AWS clusters using EBS volumes may no longer be present by default in clusters running Kubernetes 1.23. Please check the documentation for the installer -being used to ensure the necessary CSI drivers are installed. - -If using Kubernetes Operations (kOps) as further down on this page please use the relevant linked kOps documentation to ensure your cluster has the necessary configuration. - -::: - -## How to - -There are many ways to install and manage Kubernetes in AWS. Using Kubernetes Operations (kOps) is a good default choice for most people, as it gives you access to all of $[prodname]’s [flexible and powerful networking features](../../../networking/index.mdx). However, there are other options that may work better for your environment. - -- [Kubernetes Operations for Calico networking and network policy](#kubernetes-operations-for-calico-networking-and-network-policy) -- [Other options and tools](#other-options-and-tools) - -### Kubernetes Operations for Calico networking and network policy - -To use kOps to create a cluster with $[prodname] networking and network policy: - -1. [Install kOps](https://kops.sigs.k8s.io/install/) on your workstation. -1. [Set up your environment for AWS](https://kops.sigs.k8s.io/getting_started/aws/) . -1. Be sure to [set up an S3 state store](https://kops.sigs.k8s.io/getting_started/aws/#cluster-state-storage) and export its name: - - ``` - export KOPS_STATE_STORE=s3://name-of-your-state-store-bucket - ``` - -1. [Verify CSI driver installation configuration as per your particular cluster and volumes](https://kops.sigs.k8s.io/addons/#self-managed-aws-ebs-csi-driver) -1. Configure kOps to use $[prodname] for networking. - The easiest way to do this is to pass `--networking calico` to kOps when creating the cluster. For example: - - ``` - kops create cluster \ - --zones us-west-2a \ - --networking calico \ - name-of-your-cluster - ``` - - Or, you can add `calico` to your cluster config. Run kops edit cluster and set the following networking configuration. - - ```yaml - networking: - calico: {} - ``` - -The geeky details of what you get: - -{' '} - -You can further customize the $[prodname] install with [options listed in the kOps documentation](https://kops.sigs.k8s.io/networking/#calico-example-for-cni-and-network-policy). - -### Other options and tools - -#### Amazon VPC CNI plugin - -As an alternative to $[prodname] for both networking and network policy, you can use Amazon’s VPC CNI plugin for networking, and $[prodname] for network policy. The advantage of this approach is that pods are assigned IP addresses associated with Elastic Network Interfaces on worker nodes. The IPs come from the VPC network pool and therefore do not require NAT to access resources outside the Kubernetes cluster. - -Set your kOps cluster configuration to: - -```yaml -networking: - amazonvpc: {} -``` - -Then install $[prodname] for network policy only after the cluster is up and ready. - -The geeky details of what you get: - - - -#### Kubespray - -[Kubespray](https://kubespray.io/) is a tool for provisioning and managing Kubernetes clusters with support for multiple clouds including Amazon Web Services. $[prodname] is the default networking provider, or you can set the `kube_network_plugin` variable to `calico`. See the [Kubespray docs](https://kubespray.io/#/?id=network-plugins) for more details. - -## Next steps - -**Required** - -- [Install and configure calicoctl](../../../operations/calicoctl/install.mdx) - -**Recommended** - -- [Try out $[prodname] network policy](../../../network-policy/get-started/calico-policy/calico-network-policy.mdx) diff --git a/calico_versioned_docs/version-3.29/getting-started/kubernetes/self-managed-public-cloud/azure.mdx b/calico_versioned_docs/version-3.29/getting-started/kubernetes/self-managed-public-cloud/azure.mdx deleted file mode 100644 index b481eec370..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/kubernetes/self-managed-public-cloud/azure.mdx +++ /dev/null @@ -1,87 +0,0 @@ ---- -description: Use Calico with a self-managed Kubernetes cluster in Microsoft Azure. -title: Installing on Azure ---- - -# Self-managed Kubernetes in Microsoft Azure - -## Big picture - -Use $[prodname] with a self-managed Kubernetes cluster in Microsoft Azure. - -## Value - -Managing your own Kubernetes cluster (as opposed to using a managed-Kubernetes service like AKS), gives you the most flexibility in configuring $[prodname] and Kubernetes. $[prodname] combines flexible networking capabilities with "run-anywhere" security enforcement to provide a solution with native Linux kernel performance and true cloud-native scalability. - -## Concepts - -**aks-engine** is an open-source tool for creating and managing Kubernetes clusters in Microsoft Azure. It is the core technology for Microsoft’s Azure Kubernetes Service (AKS), but allows you to manage the cluster yourself. - -## Before you begin... - -- Install [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) -- Install [Azure CLI tools](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) - -## How to - -There are many ways to install and manage Kubernetes in Azure. This guide shows how to use **aks-engine** to deploy a cluster with **Azure’s CNI plugin for networking** and **$[prodname] for network policy enforcement**. The advantage of this approach is that pods are assigned IP addresses associated with Azure Network Interfaces on worker nodes. The IPs come from the VNet network pool and therefore do not require NAT to access resources outside the Kubernetes cluster. However, there are other options that may work better for your environment. - -- [aks-engine for Azure networking and Calico network policy](#aks-engine-for-azure-networking-and-calico-network-policy) -- [Other options and tools](#other-options-and-tools) - -### aks-engine for Azure networking and Calico network policy - -[Install aks-engine](https://github.com/Azure/aks-engine/blob/master/docs/tutorials/quickstart.md#install-aks-engine) on your workstation. - -Before deploying, customize your cluster definition to use $[prodname] for network policy. Add or modify the `kubernetesConfig` section to include the following (see the [aks-engine documentation](https://github.com/Azure/aks-engine/blob/master/docs/topics/clusterdefinitions.md#kubernetesconfig) for other Kubernetes configuration settings). - -``` -"kubernetesConfig": { - "networkPlugin": "azure", - "networkPolicy": "calico" - } -``` - -Or, start with this [example cluster definition](https://github.com/Azure/aks-engine/blob/master/examples/networkpolicy/kubernetes-calico-azure.json) with these value already set, and customize to meet your needs. - -Then, [follow the aks-engine documentation to deploy your cluster](https://github.com/Azure/aks-engine/blob/master/docs/tutorials/quickstart.md#deploy), passing your cluster definition to `aks-engine deploy` via the `-m` flag. - -The geeky details of what you get: - -{' '} - -### Other options and tools - -#### $[prodname] networking - -You can also deploy $[prodname] for both networking and policy enforcement. In this mode, $[prodname] uses a VXLAN-based overlay network that masks the IP addresses of the pods from the underlying Azure VNet. This can be useful in large deployments or when running multiple clusters and IP address space is a big concern. - -Unfortunately, aks-engine does not support this mode, so you must use a different tool chain to install and manage the cluster. Some options: - -- Use [Terraform](#terraform) to provision the Azure networks and VMs, then [kubeadm](#kubeadm) to install the Kubernetes cluster. -- Use [Kubespray](#kubespray) - -### Terraform - -Terraform is a tool for automating infrastructure provisioning using declarative configurations. You can also go as far as automating the install of Docker, kubeadm, and Kubernetes using Terraform “provisioners.” See the [Terraform documentation](https://developer.hashicorp.com/terraform) for more details. - -#### kubeadm - -[kubeadm](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/) is a command line tool for bootstrapping a Kubernetes cluster on top of already-provisioned compute resources, like VMs in a cloud or bare metal hosts. Unlike aks-engine which handles provisioning cloud resources, installing Kubernetes, and installing $[prodname], kubeadm only handles the second step of installing Kubernetes. You should proceed to install $[prodname] after completing kubeadm install. - -#### Kubespray - -[Kubespray](https://kubespray.io/) is a tool for provisioning and managing Kubernetes clusters with support for multiple clouds including Azure. $[prodname] is the default networking provider, or you can set the `kube_network_plugin` variable to `calico`. See the [Kubespray docs](https://kubespray.io/#/?id=network-plugins) for more details. - -## Next steps - -**Required** - -- [Install and configure calicoctl](../../../operations/calicoctl/install.mdx) - -**Recommended** - -- [Try out $[prodname] network policy](../../../network-policy/get-started/calico-policy/calico-network-policy.mdx) diff --git a/calico_versioned_docs/version-3.29/getting-started/kubernetes/self-managed-public-cloud/do.mdx b/calico_versioned_docs/version-3.29/getting-started/kubernetes/self-managed-public-cloud/do.mdx deleted file mode 100644 index 18100aec66..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/kubernetes/self-managed-public-cloud/do.mdx +++ /dev/null @@ -1,129 +0,0 @@ ---- -description: Use Calico with a self-managed Kubernetes cluster in DigitalOcean (DO). -title: Installing on Digital Ocean ---- - -# Self-managed Kubernetes in DigitalOcean (DO) - -## Big picture - -This tutorial creates a self-managed Kubernetes cluster (1 Master, 2 Worker nodes) using $[prodname] networking in DigitalOcean. - -## Value - -Managing your own Kubernetes cluster (as opposed to using a managed-Kubernetes service like EKS), gives you the most flexibility in configuring $[prodname] and Kubernetes. $[prodname] combines flexible networking capabilities with "run-anywhere" security enforcement to provide a solution with native Linux kernel performance and true cloud-native scalability. - -## Concepts - -Kubernetes Operations (kOps) is a cluster management tool that handles provisioning cluster VMs and installing Kubernetes. It has built-in support for using $[prodname] as the Kubernetes networking provider. - -:::note - -kOps support for DigitalOcean is currently in the early stages of development and subject to change. -More information can be viewed [at this link.](https://kops.sigs.k8s.io/getting_started/digitalocean/) - -::: - -## Before you begin... - -- Install [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) -- Install [kOps](https://kops.sigs.k8s.io/install/) - -## How to - -There are many ways to install and manage Kubernetes in DO. Using Kubernetes Operations (kOps) is a good default choice for most people, as it gives you access to all of $[prodname]’s [flexible and powerful networking features](../../../networking/index.mdx). However, there are other options that may work better for your environment. - -The geeky details of what you get: - - - -### Generate your DigitalOcean API token - -An API token is needed by kOps for the CRUD (Create, Read, Update and Delete) operations necessary for resources in your DigitalOcean account. -Use [this link](https://www.digitalocean.com/docs/apis-clis/api/create-personal-access-token/) to generate your API token and then export it as an environment variable. - -```bash -export DIGITALOCEAN_ACCESS_TOKEN= -``` - -### Create an object storage - -DigitalOcean provides an S3 compatible storage API that kOps uses object storage to save your cluster status. -You should create a Space using [this link](https://www.digitalocean.com/docs/spaces/how-to/create/) and export it. - -```bash -export KOPS_STATE_STORE=do:// -export S3_ENDPOINT= -``` - -:::note - -Using FQDN for `S3_ENDPOINT` causes an error. -If your Space FQDN is `my-test-space.nyc3.digitaloceanspaces.com` just export `my-test-space` as `` . - -::: - -### Generate an API key for object storage - -Access to object storage requires an API key. -Follow this [tutorial](https://www.digitalocean.com/docs/spaces/how-to/manage-access/) and generate your keys then export them as environment variables. - -```bash -export S3_ACCESS_KEY_ID= -export S3_SECRET_ACCESS_KEY= -``` - -### Enable kOps alpha feature - -Enable alpha feature support using `KOPS_FEATURE_FLAGS` environment variable. - -```bash - export KOPS_FEATURE_FLAGS="AlphaAllowDO" -``` - -### Create your cluster - -kOps supports various options that enables you to customize your cluster the way you like. - -1. Add Calico to your cluster using `--networking=calico`. -1. kOps requires an external DNS server to create a cluster, by adding `.k8s.local` suffix to `--name=` option - you generate a [gossip](https://kops.sigs.k8s.io/gossip/) DNS to bypass this requirement. - -:::note - -You can view a complete list of options supported by kOps -[in this link.](https://kops.sigs.k8s.io/cli/kops_create_cluster/#options) - -::: - -```bash - kops create cluster --cloud=digitalocean --name=calico-demo.k8s.local \ - --networking=calico --master-zones=nyc1 --zones=nyc1 \ - --master-count=1 --api-loadbalancer-type=public \ - --node-size=s-1vcpu-2gb --image=ubuntu-20-04-x64 --yes -``` - -You can further customize the $[prodname] install with [options listed in the kOps documentation](https://kops.sigs.k8s.io/networking/calico). - -## Cleanup - -If you wish to remove resources created by this tutorial - -```bash -kops delete cluster calico-demo.k8s.local --yes -``` - -Use the DigitalOcean web UI to remove the API tokens and Space you created. - -## Next steps - -**Required** - -- [Install and configure calicoctl](../../../operations/calicoctl/install.mdx) - -**Recommended** - -- [Try out $[prodname] network policy](../../../network-policy/get-started/calico-policy/calico-network-policy.mdx) diff --git a/calico_versioned_docs/version-3.29/getting-started/kubernetes/self-managed-public-cloud/gce.mdx b/calico_versioned_docs/version-3.29/getting-started/kubernetes/self-managed-public-cloud/gce.mdx deleted file mode 100644 index f719284cc6..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/kubernetes/self-managed-public-cloud/gce.mdx +++ /dev/null @@ -1,236 +0,0 @@ ---- -description: Use Calico with a self-managed Kubernetes cluster in Google Compute Engine (GCE). -title: Installing on GCE ---- - -# Self-managed Kubernetes in Google Compute Engine (GCE) - -## Big picture - -Use $[prodname] with a self-managed Kubernetes cluster in Google Compute Engine (GCE). - -## Value - -Managing your own Kubernetes cluster (as opposed to using a managed-Kubernetes service like GKE) gives you the most flexibility in configuring $[prodname] and Kubernetes. $[prodname] combines flexible networking capabilities with "run-anywhere" security enforcement to provide a solution with native Linux kernel performance and true cloud-native scalability. - -## Concepts - -**kubeadm** is a cluster management tool that is used to install Kubernetes. - -## Before you begin... - -[Install and configure the Google Cloud CLI tools](https://docs.cloud.google.com/sdk/docs/install) - -## How to - -There are many ways to install and manage Kubernetes in GCE. Using kubeadm is a good default choice for most people, as it gives you access to all of $[prodname]’s [flexible and powerful networking features](../../../networking/index.mdx). However, there are other options that may work better for your environment. - -- [kubeadm for Calico networking and network policy](#kubeadm-for-calico-networking-and-network-policy) -- [Other tools and options](#other-tools-and-options) - -### kubeadm for Calico networking and network policy - -#### Create cloud resources - -You will need at least one VM to serve as a control plane node and one or more worker nodes. (It is possible to have control plane nodes also act as workers. This is not recommended in most cases and not covered by this guide.) See [requirements](../requirements.mdx) for specific OS requirements for these VMs. - -The following worked example creates a single control node and three workers on a dedicated virtual private network (VPC). Adjust the example as needed for your requirements. Consider a dedicated infrastructure management tool like [Terraform](https://www.terraform.io/) for managing cloud resources. (This example is adapted from [Kubernetes the Hard Way](https://github.com/kelseyhightower/kubernetes-the-hard-way/blob/master/docs/03-compute-resources.md).) - -1. Create the VPC. - - ```bash - gcloud compute networks create example-k8s --subnet-mode custom - ``` - -2. Create the k8s-nodes subnet in the example-k8s VPC network: - - ```bash - gcloud compute networks subnets create k8s-nodes \ - --network example-k8s \ - --range 10.240.0.0/24 - ``` - -3. Create a firewall rule that allows internal communication across TCP, UDP, ICMP and IP in IP (used for the Calico overlay): - - ```bash - gcloud compute firewall-rules create example-k8s-allow-internal \ - --allow tcp,udp,icmp,ipip \ - --network example-k8s \ - --source-ranges 10.240.0.0/24 - ``` - -4. Create a firewall rule that allows external SSH, ICMP, and HTTPS: - - ```bash - gcloud compute firewall-rules create example-k8s-allow-external \ - --allow tcp:22,tcp:6443,icmp \ - --network example-k8s \ - --source-ranges 0.0.0.0/0 - ``` - -5. Create the controller VM. - - ```bash - gcloud compute instances create controller \ - --async \ - --boot-disk-size 200GB \ - --can-ip-forward \ - --image-family ubuntu-2204-lts \ - --image-project ubuntu-os-cloud \ - --machine-type n1-standard-2 \ - --private-network-ip 10.240.0.11 \ - --scopes compute-rw,storage-ro,service-management,service-control,logging-write,monitoring \ - --subnet k8s-nodes \ - --zone us-central1-f \ - --tags example-k8s,controller - ``` - -6. Create three worker VMs. - - ```bash - for i in 0 1 2; do - gcloud compute instances create worker-${i} \ - --async \ - --boot-disk-size 200GB \ - --can-ip-forward \ - --image-family ubuntu-2204-lts \ - --image-project ubuntu-os-cloud \ - --machine-type n1-standard-2 \ - --private-network-ip 10.240.0.2${i} \ - --scopes compute-rw,storage-ro,service-management,service-control,logging-write,monitoring \ - --subnet k8s-nodes \ - --zone us-central1-f \ - --tags example-k8s,worker - done - ``` -7. Install Docker on the controller VM and each worker VM. On each VM run: - - ```bash - sudo apt update - sudo apt install -y docker.io - sudo systemctl enable docker.service - sudo apt install -y apt-transport-https curl - ``` - -#### Install Kubernetes and create the cluster - -1. Install `kubeadm`,` kubelet`, and `kubectl` on each worker node and the controller node (see [kubeadm docs](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-kubeadm-kubelet-and-kubectl) for more details). - - Connect to each node and run these commands: - - ```bash - curl -fsSL https://dl.k8s.io/apt/doc/apt-key.gpg | sudo apt-key add - - cat < --discovery-token-ca-cert-hash sha256: - ``` - -5. Verify that all nodes have joined. - - Run this command on the controller node. - - ```bash - kubectl get nodes - ``` - -which should output something similar to: - -``` -NAME STATUS ROLES AGE VERSION -controller NotReady master 5m49s v1.17.2 -worker-0 NotReady 3m38s v1.17.2 -worker-1 NotReady 3m7s v1.17.2 -worker-2 NotReady 5s v1.17.2 -``` - -#### Install $[prodname] - -1. On the controller, install $[prodname] using the operator: - - ```bash - kubectl create -f $[manifestsUrl]/manifests/tigera-operator.yaml - ``` - -2. Download the custom resources necessary to configure $[prodname] - - ```bash - curl $[manifestsUrl]/manifests/custom-resources.yaml -O - ``` - -3. If you wish to customize the $[prodname] install, customize the downloaded custom-resources.yaml manifest. Then create the manifest to install $[prodname]. - - ```bash - kubectl create -f custom-resources.yaml - ``` - -The geeky details of what you get: - -{' '} - -### Other tools and options - -#### Terraform - -You may have noticed that the bulk of the above instructions are about provisioning the Google Cloud resources for the cluster and installing Kubernetes. Terraform is a tool for automating infrastructure provisioning using declarative configurations. You can also go as far as automating the install of Docker, kubeadm, and Kubernetes using Terraform “provisioners.” See the [Terraform documentation](https://developer.hashicorp.com/terraform) for more details. - -#### Kubespray - -[Kubespray](https://kubespray.io/) is a tool for provisioning and managing Kubernetes clusters with support for multiple clouds including Google Compute Engine. Calico is the default networking provider, or you can set the `kube_network_plugin` variable to `calico`. See the Kubespray docs for more details. See the [Kubespray docs](https://kubespray.io/#/?id=network-plugins) for more details. - -## Next steps - -**Required** - -- [Install and configure calicoctl](../../../operations/calicoctl/install.mdx) - -**Recommended** - -- [Try out $[prodname] network policy](../../../network-policy/get-started/calico-policy/calico-network-policy.mdx) diff --git a/calico_versioned_docs/version-3.29/getting-started/kubernetes/vpp/getting-started.mdx b/calico_versioned_docs/version-3.29/getting-started/kubernetes/vpp/getting-started.mdx deleted file mode 100644 index c41cbf0927..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/kubernetes/vpp/getting-started.mdx +++ /dev/null @@ -1,437 +0,0 @@ ---- -description: Install Calico with the VPP data plane on a Kubernetes cluster. ---- - -# Get started with VPP networking - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - -## Big picture - -Install $[prodname] and enable the VPP data plane. - -## Value - -The VPP data plane mode has several advantages over standard Linux networking pipeline mode: - -- Scales to higher throughput, especially with WireGuard encryption enabled -- Further improves encryption performance with IPsec -- Native support for Kubernetes services without needing kube-proxy, which: - - Reduces first-packet latency for packets to services - - Preserves external client source IP addresses all the way to the pod - -The VPP data plane is entirely compatible with the other $[prodname] data planes, meaning you can have a cluster with VPP-enabled nodes along with regular nodes. This makes it possible to migrate a cluster from Linux or eBPF networking to VPP networking. - -In addition, the VPP data plane offers some specific features for network-intensive applications, such as providing `memif` userspace packet interfaces to the pods (instead of regular Linux network devices), or exposing the VPP Host Stack to run optimized L4+ applications in the pods. - -:::note - -The VPP data plane has some minor behavioural differences wrt the other $[prodname] data planes and some of the features are not supported. For details please refer to [Known issues & unsupported features](./specifics.mdx). -Please report bugs on the [Calico Users slack](https://calicousers.slack.com/archives/C017220EXU1) or [GitHub](https://github.com/projectcalico/vpp-dataplane/issues)). - -::: - -## Concepts - -### VPP - -The Vector Packet Processor (VPP) is a high-performance, open-source userspace network data plane written in C, developed under the [fd.io](https://fd.io) umbrella. It supports many standard networking features (L2 switching, L3 routing, NAT, encapsulations), and is easily extensible using plugins. The VPP data plane uses plugins to efficiently implement Kubernetes services load balancing and $[prodname] policies. - -### Operator based installation - -This guide uses the Tigera Operator to install $[prodname]. The operator provides lifecycle management for $[prodname] -exposed via the Kubernetes API defined as a custom resource definition. While it is also technically possible to install $[prodname] -and configure it for VPP using manifests directly, only operator based installations are supported at this stage. - -## How to - -This guide details ways to install $[prodname] with the VPP data plane: - -- On a managed EKS cluster. This is the option that requires the least configuration. -- On a managed EKS cluster with the DPDK interface driver. This options is more complex to set up but provides better performance. -- On any Kubernetes cluster. - -In all cases, here are the details of what you will get: - - - - - - -## Install Calico with the VPP data plane on an EKS cluster - -### Requirements - -For these instructions, we will use `eksctl` to provision the cluster. However, you can use any of the methods in [Getting Started with Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html) - -Before you get started, make sure you have downloaded and configured the [necessary prerequisites](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html#eksctl-prereqs) - -### Provision the cluster - -1. First, create an Amazon EKS cluster without any nodes. - - ```bash - eksctl create cluster --name my-calico-cluster --without-nodegroup - ``` - -1. Since this cluster will use $[prodname] for networking, you must delete the `aws-node` DaemonSet to disable the default AWS VPC networking for the pods. - - ```bash - kubectl delete daemonset -n kube-system aws-node - ``` - -### Install and configure Calico with the VPP data plane - -1. Now that you have an empty cluster configured, you can install the Tigera Operator. - - ```bash - kubectl create -f $[manifestsUrl]/manifests/tigera-operator.yaml - ``` - - :::note - - Due to the large size of the CRD bundle, `kubectl apply` might exceed request limits. Instead, use `kubectl create` or `kubectl replace`. - - ::: - -1. Then, you need to configure the $[prodname] installation for the VPP data plane. The yaml in the link below contains a minimal viable configuration for EKS. For more information on configuration options available in this manifest, see [the installation reference](../../../reference/installation/api.mdx). - - :::note - - Before applying this manifest, read its contents and make sure its settings are correct for your environment. For example, - you may need to specify the default IP pool CIDR to match your desired pod network CIDR. - - ::: - - ```bash - kubectl create -f https://raw.githubusercontent.com/projectcalico/vpp-dataplane/$[vppbranch]/yaml/calico/installation-eks.yaml - ``` - -1. Now is time to install the VPP data plane components. - - ```bash - kubectl create -f https://raw.githubusercontent.com/projectcalico/vpp-dataplane/$[vppbranch]/yaml/generated/calico-vpp-eks.yaml - ``` - -1. Finally, add nodes to the cluster. - - ```bash - eksctl create nodegroup --cluster my-calico-cluster --node-type t3.medium --node-ami auto --max-pods-per-node 50 - ``` - - :::tip - - The --max-pods-per-node option above, ensures that EKS does not limit the [number of pods based on node-type](https://github.com/awslabs/amazon-eks-ami/blob/main/nodeadm/internal/kubelet/eni-max-pods.txt). For the full set of node group options, see `eksctl create nodegroup --help`. - - ::: - - - - -## Install Calico with the VPP data plane on an EKS cluster with the DPDK driver - -### Requirements - -DPDK provides better performance compared to the standard install but it requires some additional customisations (hugepages, for instance) in the EKS worker instances. We have a bash script, [init_eks.sh](https://raw.githubusercontent.com/projectcalico/vpp-dataplane/$[vppbranch]/scripts/init_eks.sh), which takes care of applying the required customizations and we make use of the `preBootstrapCommands` property of `eksctl` [configuration file](https://eksctl.io/usage/schema) to execute the script during the worker node creation. These instructions require the latest version of `eksctl`. - -### Provision the cluster - -1. First, create an Amazon EKS cluster without any nodes. - - ```bash - eksctl create cluster --name my-calico-cluster --without-nodegroup - ``` - -2. Since this cluster will use $[prodname] for networking, you must delete the `aws-node` DaemonSet to disable the default AWS VPC networking for the pods. - - ```bash - kubectl delete daemonset -n kube-system aws-node - ``` - -### Install and configure Calico with the VPP data plane - -1. Now that you have an empty cluster configured, you can install the Tigera Operator. - - ```bash - kubectl create -f $[manifestsUrl]/manifests/tigera-operator.yaml - ``` - - :::note - - Due to the large size of the CRD bundle, `kubectl apply` might exceed request limits. Instead, use `kubectl create` or `kubectl replace`. - - ::: - -2. Then, you need to configure the $[prodname] installation for the VPP data plane. The yaml in the link below contains a minimal viable configuration for EKS. For more information on configuration options available in this manifest, see [the installation reference](../../../reference/installation/api.mdx). - - :::note - - Before applying this manifest, read its contents and make sure its settings are correct for your environment. For example, - you may need to specify the default IP pool CIDR to match your desired pod network CIDR. - - ::: - - ```bash - kubectl create -f https://raw.githubusercontent.com/projectcalico/vpp-dataplane/$[vppbranch]/yaml/calico/installation-eks.yaml - ``` - -3. Now is time to install the VPP data plane components. - - ```bash - kubectl create -f https://raw.githubusercontent.com/projectcalico/vpp-dataplane/$[vppbranch]/yaml/generated/calico-vpp-eks-dpdk.yaml - ``` - -4. Finally, time to add nodes to the cluster. Since we need to customize the nodes for DPDK, we will use an `eksctl` config file with the `preBootstrapCommands` property to create the worker nodes. The following command will create a managed nodegroup with 2 t3.large worker nodes in the cluster: - - ``` - cat < - ``` - - For details on ssh access refer to [Amazon EC2 key pairs and Linux instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html). - - - - -## Install Calico with the VPP data plane on any Kubernetes cluster - -### Requirements - -The VPP data plane has the following requirements: - -#### Required - -- A blank Kubernetes cluster, where no CNI was ever configured. -- These [base requirements](../requirements.mdx), except those related to the management of `cali*`, `tunl*` and `vxlan.calico` interfaces. - - :::note - - If you are using `kubeadm` to create the cluster please make sure to specify the pod network CIDR using the `--pod-network-cidr` command-line argument, i.e., `sudo kubeadm init --pod-network-cidr=192.168.0.0/16`. If 192.168.0.0/16 is already in use within your network you must select a different pod network CIDR. - - ::: - -#### Optional - -For some hardware, the following hugepages configuration may enable VPP to use more efficient drivers: - -- At least 512 x 2MB-hugepages are available (`grep HugePages_Free /proc/meminfo`) -- The `vfio-pci` (`vfio_pci` on centos) or `uio_pci_generic` kernel module is loaded. For example: - - ```bash - echo "vfio-pci" > /etc/modules-load.d/95-vpp.conf - modprobe vfio-pci - echo "vm.nr_hugepages = 512" >> /etc/sysctl.conf - sysctl -p - # restart kubelet to take the changes into account - # you may need to use a different command depending on how kubelet was installed - systemctl restart kubelet - ``` - -### Install Calico and configure it for VPP - -1. Start by installing the Tigera Operator on your cluster. - - ```bash - kubectl create -f $[manifestsUrl]/manifests/tigera-operator.yaml - ``` - - :::note - - Due to the large size of the CRD bundle, `kubectl apply` might exceed request limits. Instead, use `kubectl create` or `kubectl replace`. - - ::: - -1. Then, you need to configure the $[prodname] installation for the VPP data plane. The yaml in the link below contains a minimal viable configuration for VPP. For more information on configuration options available in this manifest, see [the installation reference](../../../reference/installation/api.mdx). - - :::note - - Before applying this manifest, read its contents and make sure its settings are correct for your environment. For example, - you may need to specify the default IP pool CIDR to match your desired pod network CIDR. - - ::: - - ```bash - kubectl create -f https://raw.githubusercontent.com/projectcalico/vpp-dataplane/$[vppbranch]/yaml/calico/installation-default.yaml - ``` - -### Install the VPP data plane components - -Start by getting the appropriate yaml manifest file for the VPP data plane resources: - -```bash -# If you have configured hugepages on your machines -curl -o calico-vpp.yaml https://raw.githubusercontent.com/projectcalico/vpp-dataplane/$[vppbranch]/yaml/generated/calico-vpp.yaml -``` - -```bash -# If not, or if you're unsure -curl -o calico-vpp.yaml https://raw.githubusercontent.com/projectcalico/vpp-dataplane/$[vppbranch]/yaml/generated/calico-vpp-nohuge.yaml -``` - -Then locate the `calico-vpp-config` ConfigMap in this yaml manifest file and configure it as follows. - -#### Required Configuration - -- `SERVICE_PREFIX` is the Kubernetes service CIDR. You can retrieve it by running: - - ```bash - kubectl cluster-info dump | grep -m 1 service-cluster-ip-range - ``` - - If this command doesn't return anything, you can leave the default value of `10.96.0.0/12`. - -- `CALICOVPP_INTERFACES` contains a dictionary with parameters specific to interfaces in VPP. The field `uplinkInterfaces` contains a list of uplink interfaces and their configuration, with the first element of the list being the primary/main uplink interface, and the rest (if any) being the secondary host interfaces. You **must** specify at the least the primary/main uplink interface name, for example, - - ```yaml - CALICOVPP_INTERFACES: |- - { - "uplinkInterfaces": [ { "interfaceName": "eth0" } ] - } - ``` - Please make sure that the interface name is that of a valid Linux interface and that it is up and configured with an address. Also, the address configured on this interface **must** be the node address in Kubernetes (`kubectl get nodes -o wide`). - - ##### CALICOVPP_INTERFACES spec - - | Field | Description | Type | - | ---------------- | -------------------------------------------------------- | --------------------------------------------------- | - | maxPodIfSpec | spec containing max values for pod interfaces config | [InterfaceSpec](#interfacespec) | - | defaultPodIfSpec | spec containing default values for pod interfaces config | [InterfaceSpec](#interfacespec) | - | vppHostTapSpec | spec containing config for host tap interface in vpp | [InterfaceSpec](#interfacespec) | - | uplinkInterfaces | list of host interfaces in vpp | List of [UplinkInterfaceSpec](#uplinkinterfacespec) | - - ##### InterfaceSpec - - | Field | Description | Type | Default | - | ------ | ---------------------------------- | -------------------------------------------------- | --------------------------------- | - | rx | Number of RX queues | int | 1 | - | tx | Number of TX queues | int | 1 | - | rxqsz | RX queue size | int | 1024 | - | txqsz | TX queue size | int | 1024 | - | isl3 | Defines the interface mode (L2/L3) | boolean | true for tuntap ; false for memif | - | rxMode | RX mode | string among "interrupt", "adaptive", or "polling" | `adaptive` | - - ##### UplinkInterfaceSpec - - | Field | Description | Type | Default | - | ------------- | -------------------------------------------------------------- | -------------------------------------------------- | ----------------------------- | - | rx | Number of RX queues | int | 1 | - | tx | Number of TX queues | int | 1 | - | rxqsz | RX queue size | int | 1024 | - | txqsz | TX queue size | int | 1024 | - | isl3 | Defines the interface mode (L2/L3) for drivers that support it | boolean | true | - | rxMode | RX mode | string among "interrupt", "adaptive", or "polling" | `adaptive` | - | InterfaceName | interface name | string | unset | - | vppDriver | driver to use in vpp | string | unset | - | newDriver | linux driver to use before passing the interface to VPP | string | unset | - | mtu | the interface's mtu | int | use the existing MTU in linux | - -#### Optional Configuration - -To configure how VPP drives the uplink interface, use the `vppDriver` field in `uplinkInterfaces` in `CALICOVPP_INTERFACES`. - -The supported values will depend on the interface type. Available values are: - -- `""` : will automatically select and try drivers based on interface type and available resources, starting with the fastest -- `af_xdp` : use an AF_XDP socket to drive the interface (requires kernel 5.4 or newer) -- `af_packet` : use an AF_PACKET socket to drive the interface (not optimized but works everywhere) -- `avf` : use the VPP native driver for Intel 700-Series and 800-Series interfaces (requires hugepages) -- `vmxnet3` : use the VPP native driver for VMware virtual interfaces (requires hugepages) -- `virtio` : use the VPP native driver for Virtio virtual interfaces (requires hugepages) -- `rdma` : use the VPP native driver for Mellanox CX-4 and CX-5 interfaces (requires hugepages) -- `dpdk` : use the DPDK interface drivers with VPP (requires hugepages, works with most interfaces) -- `none` : do not configure connectivity automatically. This can be used when [configuring the interface manually](../../../reference/vpp/uplink-configuration.mdx) - -For example, - -```yaml - CALICOVPP_INTERFACES: |- - { - ... - "uplinkInterfaces": [ - { - "interfaceName": "eth0", - "vppDriver": "af_packet" - } - ] - ... - } -``` - -#### Legacy options - -We still maintain legacy support for the `CALICOVPP_INTERFACE` and `CALICOVPP_NATIVE_DRIVER` environment variables. If `CALICOVPP_INTERFACES` is unspecified, `CALICOVPP_INTERFACE` is the primary interface to be used and `CALICOVPP_NATIVE_DRIVER` the uplink driver to be used by VPP. - -`CALICOVPP_INTERFACE` --> `uplinkInterfaces[0].interfaceName` - -`CALICOVPP_NATIVE_DRIVER` --> `uplinkInterfaces[0].vppDriver` - -**Example** - -```yaml noValidation -kind: ConfigMap -apiVersion: v1 -metadata: - name: calico-vpp-config - namespace: calico-vpp-dataplane -data: - ... - CALICOVPP_INTERFACE: eth1 - CALICOVPP_NATIVE_DRIVER: "af_packet" - ... -``` - -:::caution - -Please note that `CALICOVPP_INTERFACE` and `CALICOVPP_NATIVE_DRIVER` are marked **deprecated** and will no longer be supported in the future releases. Please use `CALICOVPP_INTERFACES` instead. - -::: - -### Apply the configuration - -To apply the configuration, run: - -```bash -kubectl create -f calico-vpp.yaml -``` - -This will install all the resources required by the VPP data plane in your cluster. - - - - -## Next steps - -After installing $[prodname] with the VPP data plane, you can benefit from the features of the VPP data plane, such as fast [IPsec](ipsec.mdx) or [WireGuard](../../../network-policy/encrypt-cluster-pod-traffic.mdx) encryption. - -**Tools** - -- [Install and configure calicoctl](../../../operations/calicoctl/install.mdx) to configure and monitor your cluster. - -**Security** - -- [Secure pods with $[prodname] network policy](../../../network-policy/get-started/calico-policy/calico-network-policy.mdx) diff --git a/calico_versioned_docs/version-3.29/getting-started/kubernetes/vpp/index.mdx b/calico_versioned_docs/version-3.29/getting-started/kubernetes/vpp/index.mdx deleted file mode 100644 index fd14bb3b5c..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/kubernetes/vpp/index.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: Install the VPP userspace data plane to unlock extra performance for your cluster! -hide_table_of_contents: true ---- - -# VPP data plane - -import DocCardList from '@theme/DocCardList'; -import { useCurrentSidebarCategory } from '@docusaurus/theme-common'; - - diff --git a/calico_versioned_docs/version-3.29/getting-started/kubernetes/vpp/ipsec.mdx b/calico_versioned_docs/version-3.29/getting-started/kubernetes/vpp/ipsec.mdx deleted file mode 100644 index 8b6e07e303..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/kubernetes/vpp/ipsec.mdx +++ /dev/null @@ -1,166 +0,0 @@ ---- -description: Enable IPsec for faster encryption between nodes when using the VPP data plane. ---- - -# IPsec configuration with VPP - -## Big picture - -Enable IPsec encryption for the traffic flowing between the nodes. - -## Value - -IPsec is the fastest option to encrypt the traffic between nodes. It enables blanket application traffic encryption with very little performance impact. - -## Before you begin... - -To enable IPsec encryption, you will need a Kubernetes cluster with: - -- the [VPP data plane](getting-started.mdx) configured -- [IP-in-IP encapsulation](../../../networking/configuring/vxlan-ipip.mdx) configured between the nodes - -## How to - -- [Create the IKEv2 PSK](#create-the-ikev2-psk) -- [Configure the VPP data plane](#configure-the-vpp-data-plane) - -### Create the IKEv2 PSK - -Create a Kubernetes secret that contains the PSK used for the IKEv2 exchange between the nodes. You can use the following command to create a random PSK. It will generate a unique random key. You may also replace the part after `psk=` with a key of your choice. - -```bash -kubectl -n calico-vpp-dataplane create secret generic calicovpp-ipsec-secret \ - --from-literal=psk="$(dd if=/dev/urandom bs=1 count=36 2>/dev/null | base64)" -``` - -### Configure the VPP data plane - -To enable IPsec, you first need to enable the IPsec feature in the `calico-vpp-config` ConfigMap. - -You can do so with the following kubectl command: - -```bash -kubectl -n calico-vpp-dataplane patch configmap calico-vpp-config --patch "data: - CALICOVPP_FEATURE_GATES: |- - { - \"ipsecEnabled\": true - } -" -``` - -You then need to configure the calico-vpp agent to pass it the key we previously created. -```bash -kubectl -n calico-vpp-dataplane patch daemonset calico-vpp-node --patch "spec: - template: - spec: - containers: - - name: agent - env: - - name: CALICOVPP_IPSEC_IKEV2_PSK - valueFrom: - secretKeyRef: - name: calicovpp-ipsec-secret - key: psk -" -``` -Once IPsec is enabled, all the traffic that uses IP-in-IP encapsulation in the cluster will be automatically encrypted. - -## Next steps - -### Verify encryption - -To verify that the traffic is encrypted, open a VPP debug CLI session to check the configuration with [calivppctl](../../../operations/troubleshoot/vpp.mdx) - -```bash -calivppctl vppctl my-k8s-node-1 -# Alternatively this translates to the following CLI -kubectl -n calico-vpp-dataplane exec calico-vpp-node-XXXX -c vpp -- vppctl -``` - -Then at the `vpp#` prompt, you can run the following commands: - -- `show ikev2 profile` will list the configured IKEv2 profiles, there should be one per other node in your cluster - -As an example on a three-node cluster -``` -vpp# show ikev2 profile -profile pr_172_19_0_5_to_172_19_0_3 - auth-method shared-key-mic auth data somekeysomekeysomekeysomekey - local id-type ip4-addr data 172.19.0.5 - remote id-type ip4-addr data 172.19.0.3 - protected tunnel ipip0 - responder host-eth0 172.19.0.3 - ike-crypto-alg aes-cbc 256 ike-integ-alg sha1-96 ike-dh modp-2048 - esp-crypto-alg aes-gcm-16 256 esp-integ-alg none - lifetime 0 jitter 0 handover 0 maxdata 0 -profile pr_172_19_0_5_to_172_19_0_6 - auth-method shared-key-mic auth data somekeysomekeysomekeysomekey - local id-type ip4-addr data 172.19.0.5 - remote id-type ip4-addr data 172.19.0.6 - protected tunnel ipip1 - lifetime 0 jitter 0 handover 0 maxdata 0 -profile pr_172_19_0_5_to_172_19_0_4 - auth-method shared-key-mic auth data somekeysomekeysomekeysomekey - local id-type ip4-addr data 172.19.0.5 - remote id-type ip4-addr data 172.19.0.4 - protected tunnel ipip2 - responder host-eth0 172.19.0.4 - ike-crypto-alg aes-cbc 256 ike-integ-alg sha1-96 ike-dh modp-2048 - esp-crypto-alg aes-gcm-16 256 esp-integ-alg none - lifetime 0 jitter 0 handover 0 maxdata 0 -``` - -- `show ipip tunnel` will list the interfaces configured in VPP. -``` -vpp# show ipip tunnel -[0] instance 0 src 172.19.0.5 dst 172.19.0.3 table-ID 0 sw-if-idx 9 flags [none] dscp CS0 -[1] instance 1 src 172.19.0.5 dst 172.19.0.6 table-ID 0 sw-if-idx 10 flags [none] dscp CS0 -[2] instance 2 src 172.19.0.5 dst 172.19.0.4 table-ID 0 sw-if-idx 11 flags [none] dscp CS0 -``` - -- `show interface` will show all the interfaces present in VPP with their corresponding states. This includes the ipip interfaces (which correspond to the IPsec tunnels) which should be up. - -``` -vpp# show interface -... -ipip0 9 up 9000/0/0/0 -ipip1 10 up 9000/0/0/0 rx packets 1496 - rx bytes 387772 - tx packets 1687 - tx bytes 662236 - ip4 1496 -ipip2 11 up 9000/0/0/0 -``` - -- `show ipsec protect` shows the SAs being configured on each ipip tunnel. There should be two SAs by ipip tunnel. -``` -vpp# show ipsec protect -ipip0 flags:[none] - output-sa: - [0] sa 2147483648 (0x80000000) spi 2056367583 (0x7a91addf) protocol:esp flags:[esn anti-replay aead ctr ] - input-sa: - [1] sa 3221225472 (0xc0000000) spi 1916941699 (0x72423583) protocol:esp flags:[esn anti-replay inbound aead ctr ] -ipip2 flags:[none] - output-sa: - [2] sa 2147487744 (0x80001000) spi 1305186871 (0x4dcb9237) protocol:esp flags:[esn anti-replay aead ctr ] - input-sa: - [3] sa 3221229568 (0xc0001000) spi 1107274174 (0x41ffa9be) protocol:esp flags:[esn anti-replay inbound aead ctr ] -ipip1 flags:[none] - output-sa: - [4] sa 2147491840 (0x80002000) spi 3581762498 (0xd57d5bc2) protocol:esp flags:[esn anti-replay aead ctr ] - input-sa: - [5] sa 3221233664 (0xc0002000) spi 3002607689 (0xb2f82849) protocol:esp flags:[esn anti-replay inbound aead ctr ] -``` - -- You can see the full list of Security Associations (SAs) with `show ipsec sa`. -``` -vpp# show ipsec sa -[0] sa 2147483648 (0x80000000) spi 2056367583 (0x7a91addf) protocol:esp flags:[esn anti-replay aead ctr ] -[1] sa 3221225472 (0xc0000000) spi 1916941699 (0x72423583) protocol:esp flags:[esn anti-replay inbound aead ctr ] -[2] sa 2147487744 (0x80001000) spi 1305186871 (0x4dcb9237) protocol:esp flags:[esn anti-replay aead ctr ] -[3] sa 3221229568 (0xc0001000) spi 1107274174 (0x41ffa9be) protocol:esp flags:[esn anti-replay inbound aead ctr ] -[4] sa 2147491840 (0x80002000) spi 3581762498 (0xd57d5bc2) protocol:esp flags:[esn anti-replay aead ctr ] -[5] sa 3221233664 (0xc0002000) spi 3002607689 (0xb2f82849) protocol:esp flags:[esn anti-replay inbound aead ctr ] -``` - -You can also [capture the traffic](../../../operations/troubleshoot/vpp.mdx#tracing-packets) flowing between the nodes to verify that it is encrypted. diff --git a/calico_versioned_docs/version-3.29/getting-started/kubernetes/vpp/openshift.mdx b/calico_versioned_docs/version-3.29/getting-started/kubernetes/vpp/openshift.mdx deleted file mode 100644 index 9c4e12da41..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/kubernetes/vpp/openshift.mdx +++ /dev/null @@ -1,209 +0,0 @@ ---- -description: Install Calico VPP on an OpenShift 4 cluster. ---- - -import InstallOpenShiftManifests from '@site/calico_versioned_docs/version-3.29/_includes/components/InstallOpenShiftManifests'; - -# Install an OpenShift 4 cluster with Calico VPP - -## Big picture - -Install an OpenShift 4 cluster with $[prodname] VPP. - -## Value - -Augments the applicable steps in the [OpenShift documentation](https://docs.redhat.com/en/documentation/openshift_container_platform/) -to install $[prodname] VPP. - -## How to - -### Before you begin - -- Ensure that your environment meets the $[prodname] [system requirements](../openshift/requirements.mdx) except those related to the management of `cali*`, `tunl*` and `vxlan.calico` interfaces. - -- Ensure that you have a [RedHat account](https://cloud.redhat.com/). A RedHat account is required to get the pull secret necessary to provision an OpenShift cluster. - -- Currently, we only support installing on AWS with OpenShift **v4.13 or later**, so ensure that you have: - - - Configured an AWS account appropriate for OpenShift 4 - - [Set up your AWS credentials](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/setup-credentials.html) - - Generated a local SSH private key and added it to your ssh-agent - -:::note - -Please note that the OpenShift installer supports only a subset of AWS regions. - -::: - -### Create a configuration file for the OpenShift installer - -Create a staging directory for the installation. This directory will contain the configuration file, along with cluster state files, that the OpenShift installer will create: - -```bash -mkdir openshift-tigera-install && cd openshift-tigera-install -``` - -Run the OpenShift installer to create a default configuration file: - -```bash -openshift-install create install-config -``` - -:::note - -Refer to the [OpenShift installer documentation](https://docs.redhat.com/en/documentation/openshift_container_platform/) for more information -about the installer and any configuration changes required for your platform. - -::: - -Once the installer has finished, your staging directory will contain the configuration file `install-config.yaml`. - -### Update the configuration file to use $[prodname] - -Override the OpenShift networking to use Calico and update the AWS instance types to meet the [system requirements](../openshift/requirements.mdx): - -```bash -sed -i 's/networkType:.*/networkType: Calico/' install-config.yaml -sed -i 's/platform: {}/platform:\n aws:\n type: m5.4xlarge/' install-config.yaml -``` - -### Generate the install manifests - -Generate the Kubernetes manifests using your configuration file: - -```bash -openshift-install create manifests -``` - - - -Download the Calico VPP manifests for OpenShift and add them to the generated manifests directory: - -```bash -mkdir vpp -cd vpp -curl -O "https://raw.githubusercontent.com/projectcalico/vpp-dataplane/$[vppbranch]/yaml/platforms/openshift/00-namespace-calico-vpp-dataplane.yaml" -curl -o 03-cr-installation.yaml "https://raw.githubusercontent.com/projectcalico/vpp-dataplane/$[vppbranch]/yaml/platforms/openshift/01-cr-installation.yaml" -curl -o 02-configmap-calico-vpp-resources.yaml "https://raw.githubusercontent.com/projectcalico/vpp-dataplane/$[vppbranch]/yaml/platforms/openshift/03-configmap-calico-vpp-resources.yaml" -curl -o 02-role-calico-vpp-dataplane.yaml "https://raw.githubusercontent.com/projectcalico/vpp-dataplane/$[vppbranch]/yaml/platforms/openshift/03-role-calico-vpp-dataplane.yaml" -curl -o 02-rolebinding-calico-vpp-dataplane.yaml "https://raw.githubusercontent.com/projectcalico/vpp-dataplane/$[vppbranch]/yaml/platforms/openshift/03-rolebinding-calico-vpp-dataplane.yaml" -curl -o 02-serviceaccount-calico-vpp-dataplane.yaml "https://raw.githubusercontent.com/projectcalico/vpp-dataplane/$[vppbranch]/yaml/platforms/openshift/03-serviceaccount-calico-vpp-dataplane.yaml" -curl -O "https://raw.githubusercontent.com/projectcalico/vpp-dataplane/$[vppbranch]/yaml/platforms/openshift/04-calico-vpp-nohuge.yaml" -cd .. -cp vpp/* manifests/ -``` - -Make sure that `SERVICE_PREFIX` in `manifests/02-configmap-calico-vpp-resources.yaml` matches the service CIDR of the cluster: - -```bash -SERVICE_CIDR=`grep -A1 serviceNetwork: ./manifests/cluster-config.yaml | tail -n1 | cut -d '-' -f2` -sed -i "s#SERVICE_PREFIX:.*#SERVICE_PREFIX:$SERVICE_CIDR#" ./manifests/02-configmap-calico-vpp-resources.yaml -``` - -### Optionally provide additional configuration - -You may want to provide Calico or the VPP data plane with additional configuration at install time. For example, BGP configuration or peers. -You can use a Kubernetes ConfigMap with your desired Calico resources to set configuration as part of the installation. -If you do not need to provide additional configuration, you can skip this section. - -To include [Calico resources](../../../reference/resources/index.mdx) during installation, edit `manifests/02-configmap-calico-resources.yaml` to add your own configuration. - -To customize the configuration of the VPP data plane, edit `manifests/02-configmap-calico-vpp-resources.yaml`. For details refer to the **Configuration options** section of [Getting Started](./getting-started.mdx). - -:::note - -If you have a directory with the Calico resources, you can create the file with the command: - -``` -oc create configmap -n tigera-operator calico-resources \ ---from-file= --dry-run -o yaml \ -manifests/02-configmap-calico-resources.yaml -``` - -With recent versions of `oc` it is necessary to have a kubeconfig configured or add `--server='127.0.0.1:443'` -even though it is not used. - -::: - -:::note - -If you have provided a `calico-resources` ConfigMap and the tigera-operator pod fails to come up with `Init:CrashLoopBackOff`, -check the output of the init-container with `oc logs -n tigera-operator -l k8s-app=tigera-operator -c create-initial-resources`. - -::: - -### Create the cluster - -Start the cluster creation with the following command and wait for it to complete. - -```bash -openshift-install create cluster -``` - -Once the above command is complete, you can verify $[prodname] VPP is installed by verifying the components are available with the following command. - -```bash -oc get tigerastatus -``` - -### Optionally integrate with Operator Lifecycle Manager - -In OpenShift Container Platform, the [Operator Lifecycle Manager (OLM)](https://docs.openshift.com/container-platform/4.4/operators/understanding_olm/olm-understanding-olm.html#olm-overview_olm-understanding-olm) helps -cluster administrators manage the lifecycle of operators in their cluster. Managing the $[prodname] -operator with OLM gives administrators a single place to manage operators. - -1. To register the running $[prodname] operator with OLM, first you will need to create an OperatorGroup for the operator: - -```bash -oc apply -f - < - - -## Create pods on Linux nodes - -First, create a client (busybox) and server (nginx) pod on the Linux nodes: - -```bash -kubectl apply -f - < 80 -``` - -To combine both of the above steps: - -```bash -kubectl exec -n calico-demo busybox -- nc -vz $(kubectl get po porter -n calico-demo -o 'jsonpath={.status.podIP}') 80 -``` - -If the connection from the busybox pod to the porter pod succeeds, we will get output similar to the following: - -``` -192.168.40.166 (192.168.40.166:80) open -``` - -Now let's verify that the powershell pod can reach the nginx pod: - -```bash -kubectl exec -n calico-demo pwsh -- powershell Invoke-WebRequest -Uri http://$(kubectl get po nginx -n calico-demo -o 'jsonpath={.status.podIP}') -UseBasicParsing -TimeoutSec 5 -``` - -If the connection succeeds, we will get output similar to: - -``` -StatusCode : 200 -StatusDescription : OK -Content : - - - Welcome to nginx! - - <... -... -``` - -Finally, let's verify that the powershell pod can reach the porter pod: - -```bash -kubectl exec -n calico-demo pwsh -- powershell Invoke-WebRequest -Uri http://$(kubectl get po porter -n calico-demo -o 'jsonpath={.status.podIP}') -UseBasicParsing -TimeoutSec 5 -``` - -If that succeeds, we will see something like: - -``` -StatusCode : 200 -StatusDescription : OK -Content : This is a $[prodnameWindows] demo. -RawContent : HTTP/1.1 200 OK - Content-Length: 49 - Content-Type: text/plain; charset=utf-8 - Date: Fri, 21 Aug 2020 22:45:46 GMT - - This is a $[prodnameWindows] demo. -Forms : -Headers : {[Content-Length, 49], [Content-Type, text/plain; - charset=utf-8], [Date, Fri, 21 Aug 2020 22:45:46 GMT]} -Images : {} -InputFields : {} -Links : {} -ParsedHtml : -RawContentLength : 49 -``` - -## Apply policy to the Windows client pod - -Now let's apply a basic network policy that allows only the busybox pod to reach the porter pod. - -```bash -kubectl apply -f - < - - -## Installing kubectl on Windows - -To run the commands in this demo you need the Windows version of kubectl installed and add it to the system path. -[Install kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl-windows/) and move the kubectl binary to **c:\k**. - -Add `c:\k` to the system path - -1. Open a PowerShell window as Administrator - - ```powershell - $env:Path += ";C:\k" - ``` - -1. Close all PowerShell windows. - -## Create pods on Linux nodes - -First, create a client (busybox) and server (nginx) pod on the Linux nodes. - -### Create a YAML file policy-demo-linux.yaml using your favorite editor on Windows - -```yaml -apiVersion: v1 -kind: Namespace -metadata: - name: calico-demo - ---- -apiVersion: v1 -kind: Pod -metadata: - labels: - app: busybox - name: busybox - namespace: calico-demo -spec: - containers: - - args: - - /bin/sh - - -c - - sleep 360000 - image: busybox:1.28 - imagePullPolicy: Always - name: busybox - nodeSelector: - kubernetes.io/os: linux - ---- -apiVersion: v1 -kind: Pod -metadata: - labels: - app: nginx - name: nginx - namespace: calico-demo -spec: - containers: - - name: nginx - image: nginx:1.8 - ports: - - containerPort: 80 - nodeSelector: - kubernetes.io/os: linux -``` - -### Apply the policy-demo-linux.yaml file to the Kubernetes cluster - -1. Open a PowerShell window. -1. Use `kubectl` to apply the `policy-demo-linux.yaml` configuration. - -```powershell -kubectl apply -f policy-demo-linux.yaml -``` - -## Create pods on Window nodes - -Next, we’ll create a client (pwsh) and server (porter) pod on the Windows nodes. -:::note - -The pwsh and porter pod manifests below use images based on mcr.microsoft.com/windows/servercore:1809. If you are using a more recent Windows Server version, update the manifests to use a servercore image that matches your Windows Server version. - -::: - -### Create the policy-demo-windows.yaml using your favorite editor on Windows - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: pwsh - namespace: calico-demo - labels: - app: pwsh -spec: - containers: - - name: pwsh - image: mcr.microsoft.com/windows/servercore:1809 - args: - - powershell.exe - - -Command - - 'Start-Sleep 360000' - imagePullPolicy: IfNotPresent - nodeSelector: - kubernetes.io/os: windows ---- -apiVersion: v1 -kind: Pod -metadata: - name: porter - namespace: calico-demo - labels: - app: porter -spec: - containers: - - name: porter - image: calico/porter:1809 - ports: - - containerPort: 80 - env: - - name: SERVE_PORT_80 - value: This is a $[prodnameWindows] demo. - imagePullPolicy: IfNotPresent - nodeSelector: - kubernetes.io/os: windows -``` - -### Apply the policy-demo-windows.yaml file to the Kubernetes cluster - -1. Open a PowerShell window. -1. Use `kubectl` to apply the `policy-demo-windows.yaml` configuration - -```powershell -kubectl apply -f policy-demo-windows.yaml -``` - -### Verify four pods have been created and are running - -:::note - -Launching the Windows pods is going to take some time depending on your network download speed. - -::: - -1. Open a PowerShell window. -1. Using `kubectl` to list the pods in the `calico-demo` namespace. - -```powershell -kubectl get pods --namespace calico-demo -``` - -You should see something like the below - -```output -NAME READY STATUS RESTARTS AGE -busybox 1/1 Running 0 4m14s -nginx 1/1 Running 0 4m14s -porter 0/1 ContainerCreating 0 74s -pwsh 0/1 ContainerCreating 0 2m9s -``` - -Repeat the command every few minutes until the output shows all 4 pods in the Running state. - -```output -NAME READY STATUS RESTARTS AGE -busybox 1/1 Running 0 7m24s -nginx 1/1 Running 0 7m24s -porter 1/1 Running 0 4m24s -pwsh 1/1 Running 0 5m19s -``` - -### Check connectivity between pods on Linux and Windows nodes - -Now that client and server pods are running on both Linux and Windows nodes, let’s verify that client pods on Linux nodes can reach server pods on Windows nodes. - -1. Open a PowerShell window. -1. Using `kubectl` to determine the porter pod IP address: - - ```powershell - kubectl get pod porter --namespace calico-demo -o 'jsonpath={.status.podIP}' - ``` - -1. Log into the busybox pod and try reaching the porter pod on port 80. Replace the `` tag with the IP address returned from the previous command. - - ```powershell - kubectl exec --namespace calico-demo busybox -- nc -vz 80 - ``` - - :::note - - You can also combine both of the above steps: - - ::: - - ```powershell - kubectl exec --namespace calico-demo busybox -- nc -vz $(kubectl get pod porter --namespace calico-demo -o 'jsonpath={.status.podIP}') 80 - ``` - - If the connection from the busybox pod to the porter pod succeeds, you will get output similar to the following: - - ```powershell - 192.168.40.166 (192.168.40.166:80) open - ``` - - :::note - - The IP addresses returned will vary depending on your environment setup. - - ::: - -1. Now you can verify that the pwsh pod can reach the nginx pod: - - ```powershell - kubectl exec --namespace calico-demo pwsh -- powershell Invoke-WebRequest -Uri http://$(kubectl get po nginx -n calico-demo -o 'jsonpath={.status.podIP}') -UseBasicParsing -TimeoutSec 5 - ``` - - If the connection succeeds, you will see output similar to: - - ``` - StatusCode : 200 - StatusDescription : OK - Content : - - - Welcome to nginx! - - <... - ``` - -1. Verify that the pwsh pod can reach the porter pod: - - ```powershell - kubectl exec --namespace calico-demo pwsh -- powershell Invoke-WebRequest -Uri http://$(kubectl get po porter -n calico-demo -o 'jsonpath={.status.podIP}') -UseBasicParsing -TimeoutSec 5 - ``` - - If that succeeds, you will see something like: - - ``` - StatusCode : 200 - StatusDescription : OK - Content : This is a $[prodnameWindows] demo. - RawContent : HTTP/1.1 200 OK - Content-Length: 49 - Content-Type: text/plain; charset=utf-8 - Date: Fri, 21 Aug 2020 22:45:46 GMT - - This is a $[prodnameWindows] demo. - Forms : - Headers : {[Content-Length, 49], [Content-Type, text/plain; - charset=utf-8], [Date, Fri, 21 Aug 2020 22:45:46 GMT]} - Images : {} - InputFields : {} - Links : {} - ParsedHtml : - RawContentLength : 49 - - ``` - -You have now verified that communication is possible between all pods in the application. - -## Apply policy to the Windows client pod - -In a real world deployment you would want to make sure only pods that are supposed to communicate with each other, are actually allowed to do so. - -To achieve this you will apply a basic network policy which allows only the busybox pod to reach the porter pod. - -### Create the network-policy.yaml file using your favorite editor on Windows - -```yaml -apiVersion: networking.k8s.io/v1 -kind: NetworkPolicy -metadata: - name: allow-busybox - namespace: calico-demo -spec: - podSelector: - matchLabels: - app: porter - policyTypes: - - Ingress - ingress: - - from: - - podSelector: - matchLabels: - app: busybox - ports: - - protocol: TCP - port: 80 -``` - -### Apply the network-policy.yaml file - -1. Open a PowerShell window. -1. Use `kubectl` to apply the network-policy.yaml file. - -```powershell -kubectl apply -f network-policy.yaml -``` - -### Verify the policy is in effect - -With the policy in place, the busybox pod should still be able to reach the porter pod: -:::note - -We will be using the combined command line from earlier in this chapter. - -::: - -```powershell -kubectl exec --namespace calico-demo busybox -- nc -vz $(kubectl get po porter -n calico-demo -o 'jsonpath={.status.podIP}') 80 -``` - -However, the pwsh pod will not able to reach the porter pod: - -```powershell -kubectl exec --namespace calico-demo pwsh -- powershell Invoke-WebRequest -Uri http://$(kubectl get po porter -n calico-demo -o 'jsonpath={.status.podIP}') -UseBasicParsing -TimeoutSec 5 -``` - -The request times out with a message like the below: - -```powershell -Invoke-WebRequest : The operation has timed out. -At line:1 char:1 -+ Invoke-WebRequest -Uri http://192.168.40.166 -UseBasicParsing -Timeout ... -+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - + CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:Htt -pWebRequest) [Invoke-WebRequest], WebException - + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand -command terminated with exit code 1 -``` - -## Wrap up - -In this demo we’ve configured pods on Linux and Windows nodes, verified basic pod connectivity, and tried a basic network policy to isolate pod to pod traffic. -As the final step you can clean up all of the demo resources: - -1. Open a PowerShell window. - -```powershell -kubectl delete namespace calico-demo -``` - - - diff --git a/calico_versioned_docs/version-3.29/getting-started/kubernetes/windows-calico/index.mdx b/calico_versioned_docs/version-3.29/getting-started/kubernetes/windows-calico/index.mdx deleted file mode 100644 index 6e0421123d..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/kubernetes/windows-calico/index.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: Install and configure Calico for Windows. -hide_table_of_contents: true ---- - -# Calico for Windows - -import DocCardList from '@theme/DocCardList'; -import { useCurrentSidebarCategory } from '@docusaurus/theme-common'; - - diff --git a/calico_versioned_docs/version-3.29/getting-started/kubernetes/windows-calico/limitations.mdx b/calico_versioned_docs/version-3.29/getting-started/kubernetes/windows-calico/limitations.mdx deleted file mode 100644 index c9f286637b..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/kubernetes/windows-calico/limitations.mdx +++ /dev/null @@ -1,174 +0,0 @@ ---- -description: Review limitations before starting installation. ---- - -# Limitations and known issues - -## $[prodnameWindows] feature limitations - -| Feature | | -| ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Distributions | **Supported:**
    - EKS
    - AKS
    - AWS
    - GCE
    - Azure
    - Kubernetes on-premises
    - Kubernetes on DigitalOcean
    - OpenShift
    - Rancher RKE

    **Not supported**:
    - GKE
    - IKS
    - OpenStack
    - K3s clusters | -| Install and upgrade | **Supported**: - Operator install

    **Not supported**:
    - Non-cluster hosts
    - Typha component for scaling (Linux-based feature) | -| Networking | **Supported**:
    - $[prodname] VXLAN, no cross-subnet or VXLAN MTU settings with [limitations](#$[prodname]-vxlan-networking-limitations)
    - $[prodname] non-overlay mode with BGP peering with [limitations](#$[prodname]-bgp-networking-limitations)
    - IPv4

    **Not supported**:
    - Overlay mode with BGP peering
    - IP in IP overlay with BGP routing
    - Cross-subnet support and MTU setting for VXLAN
    - IPv6 and dual stack
    - Service advertisement | -| Security | **Not supported**:
    - Application Layer Policy (ALP) for Istio
    - Policy for hosts (host endpoints, including automatic host endpoints)
    - Encryption with WireGuard | -| Visibility and troubleshooting | Visibility and troubleshooting | **Not supported**:
    - 'Log' action in network policy | -| Operations | **Supported**:
    - $[prodname] node status | -| Metrics | **Supported**: Prometheus monitoring | -| eBPF | **Not supported**: (Linux-based feature) | - -## $[prodname] BGP networking limitations - -If you are using $[prodname] with BGP, note these current limitations with Windows. - -| Feature | Limitation | -| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| IP mobility/ borrowing | $[prodname] IPAM allocates IPs to host in blocks for aggregation purposes.
    If the IP pool is full, nodes can also "borrow" IPs from another node's block. In BGP terms, the borrower then advertises a more specific "/32" route for the borrowed IP and traffic for that IP only is routed to the borrowing host.

    Windows nodes do not support this borrowing mechanism; they will not borrow IPs even if the IP pool is full and they mark their blocks so that Linux nodes will not borrow from them. | -| IPs reserved for Windows | $[prodname] IPAM allocates IPs in CIDR blocks. Due to networking requirements on Windows, four IPs per Windows node-owned block must be reserved for internal purposes.

    For example, with the default block size of /26, each block contains 64 IP addresses, 4 are reserved for Windows, leaving 60 for pod networking.

    To reduce the impact of these reservations, a larger block size can be configured at the IP pool scope (before any pods are created). | -| Single IP block per host | $[prodname] IPAM is designed to allocate blocks of IPs (default size /26) to hosts on demand. While the $[prodname] CNI plugin was written to do the same, kube-proxy currently only supports a single IP block per host.

    To work around the default limit of one /26 per host there some options:

    - With $[prodname] BGP networking and the etcd datastore before creating any blocks, change the block size used by the IP pool so that it is sufficient for the largest number of Pods that are to be used on a single Windows host.
    - Use $[prodname] BGP networking with the kubernetes datastore. In that mode, $[prodname] IPAM is not used and the CNI host-local IPAM plugin is used with the node's Pod CIDR.

    To allow multiple IPAM blocks per host (at the expense of kube-proxy compatibility), set the `windows_use_single_network` flag to `false` in the `cni.conf.template` before installing $[prodname]. Changing that setting after pods are networked is not recommended because it may leak HNS endpoints. | -| IP-in-IP overlay | $[prodname]'s IPIP overlay mode cannot be used in clusters that contain Windows nodes because Windows does not support IP-in-IP. | -| NATOutgoing | $[prodname] IP pools support a "NAT outgoing" setting with the following behaviour:

    - Traffic between $[prodname] workloads (in any IP pools) is not NATted.
    - Traffic leaving the configured IP pools is NATted if the workload has an IP within an IP pool that has NAT outgoing enabled. $[prodnameWindows] honors the above setting but it is only applied at pod creation time. If the IP pool configuration is updated after a pod is created, the pod's traffic will continue to be NATted (or not) as before. NAT policy for newly-networked pods will honor the new configuration. $[prodnameWindows] automatically adds the host itself and its subnet to the NAT exclusion list. This behaviour can be disabled by setting flag `windows_disable_host_subnet_nat_exclusion` to `true` in `cni.conf.template` before running the install script. | -| Service IP advertisement | This $[prodname] feature is not supported on Windows. | - -### Check your network configuration - -If you are using a networking type that requires layer 2 reachability (such as $[prodname] with a BGP mesh and no peering to your fabric), you can check that your network has layer 2 reachability as follows: - -On each of your nodes, check the IP network of the network adapter that you plan to use for pod networking. For example, on Linux, assuming your network adapter is eth0, you can run: - -``` -$ ip addr show eth0 - 2: eth0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 - - link/ether 00:0c:29:cb:c8:19 brd ff:ff:ff:ff:ff:ff - inet 192.168.171.136/24 brd 192.168.171.255 scope - - global eth0 - valid_lft forever preferred_lft forever - inet6 fe80::20c:29ff:fecb:c819/64 scope - link - - valid_lft forever preferred_lft - forever -``` - -In this case, the IPv4 is 192.168.171.136/24; which, after applying the /24 mask gives 192.168.171.0/24 for the IP network. - -Similarly, on Windows, you can run - -``` -PS C:\> ipconfig - -Windows IP Configuration - -Ethernet adapter vEthernet (Ethernet 2): - - Connection-specific DNS Suffix . : - us-west-2.compute.internal Link-local IPv6 Address . . . . - . : fe80::6d10:ccdd:bfbe:bce2%15 IPv4 Address. . . . . . . - . . . . : 172.20.41.103 Subnet Mask . . . . . . . . . . . - : 255.255.224.0 Default Gateway . . . . . . . . . : - 172.20.32.1 - -``` - -In this case, the IPv4 address is 172.20.41.103 and the mask is represented as bytes 255.255.224.0 rather than CIDR notation. Applying the mask, we get a network address 172.20.32.0/19. - -Because the linux node has network 192.168.171.136/24 and the Windows node has a different network, 172.20.32.0/19, they are unlikely to be on the same layer 2 network. - -## $[prodname] VXLAN networking limitations - -Because of differences between the Linux and Windows data plane feature sets, the following $[prodname] features are not supported on Windows. - -| Feature | Limitation | -| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| IPs reserved for Windows | $[prodname] IPAM allocates IPs in CIDR blocks. Due to networking requirements on Windows, four IPs per Windows node-owned block must be reserved for internal purposes.

    For example, with the default block size of /26, each block contains 64 IP addresses, 4 are reserved for Windows, leaving 60 for pod networking.

    To reduce the impact of these reservations, a larger block size can be configured at the IP pool scope (before any pods are created). | -| Single IP block per host | $[prodname] IPAM is designed to allocate blocks of IPs (default size /26) to hosts on demand. While the $[prodname] CNI plugin was written to do the same, kube-proxy currently only supports a single IP block per host.
    To allow multiple IPAM blocks per host (at the expense of kube-proxy compatibility), set the `windows_use_single_network` flag to `false` in the `cni.conf.template` before installing $[prodname]. Changing that setting after pods are networked is not recommended because it may leak HNS endpoints. | - -## Routes are lost in cloud providers - -If you create a Windows host with a cloud provider (AWS for example), the creation of the vSwitch at $[prodname] install time can remove the cloud provider's metadata route. If your application relies on the metadata service, you may need to examine the routing table before and after installing $[prodname] to reinstate any lost routes. - -## VXLAN limitations - -**VXLAN support** - -- Windows 1903 build 18317 and above -- Windows 1809 build 17763 and above - -**Configuration updates** - -Certain configuration changes will not be honored after the first pod is networked. This is because Windows does not currently support updating the VXLAN subnet parameters after the network is created so updating those parameters requires the node to be drained: - -One example is the VXLAN VNI setting. To change such parameters: - -- Drain the node of all pods -- Delete the $[prodname] HNS network: - - ```powershell - Import-Module -DisableNameChecking $[rootDirWindows]\libs\hns\hns.psm1 - Get-HNSNetwork | ? Name -EQ "$[prodname]" | Remove-HNSNetwork - ``` - -- Update the configuration in `config.ps1`, run `uninstall-calico.ps1` and then `install-calico.ps1` to regenerate the CNI configuration. - -## Pod-to-pod connections are dropped with TCP reset packets - -Restarting Felix or changes to policy (including changes to endpoints referred to in policy), can cause pod-to-pod connections to be dropped with TCP reset packets. When one of the following occurs: - -- The policy that applies to a pod is updated -- Some ingress or egress policy that applies to a pod contains selectors and the set of endpoints that those selectors match changes - -Felix must reprogram the HNS ACL policy attached to the pod. This reprogramming can cause TCP resets. Microsoft has confirmed this is a HNS issue, and they are investigating. - -## Service ClusterIPs incompatible with selectors/pod IPs in network policy - -**Windows 1809 prior to build 17763.1432** - -On Windows nodes, kube-proxy unconditionally applies source NAT to traffic from local pods to service ClusterIPs. This means that, at the destination pod, where policy is applied, the traffic appears to come from the source host rather than the source pod. In turn, this means that a network policy with a source selector matching the source pod will not match the expected traffic. - -## Network policy and using selectors - -Under certain conditions, relatively simple $[prodname] policies can require significant Windows data plane resources, that can cause significant CPU and memory usage, and large policy programming latency. - -We recommend avoiding policies that contain rules with both a source and destination selector. The following is an example of a policy that would be inefficient. The policy applies to all workloads, and it only allows traffic from workloads labeled as clients to workloads labeled as servers: - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: calico-dest-selector -spec: - selector: all() - order: 500 - ingress: - - action: Allow - destination: - selector: role == "webserver" - source: - selector: role == "client" -``` - -Because the policy applies to all workloads, it will be rendered once per workload (even if the workload is not labeled as a server), and then the selectors will be expanded into many individual data plane rules to capture the allowed connectivity. - -Here is a much more efficient policy that still allows the same traffic: - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: calico-dest-selector -spec: - selector: role == "webserver" - order: 500 - ingress: - - action: Allow - source: - selector: role == "client" -``` - -The destination selector is moved into the policy selector, so this policy is only rendered for workloads that have the `role: webserver` label. In addition, the rule is simplified so that it only matches on the source of the traffic. Depending on the number of webserver pods, this change can reduce the data plane resource usage by several orders of magnitude. - -## Next steps - -- [Install $[prodnameWindows] using operator](operator.mdx) diff --git a/calico_versioned_docs/version-3.29/getting-started/kubernetes/windows-calico/operator.mdx b/calico_versioned_docs/version-3.29/getting-started/kubernetes/windows-calico/operator.mdx deleted file mode 100644 index a6f5a5933d..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/kubernetes/windows-calico/operator.mdx +++ /dev/null @@ -1,126 +0,0 @@ ---- -description: Install Calico for Windows on a Kubernetes cluster for testing or development. ---- - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; -import CalicoWindowsInstall from '@site/calico_versioned_docs/version-3.29/_includes/components/CalicoWindowsInstall'; - -# Install using Operator - -## Big picture - -Install $[prodnameWindows] on your Kubernetes cluster using the Tigera Operator. - -## Concepts - -$[prodnameWindows] is a hybrid implementation that requires a Linux cluster for $[prodname] components and Linux workloads, and Windows nodes for Windows workloads. - -## Before you begin - -Review the [Linux requirements](../requirements.mdx) and the [$[prodnameWindows] requirements](requirements.mdx). - -Before beginning, setup a $[prodname] cluster on Linux nodes and provision Windows machines. - -## How to - -- [Configure strict affinity for clusters using $[prodname] networking](#configure-strict-affinity-for-clusters-using-calico-networking) -- [Install $[prodnameWindows] using the operator](#install-calico-for-windows-using-the-operator) - -### Configure strict affinity for clusters using $[prodname] networking - -For Linux control nodes using $[prodname] networking, strict affinity must be set to `true`. -This is required to prevent Linux nodes from borrowing IP addresses from Windows nodes: - -```bash -kubectl patch ipamconfigurations default --type merge --patch='{"spec": {"strictAffinity": true}}' -``` - -:::note - -If the above command failed to find ipamconfigurations resource, you need to install the Calico API server. Please refer to [installing the Calico API server](../../../operations/install-apiserver.mdx). - -::: - -### Install $[prodnameWindows] using the operator - -With Kubernetes v1.22, there is a new Windows container type called **HostProcess containers (HPC)** that can run directly on the host with access to the host network namespace, -storage, and devices. With this feature, $[prodnameWindows] can now be installed and managed using Kubernetes resources such as Daemonsets and ConfigMaps, -instead of needing to configure and install $[prodnameWindows] manually on each node. Using this installation method, the $[prodnameWindows] -services are no longer registered on the host. Instead, the services are run directly within HostProcess containers. - -#### HPC requirements - -In addition to the [$[prodnameWindows] requirements](requirements.mdx), -this installation method has [additional requirements](https://kubernetes.io/docs/tasks/configure-pod-container/create-hostprocess-pod/): - -- Kubernetes v1.22+ -- Enable HostProcess containers support. For Kubernetes v1.22, see [here](https://kubernetes.io/docs/tasks/configure-pod-container/create-hostprocess-pod/#before-you-begin). For Kubernetes v1.23+, HostProcess containers are enabled by default. -- [containerd](https://kubernetes.io/docs/setup/production-environment/container-runtimes/#containerd) v1.6+ -- The Windows nodes have joined the cluster. - -To install containerd on the Windows node and configure the containerd service: - -```powershell -Invoke-WebRequest $[windowsScriptsURL]/Install-Containerd.ps1 -OutFile c:\Install-Containerd.ps1 -c:\Install-Containerd.ps1 -ContainerDVersion 1.6.22 -skipHypervisorSupportCheck -CNIConfigPath "c:/etc/cni/net.d" -CNIBinPath "c:/opt/cni/bin" -``` - -If you have an existing $[prodnameWindows] installation using the manual method, your Windows nodes may have already joined the cluster. - -To join a Windows node to a cluster provisioned with kubeadm: - -- Install kubeadm and kubelet binaries and install the kubelet service - -```powershell -Invoke-WebRequest $[windowsScriptsURL]/PrepareNode.ps1 -OutFile c:\PrepareNode.ps1 -c:\PrepareNode.ps1 -KubernetesVersion v1.26.6 -``` - -- Run kubeadm on a control plane host and copy the join command - -```bash -kubeadm token create --print-join-command -``` - -- Edit the join command by updating the kubeadm.exe path to `c:\k\kubeadm.exe`. -- If using a Kubernetes version earlier than v1.25, also append `--cri-socket "npipe:////./pipe/containerd-containerd"` to the join command. - An example join command: - -``` -c:\k\kubeadm.exe join 172.16.101.139:6443 --token v8w2jt.jmc45acn85dbll1e --discovery-token-ca-cert-hash sha256:d0b7040a704d8deb805ba1f29f56bbc7cea8af6aafa78137a9338a62831739b4 --cri-socket "npipe:////./pipe/containerd-containerd" -``` - -- Run the join command on the Windows node. Shortly after it completes successfully, the Windows node will appear in `kubectl get nodes`. - The new node's status will be NotReady since the Calico CNI has not yet been installed. - -#### Migrate from $[prodnameWindows] manual installation to operator installation - -The HPC installation in this guide is operator-based and will automatically migrate your Windows nodes that have $[prodnameWindows] installed using the manual installation method. This installation process will uninstall any existing $[prodnameWindows] services and overwrite the $[prodnameWindows] installation files with those included in the `calico/cni-windows` and `calico/node-windows` images. If `kubelet` was installed using `$[rootDirWindows]\kubernetes\install-kube-services.ps1`, this service will remain installed. If the `kube-proxy` service was also installed using `$[rootDirWindows]\kubernetes\install-kube-services.ps1`, it will be stopped and uninstalled by the `calico-node-windows` HPC initContainers. It is recommended to run `kube-proxy-windows` as hostprocess container images using the [manifest provided in the kubernetes-sigs sig-windows-tools repository](https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/hostprocess/calico/kube-proxy/kube-proxy.yml). - -:::note - -Before proceeding, take note of the configuration parameters in `$[rootDirWindows]\config.ps1`. These configuration parameters will be needed during the install. - -::: - -#### Operator installation - - - - - - - - - - - - - - -Congratulations! You now have a Kubernetes cluster with $[prodnameWindows] and a Linux control node. - -## Next steps - -You can now use the $[prodname] Linux-based docs site for your documentation. Before you continue, review the [Limitations and known issues](limitations.mdx) to understand the features (and sections of documentation) that do not apply to Windows. diff --git a/calico_versioned_docs/version-3.29/getting-started/kubernetes/windows-calico/rancher.mdx b/calico_versioned_docs/version-3.29/getting-started/kubernetes/windows-calico/rancher.mdx deleted file mode 100644 index 756751764d..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/kubernetes/windows-calico/rancher.mdx +++ /dev/null @@ -1,126 +0,0 @@ ---- -description: Install Calico for Windows on a Rancher RKE cluster. ---- - -# Calico for Windows on a Rancher Kubernetes Engine cluster - -## Big picture - -Install $[prodnameWindows] on a Rancher Kubernetes Engine (RKE) cluster. - -## Value - -Run Linux and Windows workloads on a RKE cluster with $[prodname]. - -## Before you begin - -**Supported** - -- RKE Kubernetes 1.20, 1.19, or 1.18 - -**Supported networking** - -- BGP with no encapsulation -- VXLAN - -**Required** - -- An RKE cluster provisioned with [no network plugin](https://rancher.com/docs/rke/latest/en/config-options/add-ons/network-plugins#disabling-deployment-of-a-network-plug-in) - but which otherwise meets the $[prodnameWindows] Kubernetes [cluster requirements](requirements.mdx). This guide was tested with RKE v1.18.9. -- One or more Windows nodes that meet the [requirements](requirements.mdx). - -## How to - -The following steps will outline the installation of $[prodname] networking on the RKE cluster, then the installation of $[prodnameWindows] on the Windows nodes. - -1. Install the Tigera Operator and custom resource definitions. - - ``` - kubectl create -f $[manifestsUrl]/manifests/tigera-operator.yaml - ``` - - :::note - - Due to the large size of the CRD bundle, `kubectl apply` might exceed request limits. Instead, use `kubectl create` or `kubectl replace`. - - ::: - -1. Download the necessary Installation custom resources. - - ```bash - wget $[manifestsUrl]/manifests/custom-resources.yaml - ``` - -1. Update the `calicoNetwork` options, ensuring that the correct pod CIDR is set. (Rancher uses `10.42.0.0/16` by default.) - Below are sample installations for VXLAN and BGP networking using the default Rancher pod CIDR: - - **VXLAN** - - ```yaml - apiVersion: operator.tigera.io/v1 - kind: Installation - metadata: - name: default - spec: - # Configures Calico networking. - calicoNetwork: - bgp: Disabled - ipPools: - - blockSize: 26 - cidr: 10.42.0.0/16 - encapsulation: VXLAN - natOutgoing: Enabled - nodeSelector: all() - ``` - - **BGP** - - ```yaml - apiVersion: operator.tigera.io/v1 - kind: Installation - metadata: - name: default - spec: - # Configures Calico networking. - calicoNetwork: - ipPools: - - blockSize: 26 - cidr: 10.42.0.0/16 - encapsulation: None - natOutgoing: Enabled - nodeSelector: all() - ``` - - :::note - - For more information on configuration options available in this manifest, see [the installation reference](../../../reference/installation/api.mdx). - - ::: - -1. Apply the updated custom resources: - - ```bash - kubectl create -f custom-resources.yaml - ``` - -1. Configure strict affinity: - - ```bash - kubectl patch ipamconfigurations default --type merge --patch='{"spec": {"strictAffinity": true}}' - ``` - -1. Finally, install $[prodnameWindows]. For an operator installation, follow the [operator guide](operator.mdx). - For VXLAN clusters, follow the instructions under the "Kubernetes VXLAN" tab. For BGP clusters, follow the instructions under the "Kubernetes BGP" tab. - - :::note - - For Rancher default values for service CIDR and DNS cluster IP, see the [Rancher kube-api service options](https://rancher.com/docs/rke/latest/en/config-options/services/#kubernetes-api-server-options). - - ::: - -1. Check the status of the nodes with `kubectl get nodes`. If you see that the Windows node has the status `Ready`, then you have a $[prodnameWindows] on RKE cluster ready for Linux and Windows workloads! - -## Next steps - -- [Try the basic policy demo](demo.mdx) -- [Secure pods with $[prodname] network policy](../../../network-policy/get-started/calico-policy/calico-network-policy.mdx) diff --git a/calico_versioned_docs/version-3.29/getting-started/kubernetes/windows-calico/requirements.mdx b/calico_versioned_docs/version-3.29/getting-started/kubernetes/windows-calico/requirements.mdx deleted file mode 100644 index 55748de380..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/kubernetes/windows-calico/requirements.mdx +++ /dev/null @@ -1,108 +0,0 @@ ---- -description: Review the requirements for Calico for Windows. ---- - -# Requirements - -## What's supported in this release - -✓ Install: -- Operator install for Kubernetes clusters using hostprocess containers (HPC) on Windows nodes - -✓ Platforms: Kubernetes, OpenShift, RKE, EKS, AKS - -✓ Networking: - -- Kubernetes, on-premises: Calico CNI with BGP or VXLAN -- OpenShift: Calico CNI with BGP or VXLAN -- Rancher Kubernetes Engine: Calico CNI with BGP or VXLAN -- EKS: VPC CNI -- AKS: Azure CNI - -## Requirements - -Because the Kubernetes and $[prodname] control components do not run on Windows yet, a hybrid Linux/Windows cluster is required. - -### CNI and networking options - -The following table summarizes the networking options and considerations. - -| Networking | Components | **Value/Content** | -| ------------------ | ------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| $[prodname] BGP | Windows CNI plugin:

    calico.exe

    Linux: $[prodname] for policy and networking | $[prodname]'s native networking approach, supports:
    - Auto-configured node-to-node BGP mesh over an L2 fabric
    - Peering with external routers for an L3 fabric
    - $[prodname] IPAM and IP aggregation (with some limitations)
    - Route reflectors (including the new in-cluster route reflector introduced in $[prodname] v3.3). **Note**: Windows node cannot act as route reflectors.
    - Kubernetes API datastore driver

    **AWS users**: If running on AWS, you must disable the source/dest check on your EC2 instances so that hosts can forward traffic on behalf of pods. | -| $[prodname] VXLAN | Windows CNI plugin:
    calico.exe

    Linux: $[prodname] for policy and networking | $[prodname]'s VXLAN overlay, supports:

    - VXLAN overlay, which can traverse most networks.
    - Auto-configured node-to-node routing
    - $[prodname] IPAM and IP aggregation (with some limitations)
    - Kubernetes API datastore driver
    **Note**: VXLAN runs on UDP port 4789 (this is the only port supported by Windows), remember to open that port between your $[prodname] hosts in any firewalls / security groups. | -| Cloud provider | Windows CNI plugin: win-bridge.exe

    Linux: $[prodname] policy-only | A useful fallback, particularly if you have a Kubernetes cloud provider that automatically installs inter-host routes. $[prodname] has been tested with the standard **win-bridge.exe** CNI plugin so it should work with any networking provider that ultimately uses win-bridge.exe to network the pod (such as the Azure CNI plugin and cloud provider). | - -:::note - -If Calico CNI with VXLAN is used, BGP must be disabled. See the [installation reference](../../../reference/installation/api.mdx#bgpoption). - -::: - -### Datastores - -When using Operator install, only Kubernetes datastore (kdd) is supported. - -### Kubernetes version - -See the [Kubernetes requirements](../requirements.mdx#kubernetes-requirements). - -When using Operator install and Windows hostprocess containers (HPC), see [here for the additional requirements](operator.mdx#hpc-requirements). - -Earlier versions may work, but we do not actively test $[prodnameWindows] against them, and they may have known issues and incompatibilities. - -### Linux platform requirements - -- At least one Linux Kubernetes worker node to run $[prodname]'s cluster-wide components that meets [Linux system requirements](../requirements.mdx), and is installed with $[prodname]. $[prodname] v3.27+ is required for Operator installs. -- VXLAN or BGP without encapsulation is supported if using $[prodname] CNI. IPIP ($[prodname]'s default encapsulation mode) is not supported. Use the following command to turn off IPIP on the default IP pool. - - ```bash - kubectl patch ippool default-ipv4-ippool -p '{"spec":{"ipipMode":"Never","vxlanMode":"Always"}}' - ``` - -- If using $[prodname] IPAM, strict affinity of IPAM configuration must be set to `true`. - - ```bash - kubectl patch ipamconfigurations default --type merge --patch='{"spec": {"strictAffinity": true}}' - ``` - -:::note - -For operator-managed Linux $[prodname] clusters, three Linux worker nodes are required to meet the high-availability requirements for Typha, which only runs on Linux nodes. - -::: - -### Windows platform requirements - -- Windows versions: - - - Windows Server 1809 (build 17763.1432 or later) - - Windows Server 2022 (build 20348.169 or later) - - :::note - - Windows Server version support differs for each Kubernetes version. Review the [Windows OS Version Support](https://kubernetes.io/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#windows-os-version-support) table for the Windows Server versions supported by each Kubernetes version. - - ::: - -#### Operator install requirements - -- Kubernetes v1.22+ -- Enable HostProcess containers support. For Kubernetes v1.22, see [here](https://kubernetes.io/docs/tasks/configure-pod-container/create-hostprocess-pod/#before-you-begin). For Kubernetes v1.23+, HostProcess containers are enabled by default. -- [containerd](https://kubernetes.io/docs/setup/production-environment/container-runtimes/#containerd) v1.6.0+ -- The Windows nodes have joined the cluster. -- See [this section of the operator install guide for example commands](operator.mdx#hpc-requirements). - -### EKS requirements - -- The VPC controllers must be installed to run Windows pods. -- An instance role on the Windows instance must have permissions to get `namespaces` and get `secrets` in the calico-system namespace (or kube-system namespace if you are using a non operator-managed $[prodname] installation.) - -### AKS requirements - -- $[prodnameWindows] can be enabled only on newly created clusters. -- Non-HPC $[prodnameWindows] is available with Kubernetes version 1.20 or later - -## Next steps - -[Install Calico for Windows using operator](operator.mdx) diff --git a/calico_versioned_docs/version-3.29/getting-started/kubernetes/windows-calico/troubleshoot.mdx b/calico_versioned_docs/version-3.29/getting-started/kubernetes/windows-calico/troubleshoot.mdx deleted file mode 100644 index 0deda89104..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/kubernetes/windows-calico/troubleshoot.mdx +++ /dev/null @@ -1,197 +0,0 @@ ---- -description: Help for troubleshooting Calico for Windows issues in Calico this release. ---- - -# Troubleshoot Calico for Windows - -## Useful troubleshooting commands - -**Examine the HNS network(s)** - -When using the $[prodname] CNI plugin, each $[prodname] IPAM block (or the single podCIDR in host-local IPAM mode), is represented as a HNS l2bridge network. Use the following command to inspect the networks. - -```powershell -ipmo -DisableNameChecking $[rootDirWindows]\libs\hns\hns.psm1 -Get-HNSNetwork -``` - -**Examine pod endpoints** - -Use the following command to view the HNS endpoints on the system. There should be one HNS endpoint per pod networked with $[prodname]: - -```powershell -ipmo -DisableNameChecking $[rootDirWindows]\libs\hns\hns.psm1 -Get-HNSEndpoint -``` - -## Troubleshoot - -### kubectl exec fails with timeout for Windows pods - -Ensure that the Windows firewall (and any network firewall or cloud security group) allows traffic to the host on port 10250. - -### kubelet fails to register, complains of node not found in logs - -This can be caused by a mismatch between a cloud provider (such as the AWS cloud provider) and the configuration of the node. For example, the AWS cloud provider requires that the node has a nodename matching its private domain name. - -### After initializing $[prodnameWindows], AWS metadata server is no longer reachable - -This is a known Windows issue that Microsoft is working on. The route to the metadata server is lost when the vSwitch is created. As a workaround, manually add the route back by running: - -```powershell -New-NetRoute -DestinationPrefix 169.254.169.254/32 -InterfaceIndex -``` - -Where `` is the index of the "vEthernet (Ethernet 2)" device as shown by - -```powershell -Get-NetAdapter -``` - -### Installation stalls at "Waiting for $[prodname] initialization to finish" - -This can be caused by Window's Execution protection feature. Exit the install using Ctrl-C, unblock the scripts, run `uninstall-calico.ps1`, followed by `install-calico.ps1`. - -### Windows Server 2019 insider preview: after rebooting a node, $[prodnameWindows] fails to start, the tigera-node.err.log file contains errors - -After rebooting the Windows node, pods fail to schedule, and the kubelet log has CNI errors like "timed out waiting for interface matching the management IP (169.254.57.5) of network" (where the IP address may vary but will always be a 169.254.x.x address). To workaround: - -- Stop and then start $[prodnameWindows] using the `stop-calico.ps1` and `start-calico.ps1` scripts -- Sometimes the HNS network picks up a temporary self-assigned address at start-of-day and it does not get refreshed when the correct IP becomes known. Rebooting the node a second time often resolves the problem. - -### Invoke-Webrequest fails with TLS errors - -The error, "The request was aborted: Could not create SSL/TLS secure channel", often means that Windows does not support TLS v1.2 (which is required by many websites) by default. To enable TLS v1.2, run the following command: - -```powershell -[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 -``` - -### Kubelet persistently fails to contact the API server - -If kubelet is already running when $[prodnameWindows] is installed, the creation of the container vSwitch can cause kubelet to lose its connection and then persistently fail to reconnect to the API server. -To resolve this, restart kubelet after installing $[prodnameWindows]. - -### No connectivity between pods on Linux and Windows nodes - -If using AWS, check that the source/dest check is disabled on the interfaces assigned to your nodes. This allows nodes to forward traffic on behalf of local pods. -In AWS, the "Change Source/Dest. Check" option can be found on the Actions menu for a selected network interface. - -If using $[prodname] networking, check that the $[prodname] IP pool you are using has IPIP mode disabled (set to "Never). IPIP is not supported on Windows. To check the IP pool, you can use `calicoctl`: - -```bash -calicoctl get ippool -o yaml -``` - -Example output of an IP pool with IPIP disabled: - -```yaml -apiVersion: projectcalico.org/v3 -items: - - apiVersion: projectcalico.org/v3 - kind: IPPool - metadata: - creationTimestamp: 2018-11-26T15:37:39Z - name: default-ipv4-ippool - resourceVersion: '172' - uid: 34db7316-f191-11e8-ad7d-02850eebe6c4 - spec: - blockSize: 26 - cidr: 192.168.0.0/16 - disabled: true - ipipMode: Never - natOutgoing: true -``` - -### Felix starts, but does not output logs - -By default, Felix waits to connect to the datastore before logging (in case the datastore configuration intentionally disables logging). To start logging at startup, update the [FELIX_LOGSEVERITYSCREEN environment variable](../../../reference/felix/configuration.mdx) to "info" or "debug" level. - -### $[prodname] BGP mode: connectivity issues, Linux calico/node pods report unready - -Check the detailed health output that shows which health check failed: - -``` -kubectl describe pod -n calico-system -``` - -:::note - -Use namespace `kube-system` instead of `calico-system` if your Calico installation is non operator-managed. - -::: - -If the health check reports a BGP peer failure, check the IP address of the peer is either an -expected IP of a node or an external BGP peer. If the IP of the failed peering is a Windows node: - -- Check that the node is up a reachable over IP -- Check that the RemoteAccess service is installed and running: - - ```powershell - Get-Service | ? Name -EQ RemoteAccess - ``` - -- Check the logs for the confd service in the configured log directory for errors - (default $[rootDirWindows]\logs). - -**Examine BGP state on a Windows host** - -The Windows BGP router exposes its configuration and state as PowerShell commandlets. - -**To show BGP peers**: - -```powershell -Get-BgpPeer -``` - -Example output: - -``` -PeerName LocalIPAddress PeerIPAddress PeerASN OperationMode ConnectivityStatus --------- -------------- ------------- ------- ------------- ------------------ -Mesh_172_20_48_43 172.20.55.101 172.20.48.43 64512 Mixed Connected -Mesh_172_20_51_170 172.20.55.101 172.20.51.170 64512 Mixed Connected -Mesh_172_20_54_3 172.20.55.101 172.20.54.3 64512 Mixed Connected -Mesh_172_20_58_252 172.20.55.101 172.20.58.252 64512 Mixed Connected -For an established peering, the ConnectivityStatus column should be "Connected". -``` - -**To examine routes learned from other hosts**: - -```powershell -Get-BgpRouteInformation -Type all -``` - -Example output: - -``` -DestinationNetwork NextHop LearnedFromPeer State LocalPref MED ------------------- ------- --------------- ----- --------- --- -10.243.128.192/26 172.20.58.252 Mesh_172_20_58_252 Best 100 -10.244.115.128/26 172.20.48.43 Mesh_172_20_48_43 Best 100 -10.244.128.192/26 172.20.58.252 Mesh_172_20_58_252 Best 100 -``` - -For active routes, the State should show as "Best". Routes with State equal to "Unresolved" -indicate that the BGP router could not resolve a route to the peer and the route will not be -used. This can occur if the networking state changes after the BGP router is started; -restarting the BGP router may solve the problem: - -```powershell -Restart-Service RemoteAccess -``` - -To see the routes being exported by this host: - -```powershell -(Get-BgpCustomRoute).Network -``` - -Example output: - -``` -10.243.214.152/29 -10.243.214.160/29 -10.243.214.168/29 -10.244.42.0/26 -``` diff --git a/calico_versioned_docs/version-3.29/getting-started/openstack/index.mdx b/calico_versioned_docs/version-3.29/getting-started/openstack/index.mdx deleted file mode 100644 index 5057d063c4..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/openstack/index.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: Install Calico networking and network policy for OpenStack. -hide_table_of_contents: true ---- - -# OpenStack - -import DocCardList from '@theme/DocCardList'; -import { useCurrentSidebarCategory } from '@docusaurus/theme-common'; - - diff --git a/calico_versioned_docs/version-3.29/getting-started/openstack/installation/devstack.mdx b/calico_versioned_docs/version-3.29/getting-started/openstack/installation/devstack.mdx deleted file mode 100644 index 495a98ca21..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/openstack/installation/devstack.mdx +++ /dev/null @@ -1,83 +0,0 @@ ---- -description: Quickstart to show connectivity between DevStack and Calico. ---- - -# DevStack - -$[prodname] provides a DevStack plugin. The following -instructions explain how to set up a single or multiple node DevStack/$[prodname] -system, and then how to see $[prodname] connectivity in action. - -:::note - -$[prodname] includes a -[shell script](https://github.com/projectcalico/calico/blob/master/networking-calico/devstack/bootstrap.sh) -that implements the following setup instructions. You are welcome to use it, -but we recommend that you read the following description first anyway, and -briefly review the script's code, so that you will understand what the -script does. - -::: - -## Single (or first) node setup - -To prepare a single node DevStack/$[prodname] system, that is with all controller -and compute functions running on the same node: - -1. Download DevStack as usual. - -2. Add to your DevStack local.conf file: - - ```bash - enable_plugin calico https://github.com/projectcalico/calico - ``` - -3. Run `stack.sh`. - -4. Create a shared, routed network with an IPv4 subnet: - - ```bash - . openrc admin admin - neutron net-create --shared --provider:network_type local calico - neutron subnet-create --gateway 10.65.0.1 --enable-dhcp --ip-version 4 --name calico-v4 calico 10.65.0/24 - ``` - -5. Ensure that IPv4 and IPv6 forwarding are enabled: - - ```bash - sysctl -w net.ipv4.ip_forward=1 - sysctl -w net.ipv6.conf.all.forwarding=1 - ``` - -## Multi-node setup - -This plugin also supports additional compute-only nodes. So, in the system as -a whole, there can then be: - -- one node with both controller and compute function - -- any number of additional nodes with just compute function. - -The first node should be prepared as described above. Then, for each -additional compute node: - -- set and export the SERVICE_HOST environment variable, to the name of the - controller node; for example: - - ```bash - export SERVICE_HOST=calico-vm18 - ``` - -- follow the steps above, except for the network and subnet creations, to - install and set up DevStack with $[prodname] on that node. - -## Demonstrating $[prodname] connectivity - -Then, to see $[prodname] connectivity in action: - -1. Launch instances attached to the 'calico' network. - -2. Use `ip route` to observe per-instance routes created by the $[prodname] agent. - -3. Log into each instance (e.g. through Horizon console) and verify that it can - ping the others. diff --git a/calico_versioned_docs/version-3.29/getting-started/openstack/installation/index.mdx b/calico_versioned_docs/version-3.29/getting-started/openstack/installation/index.mdx deleted file mode 100644 index 3e4dfe81db..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/openstack/installation/index.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: Install Calico on OpenStack -hide_table_of_contents: true ---- - -# Install Calico on OpenStack - -import DocCardList from '@theme/DocCardList'; -import { useCurrentSidebarCategory } from '@docusaurus/theme-common'; - - diff --git a/calico_versioned_docs/version-3.29/getting-started/openstack/installation/overview.mdx b/calico_versioned_docs/version-3.29/getting-started/openstack/installation/overview.mdx deleted file mode 100644 index 24df7acae3..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/openstack/installation/overview.mdx +++ /dev/null @@ -1,17 +0,0 @@ ---- -description: Choose a method for installing Calico for OpenStack. ---- - -# Calico on OpenStack - -There are many ways to try out $[prodname] with OpenStack. We provide instructions for the -following methods: - -- [Package-based install for Ubuntu](ubuntu.mdx) - -- [RPM-based install for Red Hat Enterprise Linux (RHEL)](redhat.mdx) - -- [DevStack](devstack.mdx) (for development purposes only—not recommended for production!) - -In all cases, except DevStack, you will need at least two or three servers to -get going: one OpenStack controller and one or more OpenStack compute nodes. diff --git a/calico_versioned_docs/version-3.29/getting-started/openstack/installation/redhat.mdx b/calico_versioned_docs/version-3.29/getting-started/openstack/installation/redhat.mdx deleted file mode 100644 index 3f55aaf237..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/openstack/installation/redhat.mdx +++ /dev/null @@ -1,287 +0,0 @@ ---- -description: Install Calico on OpenStack, Red Hat Enterprise Linux nodes. ---- - -# Red Hat Enterprise Linux - -import OpenStackEtcdAuth from '@site/calico_versioned_docs/version-3.29/_includes/content/_openstack-etcd-auth.mdx'; - -These instructions will take you through a first-time install of -$[prodname]. If you are upgrading an existing system, please see -[Upgrading $[prodname] on OpenStack](../../../operations/upgrading/openstack-upgrade.mdx) -instead. - -There are two sections to the install: adding $[prodname] to OpenStack -control nodes, and adding $[prodname] to OpenStack compute nodes. Follow -the [Common steps](#common-steps) on each node before moving on to the specific -instructions in the control and compute sections. If you want to create a -combined control and compute node, work through all three sections. - -## Before you begin - -- Ensure that you meet the [requirements](../requirements.mdx). -- Confirm that you have SSH access to and root privileges on one or more Red Hat - Enterprise Linux (RHEL) hosts. -- Make sure you have working DNS between the RHEL hosts (use `/etc/hosts` if you - don't have DNS on your network). -- [Install OpenStack with Neutron and ML2 networking](http://docs.openstack.org) - on the RHEL hosts. - -## Common steps - -Some steps need to be taken on all machines being installed with $[prodname]. -These steps are detailed in this section. - -1. [Add the EPEL repository](https://fedoraproject.org/wiki/EPEL). You may - have already added this to install OpenStack. - -1. Configure the $[prodname] repository: - - ```bash - cat > /etc/yum.repos.d/calico.repo <` is the IP address of the etcd - server. - - ``` - [calico] - etcd_host = - ``` - -## Control node install - -On each control node, perform the following steps: - -1. Delete all configured OpenStack state, in particular any instances, - routers, subnets and networks (in that order) created by the install - process referenced above. You can do this using the web dashboard or - at the command line. - - :::tip - - The Admin and Project sections of the web dashboard both - have subsections for networks and routers. Some networks may - need to be deleted from the Admin section. - - ::: - - :::caution - - The $[prodname] install will fail if incompatible state is - left around. - - ::: - -1. Edit `/etc/neutron/neutron.conf`. In the `[DEFAULT]` section, find - the line beginning with `core_plugin`, and change it to read `core_plugin = calico`. Also remove any existing setting for `service_plugins`. - -1. Install the `calico-control` package: - - ``` - yum install -y calico-control - ``` - -1. Restart the neutron server process: - - ``` - service neutron-server restart - ``` - -## Compute node install - -On each compute node, perform the following steps: - -1. Open `/etc/nova/nova.conf` and remove the line from the `[DEFAULT]` - section that reads: - - ```conf - linuxnet_interface_driver = nova.network.linux_net.LinuxOVSInterfaceDriver - ``` - - Remove the lines from the `[neutron]` section setting - `service_neutron_metadata_proxy` or `service_metadata_proxy` to - `True`, if there are any. Additionally, if there is a line setting - `metadata_proxy_shared_secret`, comment that line out as well. - - Restart nova compute. - - ```bash - service openstack-nova-compute restart - ``` - - If this node is also a controller, additionally restart nova-api. - - ```bash - service openstack-nova-api restart - ``` - -1. If they're running, stop the Open vSwitch services. - - ```bash - service neutron-openvswitch-agent stop - service openvswitch stop - ``` - - Then, prevent the services running if you reboot. - - ```bash - chkconfig openvswitch off - chkconfig neutron-openvswitch-agent off - ``` - - Then, on your control node, run the following command to find the - agents that you just stopped. - - ``` - neutron agent-list - ``` - - For each agent, delete them with the following command on your - control node, replacing `` with the ID of the agent. - - ``` - neutron agent-delete - ``` - -1. Install Neutron infrastructure code on the compute host. - - ``` - yum install -y openstack-neutron - ``` - -1. Edit `/etc/neutron/neutron.conf`. In the `[oslo_concurrency]` section, - ensure that the `lock_path` variable is uncommented and set as follows. - - ``` - # Directory to use for lock files. For security, the specified directory should - # only be writable by the user running the processes that need locking. - # Defaults to environment variable OSLO_LOCK_PATH. If external locks are used, - # a lock path must be set. - lock_path = $state_path/lock - ``` - -1. Stop and disable the Neutron DHCP agent, and install the - $[prodname] DHCP agent (which uses etcd, allowing it to scale to higher - numbers of hosts). - - ``` - service neutron-dhcp-agent stop - chkconfig neutron-dhcp-agent off - yum install -y calico-dhcp-agent - ``` - -1. Stop and disable any other routing/bridging agents such as the L3 - routing agent or the Linux bridging agent. These conflict - with $[prodname]. - - ```bash - service neutron-l3-agent stop - chkconfig neutron-l3-agent off - ``` - - Repeat for bridging agent and any others. - -1. If this node is not a controller, install and start the Nova - Metadata API. This step is not required on combined compute and - controller nodes. - - ```bash - yum install -y openstack-nova-api - service openstack-nova-metadata-api restart - chkconfig openstack-nova-metadata-api on - ``` - -1. Install the BIRD BGP client. - - ```bash - yum install -y bird bird6 - ``` - -1. Install the `calico-compute` package. - - ```bash - yum install -y calico-compute - ``` - -1. Configure BIRD. By default $[prodname] assumes that you will deploy a - route reflector to avoid the need for a full BGP mesh. To this end, it - includes configuration scripts to prepare a BIRD config file with a single - peering to the route reflector. If that's correct for your network, you can - run either or both of the following commands. - - For IPv4 connectivity between compute hosts: - - ```bash - calico-gen-bird-conf.sh - ``` - - And/or for IPv6 connectivity between compute hosts: - - ```bash - calico-gen-bird6-conf.sh - ``` - - You will also need to [configure your route reflector to allow connections from the compute node as a route reflector client](../../../networking/configuring/bgp.mdx) -. - - If you _are_ configuring a full BGP mesh you need to handle the BGP - configuration appropriately on each compute host. The scripts above can be - used to generate a sample configuration for BIRD, by replacing the - `` with the IP of one other compute host—this will - generate the configuration for a single peer connection, which you can - duplicate and update for each compute host in your mesh. - - To maintain connectivity between VMs if BIRD crashes or is upgraded, - configure BIRD graceful restart. Edit the systemd unit file - /usr/lib/systemd/system/bird.service (and bird6.service for IPv6): - - - Add `-R` to the end of the `ExecStart` line. - - Add `KillSignal=SIGKILL` as a new line in the `[Service]` section. - - Run `systemctl daemon-reload` to tell systemd to reread that file. - - Ensure that BIRD (and/or BIRD 6 for IPv6) is running and starts on - reboot. - - ```bash - service bird restart - service bird6 restart - chkconfig bird on - chkconfig bird6 on - ``` - -1. Create `/etc/calico/felix.cfg` with the following content, where `` is the IP - address of the etcd server. - - ```conf - [global] - DatastoreType = etcdv3 - EtcdAddr = :2379 - EndpointStatusPathPrefix = none - ``` - -1. Restart the Felix service. - - ``` - service calico-felix restart - ``` - - diff --git a/calico_versioned_docs/version-3.29/getting-started/openstack/installation/ubuntu.mdx b/calico_versioned_docs/version-3.29/getting-started/openstack/installation/ubuntu.mdx deleted file mode 100644 index ace1fc4537..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/openstack/installation/ubuntu.mdx +++ /dev/null @@ -1,270 +0,0 @@ ---- -description: Install Calico on OpenStack, Ubuntu nodes. ---- - -# Ubuntu - -import OpenStackEtcdAuth from '@site/calico_versioned_docs/version-3.29/_includes/content/_openstack-etcd-auth.mdx'; - -These instructions will take you through a first-time install of -$[prodname]. If you are upgrading an existing system, please see -[Upgrading $[prodname] on OpenStack](../../../operations/upgrading/openstack-upgrade.mdx) -instead. - -There are two sections to the install: adding $[prodname] to OpenStack -control nodes, and adding $[prodname] to OpenStack compute nodes. Follow -the [Common steps](#common-steps) on each node before moving on to the specific -instructions in the control and compute sections. If you want to create a -combined control and compute node, work through all three sections. - -## Before you begin - -- Ensure that you meet the [requirements](../requirements.mdx). -- Confirm that you have SSH access to and root privileges on one or more Ubuntu hosts - (your OpenStack compute or control nodes). -- [Install OpenStack with Neutron and ML2 networking](http://docs.openstack.org) - on the Ubuntu hosts. - -## Common steps - -Some steps need to be taken on all machines being installed with $[prodname]. -These steps are detailed in this section. - -1. Configure APT to use the $[prodname] PPA: - - ```bash - add-apt-repository ppa:project-calico/$[ppa_repo_name] - ``` - -1. Add the official BIRD PPA. This PPA contains - fixes to BIRD that are not yet available in Ubuntu. To add the PPA, run: - - ```bash - add-apt-repository ppa:cz.nic-labs/bird - ``` - - :::tip - - If the above command fails with error - `'ascii' codec can't decode byte`, try running the command with a - UTF-8 enabled locale: - `LC_ALL=en_US.UTF-8 add-apt-repository ppa:cz.nic-labs/bird`. - - ::: - -1. Update your package manager on each machine: - - ```bash - apt-get update - ``` - -1. Install version 1.0.1 of the `etcd3gw` Python package. This is - needed by $[prodname]'s OpenStack driver and DHCP agent. - - ``` - apt-get install -y python3-pip - pip3 install etcd3gw==1.0.1 - ``` - -1. Edit `/etc/neutron/neutron.conf`. Add a `[calico]` section with - the following content, where `` is the IP address of the etcd - server. - - ``` - [calico] - etcd_host = - ``` - -## Control node install - -On each control node, perform the following steps. - -1. Delete all configured OpenStack state, in particular any instances, - routers, subnets and networks (in that order) created by the install - process referenced above. You can do this using the web dashboard or - at the command line. - - :::tip - - The Admin and Project sections of the web dashboard both - have subsections for networks and routers. Some networks may - need to be deleted from the Admin section. - - ::: - - :::caution - - The $[prodname] install will fail if incompatible state is - left around. - - ::: - -1. Run `apt-get upgrade` and `apt-get dist-upgrade`. These commands - bring in $[prodname]-specific updates to the OpenStack packages and - to `dnsmasq`. - -1. Edit `/etc/neutron/neutron.conf`. In the `[DEFAULT]` section, find - the line beginning with `core_plugin`, and change it to read `core_plugin = calico`. Also remove any existing setting for `service_plugins`. - -1. Install the `calico-control` package: - - ``` - apt-get install -y calico-control - ``` - -1. Restart the Neutron server process: - - ``` - service neutron-server restart - ``` - -## Compute node install - -On each compute node, perform the following steps: - -1. Open `/etc/nova/nova.conf` and remove the line from the `[DEFAULT]` - section that reads: - - ```bash - linuxnet_interface_driver = nova.network.linux_net.LinuxOVSInterfaceDriver - ``` - - Remove the lines from the `[neutron]` section setting - `service_neutron_metadata_proxy` or `service_metadata_proxy` to - `True`, if there are any. - - Restart nova compute. - - ```bash - service nova-compute restart - ``` - -1. If they're running, stop the Open vSwitch services: - - ```bash - service openvswitch-switch stop - service neutron-plugin-openvswitch-agent stop - ``` - - Then, prevent the services running if you reboot: - - ```bash - sh -c "echo 'manual' > /etc/init/openvswitch-switch.override" - sh -c "echo 'manual' > /etc/init/openvswitch-force-reload-kmod.override" - sh -c "echo 'manual' > /etc/init/neutron-plugin-openvswitch-agent.override" - ``` - - Then, on your control node, run the following command to find the - agents that you just stopped: - - ```bash - neutron agent-list - ``` - - For each agent, delete them with the following command on your - control node, replacing `` with the ID of the agent: - - ```bash - neutron agent-delete - ``` - -1. Install some extra packages: - - ```bash - apt-get install -y neutron-common neutron-dhcp-agent nova-api-metadata - ``` - -1. Run `apt-get upgrade` and `apt-get dist-upgrade`. These commands - bring in $[prodname]-specific updates to the OpenStack packages and - to `dnsmasq`. - -1. Edit `/etc/neutron/neutron.conf`. In the `[oslo_concurrency]` section, - ensure that the `lock_path` variable is uncommented and set as follows. - - ``` - # Directory to use for lock files. For security, the specified directory should - # only be writable by the user running the processes that need locking. - # Defaults to environment variable OSLO_LOCK_PATH. If external locks are used, - # a lock path must be set. - lock_path = $state_path/lock - ``` - -1. Install the $[prodname] DHCP agent (which uses etcd, allowing - it to scale to higher numbers of hosts) and disable the Neutron-provided - one: - - ``` - service neutron-dhcp-agent stop - echo manual | tee /etc/init/neutron-dhcp-agent.override - apt-get install -y calico-dhcp-agent - ``` - -1. Install the `calico-compute` package: - - ```bash - apt-get install -y calico-compute - ``` - - This step may prompt you to save your iptables rules to make them - persistent on restart -- hit yes. - -1. Configure BIRD. By default $[prodname] assumes that you will deploy a - route reflector to avoid the need for a full BGP mesh. To this end, it - includes configuration scripts to prepare a BIRD config file with a single - peering to the route reflector. If that's correct for your network, you can - run either or both of the following commands. - - For IPv4 connectivity between compute hosts: - - ```bash - calico-gen-bird-conf.sh - ``` - - And/or for IPv6 connectivity between compute hosts: - - ```bash - calico-gen-bird6-conf.sh - ``` - - You will also need to [configure your route reflector to allow connections from the compute node as a route reflector client](../../../networking/configuring/bgp.mdx) -. - - If you _are_ configuring a full BGP mesh you need to handle the BGP - configuration appropriately on each compute host. The scripts above can be - used to generate a sample configuration for BIRD, by replacing the - `` with the IP of one other compute host -- this will - generate the configuration for a single peer connection, which you can - duplicate and update for each compute host in your mesh. - - To maintain connectivity between VMs if BIRD crashes or is upgraded, - configure BIRD graceful restart: - - - Add `-R` to `BIRD_ARGS` in /etc/bird/envvars (you may need to - uncomment this option). - - Edit the upstart jobs /etc/init/bird.conf and bird6.conf (if - you're using IPv6), and add the following script to it. - - ```bash - pre-stop script - PID=`status bird | egrep -oi '([0-9]+)$' | head -n1` - kill -9 $PID - end script - ``` - -1. Create `/etc/calico/felix.cfg` with the following content, where `` is the IP - address of the etcd server. - - ```conf - [global] - DatastoreType = etcdv3 - EtcdAddr = :2379 - EndpointStatusPathPrefix = none - ``` - -1. Restart the Felix service. - - ``` - service calico-felix restart - ``` - - diff --git a/calico_versioned_docs/version-3.29/getting-started/openstack/installation/verification.mdx b/calico_versioned_docs/version-3.29/getting-started/openstack/installation/verification.mdx deleted file mode 100644 index a657c8fd79..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/openstack/installation/verification.mdx +++ /dev/null @@ -1,175 +0,0 @@ ---- -description: Quick steps to test that your Calico-based OpenStack deployment is running correctly. ---- - -# Verify your deployment - -This document takes you through the steps you can perform to verify that -a $[prodname]-based OpenStack deployment is running correctly. - -## Prerequisites - -This document requires you have the following things: - -- SSH access to the nodes in your $[prodname]-based OpenStack deployment. -- Access to an administrator account on your $[prodname]-based - OpenStack deployment. - -## Procedure - -Begin by creating several instances on your OpenStack deployment using -your administrator account. Confirm that these instances all launch and -correctly obtain IP addresses. - -You'll want to make sure that your new instances are evenly striped -across your hypervisors. On your control node, run: - -```bash -nova list --fields host -``` - -Confirm that there is an even spread across your compute nodes. If there -isn't, it's likely that an error has happened in either nova or $[prodname] -on the affected compute nodes. Check the logs on those nodes for more -logging, and report your difficulty on the mailing list. - -Now, SSH into one of your compute nodes. We're going to verify that the -FIB on the compute node has been correctly populated by $[prodname]. To do -that, run the `route` command. You'll get output something like this: - -``` -Kernel IP routing table -Destination Gateway Genmask Flags Metric Ref Use Iface -default net-vl401-hsrp- 0.0.0.0 UG 0 0 0 eth0 -10.65.0.0 * 255.255.255.0 U 0 0 0 ns-b1163e65-42 -10.65.0.103 npt06.datcon.co 255.255.255.255 UGH 0 0 0 eth0 -10.65.0.104 npt09.datcon.co 255.255.255.255 UGH 0 0 0 eth0 -10.65.0.105 * 255.255.255.255 UH 0 0 0 tap242f8163-08 -10.65.0.106 npt09.datcon.co 255.255.255.255 UGH 0 0 0 eth0 -10.65.0.107 npt07.datcon.co 255.255.255.255 UGH 0 0 0 eth0 -10.65.0.108 npt08.datcon.co 255.255.255.255 UGH 0 0 0 eth0 -10.65.0.109 npt07.datcon.co 255.255.255.255 UGH 0 0 0 eth0 -10.65.0.110 npt06.datcon.co 255.255.255.255 UGH 0 0 0 eth0 -10.65.0.111 npt08.datcon.co 255.255.255.255 UGH 0 0 0 eth0 -10.65.0.112 * 255.255.255.255 UH 0 0 0 tap3b561211-dd -link-local * 255.255.0.0 U 1000 0 0 eth0 -172.18.192.0 * 255.255.255.0 U 0 0 0 eth0 -``` - -You'll expect to see one route for each of the VM IP addresses in this -table. For VMs on other compute nodes, you should see that compute -node's IP address (or domain name) as the `gateway`. For VMs on this -compute node, you should see `*` as the `gateway`, and the tap interface -for that VM in the `Iface` field. As long as routes are present to all -VMs, the FIB has been configured correctly. If any VMs are missing from -the routing table, you'll want to verify the state of the BGP -connection(s) from the compute node hosting those VMs. - -Having confirmed the FIB is present and correct, open the console for -one of the VM instances you just created. Confirm that the machine has -external connectivity by pinging `google.com` (or any other host you are -confident is routable and that will respond to pings). Additionally, -confirm it has internal connectivity by pinging the other instances -you've created (by IP). - -If all of these tests behave correctly, your $[prodname]-based OpenStack -deployment is in good shape. - -## Troubleshooting - -If you find that none of the advice below solves your problems, please -use our diagnostics gathering script to generate diagnostics, and then -raise a GitHub issue against our repository. To generate the diags, run: - -```bash -/usr/bin/calico-diags -``` - -### VMs cannot DHCP - -This can happen if your iptables is configured to have a default DROP -behaviour on the INPUT or FORWARD chains. You can test this by running -`iptables -L -t filter` and checking the output. You should see -something that looks a bit like this: - -``` -Chain INPUT (policy ACCEPT) -target prot opt source destination -ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED -ACCEPT icmp -- anywhere anywhere -ACCEPT all -- anywhere anywhere -ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh -REJECT all -- anywhere anywhere reject-with icmp-host-prohibited - -Chain FORWARD (policy ACCEPT) -target prot opt source destination -REJECT all -- anywhere anywhere reject-with icmp-host-prohibited - -Chain OUTPUT (policy ACCEPT) -target prot opt source destination -``` - -The important sections are `Chain INPUT` and `Chain FORWARD`. Each of -those needs to have a policy of `ACCEPT`. In some systems, this policy -may be set to `DENY`. To change it, run `iptables -P ACCEPT`, -replacing `` with either `INPUT` or `FORWARD`. - -Note that doing this may be considered a security risk in some networks. -A future $[prodname] enhancement will remove the requirement to perform this -step. - -### Routes are missing in the FIB. - -If routes to some VMs aren't present when you run `route`, this suggests -that your BGP sessions are not functioning correctly. Your BGP daemon -should have either an interactive console or a log. Open the relevant -one and check that all of your BGP sessions have come up appropriately -and are replicating routes. If you're using a full mesh configuration, -confirm that you have configured BGP sessions with _all_ other $[prodname] -nodes. - -### VMs Cannot Ping Non-VM IPs - -Assuming all the routes are present in the FIB (see above), this most -commonly happens because the gateway is not configured with routes to -the VM IP addresses. To get full $[prodname] functionality the gateway should -also be a BGP peer of the compute nodes (or the route reflector). - -Confirm that your gateway has routes to the VMs. Assuming it does, make -sure that your gateway is also advertising those routes to its external -peers. It may do this using eBGP, but it may also be using some other -routing protocol. - -### VMs Cannot Ping Other VMs - -Before continuing, confirm that the two VMs are in security groups that -allow inbound traffic from each other (or are both in the same security -group which allows inbound traffic from itself). Traffic will not be -routed between VMs that do not allow inbound traffic from each other. - -Assuming that the security group configuration is correct, confirm that -the machines hosting each of the VMs (potentially the same machine) have -routes to both VMs. If they do not, check out the troubleshooting -section [above](#routes-are-missing-in-the-fib). - -### Web UI Shows Error Boxes Saying "Error: Unable to get quota info" and/or "Error: Unable to get volume limit" - -This is likely a problem encountered with mapping devices in `cinder`, -OpenStack's logical volume management component. Many of these can be -resolved by restarting `cinder`. - -```bash -service cinder-volume restart -service cinder-scheduler restart -service cinder-api restart -``` - -### Cannot create instances, error log says "could not open /dev/net/tun: Operation not permitted" - -This is caused by having not restarted libvirt after you add lines to -the end of `/etc/libvirt/qemu.conf`. This can be fixed by either -rebooting your entire system or running: - -```bash -service libvirt-bin restart -``` diff --git a/calico_versioned_docs/version-3.29/getting-started/openstack/overview.mdx b/calico_versioned_docs/version-3.29/getting-started/openstack/overview.mdx deleted file mode 100644 index 04b882a95c..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/openstack/overview.mdx +++ /dev/null @@ -1,51 +0,0 @@ ---- -description: Review the Calico components used in an OpenStack deployment. ---- - -# Calico for OpenStack - -$[prodname]'s integration with OpenStack involves the following software -components. - -- etcd, providing a distributed key/value database that is accessible from all - compute hosts and Neutron servers. - -- Felix (the $[prodname] agent) running on each compute host. Felix reads - information from etcd that specifies workloads and their properties (IP - addresses, security etc.), and implements that connectivity and security for - them. Felix also reports its own agent status, and the programming status - for each workload, through etcd. - -- BIRD, or some equivalent routing daemon, also running on each compute host, - to propagate local workload routes to other compute hosts and infrastructure - routers. - -- The $[prodname] driver for Neutron, that runs as part of the Neutron server on - each machine where the Neutron server runs. (There can be just one Neutron - server, but typically there are more, to provide higher availability.) This - driver handles OpenStack network, subnet, instance and security operations - and translates them into equivalent etcd data for Felix to implement. It - also reads the agent and per-port status information that Felix writes into - etcd, and reports this into the Neutron DB. - -- The $[prodname] DHCP agent, running on each compute host, that configures and - launches Dnsmasq instances to provide DHCP for the locally hosted workloads. - Architecturally this fills the same role as the reference Neutron DHCP agent; - the key difference is that it gets its information from Etcd instead of by - RPC from the Neutron server, as we have found this to be more scalable. - -Some of these pieces are Calico deliverables. Others must be provisioned -separately, as explained by the following table. - -| Component | Provisioning | -|--------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| etcd | Must be provisioned by the user before installing Calico deliverables. Typically now covered by OpenStack install - see https://docs.openstack.org/install-guide/environment-etcd.html. | -| Felix | Calico deliverable, provided by the `calico-felix` package. | -| BIRD (or equivalent) | Must be provisioned and configured by the user. See guidance on our [install pages](installation). | -| $[prodname] driver for Neutron | Calico deliverable, provided by the `calico-control` package. | -| $[prodname] DHCP agent | Calico deliverable, provided by the `calico-dhcp-agent` package. | - -From an OpenStack point of view, Calico is just one of many possible -Neutron drivers that provide connectivity between instances (VMs) as specified -by the Neutron API. Refer to [$[prodname]'s interpretation of Neutron API calls](../../networking/openstack/neutron-api.mdx) for more detail about the -parts of the Neutron API that Calico provides. diff --git a/calico_versioned_docs/version-3.29/getting-started/openstack/requirements.mdx b/calico_versioned_docs/version-3.29/getting-started/openstack/requirements.mdx deleted file mode 100644 index 262ae48b90..0000000000 --- a/calico_versioned_docs/version-3.29/getting-started/openstack/requirements.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: Requirements for installing Calico on OpenStack nodes. -title: System requirements ---- - -import SystemRequirements from '../../_includes/partials/_system-requirements.mdx'; -export const platform='openstack'; - -# System requirements for OpenStack - - \ No newline at end of file diff --git a/calico_versioned_docs/version-3.29/network-policy/adopt-zero-trust.mdx b/calico_versioned_docs/version-3.29/network-policy/adopt-zero-trust.mdx deleted file mode 100644 index 0127ae0be9..0000000000 --- a/calico_versioned_docs/version-3.29/network-policy/adopt-zero-trust.mdx +++ /dev/null @@ -1,296 +0,0 @@ ---- -description: Best practices to adopt a zero trust network model to secure workloads and hosts. Learn 5 key requirements to control network access for cloud-native strategy. ---- - -# Adopt a zero trust network model for security - -## Big picture - -Adopting a zero trust network model is best practice for securing workloads and hosts in your cloud-native strategy. - -## Value - -Zero Trust Networks are resilient even when attackers manage to breach applications or infrastructure. They make it hard for attackers to move laterally, and reconnaissance activities easier to spot. - -Organizations that embrace the change control model in this How-To will be able to tightly secure their network without imposing a drag on innovation in their applications. Security teams can be enablers of business value, not roadblocks. - -## Concepts - -### The network is always hostile - -**Zero Trust Networking** is an approach to network security that is unified by the principle that the network is always assumed to be hostile. This is in direct contrast to perimeter and “segmentation” approaches that focus on separating the world into trusted and untrusted network segments. - -Why assume the network is hostile? In many attack scenarios, it is. - -- Attackers may compromise “trusted” parts of your network infrastructure: routers, switches, links, etc. -- Deliberate or accidental misconfiguration can route sensitive traffic over untrusted networks, like the public Internet. -- Other endpoints on a “trusted” network may be compromised: your application may share a network with thousands of other servers, tens of thousands of other containers, thousands of personal laptops, phones, etc. - -Major breaches typically start as a minor compromise of as little as a single component, but attackers then use the network to move laterally toward high value targets: your company’s or customers’ data. In a zone or perimeter model, attackers can move freely inside the perimeter or zone after they have compromised a single endpoint. A Zero Trust Network is resilient to this threat because it enforces strong, cryptographic authentication and access control on each and every network connection. - -### Requirements of a Zero Trust Network - -Zero Trust Networks rely on network access controls with specific requirements: - -**Requirement 1:** All network connections are subject to enforcement (not just those that cross zone boundaries). - -**Requirement 2**: Establishing the identity of a remote endpoint is always based on multiple criteria including strong cryptographic proofs of identity. In particular, network-level identifiers like IP address and port are not sufficient on their own as they can be spoofed by a hostile network. - -**Requirement 3**: All expected and allowed network flows are explicitly allowed. Any connection not explicitly allowed is denied. - -**Requirement 4**: Compromised workloads must not be able to circumvent policy enforcement. - -**Requirement 5**: Many Zero Trust Networks also rely on encryption of network traffic to prevent disclosure of sensitive data to hostile entities snooping network traffic. This is not an absolute requirement if private data are not exchanged over the network, but to fit the criteria of a Zero Trust Network, encryption must be used on every network connection if it is required at all. A Zero Trust Network does not distinguish between trusted and untrusted network links or paths. Also note that even when not using encryption for data privacy, cryptographic proofs of authenticity are still used to establish identity. - -### How $[prodname] and Istio implement Zero Trust Network requirements - -$[prodname] works in concert with the Istio service mesh to implement all you need to build a Zero Trust Network in your Kubernetes cluster. - -#### Multiple enforcement points - -When operating with Istio, incoming requests to your workloads traverse two distinct enforcement points: - -1. The host Linux kernel. $[prodname] policy is enforced in the Linux kernel using iptables at L3-L4. -1. The Envoy proxy. $[prodname] policy is enforced in the Envoy proxy at L3-7, with requests being cryptographically authenticated. A lightweight policy decision sidecar called Dikastes assists Envoy in this enforcement. - -These multiple enforcement points establish the identity of the remote endpoint based on multiple criteria (Requirement 2). The host Linux kernel enforcement protects your workloads even if the workload pod is compromised and the Envoy proxy bypassed (Requirement 4). - -#### $[prodname] policy store - -The policies in the $[prodname] data store encode the allow-list of allowed flows (Requirement 3). - -$[prodname] network policy is designed to be flexible to fit many different security paradigms, so it can express, for example, both Zero Trust Network-style allow-lists as well as legacy paradigms like zones. You can even layer both of these approaches on top of one another without creating a maintenance mess by composing multiple policy documents. - -The How To section of this document explains how to write policy specifically in the style of Zero Trust Networks. Conceptually, you will begin by denying all network flows by default, then add rules that allow the specific expected flows that make up your application. When you finish, only legitimate application flows are allowed and all others are denied. - -#### $[prodname] control plane - -The $[prodname] control plane handles distributing all the policy information from the $[prodname] data store to each enforcement point, ensuring that all network connections are subject to enforcement (Requirement 4). It translates the high-level declarative policy into the detailed enforcement attributes that change as applications scale up and down to meet demand, and evolve as developers modify them. - -#### Istio Citadel Identity System - -In $[prodname] and Istio, workload identities are based on Kubernetes Service Accounts. An Istio component called Citadel handles minting cryptographic keys for each Service Account to prove its identity on the network (Requirement 2) and encrypt traffic (Requirement 5). This allows the Zero Trust Network to be resilient even if attackers compromise network infrastructure like routers or links. - -## How to - -This section explains how to establish a Zero Trust Network using $[prodname] and Istio. It is written from the perspective of platform and security engineers, but should also be useful for individual developers looking to understand the process. - -Building and maintaining a Zero Trust Network is the job of an entire application delivery organization, that is, everyone involved in delivering a networked application to its end users. This includes: - -- Developers, DevOps, and Operators -- Platform Engineers -- Network Engineers -- Security Engineers and Security Operatives - -In particular, the view that developers build applications which they hand off to others to figure out how to secure is incompatible with a Zero Trust Network strategy. To function correctly, a Zero Trust Network needs to be configured with detailed information about expected flows---information that developers are in a unique position to know. - -At a high level, you will undertake the following steps to establish a Zero Trust Network: - -1. Install $[prodname]. -1. Install Istio and enable $[prodname] integration. -1. Establish workload identity by using Service Accounts. -1. Write initial allow-list policies for each service. - -After your Zero Trust Network is established, you will need to maintain it. - -### Install $[prodname] - -Follow the [install instructions](../getting-started/index.mdx) to get $[prodname] software running in your cluster. - -### Install Istio and enable $[prodname] integration - -Follow the instructions to [Enable application layer policy](istio/app-layer-policy.mdx). - -The instructions include a “demo” install of Istio for quickly testing out functionality. For a production installation to support a Zero Trust Network, you should instead follow the official Istio install instructions. Be sure to enable mutually authenticated TLS (mTLS) in your install options by setting **global.mtls.enabled** to **true**. - -### Establish workload identity by using Service Accounts - -Our eventual goal is to write access control policy that authorizes individual expected network flows. We want these flows to be scoped as tightly as practical. In a $[prodname] Zero Trust Network, the cryptographic identities are Kubernetes Service Accounts. Istio handles crypto-key management for you so that each workload can assert its Service Account identity in a secure manner. - -You have some flexibility in how you assign identities for the purpose of your Zero Trust Network policy. The right balance for most people is to use a unique identity for each Kubernetes Service in your application (or Deployment if you have workloads that don’t accept any incoming connections). Assigning identity to entire applications or namespaces is probably too coarse, since applications usually consist of multiple services (or dozens of microservices) with different actual access needs. - -You should assign unique identities to microservices even if you happen to know that they access the same things. Your policy will be more readable if the identities correspond to logical components of the application. You can grant them the same permissions easily, and if in the future they need different permissions it will be easier to handle. - -After you decide on the set of identities you require, create the Kubernetes Service Accounts, then modify your application configuration so that each Deployment, ReplicaSet, StatefulSet, etc. uses the correct Service Account. - -### Write initial allow-list policies for each service - -The final step to establishing your Zero Trust Network is to write the policies for each service in your network. The [Application Layer Policy Tutorial](istio/enforce-policy-istio.mdx) gives an overview of setting up policies that allow traffic based on Service Account identity. - -For each service you will: - -1. Determine the full set of other identities that should access it. -1. Add rules to allow each of those flows. - -After a pod is selected by at least one policy, any traffic not explicitly allowed is denied. This implements the Zero Trust Network paradigm of an explicit allow-list of expected flows. - -### Determine the full set of identities that should access each service - -There are several approaches to determining the set of identities that should access a service. Work with the developers of the application to generate this list and ensure it is correct. One approach is to create a flow diagram of your entire application. A flow diagram is a kind of graph where each identity is a node, and each expected flow is an edge. - -Let’s look at an example application. - -![zero-trust-app](/img/calico/zero-trust-app.png) - -In this example, requests from end-users all flow through a service called api, where they can trigger calls to other services in the backend. These in turn can call other services. Each arrow in this diagram represents an expected flow, and if two services do not have a connecting arrow, the are not expected to have any network communication. For example, the only services that call the post service are api and search. - -For simple applications, especially if they are maintained by a single team, the developers will probably be able to just write down this flow graph from memory or with a quick look at the application code. - -If this is difficult to do from memory, you have several options. - -1. Run the application in a test environment with policy enabled. - a. Look at service logs to see what connectivity has broken. - b. Add rules that allow those flows and iterate until the application functions normally. - c. Move on to the next service and repeat. -1. Collect flow logs from a running instance of your application. Calico Enterprise can be used for this purpose, or the Kiali dashboard that comes with Istio. - a. Process the flow logs to determine the set of flows. - b. Review the logged flows and add rules for each expected flow. -1. Use Calico Enterprise for policy, and put it into logging-only mode. - a. In this mode “denied” connections are logged instead of dropped. - b. Review the “denied” logs and add rules for each expected flow. - -When determining flows from a running application instance, be sure to review each rule you add with application developers to determine if it is legitimate and expected. The last thing you want is for a breach-in-progress to be enshrined as expected flows in policy! - -### Write policies with allow rules for each flow - -After you have the set of expected flows for each service, you are ready to write $[prodname] network policy to allow-list those flows and deny all others. - -Returning to the example flow graph in the previous section, let’s write the policy for the post service. For the purpose of this example, assume all the services in the application run in a Kubernetes Namespace called microblog. We see from the flow graph that the post service is accessed by the api and search services. - -```yaml -apiVersion: projectcalico.org/v3 -kind: NetworkPolicy -metadata: - name: post-allow-list - namespace: microblog -spec: - selector: svc == 'post' - types: - - Ingress - ingress: - - action: Allow - source: - serviceAccounts: - names: ['api', 'search'] - namespaceSelector: app == 'microblog' - protocol: TCP - destination: - ports: - - 8080 -``` - -Things to notice in this example: - -- **Namespace** - - Create a $[prodname] NetworkPolicy in the same **namespace** as the service for the allow-list (microblog). - - ```yaml - metadata: - name: post-allow-list - namespace: microblog - ``` - -- **Selectors** - - The selector controls which pods to apply policy. It should be the same selector used to define the Kubernetes Service. - - ```yaml - spec: - selector: svc == 'post' - ``` - -- **Service account by name** - - In the **source:** selector, allow **api** and **search** by name. An alternative to selecting service accounts by name, is by namespaceSelector (next example). - - ```yaml - source: - serviceAccounts: - names: ['api', 'search'] - ``` - -- **Service account by namespaceSelector** - - Service Accounts are uniquely identified by name and namespace. Use a **namespaceSelector** to fully-qualify the Service Accounts you are allowing, so if names are repeated in other namespaces they will not be granted access to the service. - - ```yaml - source: - serviceAccounts: - names: ['api', 'search'] - namespaceSelector: app == 'microblog' - ``` - -- **Rules** - - Scope your rules as tightly as possible. In this case we are allowing connection only on TCP port 8080. - - ```yaml - destination: - ports: - - 8080 - ``` - -The above example lists the identities that need access to the post service by name. This style of allow-list works best when the developers responsible for a service have explicit knowledge of who needs access to their service. - -However, some development teams don’t explicitly know who needs access to their service, and don’t need to know. The service might be very generic and used by lots of different applications across the organization---for example: a logging service. Instead of listing the Service Accounts that get access to the service explicitly one-by-one, you can use a label selector that selects on Service Accounts. - -In the following example, we have changed the **serviceAccount** clause. Instead of a name, we use a label selector. The **selector: svc-post == access** label grants access to the post service. - -```yaml -apiVersion: projectcalico.org/v3 -kind: NetworkPolicy -metadata: - name: post-allow-list - namespace: microblog -spec: - selector: svc == 'post' - types: - - Ingress - ingress: - - action: Allow - source: - serviceAccounts: - selector: svc-post == 'access' - namespaceSelector: app == 'microblog' - protocol: TCP - destination: - ports: - - 8080 -``` - -Define labels that indicate permission to access services in the cluster. Then, modify the ServiceAccounts for each identity that needs access. In this example, we would add the label **svc-post == access** to the **api** and **search** Service Accounts. - -Whether you choose to explicitly name the Service Accounts or use a label selector is up to you, and you can make a different choice for different services. Using explicit names works best for services that have a small number of clients, or when you want the service owner to be involved in the decision to allow something new to access the service. If some other team wants to get access to the service, they call up the owner of the service and ask them to grant access. In contrast, using labels is good when you want more decentralized control. The service owner defines the labels that grant access to the service and trusts the other development teams to label their Service Accounts when they need access. - -### Maintain your zero trust network - -The allow-list policies are tightly scoped to the exact expected flows in the applications running in the Zero Trust Network. If these applications are under active development the expected flows will change, and policy, therefore, also needs to change. Maintaining a Zero Trust Network means instituting a change control policy that ensures: - -- Policies are up to date with application changes -- Policies are tightly scoped to expected flows -- Changes keep up with the pace of application development - -It is difficult to overstate how important the last point is. If your change control process cannot handle the volume of changes, or introduces too much latency in deploying new features, your transition to a Zero Trust Network is very likely to fail. Either your senior leadership will choose business expediency and overrule your security concerns, or competitors that can roll out new versions faster will stifle your market share. On the other hand, if your change control process does keep pace with application development, it will bring security value without sacrificing the pace of innovation. - -The size of the security team is often relatively small compared with application development and operations teams in most organizations. Fortunately, most application changes will not require changes in security policy, but even a small proportion of changes can lead to a large absolute number when dealing with large application teams. For this reason, it is often not feasible for a member of the security team to make every policy change. A classic complaint in large enterprises is that it takes weeks to change a firewall rule---this is often not because the actual workflow is time consuming but because the security team is swamped with a large backlog. - -Therefore, we recommend that the authors of the policy changes be developers/DevOps (i.e. authorship should “shift left”). This allows your change control process to scale naturally as your applications do. When application authors make changes that require policy changes (say, adding a new microservice), they also make the required policy changes to authorize the network activity associated with it. - -Here is a simplified application delivery pipeline flow. - -![zero-trust-app](/img/calico/zero-trust-deploy.png) - -Developers, DevOps, and/or Operators make changes to applications primarily by making changes to the artifacts at the top of the diagram: the source code and associated deployment configuration. These artifacts are put in source control (e.g. git) and control over changes to the running applications are managed as commits to this source repository. In a Kubernetes environment, the deployment configuration is typically the objects that appear on the Kubernetes API, such as Services and Deployment manifests. - -What you should do is include the NetworkPolicy as part of those deployment config artifacts. In some organizations, these artifacts are in the same repo as the source code, and in others they reside in a separate repo, but the principle is the same: you manage policy change control as commits to the deployment configuration. This config then works its way through the delivery pipeline and is finally applied to the running Kubernetes cluster. - -Your developers will likely require training and support from the security team to get policy correct at first. Many trained developers are not used to thinking about network security. The logical controls expressed in network policy are simple compared with the flexibility they have in source code, so the primary support they will need from you is around the proper security mindset and principles of Zero Trust Networks. You can apply a default deny policy in your cluster to ensure that developers can’t simply forget to apply their own allow-listed policy. - -You may wish to review every security policy change request (aka pull request in git workflows) at first. If you do, then be sure you have time allotted, and consider rolling out Zero Trust Network policies incrementally, one application or service at a time. As development teams gain confidence you can pull back and have them do their own reviews. Security professionals can do spot checks on change requests or entire policies to ensure quality remains high in the long term. - -## Additional resources - -- [Protect hosts](hosts/protect-hosts.mdx) -- [Global network policy](../reference/resources/globalnetworkpolicy.mdx) -- [Network policy](../reference/resources/networkpolicy.mdx) diff --git a/calico_versioned_docs/version-3.29/network-policy/comms/crypto-auth.mdx b/calico_versioned_docs/version-3.29/network-policy/comms/crypto-auth.mdx deleted file mode 100644 index 954bc478b6..0000000000 --- a/calico_versioned_docs/version-3.29/network-policy/comms/crypto-auth.mdx +++ /dev/null @@ -1,144 +0,0 @@ ---- -description: Enable TLS authentication and encryption for various Calico components. ---- - -# Configure encryption and authentication to secure Calico components - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - -## Connections from $[prodname] components to etcd - - - - -Operator based installations do not required communication to etcd, and so this section does not apply. - - - - -If you are using the etcd datastore, we recommend enabling mutual TLS authentication on -its connections as follows. - -- [Configure etcd](https://coreos.com/etcd/docs/latest/op-guide/security.html) to encrypt its - communications with TLS and require clients to present certificates signed by the etcd certificate - authority. - -- Configure each $[prodname] component to verify the etcd server's identity and to present - a certificate to the etcd server that is signed by the etcd certificate authority. - - [$[nodecontainer]](../../reference/configure-calico-node.mdx) - - [`calicoctl`](../../operations/calicoctl/configure/etcd.mdx) - - [CNI plugin](../../reference/configure-cni-plugins.mdx#etcd-location) (Kubernetes and OpenShift only) - - [Kubernetes controllers](../../reference/kube-controllers/configuration.mdx#configuring-datastore-access) (Kubernetes and OpenShift only) - - [Felix](../../reference/felix/configuration.mdx) - - [Typha](../../reference/typha/configuration.mdx#etcd-datastore-configuration) (often deployed in - larger Kubernetes deployments) - - [Neutron plugin or ML2 driver](../../networking/openstack/configuration.mdx#neutron-server-etcneutronneutronconf) (OpenStack only) - - [DHCP agent](../../networking/openstack/configuration.mdx#neutron-server-etcneutronneutronconf) (OpenStack only) - - - - -### Connections from $[prodname] components to kube-apiserver (Kubernetes and OpenShift) - -We recommend enabling TLS on kube-apiserver, as well as the client certificate and JSON web token (JWT) -authentication modules. This ensures that all of its communications with $[prodname] components occur -over TLS. The $[prodname] components present either an X.509 certificate or a JWT to kube-apiserver -so that kube-apiserver can verify their identities. - -### Connections from Felix to Typha (Kubernetes) - - - - -Operator based installations automatically configure mutual TLS authentication on connections from -Felix to Typha. - - - - -We recommend enabling mutual TLS authentication on connections from Felix to Typha. -To do so, you must provision Typha with a server certificate and Felix with a client -certificate. Each service will need the private key associated with their certificate. -In addition, you must configure one of the following. - -- **SPIFFE identifiers** (recommended): Generate a [SPIFFE](https://github.com/spiffe/spiffe) identifier for Felix, - set `ClientURISAN` on Typha to Felix's SPIFFE ID, and include Felix's SPIFFE ID in the `URI SAN` field - of its certificate. Similarly, generate a [SPIFFE](https://github.com/spiffe/spiffe) identifier for Typha, - set `TyphaURISAN` on Felix to Typha's SPIFFE ID, and include Typha's SPIFFE ID in the `URI SAN` field - of its certificate. - -- **Common Name identifiers**: Configure `ClientCN` on Typha to the value in the `Common Name` of Felix's - certificate. Configure `ClientCN` on Felix to the value in the `Common Name` of Typha's - certificate. - -:::tip - -If you are migrating from Common Name to SPIFFE identifiers, you can set both values. -If either matches, the communication succeeds. - -::: - -Here is an example of how you can secure the Felix-Typha communications in your -cluster: - -1. Choose a certificate authority, or set up your own. - -1. Obtain or generate the following leaf certificates, signed by that - authority, and corresponding keys: - - - A certificate for each Felix with Common Name `typha-client` and - extended key usage `ClientAuth`. - - - A certificate for each Typha with Common Name `typha-server` and - extended key usage `ServerAuth`. - -1. Configure each Typha with: - - - `CAFile` pointing to the certificate authority certificate - - - `ServerCertFile` pointing to that Typha's certificate - - - `ServerKeyFile` pointing to that Typha's key - - - `ClientCN` set to `typha-client` - - - `ClientURISAN` unset. - -1. Configure each Felix with: - - - `TyphaCAFile` pointing to the Certificate Authority certificate - - - `TyphaCertFile` pointing to that Felix's certificate - - - `TyphaKeyFile` pointing to that Felix's key - - - `TyphaCN` set to `typha-server` - - - `TyphaURISAN` unset. - -For a [SPIFFE](https://github.com/spiffe/spiffe)-compliant deployment you can -follow the same procedure as above, except: - -1. Choose [SPIFFE Identities](https://github.com/spiffe/spiffe/blob/master/standards/SPIFFE-ID.md#2-spiffe-identity) - - to represent Felix and Typha. - -1. When generating leaf certificates for Felix and Typha, put the relevant - SPIFFE Identity in the certificate as a URI SAN. - -1. Leave `ClientCN` and `TyphaCN` unset. - -1. Set Typha's `ClientURISAN` parameter to the SPIFFE Identity for Felix that - you use in each Felix certificate. - -1. Set Felix's `TyphaURISAN` parameter to the SPIFFE Identity for Typha. - -For detailed reference information on these parameters, refer to: - -- **Typha**: [Felix-Typha TLS configuration](../../reference/typha/configuration.mdx#felix-typha-tls-configuration) - -- **Felix**: [Felix-Typha TLS configuration](../../reference/felix/configuration.mdx) - - - diff --git a/calico_versioned_docs/version-3.29/network-policy/comms/index.mdx b/calico_versioned_docs/version-3.29/network-policy/comms/index.mdx deleted file mode 100644 index 24e13343f5..0000000000 --- a/calico_versioned_docs/version-3.29/network-policy/comms/index.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: Secure communications for Calico components. -hide_table_of_contents: true ---- - -# Secure Calico component communications - -import DocCardList from '@theme/DocCardList'; -import { useCurrentSidebarCategory } from '@docusaurus/theme-common'; - - diff --git a/calico_versioned_docs/version-3.29/network-policy/comms/reduce-nodes.mdx b/calico_versioned_docs/version-3.29/network-policy/comms/reduce-nodes.mdx deleted file mode 100644 index 1791ea90d1..0000000000 --- a/calico_versioned_docs/version-3.29/network-policy/comms/reduce-nodes.mdx +++ /dev/null @@ -1,83 +0,0 @@ ---- -description: Configure the Calico Typha TCP port. ---- - -# Schedule Typha for scaling to well-known nodes - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - -## Big picture - -Schedule Typha to well-known nodes. - -## Value - -By scheduling Typha to well-known nodes, you can reduce the number of nodes which expose -Typha's listen port. - -## Concepts - -### Typha - -Typha is a $[prodname] component which improves scalability and reduces the impact that -large clusters may have on the Kubernetes API. Typha agents must accept connections from other agents on a fixed port. - -As part of the $[prodname] bootstrap infrastructure, Typha must be available before -pod networking begins and uses host networking instead. It opens a port on the node it is -scheduled on. By default, it can get scheduled to any node and opens TCP 5473. - -## How to - -### Tell if you have installed Typha - - - - -Operator based installations always include Typha. - - - - -Check if the `calico-typha` deployment exists in the `kube-system` namespace. - -``` -kubectl get deployment -n kube-system calico-typha -``` - - - - -### Schedule Typha to well-known nodes - - - - -You can use the Installation API to configure a node affinity for Typha pods. The operator supports both -`preferredDuringSchedulingIgnoredDuringExecution` and `requiredDuringSchedulingIgnoredDuringExecution` options. - -For example, to require the scheduler to place Typha on nodes with the label "typha=allowed": - -```yaml -kind: Installation -apiVersion: operator.tigera.io/v1 -metadata: - name: default -spec: - typhaAffinity: - nodeAffinity: - requiredDuringSchedulingIgnoredDuringExecution: - - matchExpressions: - - key: typha - operator: In - values: - - allowed -``` - - - - -See [scheduling Typha to well-known nodes](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/). - - - diff --git a/calico_versioned_docs/version-3.29/network-policy/comms/secure-bgp.mdx b/calico_versioned_docs/version-3.29/network-policy/comms/secure-bgp.mdx deleted file mode 100644 index 358177aec0..0000000000 --- a/calico_versioned_docs/version-3.29/network-policy/comms/secure-bgp.mdx +++ /dev/null @@ -1,185 +0,0 @@ ---- -description: Configure BGP passwords to prevent attackers from injecting false routing information. ---- - -# Secure BGP sessions - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - -## Big picture - -Use BGP passwords to prevent attackers from injecting false routing information. - -## Value - -Setting a password on a BGP peering between BGP speakers means that a peering will only -work when both ends of the peering have the same password. This provides a layer of defense -against an attacker impersonating an external BGP peer or a workload in the cluster, for -example to inject malicious routing information into the cluster. - -## Concepts - -### Password protection on BGP sessions - -Password protection is a [standardized](https://tools.ietf.org/html/rfc5925) optional -feature of BGP sessions. The effect is that the two peers at either end of a BGP session -can only communicate, and exchange routing information, if they are both configured with -the same password. - -Please note that password use does not cause the data exchange to be _encrypted_. It -remains relatively easy to _eavesdrop_ on the data exchange, but not to _inject_ false -information. - -### Using Kubernetes secrets to store passwords - -In Kubernetes, the Secret resource is designed for holding sensitive information, -including passwords. Therefore, for this $[prodname] feature, we use Secrets to -store BGP passwords. - -## How to - -To use a password on a BGP peering: - -1. Create (or update) a Kubernetes secret in the namespace where $[noderunning] is - running, so that it has a key whose value is the desired password. Note the secret - name and the key name. - - :::note - - BGP passwords must be 80 characters or fewer. If a - password longer than that is configured, the BGP sessions with - that password will fail to be established. - - ::: - -1. Ensure that $[noderunning] has RBAC permissions to access that secret. - -1. Specify the secret and key name on the relevant BGPPeer resource. - -### Create or update Kubernetes secret - -For example: - -``` -kubectl create -f - < - - -When [configuring a BGP peer](../../networking/configuring/bgp.mdx), -include the secret and key name in the specification of the BGPPeer resource, like this: - -```yaml -apiVersion: projectcalico.org/v3 -kind: BGPPeer -metadata: - name: bgppeer-global-3040 -spec: - peerIP: 192.20.30.40 - asNumber: 64567 - password: - secretKeyRef: - name: bgp-secrets - key: rr-password -``` - - - - -Include the secret in the default [BGP configuration](../../reference/resources/bgpconfig.mdx) -similar to the following: - -```yaml -kind: BGPConfiguration -apiVersion: projectcalico.org/v3 -metadata: - name: default -spec: - logSeverityScreen: Info - nodeToNodeMeshEnabled: true - nodeMeshPassword: - secretKeyRef: - name: bgp-secrets - key: rr-password -``` - -:::note - -Node to node mesh must be enabled to set node to node mesh -BGP password. - -::: - - - - - -## Additional resources - -For more detail about the BGPPeer resource, see -[BGPPeer](../../reference/resources/bgppeer.mdx). - -For more on configuring BGP peers, see [configuring BGP peers](../../networking/configuring/bgp.mdx) -. diff --git a/calico_versioned_docs/version-3.29/network-policy/comms/secure-metrics.mdx b/calico_versioned_docs/version-3.29/network-policy/comms/secure-metrics.mdx deleted file mode 100644 index 4bf2a49eaa..0000000000 --- a/calico_versioned_docs/version-3.29/network-policy/comms/secure-metrics.mdx +++ /dev/null @@ -1,512 +0,0 @@ ---- -description: Limit access to Calico metric endpoints using network policy. ---- - -# Secure Calico Prometheus endpoints - -## About securing access to $[prodname]'s metrics endpoints - -When using $[prodname] with Prometheus metrics enabled, we recommend using network policy -to limit access to $[prodname]'s metrics endpoints. - -## Prerequisites - -- $[prodname] is installed with Prometheus metrics reporting enabled. -- `calicoctl` is [installed in your PATH and configured to access the data store](../../operations/calicoctl/install.mdx). - -## Choosing an approach - -This guide provides two example workflows for creating network policies to limit access -to $[prodname]'s Prometheus metrics. Choosing an approach depends on your requirements. - -- [Using a deny-list approach](#using-a-deny-list-approach) - - This approach allows all traffic to your hosts by default, but lets you limit access to specific ports using - $[prodname] policy. This approach allows you to restrict access to specific ports, while leaving other - host traffic unaffected. - -- [Using an allow-list approach](#using-an-allow-list-approach) - - This approach denies traffic to and from your hosts by default, and requires that all - desired communication be explicitly allowed by a network policy. This approach is more secure because - only explicitly-allowed traffic will get through, but it requires you to know all the ports that should be open on the host. - -## Using a deny-list approach - -### Overview - -The basic process is as follows: - -1. Create a default network policy that allows traffic to and from your hosts. -1. Create host endpoints for each node that you'd like to secure. -1. Create a network policy that denies unwanted traffic to the $[prodname] metrics endpoints. -1. Apply labels to allow access to the Prometheus metrics. - -### Example for $[nodecontainer] - -This example shows how to limit access to the $[nodecontainer] Prometheus metrics endpoints. - -1. Create a default network policy to allow host traffic - - First, create a default-allow policy. Do this first to avoid a drop in connectivity when adding the host endpoints - later, since host endpoints with no policy default to deny. - - To do this, create a file named `default-host-policy.yaml` with the following contents. - - ```yaml - apiVersion: projectcalico.org/v3 - kind: GlobalNetworkPolicy - metadata: - name: default-host - spec: - # Select all $[prodname] nodes. - selector: running-calico == "true" - order: 5000 - ingress: - - action: Allow - egress: - - action: Allow - ``` - - Then, use `calicoctl` to apply this policy. - - ```bash - calicoctl apply -f default-host-policy.yaml - ``` - -1. List the nodes on which $[prodname] is running with the following command. - - ```bash - calicoctl get nodes - ``` - - In this case, we have two nodes in the cluster. - - ``` - NAME - kubeadm-master - kubeadm-node-0 - ``` - -1. Create host endpoints for each $[prodname] node. - - Create a file named `host-endpoints.yaml` containing a host endpoint for each node listed - above. In this example, the contents would look like this. - - ```yaml - apiVersion: projectcalico.org/v3 - kind: HostEndpoint - metadata: - name: kubeadm-master.eth0 - labels: - running-calico: 'true' - spec: - node: kubeadm-master - interfaceName: eth0 - expectedIPs: - - 10.100.0.15 - --- - apiVersion: projectcalico.org/v3 - kind: HostEndpoint - metadata: - name: kubeadm-node-0.eth0 - labels: - running-calico: 'true' - spec: - node: kubeadm-node-0 - interfaceName: eth0 - expectedIPs: - - 10.100.0.16 - ``` - - In this file, replace `eth0` with the desired interface name on each node, and populate the - `expectedIPs` section with the IP addresses on that interface. - - Note the use of a label to indicate that this host endpoint is running $[prodname]. The - label matches the selector of the network policy created in step 1. - - Then, use `calicoctl` to apply the host endpoints with the following command. - - ```bash - calicoctl apply -f host-endpoints.yaml - ``` - -1. Create a network policy that restricts access to the $[nodecontainer] Prometheus metrics port. - - Now let's create a network policy that limits access to the Prometheus metrics port such that - only endpoints with the label `calico-prometheus-access: true` can access the metrics. - - To do this, create a file named `calico-prometheus-policy.yaml` with the following contents. - - ```yaml - # Allow traffic to Prometheus only from sources that are - # labeled as such, but don't impact any other traffic. - apiVersion: projectcalico.org/v3 - kind: GlobalNetworkPolicy - metadata: - name: restrict-calico-node-prometheus - spec: - # Select all $[prodname] nodes. - selector: running-calico == "true" - order: 500 - types: - - Ingress - ingress: - # Deny anything that tries to access the Prometheus port - # but that doesn't match the necessary selector. - - action: Deny - protocol: TCP - source: - notSelector: calico-prometheus-access == "true" - destination: - ports: - - 9091 - ``` - - This policy selects all endpoints that have the label `running-calico: true`, and enforces a single ingress deny rule. - The ingress rule denies traffic to port 9091 unless the source of traffic has the label `calico-prometheus-access: true`, meaning - all $[prodname] workload endpoints, host endpoints, and global network sets that do not have the label, as well as any - other network endpoints unknown to $[prodname]. - - Then, use `calicoctl` to apply this policy. - - ```bash - calicoctl apply -f calico-prometheus-policy.yaml - ``` - -1. Apply labels to any endpoints that should have access to the metrics. - - At this point, only endpoints that have the label `calico-prometheus-access: true` can reach - $[prodname]'s Prometheus metrics endpoints on each node. To grant access, simply add this label to the - desired endpoints. - - For example, to allow access to a Kubernetes pod you can run the following command. - - ```bash - kubectl label pod my-prometheus-pod calico-prometheus-access=true - ``` - - If you would like to grant access to a specific IP network, you - can create a [global network set](../../reference/resources/globalnetworkset.mdx) using `calicoctl`. - - For example, you might want to grant access to your management subnets. - - ```yaml - apiVersion: projectcalico.org/v3 - kind: GlobalNetworkSet - metadata: - name: calico-prometheus-set - labels: - calico-prometheus-access: 'true' - spec: - nets: - - 172.15.0.0/24 - - 172.101.0.0/24 - ``` - -### Additional steps for Typha deployments - -If your $[prodname] installation uses the Kubernetes API datastore and has greater than 50 nodes, it is likely -that you have installed Typha. This section shows how to use an additional network policy to secure the Typha -Prometheus endpoints. - -After following the steps above, create a file named `typha-prometheus-policy.yaml` with the following contents. - -```yaml -# Allow traffic to Prometheus only from sources that are -# labeled as such, but don't impact any other traffic. -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: restrict-calico-node-prometheus -spec: - # Select all $[prodname] nodes. - selector: running-calico == "true" - order: 500 - types: - - Ingress - ingress: - # Deny anything that tries to access the Prometheus port - # but that doesn't match the necessary selector. - - action: Deny - protocol: TCP - source: - notSelector: calico-prometheus-access == "true" - destination: - ports: - - 9093 -``` - -This policy selects all endpoints that have the label `running-calico: true`, and enforces a single ingress deny rule. -The ingress rule denies traffic to port 9093 unless the source of traffic has the label `calico-prometheus-access: true`, meaning -all $[prodname] workload endpoints, host endpoints, and global network sets that do not have the label, as well as any -other network endpoints unknown to $[prodname]. - -Then, use `calicoctl` to apply this policy. - -```bash -calicoctl apply -f typha-prometheus-policy.yaml -``` - -### Example for kube-controllers - -If your $[prodname] installation exposes metrics from kube-controllers, you can limit access to those metrics -with the following network policy. - -Create a file named `kube-controllers-prometheus-policy.yaml` with the following contents. - -```yaml -apiVersion: projectcalico.org/v3 -kind: NetworkPolicy -metadata: - name: restrict-kube-controllers-prometheus - namespace: calico-system -spec: - # Select kube-controllers. - selector: k8s-app == "calico-kube-controllers" - order: 500 - types: - - Ingress - ingress: - # Deny anything that tries to access the Prometheus port - # but that doesn't match the necessary selector. - - action: Deny - protocol: TCP - source: - notSelector: calico-prometheus-access == "true" - destination: - ports: - - 9094 -``` - -:::note - -The above policy is installed in the calico-system namespace. If your cluster has $[prodname] installed -in the kube-system namespace, you will need to create the policy in that namespace instead. - -::: - -Then, use `calicoctl` to apply this policy. - -```bash -calicoctl apply -f kube-controllers-prometheus-policy.yaml -``` - -## Using an allow-list approach - -### Overview - -The basic process is as follows: - -1. Create host endpoints for each node that you'd like to secure. -1. Create a network policy that allows desired traffic to the $[prodname] metrics endpoints. -1. Apply labels to allow access to the Prometheus metrics. - -### Example for $[nodecontainer] - -1. List the nodes on which $[prodname] is running with the following command. - - ```bash - calicoctl get nodes - ``` - - In this case, we have two nodes in the cluster. - - ``` - NAME - kubeadm-master - kubeadm-node-0 - ``` - -1. Create host endpoints for each $[prodname] node. - - Create a file named `host-endpoints.yaml` containing a host endpoint for each node listed - above. In this example, the contents would look like this. - - ```yaml - apiVersion: projectcalico.org/v3 - kind: HostEndpoint - metadata: - name: kubeadm-master.eth0 - labels: - running-calico: 'true' - spec: - node: kubeadm-master - interfaceName: eth0 - expectedIPs: - - 10.100.0.15 - --- - apiVersion: projectcalico.org/v3 - kind: HostEndpoint - metadata: - name: kubeadm-node-0.eth0 - labels: - running-calico: 'true' - spec: - node: kubeadm-node-0 - interfaceName: eth0 - expectedIPs: - - 10.100.0.16 - ``` - - In this file, replace `eth0` with the desired interface name on each node, and populate the - `expectedIPs` section with the IP addresses on that interface. - - Note the use of a label to indicate that this host endpoint is running $[prodname]. The - label matches the selector of the network policy created in step 1. - - Then, use `calicoctl` to apply the host endpoints with the following command. This will prevent all - traffic to and from the host endpoints. - - ```bash - calicoctl apply -f host-endpoints.yaml - ``` - - :::note - - $[prodname] allows some traffic as a failsafe even after applying this policy. This can - be adjusted using the `failsafeInboundHostPorts` and `failsafeOutboundHostPorts` options - on the [FelixConfiguration resource](../../reference/resources/felixconfig.mdx). - - ::: - -1. Create a network policy that allows access to the $[nodecontainer] Prometheus metrics port. - - Now let's create a network policy that allows access to the Prometheus metrics port such that - only endpoints with the label `calico-prometheus-access: true` can access the metrics. - - To do this, create a file named `calico-prometheus-policy.yaml` with the following contents. - - ```yaml - apiVersion: projectcalico.org/v3 - kind: GlobalNetworkPolicy - metadata: - name: restrict-calico-node-prometheus - spec: - # Select all $[prodname] nodes. - selector: running-calico == "true" - order: 500 - types: - - Ingress - ingress: - # Allow traffic from selected sources to the Prometheus port. - - action: Allow - protocol: TCP - source: - selector: calico-prometheus-access == "true" - destination: - ports: - - 9091 - ``` - - This policy selects all endpoints that have the label `running-calico: true`, and enforces a single ingress allow rule. - The ingress rule allows traffic to port 9091 from any source with the label `calico-prometheus-access: true`, meaning - all $[prodname] workload endpoints, host endpoints, and global network sets that have the label will be allowed access. - - Then, use `calicoctl` to apply this policy. - - ```bash - calicoctl apply -f calico-prometheus-policy.yaml - ``` - -1. Apply labels to any endpoints that should have access to the metrics. - - At this point, only endpoints that have the label `calico-prometheus-access: true` can reach - $[prodname]'s Prometheus metrics endpoints on each node. To grant access, simply add this label to the - desired endpoints. - - For example, to allow access to a Kubernetes pod you can run the following command. - - ```bash - kubectl label pod my-prometheus-pod calico-prometheus-access=true - ``` - - If you would like to grant access to a specific IP address in your network, you - can create a [global network set](../../reference/resources/globalnetworkset.mdx) using `calicoctl`. - - For example, creating the following network set would grant access to a host with IP 172.15.0.101. - - ```yaml - apiVersion: projectcalico.org/v3 - kind: GlobalNetworkSet - metadata: - name: calico-prometheus-set - labels: - calico-prometheus-access: 'true' - spec: - nets: - - 172.15.0.101/32 - ``` - -### Additional steps for Typha deployments - -If your $[prodname] installation uses the Kubernetes API datastore and has greater than 50 nodes, it is likely -that you have installed Typha. This section shows how to use an additional network policy to secure the Typha -Prometheus endpoints. - -After following the steps above, create a file named `typha-prometheus-policy.yaml` with the following contents. - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: restrict-typha-prometheus -spec: - # Select all $[prodname] nodes. - selector: running-calico == "true" - order: 500 - types: - - Ingress - ingress: - - action: Allow - protocol: TCP - source: - selector: calico-prometheus-access == "true" - destination: - ports: - - 9093 -``` - -This policy selects all endpoints that have the label `running-calico: true`, and enforces a single ingress allow rule. -The ingress rule allows traffic to port 9093 from any source with the label `calico-prometheus-access: true`, meaning -all $[prodname] workload endpoints, host endpoints, and global network sets that have the label will be allowed access. - -Then, use `calicoctl` to apply this policy. - -```bash -calicoctl apply -f typha-prometheus-policy.yaml -``` - -### Example for kube-controllers - -If your $[prodname] installation exposes metrics from kube-controllers, you can limit access to those metrics -with the following network policy. - -Create a file named `kube-controllers-prometheus-policy.yaml` with the following contents. - -```yaml -apiVersion: projectcalico.org/v3 -kind: NetworkPolicy -metadata: - name: restrict-kube-controllers-prometheus - namespace: calico-system -spec: - selector: k8s-app == "calico-kube-controllers" - order: 500 - types: - - Ingress - ingress: - - action: Allow - protocol: TCP - source: - selector: calico-prometheus-access == "true" - destination: - ports: - - 9094 -``` - -Then, use `calicoctl` to apply this policy. - -```bash -calicoctl apply -f kube-controllers-prometheus-policy.yaml -``` diff --git a/calico_versioned_docs/version-3.29/network-policy/encrypt-cluster-pod-traffic.mdx b/calico_versioned_docs/version-3.29/network-policy/encrypt-cluster-pod-traffic.mdx deleted file mode 100644 index 17867196d7..0000000000 --- a/calico_versioned_docs/version-3.29/network-policy/encrypt-cluster-pod-traffic.mdx +++ /dev/null @@ -1,265 +0,0 @@ ---- -description: Enable WireGuard for state-of-the-art cryptographic security between pods for Calico clusters. ---- - -# Encrypt in-cluster pod traffic - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - -## Big picture - -Enable WireGuard to secure on-the-wire, in-cluster pod traffic in a $[prodname] cluster. - -## Value - -When this feature is enabled, $[prodname] automatically creates and manages WireGuard tunnels between nodes providing transport-level security for inter-node, in-cluster pod traffic. WireGuard provides [formally verified](https://www.wireguard.com/formal-verification/) secure and [performant tunnels](https://www.wireguard.com/performance/) without any specialized hardware. For a deep dive in to WireGuard implementation, see this [white paper](https://www.wireguard.com/papers/wireguard.pdf). - -# Concepts - -## About WireGuard - -$[prodname] supports both inter-node pod traffic, and inter-node, host-network traffic. Because $[prodname] is not implemented using a sidecar, traffic is not encrypted for the full journey from one pod to another; traffic is only encrypted on the host-to-host portion of the journey. Though there is unencrypted traffic between the host-to-pod portion of the journey, attackers cannot easily intercept this traffic. To intercept the unencrypted traffic, they would need root access to the node. - -$[prodname] supports WireGuard encryption for both IPv4 and IPv6 traffic. You can enable traffic independently using parameters in the FelixConfiguration resource: - -- `wireguardEnabled` - enables encrypting IPv4 traffic over an IPv4 underlay network -- `wireguardEnabledV6` - enables encrypting IPv6 traffic over an IPv6 underlay network - -## Before you begin... - -**Terminology** - - - Inter-node pod traffic: Traffic leaving a pod from one node destined to a pod on another node - - Inter-node, host-network traffic: traffic generated by the node itself or a host-networked-pod destined to another node or host-networked-pod - - Same-node pod traffic: Traffic between pods on the same node - -**Supported encryption** - -- Inter-node pod traffic: IPv4 only -- Inter-node, host-network traffic, IPv4/IPv6: supported only on managed clusters deployed on EKS and AKS - -**Unsupported** - -- Encrypted same-node pod traffic -- GKE -- Using your own custom keys to encrypt traffic - -**Required** - -- On all nodes in the cluster that you want to participate in $[prodname] encryption, verify that the operating system(s) on the nodes are [installed with WireGuard](https://www.wireguard.com/install/). - - :::note - - Some node operating systems do not support WireGuard, or do not have it installed by default. Enabling $[prodname] WireGuard encryption does not require all nodes to be installed with WireGuard. However, traffic to or from a node that does not have WireGuard installed will not be encrypted. - - ::: - -- IP addresses for every node in the cluster. This is required to establish secure tunnels between the nodes. $[prodname] can automatically do this using [IP autodetection methods](../networking/ipam/ip-autodetection.mdx). - -## How to - -- [Install WireGuard](#install-wireguard) -- [Enable WireGuard for a cluster](#enable-wireguard-for-a-cluster) -- [Disable WireGuard for an individual node](#disable-wireguard-for-an-individual-node) -- [Verify configuration](#verify-configuration) -- [Disable WireGuard for a cluster](#disable-wireguard-for-a-cluster) - -### Install WireGuard - -WireGuard is included in Linux 5.6+ kernels, and has been backported to earlier Linux kernels in some Linux distributions. - -Install WireGuard on cluster nodes using [instructions for your operating system](https://www.wireguard.com/install/). Note that you may need to reboot your nodes after installing WireGuard to make the kernel modules available on your system. - -Use the following instructions for these platforms that are not listed on the WireGuard installation page, before proceeding to [enabling WireGuard](#enable-wireguard-for-a-cluster). - - - - -To install WireGuard on the default Amazon Machine Image (AMI): - -```bash - sudo yum install kernel-devel-`uname -r` -y - sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm -y - sudo curl -o /etc/yum.repos.d/jdoss-wireguard-epel-7.repo https://copr.fedorainfracloud.org/coprs/jdoss/wireguard/repo/epel-7/jdoss-wireguard-epel-7.repo - sudo yum install wireguard-dkms wireguard-tools -y -``` - - - - -AKS cluster nodes run Ubuntu with a kernel that has WireGuard installed already, so there is no manual installation required. - - - - -To install WireGuard for OpenShift v4.8: - -1. Install requirements: - - - [CoreOS Butane](https://coreos.github.io/butane/getting-started/) - - [OpenShift CLI](https://docs.openshift.com/container-platform/4.2/cli_reference/openshift_cli/getting-started-cli.html) - -1. Download and configure the tools needed for kmods. - -```bash -FAKEROOT=$(mktemp -d) -git clone https://github.com/tigera/kmods-via-containers -cd kmods-via-containers -make install FAKEROOT=${FAKEROOT} -cd .. -git clone https://github.com/tigera/kvc-wireguard-kmod -cd kvc-wireguard-kmod -make install FAKEROOT=${FAKEROOT} -cd .. -``` - -1. Configure/edit `${FAKEROOT}/root/etc/kvc/wireguard-kmod.conf`. - - a. You must then set the URLs for the `KERNEL_CORE_RPM`, `KERNEL_DEVEL_RPM` and `KERNEL_MODULES_RPM` packages in the conf file `$FAKEROOT/etc/kvc/wireguard-kmod.conf`. Obtain copies for `kernel-core`, `kernel-devel`, and `kernel-modules` rpms from [RedHat Access](https://access.redhat.com/downloads/content/package-browser) and host it in an http file server that is reachable by your OCP workers. - - b. For help configuring `kvc-wireguard-kmod/wireguard-kmod.conf` and WireGuard version to kernel version compatibility, see the [kvc-wireguard-kmod README file](https://github.com/tigera/kvc-wireguard-kmod#quick-config-variables-guide). - -1. Get RHEL Entitlement data from your own RHEL8 system from a host in your cluster. - - ```bash - tar -czf subs.tar.gz /etc/pki/entitlement/ /etc/rhsm/ /etc/yum.repos.d/redhat.repo - ``` - -1. Copy the `subs.tar.gz` file to your workspace and then extract the contents using the following command. - - ```bash - tar -x -C ${FAKEROOT}/root -f subs.tar.gz - ``` - -1. Transpile your machine config using [CoreOS Butane](https://coreos.github.io/butane/getting-started/). - - ```bash - cd kvc-wireguard-kmod - make ignition FAKEROOT=${FAKEROOT} > mc-wg.yaml - ``` - -1. With the KUBECONFIG set for your cluster, run the following command to apply the MachineConfig which will install WireGuard across your cluster. - ```bash - oc create -f mc-wg.yaml - ``` - - - - -### Enable WireGuard for a cluster - - - - -Enable IPv4 WireGuard encryption across all the nodes using the following command. - -```bash -kubectl patch felixconfiguration default --type='merge' -p '{"spec":{"wireguardEnabled":true}}' -``` - -Enable IPv6 WireGuard encryption across all the nodes using the following command. - -```bash -kubectl patch felixconfiguration default --type='merge' -p '{"spec":{"wireguardEnabledV6":true}}' -``` - -To enable both IPv4 and IPv6 WireGuard encryption across all the nodes, use the following command. - -```bash -kubectl patch felixconfiguration default --type='merge' -p '{"spec":{"wireguardEnabled":true,"wireguardEnabledV6":true}}' -``` - - - - -Enable IPv4 WireGuard encryption across all the nodes using the following command. - -```bash -calicoctl patch felixconfiguration default --type='merge' -p '{"spec":{"wireguardEnabled":true}}' -``` - -Enable IPv6 WireGuard encryption across all the nodes using the following command. - -```bash -calicoctl patch felixconfiguration default --type='merge' -p '{"spec":{"wireguardEnabledV6":true}}' -``` - -To enable both IPv4 and IPv6 WireGuard encryption across all the nodes, use the following command. - -```bash -calicoctl patch felixconfiguration default --type='merge' -p '{"spec":{"wireguardEnabled":true,"wireguardEnabledV6":true}}' -``` - -**Perform the next step for EKS and AKS clusters only, and only if your cluster is using the cloud provider CNI plugin and not Calico CNI.** Enable WireGuard encryption for inter-node, host-network traffic using the following command. - -```bash -calicoctl patch felixconfiguration default --type='merge' -p '{"spec": {"wireguardHostEncryptionEnabled": true}}' -``` - - - - -For OpenShift, add the Felix configuration with WireGuard enabled [under custom resources](../getting-started/kubernetes/openshift/installation.mdx#optionally-provide-additional-configuration). - -:::note - -The above command can be used to change other WireGuard attributes. For a list of other WireGuard parameters and configuration evaluation, see the [Felix configuration](../reference/resources/felixconfig.mdx#felix-configuration-definition). - -::: - -We recommend that you review and modify the MTU used by $[prodname] networking when WireGuard is enabled to increase network performance. Follow the instructions in the [Configure MTU to maximize network performance](../networking/configuring/mtu.mdx) guide to set the MTU to a value appropriate for your network. - -### Disable WireGuard for an individual node - -To disable WireGuard on a specific node with WireGuard installed, modify the node-specific Felix configuration. e.g., to turn off encryption for traffic on node `my-node`, use the following command. This command disables WireGuard for both IPv4 and IPv6, modify it accordingly if disabling only either IP version: - -```bash -cat < -o yaml - ... - status: - ... - wireguardPublicKey: jlkVyQYooZYzI2wFfNhSZez5eWh44yfq1wKVjLvSXgY= - wireguardPublicKeyV6: hTnWXGM4qk/Z8fQgyGFdpPd4qM9QGR2ey30s31yC6g4= - ... -``` - -### Disable WireGuard for a cluster - -To disable WireGuard on all nodes modify the default Felix configuration. For example: - -```bash - calicoctl patch felixconfiguration default --type='merge' -p '{"spec":{"wireguardEnabled":false,"wireguardEnabledV6":false}}' -``` - -## Additional resources - -- [Secure Calico component communications](comms/index.mdx) -- [Configure MTU to maximize network performance](../networking/configuring/mtu.mdx) -- [Hands-on workshop: Learn how to implement node-to-node encryption with WireGuard](https://www.tigera.io/tutorials/?_sf_s=WireGuard) diff --git a/calico_versioned_docs/version-3.29/network-policy/extreme-traffic/defend-dos-attack.mdx b/calico_versioned_docs/version-3.29/network-policy/extreme-traffic/defend-dos-attack.mdx deleted file mode 100644 index 8b3171d435..0000000000 --- a/calico_versioned_docs/version-3.29/network-policy/extreme-traffic/defend-dos-attack.mdx +++ /dev/null @@ -1,107 +0,0 @@ ---- -description: Define DoS mitigation rules in Calico policy to quickly drop connections when under attack. Learn how rules use eBPF and XDP, including hardware offload when available. ---- - -# Defend against DoS attacks - -## Big picture - -Calico automatically enforces specific types of deny-list policies at the earliest possible point in the packet processing pipeline, including offloading to NIC hardware whenever possible. - -## Value - -During a DoS attack, a cluster can receive massive numbers of connection requests from attackers. The faster these connection requests are dropped, the less flooding and overloading to your hosts. When you define DoS mitigation rules in Calico network policy, Calico enforces the rules as efficiently as possible to minimize the impact. - -## Concepts - -### Earliest packet processing - -The earliest point in the packet processing pipeline that packets can be dropped, depends on the Linux kernel version and the capabilities of the NIC driver and NIC hardware. Calico automatically uses the fastest available option. - -| Processed by... | Used by Calico if... | Performance | -| --------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | -| NIC hardware | The NIC supports **XDP offload** mode. | Fastest | -| NIC driver | The NIC driver supports **XDP native** mode. | Faster | -| Kernel | The kernel supports **XDP generic mode** and Calico is configured to explicitly use it. This mode is rarely used and has no performance benefits over iptables raw mode below. To enable, see [Felix Configuration](../../reference/resources/felixconfig.mdx). | Fast | -| Kernel | If none of the modes above are available, **iptables raw** mode is used. | Fast | - -:::note - -XDP modes require Linux kernel v4.16 or later. - -::: - -## How to - -The high-level steps to defend against a DoS attack are: - -- [Step 1: Create host endpoints](#step-1-create-host-endpoints) -- [Step 2: Add CIDRs to deny-list in a global network set](#step-2-add-cidrs-to-deny-list-in-a-global-network-set) -- [Step 3: Create deny incoming traffic global network policy](#step-3-create-deny-incoming-traffic-global-network-policy) - -### Best practice - -The following steps walk through the above required steps, assuming no prior configuration is in place. A best practice is to proactively do these steps before an attack (create the host endpoints, network policy, and global network set). In the event of a DoS attack, you can quickly respond by just adding the CIDRs that you want to deny-list to the global network set. - -### Step 1: Create host endpoints - -First, you create the HostEndpoints corresponding to the network interfaces where you want to enforce DoS mitigation rules. In the following example, the HostEndpoint secures the interface named **eth0** with IP **10.0.0.1** on node **jasper**. - -```yaml -apiVersion: projectcalico.org/v3 -kind: HostEndpoint -metadata: - name: production-host - labels: - apply-dos-mitigation: 'true' -spec: - interfaceName: eth0 - node: jasper - expectedIPs: ['10.0.0.1'] -``` - -### Step 2: Add CIDRs to deny-list in a global network set - -Next, you create a Calico **GlobalNetworkset**, adding the CIDRs that you want to deny-list. In the following example, the global network set deny-lists the CIDR ranges **1.2.3.4/32** and **5.6.0.0/16**: - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkSet -metadata: - name: dos-mitigation - labels: - dos-deny-list: 'true' -spec: - nets: - - '1.2.3.4/32' - - '5.6.0.0/16' -``` - -### Step 3: Create deny incoming traffic global network policy - -Finally, create a Calico GlobalNetworkPolicy adding the GlobalNetworkSet label (**dos-deny-list** in the previous step) as a selector to deny ingress traffic. To more quickly enforce the denial of forwarded traffic to the host at the packet level, use the **doNotTrack** and **applyOnForward** options. - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: dos-mitigation -spec: - selector: apply-dos-mitigation == 'true' - doNotTrack: true - applyOnForward: true - types: - - Ingress - ingress: - - action: Deny - source: - selector: dos-deny-list == 'true' -``` - -## Additional resources - -- [Global network sets](../../reference/resources/globalnetworkset.mdx) -- [Global network policy](../../reference/resources/globalnetworkpolicy.mdx) -- [Create a host endpoint](../../reference/resources/hostendpoint.mdx) -- [Introduction to XDP](https://www.iovisor.org/technology/xdp) -- [Advanced XDP documentation](https://prototype-kernel.readthedocs.io/en/latest/networking/XDP/index.html) diff --git a/calico_versioned_docs/version-3.29/network-policy/extreme-traffic/high-connection-workloads.mdx b/calico_versioned_docs/version-3.29/network-policy/extreme-traffic/high-connection-workloads.mdx deleted file mode 100644 index be2c1f6a22..0000000000 --- a/calico_versioned_docs/version-3.29/network-policy/extreme-traffic/high-connection-workloads.mdx +++ /dev/null @@ -1,89 +0,0 @@ ---- -description: Create a Calico network policy rule to bypass Linux conntrack for traffic to workloads that experience extremely large number of connections. ---- - -# Enable extreme high-connection workloads - -## Big picture - -Use a $[prodname] network policy rule to bypass Linux conntrack for traffic to workloads that experience extremely large number of connections. - -## Value - -When the number of connections on a node exceeds the number of connections that Linux conntrack can track, connections can be rejected or dropped. $[prodname] network policy can be used to selectively bypass Linux conntrack for traffic to/from these types of workloads. - -## Concepts - -### Linux conntrack - -Connection tracking (“conntrack”) is a core feature of the Linux kernel’s networking stack. It allows the kernel to keep track of all logical network connections or flows, and thereby identify all of the packets that make up each flow so they can be handled consistently together. Conntrack is an essential part of the mainline Linux network processing pipeline, normally improving performance, and enabling NAT and stateful access control. - -### Extreme high-connection workloads - -Some niche workloads handling extremely high number of simultaneous connections, or very high rate of short lived connections, can exceed the maximum number of connections Linux conntrack is able to track. One real world example of such a workload is an extreme scale memcached server handling 50k+ connections per second. - -### $[prodname] doNotTrack network policy - -The $[prodname] global network policy option, **doNotTrack**, indicates to apply the rules in the policy before connection tracking, and that packets allowed by these rules should not be tracked. The policy is applied early in the Linux packet processing pipeline, before any regular network policy rules, and independent of the policy order field. - -Unlike normal network policy rules, doNotTrack network policy rules are stateless, meaning you must explicitly specify rules to allow return traffic that would normally be automatically allowed by conntrack. For example, for a server on port 999, the policy must include an ingress rule allowing inbound traffic to port 999, and an egress rule to allow outbound traffic from port 999. - -In a doNotTrack policy: - -- Ingress rules apply to all incoming traffic through a host endpoint, regardless of where the traffic is going -- Egress rules apply only to traffic that is sent from the host endpoint (not a local workload) - -Finally, you must add an **applyOnForward: true expression** for a **doNotTrack policy** to work. - -## Before you begin... - -Before creating a **doNotTrack** network policy, read this [blog](https://www.tigera.io/blog/when-linux-conntrack-is-no-longer-your-friend/) to understand use cases, benefits, and trade offs. - -## How to - -### Bypass connection traffic for high connection server - -In the following example, a memcached server pod with **hostNetwork: true** was scheduled on the node memcached-node-1. We create a HostEndpoint for the node. Next, we create a GlobalNetwork Policy with symmetrical rules for ingress and egress with doNotTrack and applyOnForward set to true. - -```yaml -apiVersion: projectcalico.org/v3 -kind: HostEndpoint -metadata: - name: memcached-node-1-eth0 - labels: - memcached: server -spec: - interfaceName: eth0 - node: memcached-node-1 - expectedIPs: - - 10.128.0.162 ---- -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: memcached-server -spec: - selector: memcached == 'server' - applyOnForward: true - doNotTrack: true - ingress: - - action: Allow - protocol: TCP - source: - selector: memcached == 'client' - destination: - ports: - - 12211 - egress: - - action: Allow - protocol: TCP - source: - ports: - - 12211 - destination: - selector: memcached == 'client' -``` - -## Additional resources - -- [Global network policy](../../reference/resources/globalnetworkpolicy.mdx) diff --git a/calico_versioned_docs/version-3.29/network-policy/extreme-traffic/index.mdx b/calico_versioned_docs/version-3.29/network-policy/extreme-traffic/index.mdx deleted file mode 100644 index 65e6316852..0000000000 --- a/calico_versioned_docs/version-3.29/network-policy/extreme-traffic/index.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: Use Calico network policy early in the Linux packet processing pipeline to handle extreme traffic scenarios. -hide_table_of_contents: true ---- - -# Policy for extreme traffic - -import DocCardList from '@theme/DocCardList'; -import { useCurrentSidebarCategory } from '@docusaurus/theme-common'; - - diff --git a/calico_versioned_docs/version-3.29/network-policy/get-started/calico-policy/calico-labels.mdx b/calico_versioned_docs/version-3.29/network-policy/get-started/calico-policy/calico-labels.mdx deleted file mode 100644 index 1c01154fcf..0000000000 --- a/calico_versioned_docs/version-3.29/network-policy/get-started/calico-policy/calico-labels.mdx +++ /dev/null @@ -1,110 +0,0 @@ ---- -description: Calico automatic labels for use with resources. ---- - -# Calico automatic labels - -As a convenience, $[prodname] provides immutable labels that are used for specific resources when evaluating selectors in policies. The labels make it easier to match resources in common ways (such as matching a namespace by name). - -## Labels for matching namespaces - -The label `projectcalico.org/name` is set to the name of the namespace. This allows for matching namespaces by name when using a `namespaceSelector` field. - -For example, the following GlobalNetworkPolicy applies to workloads with label, `color: red` in namespaces named, `"foo"` and `"bar"`. The policy allows ingress traffic to port 8080 from all workloads in a third namespace named, `"baz"`: - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: foo-and-bar -spec: - namespaceSelector: projectcalico.org/name in {"foo", "bar"} - selector: color == "red" - types: - - Ingress - ingress: - - action: Allow - source: - namespaceSelector: projectcalico.org/name == "baz" - destination: - ports: - - 8080 -``` - -Be aware that the default values for `namespaceSelector` for NetworkPolicy and GlobalNetworkPolicy are different. For example: - -**In a network policy**, - - ```yaml - namespaceSelector: - selector: foo == "bar" - ``` -means "resources in the same namespace as the network policy that matches foo == 'bar'". - -**In a global network policy**, - - ```yaml - namespaceSelector: - selector: foo == "bar" - ``` -means "resources in any namespace and non-namespaced resources that match foo == 'bar'". - -Further, - - ```yaml - namespaceSelector: projectcalico.org/name == "some-namespace" - selector: foo == "bar" - ``` -is equivalent to: - - ```yaml - namespaceSelector: - selector: (foo == "bar") && (projectcalico.org/namespace == "some-namespace") - ``` - -### Labels for matching service accounts - -Similarly, the `projectcalico.org/name` label is applied to ServiceAccounts and allows for matching by name in a `serviceAccountSelector`. - -### Kubernetes labels for matching namespaces - -Kubernetes also has [automatic labeling](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/#automatic-labelling), for example `kubernetes.io/metadata.name`. The Kubernetes namespace label serves the same purpose and can be used in the same way as the $[prodname] label. The `projectcalico.org/name` label predates the automatic Kubernetes label. - -## Labels for matching workload endpoints - -WorkloadEndpoints (which represent Pods in Kubernetes, or VM instances in OpenStack), receive several automatic labels: - -* `projectcalico.org/orchestrator` is applied to all WorkloadEndpoints and allows Kubernetes Pods to be distinguished from OpenStack VM instances, and from HostEndpoints (which do not have the label): - -* `has(projectcalico.org/orchestrator)` matches only WorkloadEndpoints -* `projectcalico.org/orchestrator == "k8s"` matches only Kubernetes Pods - -* For WorkloadEndpoints that represent Kubernetes Pods, `projectcalico.org/namespace` contains the name of the pod's namespace. `projectcalico.org/namespace` predates the addition of `namespaceSelector` fields to GlobalNetworkPolicies; it serves the same purpose as the `projectcalico.org/name` label in a `namespaceSelector` field. The following GlobalNetworkPolicy is exactly equivalent to the example shown in the Namespaces section: - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: foo-and-bar -spec: - selector: projectcalico.org/namespace in {"foo", "bar"} && color == "red" - types: - - Ingress - ingress: - - action: Allow - source: - selector: projectcalico.org/namespace == "baz" - destination: - ports: - - 8080 -``` - -## Use the correct selector with labels in policies - -$[prodname] labels must be used with the correct selector or the policy will not work as designed (and there are no error messages in the web console or when applying the YAML). - -| Calico label | Usage requirements | Use in these resources... | -| --------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | -| `projectcalico.org/name` | Use with a **namespaceSelector** or **serviceAccountSelector**. | - Network policy
    - Staged network policy

    Namespaced resources that apply only to workload endpoint resources in the namespace.
    | -| `projectcalico.org/namespace` | Use only with selectors.

    Use the label as the label name, and a namespace name as the value to compare against (for example projectcalico.org/namespace == "default"). | - Global network policy
    - Staged global network policy

    Cluster-wide (non-namespaced) resources that apply to workload endpoint resources in all namespaces, and to host endpoint resources. | - diff --git a/calico_versioned_docs/version-3.29/network-policy/get-started/calico-policy/calico-network-policy.mdx b/calico_versioned_docs/version-3.29/network-policy/get-started/calico-policy/calico-network-policy.mdx deleted file mode 100644 index 3a5fea36b2..0000000000 --- a/calico_versioned_docs/version-3.29/network-policy/get-started/calico-policy/calico-network-policy.mdx +++ /dev/null @@ -1,258 +0,0 @@ ---- -description: Create your first Calico network policies. Shows the rich features using sample policies that extend native Kubernetes network policy. ---- - -# Get started with Calico network policy - -## Big picture - -Enforce which network traffic that is allowed or denied using rules in Calico network policy. - -## Value - -### Extends Kubernetes network policy - -Calico network policy provides a richer set of policy capabilities than Kubernetes including: policy ordering/priority, deny rules, and more flexible match rules. While Kubernetes network policy applies only to pods, Calico network policy can be applied to multiple types of endpoints including pods, VMs, and host interfaces. Finally, when used with Istio service mesh, Calico network policy supports securing applications layers 5-7 match criteria, and cryptographic identity. - -### Write once, works everywhere - -No matter which cloud provider you use now, adopting Calico network policy means you write the policy once and it is portable. If you move to a different cloud provider, you don’t need to rewrite your Calico network policy. Calico network policy is a key feature to avoid cloud provider lock-in. - -### Works seamlessly with Kubernetes network policies - -You can use Calico network policy in addition to Kubernetes network policy, or exclusively. For example, you could allow developers to define Kubernetes network policy for their microservices. For broader and higher-level access controls that developers cannot override, you could allow only security or Ops teams to define Calico network policies. - -## Concepts - -### Endpoints - -Calico network policies apply to **endpoints**. In Kubernetes, each pod is a Calico endpoint. However, Calico can support other kinds of endpoints. There are two types of Calico endpoints: **workload endpoints** (such as a Kubernetes pod or OpenStack VM) and **host endpoints** (an interface or group of interfaces on a host). - -### Namespaced and global network policies - -**Calico network policy** is a namespaced resource that applies to pods/containers/VMs in that namespace. - -```yaml -apiVersion: projectcalico.org/v3 -kind: NetworkPolicy -metadata: - name: allow-tcp-6379 - namespace: production -``` - -**Calico global network policy** is a non-namespaced resource and can be applied to any kind of endpoint (pods, VMs, host interfaces) independent of namespace. - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: allow-tcp-port-6379 -``` - -Because global network policies use **kind: GlobalNetworkPolicy**, they are grouped separately from **kind: NetworkPolicy**. For example, global network policies will not be returned from `calicoctl get networkpolicy`, and are rather returned from `calicoctl get globalnetworkpolicy`. - -### kubectl vs calicoctl - -Calico network policies and Calico global network policies are applied using calicoctl. Syntax is similar to Kubernetes, but there a few differences. For help, see [calicoctl user reference](../../../reference/calicoctl/overview.mdx). - -### Ingress and egress - -Each network policy rule applies to either **ingress** or **egress** traffic. From the point of view of an endpoint (pod, VM, host interface), **ingress** is incoming traffic to the endpoint, and **egress** is outgoing traffic from the endpoint. In a Calico network policy, you create ingress and egress rules independently (egress, ingress, or both). - -You can specify whether policy applies to ingress, egress, or both using the **types** field. If you do not use the types field, Calico defaults to the following values. - -| Ingress rule present? | Egress rule present? | Value | -| :-------------------: | :------------------: | :-------------: | -| No | No | Ingress | -| Yes | No | Ingress | -| No | Yes | Egress | -| Yes | Yes | Ingress, Egress | - -### Network traffic behaviors: deny and allow - -The Kubernetes network policy specification defines the following behavior: - -- If no network policies apply to a pod, then all traffic to/from that pod is allowed. -- If one or more network policies apply to a pod containing ingress rules, then only the ingress traffic specifically allowed by those policies is allowed. -- If one or more network policies apply to a pod containing egress rules, then only the egress traffic specifically allowed by those policies is allowed. - -For compatibility with Kubernetes, **Calico network policy** follows the same behavior for Kubernetes pods. For other endpoint types (VMs, host interfaces), Calico network policy is default deny. That is, only traffic specifically allowed by network policy is allowed, even if no network policies apply to the endpoint. - -## Before you begin - -`calicoctl` must be **installed** and **configured** before use. `calicoctl` will use etcd as the datastore by default, but many $[prodname] installation manifests configure Kubernetes as the datastore. You can find more information on how to configure `calicoctl` in the following link: - -- [Configure `calicoctl`](../../../operations/calicoctl/configure/overview.mdx) - -## How to - -- [Control traffic to/from endpoints in a namespace](#control-traffic-tofrom-endpoints-in-a-namespace) -- [Control traffic to/from endpoints independent of namespace](#control-traffic-tofrom-endpoints-independent-of-namespace) -- [Control traffic to/from endpoints using IP addresses or CIDR ranges](#control-traffic-tofrom-endpoints-using-ip-addresses-or-cidr-ranges) -- [Apply network policies in specific order](#apply-network-policies-in-specific-order) -- [Generate logs for specific traffic](#generate-logs-for-specific-traffic) - -### Control traffic to/from endpoints in a namespace - -In the following example, ingress traffic to endpoints in the **namespace: production** with label **color: red** is allowed, only if it comes from a pod in the same namespace with **color: blue**, on port **6379**. - -```yaml -apiVersion: projectcalico.org/v3 -kind: NetworkPolicy -metadata: - name: allow-tcp-6379 - namespace: production -spec: - selector: color == 'red' - ingress: - - action: Allow - protocol: TCP - source: - selector: color == 'blue' - destination: - ports: - - 6379 -``` - -To allow ingress traffic from endpoints in other namespaces, use a **namespaceSelector** in the policy rule. A namespaceSelector matches namespaces based on the labels that are applied in the namespace. In the following example, ingress traffic is allowed from endpoints in namespaces that match **shape == circle**. - -```yaml -apiVersion: projectcalico.org/v3 -kind: NetworkPolicy -metadata: - name: allow-tcp-6379 - namespace: production -spec: - selector: color == 'red' - ingress: - - action: Allow - protocol: TCP - source: - selector: color == 'blue' - namespaceSelector: shape == 'circle' - destination: - ports: - - 6379 -``` - -### Control traffic to/from endpoints independent of namespace - -The following Calico network policy is similar to the previous example, but uses **kind: GlobalNetworkPolicy** so it applies to all endpoints, regardless of namespace. - -In the following example, incoming TCP traffic to any pods with label **color: red** is denied if it comes from a pod with **color: blue**. - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: deny-blue -spec: - selector: color == 'red' - ingress: - - action: Deny - protocol: TCP - source: - selector: color == 'blue' -``` - -As with **kind: NetworkPolicy**, you can allow or deny ingress traffic from endpoints in specific namespaces using a namespaceSelector in the policy rule: - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: deny-circle-blue -spec: - selector: color == 'red' - ingress: - - action: Deny - protocol: TCP - source: - selector: color == 'blue' - namespaceSelector: shape == 'circle' -``` - -### Control traffic to/from endpoints using IP addresses or CIDR ranges - -Instead of using a selector to define which traffic is allowed to/from the endpoints in a network policy, you can also specify an IP block in CIDR notation. - -In the following example, outgoing traffic is allowed from pods with the label **color: red** if it goes to an IP address in the **1.2.3.4/24** CIDR block. - -```yaml -apiVersion: projectcalico.org/v3 -kind: NetworkPolicy -metadata: - name: allow-egress-external - namespace: production -spec: - selector: color == 'red' - types: - - Egress - egress: - - action: Allow - destination: - nets: - - 1.2.3.0/24 -``` - -### Apply network policies in specific order - -To control the order/sequence of applying network policies, you can use the **order** field (with precedence from the lowest value to highest). Defining policy **order** is important when you include both **action: allow** and **action: deny** rules that may apply to the same endpoint. - -In the following example, the policy **allow-cluster-internal-ingress** (order: 10) will be applied before the **policy drop-other-ingress** (order: 20). - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: drop-other-ingress -spec: - order: 20 - #...deny policy rules here... -``` - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: allow-cluster-internal-ingress -spec: - order: 10 - #...allow policy rules here... -``` - -### Generate logs for specific traffic - -In the following example, incoming TCP traffic to an application is denied, and each connection attempt is logged to syslog. - -```yaml -apiVersion: projectcalico.org/v3 -kind: NetworkPolicy -metadata: - name: allow-tcp-6379 - namespace: production -spec: - selector: role == 'database' - types: - - Ingress - - Egress - ingress: - - action: Log - protocol: TCP - source: - selector: role == 'frontend' - - action: Deny - protocol: TCP - source: - selector: role == 'frontend' -``` - -### Create policy for established connections - -Policies are immediately applied to any new connections. However, for existing connections that are already open, the policy changes will only take effect after the connection has been reestablished. This means that any ongoing sessions may not immediately reflect policy changes until they are initiated again. - -## Additional resources - -- For additional Calico network policy features, see [Calico network policy](../../../reference/resources/networkpolicy.mdx) and [Calico global network policy](../../../reference/resources/globalnetworkpolicy.mdx) -- For an alternative to using IP addresses or CIDRs in policy, see [Network sets](../../../reference/resources/networkset.mdx) -- For details on the calicoctl command line tool, see [calicoctl user reference](../../../reference/calicoctl/overview.mdx) diff --git a/calico_versioned_docs/version-3.29/network-policy/get-started/calico-policy/calico-policy-tutorial.mdx b/calico_versioned_docs/version-3.29/network-policy/get-started/calico-policy/calico-policy-tutorial.mdx deleted file mode 100644 index 0fc30bf6c0..0000000000 --- a/calico_versioned_docs/version-3.29/network-policy/get-started/calico-policy/calico-policy-tutorial.mdx +++ /dev/null @@ -1,219 +0,0 @@ ---- -description: Learn how to create more advanced Calico network policies (namespace, allow and deny all ingress and egress). ---- - -# Calico policy tutorial - -Calico network policies **extend** the functionalities of Kubernetes network policies. To demonstrate this, this tutorial follows a similar approach to the [Kubernetes Advanced Network Policy Tutorial](../kubernetes-policy/kubernetes-policy-advanced.mdx), but instead uses Calico network policies and highlights differences between the two policy types, making use of features that are not available in Kubernetes network policies. - -## Requirements - -- A working Kubernetes cluster and access to it using kubectl and calicoctl -- Your Kubernetes nodes have connectivity to the public internet -- You are familiar with [Calico NetworkPolicy](calico-network-policy.mdx) - -## Tutorial flow - -1. Create the namespace and NGINX service -2. Configure default deny -3. Allow egress traffic from busybox -4. Allow ingress traffic to NGINX -5. Clean up - -## 1. Create the namespace and nginx service - -We'll use a new namespace for this guide. Run the following commands to create the namespace and a plain NGINX service listening on port 80. - -```bash -kubectl create ns advanced-policy-demo -kubectl create deployment --namespace=advanced-policy-demo nginx --image=nginx -kubectl expose --namespace=advanced-policy-demo deployment nginx --port=80 -``` - -### Verify access - allowed all ingress and egress - -Open up a second shell session which has `kubectl` connectivity to the Kubernetes cluster and create a busybox pod to test policy access. This pod will be used throughout this tutorial to test policy access. - -```bash -kubectl run --namespace=advanced-policy-demo access --rm -ti --image busybox /bin/sh -``` - -This will open up a shell session inside the `busybox` pod, as shown below. - -``` -Waiting for pod advanced-policy-demo/access-472357175-y0m47 to be running, status is Pending, pod ready: false - -If you don't see a command prompt, try pressing enter. -/ # -``` - -Now from within the busybox "access" pod execute the following command to test access to the nginx service. - -```bash -wget -q --timeout=5 nginx -O - -``` - -It returns the HTML of the nginx welcome page. - -Still within the busybox "access" pod, issue the following command to test access to google.com. - -```bash -wget -q --timeout=5 google.com -O - -``` - -It returns the HTML of the google.com home page. - -## 2. Lock down all traffic - -We will begin by using a default deny [Global Calico Network Policy](../../../reference/resources/globalnetworkpolicy.mdx) (which you can only do using Calico) that will help us adopt best practices in using a [zero trust network model](../../adopt-zero-trust.mdx) to secure our workloads. Note that Global Calico Network Policies are not namespaced and effect all pods that match the policy selector. In contrast, Kubernetes Network Policies are namespaced, so you would need to create a default deny policy per namespace to achieve the same effect. Note that to simplify this tutorial we exclude pods in the `kube-system`,`calico-system` and `calico-apiserver` namespace, so we don't have to consider the policies required to keep Kubernetes itself running smoothly when we apply our default deny. - -```bash -calicoctl create -f - < - - -Welcome to nginx!... -``` - -Next, try to retrieve the home page of google.com. - -```bash -wget -q --timeout=5 google.com -O - -``` - -It will return the HTML of the google home page. - -We have allowed our access pod access to the outside internet and the nginx service using Calico Network Policies! - -# 5. Clean up - -To clean up this tutorial session run the following commands to clean up the network policies and remove the demo namespace. - -```bash -calicoctl delete policy allow-busybox-egress -n advanced-policy-demo -calicoctl delete policy allow-nginx-ingress -n advanced-policy-demo -calicoctl delete gnp default-deny -kubectl delete ns advanced-policy-demo -``` diff --git a/calico_versioned_docs/version-3.29/network-policy/get-started/calico-policy/index.mdx b/calico_versioned_docs/version-3.29/network-policy/get-started/calico-policy/index.mdx deleted file mode 100644 index fce333b50a..0000000000 --- a/calico_versioned_docs/version-3.29/network-policy/get-started/calico-policy/index.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: Calico network policy lets you secure both workloads and hosts. -hide_table_of_contents: true ---- - -# Calico policy - -import DocCardList from '@theme/DocCardList'; -import { useCurrentSidebarCategory } from '@docusaurus/theme-common'; - - diff --git a/calico_versioned_docs/version-3.29/network-policy/get-started/calico-policy/network-policy-openstack.mdx b/calico_versioned_docs/version-3.29/network-policy/get-started/calico-policy/network-policy-openstack.mdx deleted file mode 100644 index 87941c5292..0000000000 --- a/calico_versioned_docs/version-3.29/network-policy/get-started/calico-policy/network-policy-openstack.mdx +++ /dev/null @@ -1,99 +0,0 @@ ---- -description: Extend OpenStack security groups by applying Calico network policy and using labels to identify VMs within network policy rules. ---- - -# Get started with Calico network policy for OpenStack - -## Big picture - -Use $[prodname] network policy to extend security beyond OpenStack security groups. - -## Value - -For **deployment users**, OpenStack security groups provides enough features and flexibility. But for **deployment administrators**, limited labeling in VM security groups makes it difficult to address all security use cases that arise. $[prodname] network policy provides special VM labels so you can identify VMs and impose additional restrictions that cannot be bypassed by users’ security group configuration. - -## Concepts - -### Multi-region deployments - -Using the OpenStack API, it is difficult to apply policy to cross-region network traffic because security groups are local to a single region. In $[prodname], each region in your OpenStack deployment becomes a separate $[prodname] namespace in a single etcd datastore. With regions mapped to namespaces, you can easily define $[prodname] network policy for communications between VMs in different regions. - -### Labels: more flexibility, greater security - -$[prodname] provides predefined [VM endpoint labels](../../../networking/openstack/labels.mdx) (projects, security groups, and namespaces) for OpenStack deployments. You can use these labels in selector fields in $[prodname] network policy to identify the VMs for allow/deny policy. - -### Policy ordering and enforcement - -$[prodname] network policy is always enforced before OpenStack security groups, and cannot be overridden by user-level security group configuration. - -## Before you begin... - -- [Set up $[prodname] for OpenStack](../../../networking/openstack/dev-machine-setup.mdx) -- If you are using a multi-region VM deployment, [follow these extra steps](../../../networking/openstack/multiple-regions.mdx) - -## How to - -- [Restrict all ingress traffic between specific security groups](#restrict-all-ingress-traffic-between-specific-security-groups) -- [Allow specific traffic between VMs in different regions](#allow-specific-traffic-between-vms-in-different-regions) - -### Restrict all ingress traffic between specific security groups - -In the following example, we create a **GlobalNetworkPolicy** that is applied before any OpenStack security group policy. It prevents all ingress communication between the OpenStack **superman** and **lexluthor** projects. We use the predefined $[prodname] VM endpoint label, **openstack-project-name**, to identify projects. - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: deny-lexluthor-to-superman -spec: - order: 10 - selector: "projectcalico.org/openstack-project-name == 'superman'" - types: - - Ingress - ingress: - - action: Deny - source: - selector: "projectcalico.org/openstack-project-name == 'lexluthor'" ---- -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: deny-superman-to-lexluthor -spec: - order: 10 - selector: "projectcalico.org/openstack-project-name == 'lexluthor'" - types: - - Ingress - ingress: - - action: Deny - source: - selector: "projectcalico.org/openstack-project-name == 'superman'" -``` - -### Allow specific traffic between VMs in different regions - -In the following example, we use the predefined VM endpoint label, **openstack-security_group_ID**. Traffic is allowed to VMs with the label, **openstack-a773…** on port 80, from VMs in any region with the label, **openstack-85cc…**. - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: allow-tcp-80 -spec: - selector: 'has(sg.projectcalico.org/openstack-a7734e61-b545-452d-a3cd-0189cbd9747a)' - types: - - Ingress - ingress: - - action: Allow - protocol: TCP - source: - selector: 'has(sg.projectcalico.org/openstack-85cc3048-abc3-43cc-89b3-377341426ac5)' - destination: - ports: - - 80 -``` - -## Additional resources - -- For additional $[prodname] network policy features, see [$[prodname] network policy](../../../reference/resources/networkpolicy.mdx) and [Calico global network policy](../../../reference/resources/globalnetworkpolicy.mdx) -- For details on the OpenStack integration with $[prodname], see [$[prodname] for OpenStack](../../../networking/openstack/dev-machine-setup.mdx) diff --git a/calico_versioned_docs/version-3.29/network-policy/get-started/index.mdx b/calico_versioned_docs/version-3.29/network-policy/get-started/index.mdx deleted file mode 100644 index 7626a83757..0000000000 --- a/calico_versioned_docs/version-3.29/network-policy/get-started/index.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: If you are new to Kubernetes, start with "Kubernetes policy" and learn the basics of enforcing policy for pod traffic. Otherwise, dive in and create more powerful policies with Calico policy. The good news is, Kubernetes and Calico policies are very similar and work alongside each other -- so managing both types is easy. -hide_table_of_contents: true ---- - -# Get started with policy - -import DocCardList from '@theme/DocCardList'; -import { useCurrentSidebarCategory } from '@docusaurus/theme-common'; - - diff --git a/calico_versioned_docs/version-3.29/network-policy/get-started/kubernetes-default-deny.mdx b/calico_versioned_docs/version-3.29/network-policy/get-started/kubernetes-default-deny.mdx deleted file mode 100644 index fad1e748ed..0000000000 --- a/calico_versioned_docs/version-3.29/network-policy/get-started/kubernetes-default-deny.mdx +++ /dev/null @@ -1,148 +0,0 @@ ---- -description: Create a default deny network policy so pods that are missing policy are not allowed traffic until appropriate network policy is defined. ---- - -# Enable a default deny policy for Kubernetes pods - -## Big picture - -Enable a default deny policy for Kubernetes pods using Kubernetes or $[prodname] network policy. - -## Value - -A **default deny** network policy provides an enhanced security posture so pods without policy (or incorrect policy) are not allowed traffic until appropriate network policy is defined. - -## Features - -This how-to guide uses the following $[prodname] features: - -- **NetworkPolicy** -- **GlobalNetworkPolicy** - -## Concepts - -### Default deny/allow behavior - -**Default allow** means all traffic is allowed by default, unless otherwise specified. **Default deny** means all traffic is denied by default, unless explicitly allowed. **Kubernetes pods are default allow**, unless network policy is defined to specify otherwise. - -For compatibility with Kubernetes, **$[prodname] network policy** enforcement follows the standard convention for Kubernetes pods: - -- If no network policies apply to a pod, then all traffic to/from that pod is allowed. -- If one or more network policies apply to a pod with type ingress, then only the ingress traffic specifically allowed by those policies is allowed. -- If one or more network policies apply to a pod with type egress, then only the egress traffic specifically allowed by those policies is allowed. - -For other endpoint types (VMs, host interfaces), the default behavior is to deny traffic. Only traffic specifically allowed by network policy is allowed, even if no network policies apply to the endpoint. - -## Before you begin - -To apply the sample $[prodname] network policies in the following section, [install calicoctl](../../operations/calicoctl/install.mdx). - -## How to - -- [Create a default deny network policy](#create-a-default-deny-network-policy) -- [Create a global default deny network policy](#create-a-global-default-deny-policy) - -### Create a default deny network policy - -Immediately after installation, a best practice is to create a namespaced default deny network policy to secure pods without policy or incorrect policy until you can put policies in place and test them. - -In the following example, we create a $[prodname] default deny **NetworkPolicy** for all workloads in the namespace, **engineering**. - -```yaml -apiVersion: projectcalico.org/v3 -kind: NetworkPolicy -metadata: - name: default-deny - namespace: engineering -spec: - selector: all() - types: - - Ingress - - Egress -``` - -Here's an equivalent default deny **Kubernetes network policy** for all pods in the namespace, **engineering** - -```yaml -apiVersion: networking.k8s.io/v1 -kind: NetworkPolicy -metadata: - name: default-deny - namespace: engineering -spec: - podSelector: {} - policyTypes: - - Ingress - - Egress -``` - -### Create a global default deny policy - -A default deny policy ensures that unwanted traffic (ingress and egress) is denied by default without you having to remember default deny/allow behavior of Kubernetes and $[prodname] policies. This policy can also help mitigate risks of lateral malicious attacks. - -#### Best practice #1: Allow, stage, then deny - -We recommend that you create a global default deny policy after you complete writing policy for the traffic that you want to allow. The following steps summarizes the best practice to test and lock down the cluster to block unwanted traffic: - -1. Create a global default deny policy and test it in a staging environment. (The policy will show all the traffic that would be blocked if it were converted into a deny.) -1. Create network policies to individually allow the traffic shown as blocked in step 1 until no connections are denied. -1. Enforce the global default deny policy. - -#### Best practice #2: Keep the scope to non-system pods - -A global default deny policy applies to the entire cluster including all workloads in all namespaces, hosts (computers that run the hypervisor for VMs or container runtime for containers), including Kubernetes control plane and $[prodname] control plane nodes and pods. - -For this reason, the best practice is to create a global default deny policy for **non-system pods** as shown in the following example. - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: deny-app-policy -spec: - namespaceSelector: kubernetes.io/metadata.name not in {"calico-system", "kube-public", "kube-system", "tigera-operator"} - types: - - Ingress - - Egress - egress: - # allow all namespaces to communicate to DNS pods - - action: Allow - destination: - services: - name: kube-dns - namespace: kube-system - ports: - - 53 -``` - -Note the following: - -- Even though we call this policy "global default deny", the above policy is not explicitly denying traffic. By selecting the traffic with the `namespaceSelector` but not specifying an allow, the traffic is denied after all other policy is evaluated. This design also makes it unnecessary to ensure any specific order (priority) for the default-deny policy. -- Allowing access to `kube-dns` simplifies per-pod policies because you don't need to duplicate the DNS rules in every policy -- This policy uses a negative selector for the `spec.namespaceselector` field to exclude control plane namespaces. - In this example, those namespaces include the `calico-system`, `kube-public`, `kube-system`, and `tigera-operator` namespaces. - Because your installation may have different components, make sure to check what you have installed before implementing a similar policy. - -In a staging environment, verify that the policy does not block any necessary traffic before enforcing it. - -### Don't try this! - -The following policy works and looks fine on the surface. But as described in Best practices #2, the policy is too broad in scope and could break your cluster. Therefore, we do not recommend adding this type of policy, even if you have verified allowed traffic in your staging environment. - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: default.default-deny -spec: - tier: default - selector: all() - types: - - Ingress - - Egress -``` - -## Additional resources - -- [Network policy](../../reference/resources/networkpolicy.mdx) -- [Global network policy](../../reference/resources/globalnetworkpolicy.mdx) \ No newline at end of file diff --git a/calico_versioned_docs/version-3.29/network-policy/get-started/kubernetes-policy/index.mdx b/calico_versioned_docs/version-3.29/network-policy/get-started/kubernetes-policy/index.mdx deleted file mode 100644 index f2cfe5b06b..0000000000 --- a/calico_versioned_docs/version-3.29/network-policy/get-started/kubernetes-policy/index.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: Manage your Kubernetes network policies right alongside the more powerful Calico network policies. -hide_table_of_contents: true ---- - -# Kubernetes policy - -import DocCardList from '@theme/DocCardList'; -import { useCurrentSidebarCategory } from '@docusaurus/theme-common'; - - diff --git a/calico_versioned_docs/version-3.29/network-policy/get-started/kubernetes-policy/kubernetes-demo.mdx b/calico_versioned_docs/version-3.29/network-policy/get-started/kubernetes-policy/kubernetes-demo.mdx deleted file mode 100644 index 896d7c0270..0000000000 --- a/calico_versioned_docs/version-3.29/network-policy/get-started/kubernetes-policy/kubernetes-demo.mdx +++ /dev/null @@ -1,101 +0,0 @@ ---- -description: An interactive demo that visually shows how applying Kubernetes policy allows and denies connections. ---- - -# Kubernetes policy, demo - -The included demo sets up a frontend and backend service, as well as a client service, all -running on Kubernetes. It then configures network policy on each service. - -## Prerequisites - -To create a Kubernetes cluster which supports the Kubernetes network policy API, follow -one of our [getting started guides](../../../getting-started/index.mdx). - -## Running the stars example - -### 1) Create the frontend, backend, client, and management-ui apps. - -```shell -kubectl create -f $[tutorialFilesURL]/00-namespace.yaml -kubectl create -f $[tutorialFilesURL]/01-management-ui.yaml -kubectl create -f $[tutorialFilesURL]/02-backend.yaml -kubectl create -f $[tutorialFilesURL]/03-frontend.yaml -kubectl create -f $[tutorialFilesURL]/04-client.yaml -``` - -Wait for all the pods to enter `Running` state. - -```bash -kubectl get pods --all-namespaces --watch -``` - -> Note that it may take several minutes to download the necessary Docker images for this demo. - -The management UI runs as a `NodePort` Service on Kubernetes, and shows the connectivity -of the Services in this example. - -You can view the UI by visiting `http://:30002` in a browser. - -Once all the pods are started, they should have full connectivity. You can see this by visiting the UI. Each service is -represented by a single node in the graph. - -- `backend` -> Node "B" -- `frontend` -> Node "F" -- `client` -> Node "C" - -### 2) Enable isolation - -Running following commands will prevent all access to the frontend, backend, and client Services. - -```shell -kubectl create -n stars -f $[tutorialFilesURL]/default-deny.yaml -kubectl create -n client -f $[tutorialFilesURL]/default-deny.yaml -``` - -#### Confirm isolation - -Refresh the management UI (it may take up to 10 seconds for changes to be reflected in the UI). -Now that we've enabled isolation, the UI can no longer access the pods, and so they will no longer show up in the UI. - -### 3) Allow the UI to access the services using network policy objects - -Apply the following YAML files to allow access from the management UI. - -```shell -kubectl create -f $[tutorialFilesURL]/allow-ui.yaml -kubectl create -f $[tutorialFilesURL]/allow-ui-client.yaml -``` - -After a few seconds, refresh the UI - it should now show the Services, but they should not be able to access each other anymore. - -### 4) Create the backend-policy.yaml file to allow traffic from the frontend to the backend - -```shell -kubectl create -f $[tutorialFilesURL]/backend-policy.yaml -``` - -Refresh the UI. You should see the following: - -- The frontend can now access the backend (on TCP port 6379 only). -- The backend cannot access the frontend at all. -- The client cannot access the frontend, nor can it access the backend. - -### 5) Expose the frontend service to the client namespace - -```shell -kubectl create -f $[tutorialFilesURL]/frontend-policy.yaml -``` - -The client can now access the frontend, but not the backend. Neither the frontend nor the backend -can initiate connections to the client. The frontend can still access the backend. - -To use $[prodname] to enforce egress policy on Kubernetes pods, see [the advanced policy demo](kubernetes-policy-advanced.mdx). - -### 6) (Optional) Clean up the demo environment - -You can clean up the demo by deleting the demo Namespaces: - -```bash -kubectl delete ns client stars management-ui -``` diff --git a/calico_versioned_docs/version-3.29/network-policy/get-started/kubernetes-policy/kubernetes-network-policy.mdx b/calico_versioned_docs/version-3.29/network-policy/get-started/kubernetes-policy/kubernetes-network-policy.mdx deleted file mode 100644 index 06a4be6807..0000000000 --- a/calico_versioned_docs/version-3.29/network-policy/get-started/kubernetes-policy/kubernetes-network-policy.mdx +++ /dev/null @@ -1,179 +0,0 @@ ---- -description: Learn Kubernetes policy syntax, rules, and features for controlling network traffic. ---- - -# Get started with Kubernetes network policy - -## Big picture - -Kubernetes network policy lets administrators and developers enforce which network traffic is allowed using rules. - -## Value - -Kubernetes network policy lets developers secure access to and from their applications using the same simple language they use to deploy them. Developers can focus on their applications without understanding low-level networking concepts. Enabling developers to easily secure their applications using network policies supports a shift left DevOps environment. - -## Concepts - -The Kubernetes Network Policy API provides a standard way for users to define network policy for controlling network traffic. However, Kubernetes has no built-in capability to enforce the network policy. To enforce network policy, you must use a network plugin such as Calico. - -### Ingress and egress - -The bulk of securing network traffic typically revolves around defining egress and ingress rules. From the point of view of a Kubernetes pod, **ingress** is incoming traffic to the pod, and **egress** is outgoing traffic from the pod. In Kubernetes network policy, you create ingress and egress “allow” rules independently (egress, ingress, or both). - -### Default deny/allow behavior - -**Default allow** means all traffic is allowed by default, unless otherwise specified. -**Default deny** means all traffic is denied by default, unless explicitly allowed. - -## How to - -Before you create your first Kubernetes network policy, you need to understand the default network policy behaviors. If no Kubernetes network policies apply to a pod, then all traffic to/from the pod are allowed (default-allow). As a result, if you do not create any network policies, then all pods are allowed to communicate freely with all other pods. If one or more Kubernetes network policies apply to a pod, then only the traffic specifically defined in that network policy are allowed (default-deny). - -You are now ready to start fine-tuning traffic that should be allowed. - -- [Create ingress policies](#create-ingress-policies) -- [Allow ingress traffic from pods in the same namespace](#allow-ingress-traffic-from-pods-in-the-same-namespace) -- [Allow ingress traffic from pods in a different namespace](#allow-ingress-traffic-from-pods-in-a-different-namespace) -- [Create egress policies](#create-egress-policies) -- [Allow egress traffic from pods in the same namespace](#allow-egress-traffic-from-pods-in-the-same-namespace) -- [Allow egress traffic to IP addresses or CIDR range](#allow-egress-traffic-to-ip-addresses-or-cidr-range) -- [Best practice: create deny-all default network policy](#best-practice-create-deny-all-default-network-policy) -- [Create deny-all default ingress and egress network policy](#create-deny-all-default-ingress-and-egress-network-policy) - -### Create ingress policies - -Create ingress network policies to allow inbound traffic from other pods. - -Network policies apply to pods within a specific **namespace**. Policies can include one or more ingress rules. To specify which pods in the namespace the network policy applies to, use a **pod selector**. Within the ingress rule, use another pod selector to define which pods allow incoming traffic, and the **ports** field to define on which ports traffic is allowed. - -#### Allow ingress traffic from pods in the same namespace - -In the following example, incoming traffic to pods with label **color=blue** are allowed only if they come from a pod with **color=red**, on port **80**. - -```yaml -kind: NetworkPolicy -apiVersion: networking.k8s.io/v1 -metadata: - name: allow-same-namespace - namespace: default -spec: - podSelector: - matchLabels: - color: blue - ingress: - - from: - - podSelector: - matchLabels: - color: red - ports: - - port: 80 -``` - -#### Allow ingress traffic from pods in a different namespace - -To allow traffic from pods in a different namespace, use a namespace selector in the ingress policy rule. In the following policy, the namespace selector matches one or more Kubernetes namespaces and is combined with the pod selector that selects pods within those namespaces. - -:::note - -Namespace selectors can be used only in policy rules. The **spec.podSelector** applies to pods only in the same namespace as the policy. - -::: - -In the following example, incoming traffic is allowed only if they come from a pod with label **color=red**, in a namespace with label **shape=square**, on port **80**. - -```yaml -kind: NetworkPolicy -apiVersion: networking.k8s.io/v1 -metadata: - name: allow-different-namespace - namespace: default -spec: - podSelector: - matchLabels: - color: blue - ingress: - - from: - - podSelector: - matchLabels: - color: red - namespaceSelector: - matchLabels: - shape: square - ports: - - port: 80 -``` - -### Create egress policies - -Create egress network policies to allow outbound traffic from pods. - -#### Allow egress traffic from pods in the same namespace - -The following policy allows pod outbound traffic to other pods in the same namespace that match the pod selector. In the following example, outbound traffic is allowed only if they go to a pod with label **color=red**, on port **80**. - -```yaml -kind: NetworkPolicy -apiVersion: networking.k8s.io/v1 -metadata: - name: allow-egress-same-namespace - namespace: default -spec: - podSelector: - matchLabels: - color: blue - egress: - - to: - - podSelector: - matchLabels: - color: red - ports: - - port: 80 -``` - -#### Allow egress traffic to IP addresses or CIDR range - -Egress policies can also be used to allow traffic to specific IP addresses and CIDR ranges. Typically, IP addresses/ranges are used to handle traffic that is external to the cluster for static resources or subnets. - -The following policy allows egress traffic to pods in CIDR, **172.18.0.0/24**. - -```yaml -kind: NetworkPolicy -apiVersion: networking.k8s.io/v1 -metadata: - name: allow-egress-external - namespace: default -spec: - podSelector: - matchLabels: - color: red - egress: - - to: - - ipBlock: - cidr: 172.18.0.0/24 -``` - -### Best practice: create deny-all default network policy - -To ensure that all pods in the namespace are secure, a best practice is to create a default network policy. This avoids accidentally exposing an app or version that doesn’t have policy defined. - -#### Create deny-all default ingress and egress network policy - -The following network policy implements a default **deny-all** ingress and egress policy, which prevents all traffic to/from pods in the **policy-demo** namespace. Note that the policy applies to all pods in the policy-demo namespace, but does not explicitly allow any traffic. All pods are selected, but because the default changes when pods are selected by a network policy, the result is: **deny all ingress and egress traffic**. (Unless the traffic is allowed by another network policy). - -```yaml -kind: NetworkPolicy -apiVersion: networking.k8s.io/v1 -metadata: - name: default-deny - namespace: policy-demo -spec: - podSelector: - matchLabels: {} - policyTypes: - - Ingress - - Egress -``` - -## Additional resources - -- [Kubernetes Network Policy API documentation](https://kubernetes.io/docs/reference/kubernetes-api/policy-resources/network-policy-v1/) diff --git a/calico_versioned_docs/version-3.29/network-policy/get-started/kubernetes-policy/kubernetes-policy-advanced.mdx b/calico_versioned_docs/version-3.29/network-policy/get-started/kubernetes-policy/kubernetes-policy-advanced.mdx deleted file mode 100644 index b0cf5131d9..0000000000 --- a/calico_versioned_docs/version-3.29/network-policy/get-started/kubernetes-policy/kubernetes-policy-advanced.mdx +++ /dev/null @@ -1,342 +0,0 @@ ---- -description: Learn how to create more advanced Kubernetes network policies (namespace, allow and deny all ingress and egress). ---- - -# Kubernetes policy, advanced tutorial - -The Kubernetes `NetworkPolicy` API allows users to express ingress and egress policies (starting with Kubernetes 1.8.0) to Kubernetes pods -based on labels and ports. - -This guide walks through using Kubernetes `NetworkPolicy` to define more complex network policies. - -## Requirements - -- A working Kubernetes cluster and access to it using kubectl -- Your Kubernetes nodes have connectivity to the public internet -- You are familiar with [Kubernetes NetworkPolicy](kubernetes-policy-basic.mdx) - -## Tutorial flow - -1. Create the Namespace and Nginx Service -1. Deny all ingress traffic -1. Allow ingress traffic to Nginx -1. Deny all egress traffic -1. Allow egress traffic to kube-dns -1. Cleanup Namespace - -## 1. Create the namespace and nginx service - -We'll use a new namespace for this guide. Run the following commands to create it and a plain nginx service listening on port 80. - -```bash -kubectl create ns advanced-policy-demo -kubectl create deployment --namespace=advanced-policy-demo nginx --image=nginx -kubectl expose --namespace=advanced-policy-demo deployment nginx --port=80 -``` - -### Verify access - allowed all ingress and egress - -Open up a second shell session which has `kubectl` connectivity to the Kubernetes cluster and create a busybox pod to test policy access. This pod will be used throughout this tutorial to test policy access. - -```bash -kubectl run --namespace=advanced-policy-demo access --rm -ti --image busybox /bin/sh -``` - -This should open up a shell session inside the `access` pod, as shown below. - -``` -Waiting for pod advanced-policy-demo/access-472357175-y0m47 to be running, status is Pending, pod ready: false - -If you don't see a command prompt, try pressing enter. -/ # -``` - -Now from within the busybox "access" pod execute the following command to test access to the nginx service. - -```bash -wget -q --timeout=5 nginx -O - -``` - -It should return the HTML of the nginx welcome page. - -Still within the busybox "access" pod, issue the following command to test access to google.com. - -```bash -wget -q --timeout=5 google.com -O - -``` - -It should return the HTML of the google.com home page. - -## 2. Deny all ingress traffic - -Enable ingress isolation on the namespace by deploying a [default deny all ingress traffic policy](https://kubernetes.io/docs/concepts/services-networking/network-policies/#default-deny-all-ingress-traffic). - -```bash -kubectl create -f - < - - -Welcome to nginx!... -``` - -After creating the policy, we can now access the nginx Service. - -## 4. Deny all egress traffic - -Enable egress isolation on the namespace by deploying a [default deny all egress traffic policy](https://kubernetes.io/docs/concepts/services-networking/network-policies/#default-deny-all-egress-traffic). - -```bash -kubectl create -f - < - - -Welcome to nginx!... -``` - -Next, try to retrieve the home page of google.com. - -```bash -wget -q --timeout=5 google.com -O - -``` - -It should return: - -``` -wget: download timed out -``` - -Access to `google.com` times out because it can resolve DNS but has no egress access to anything other than pods with labels matching `app: nginx` in the `advanced-policy-demo` namespace. - -# 7. Clean up namespace - -You can clean up after this tutorial by deleting the advanced policy demo namespace. - -```bash -kubectl delete ns advanced-policy-demo -``` diff --git a/calico_versioned_docs/version-3.29/network-policy/get-started/kubernetes-policy/kubernetes-policy-basic.mdx b/calico_versioned_docs/version-3.29/network-policy/get-started/kubernetes-policy/kubernetes-policy-basic.mdx deleted file mode 100644 index 2d77dc607f..0000000000 --- a/calico_versioned_docs/version-3.29/network-policy/get-started/kubernetes-policy/kubernetes-policy-basic.mdx +++ /dev/null @@ -1,207 +0,0 @@ ---- -description: Learn how to use basic Kubernetes network policy to securely restrict traffic to/from pods. ---- - -# Kubernetes policy, basic tutorial - -This guide provides a simple way to try out Kubernetes `NetworkPolicy` with $[prodname]. It requires a Kubernetes cluster configured with $[prodname] networking, and expects that you have `kubectl` configured to interact with the cluster. - -You can quickly and easily deploy such a cluster by following one of the [installation guides](../../../getting-started/index.mdx). - -## Configure namespaces - -This guide will deploy pods in a Kubernetes namespace. Let's create the `Namespace` object for this guide. - -```bash -kubectl create ns policy-demo -``` - -## Create demo pods - -We'll use Kubernetes `Deployment` objects to easily create pods in the namespace. - -1. Create some nginx pods in the `policy-demo` namespace. - - ```bash - kubectl create deployment --namespace=policy-demo nginx --image=nginx - ``` - -1. Expose them through a service. - - ```bash - kubectl expose --namespace=policy-demo deployment nginx --port=80 - ``` - -1. Ensure the nginx service is accessible. - - ```bash - kubectl run --namespace=policy-demo access --rm -ti --image busybox /bin/sh - ``` - - This should open up a shell session inside the `access` pod, as shown below. - - ``` - Waiting for pod policy-demo/access-472357175-y0m47 to be running, status is Pending, pod ready: false - - If you don't see a command prompt, try pressing enter. - - / # - ``` - -1. From inside the `access` pod, attempt to reach the `nginx` service. - - ```bash - wget -q nginx -O - - ``` - - You should see a response from `nginx`. Great! Our service is accessible. You can exit the pod now. - -## Enable isolation - -Let's turn on isolation in our `policy-demo` namespace. $[prodname] will then prevent connections to pods in this namespace. - -Running the following command creates a NetworkPolicy which implements a default deny behavior for all pods in the `policy-demo` namespace. - -```bash -kubectl create -f - < diff --git a/calico_versioned_docs/version-3.29/network-policy/hosts/kubernetes-nodes.mdx b/calico_versioned_docs/version-3.29/network-policy/hosts/kubernetes-nodes.mdx deleted file mode 100644 index a5f98de4e7..0000000000 --- a/calico_versioned_docs/version-3.29/network-policy/hosts/kubernetes-nodes.mdx +++ /dev/null @@ -1,214 +0,0 @@ ---- -description: Protect Kubernetes nodes with host endpoints managed by Calico. ---- - -# Protect Kubernetes nodes - -## Big picture - -Secure Kubernetes nodes with host endpoints managed by $[prodname]. - -## Value - -$[prodname] can automatically create host endpoints for your Kubernetes nodes. This means $[prodname] can manage the lifecycle of host endpoints as your cluster evolves, ensuring nodes are always protected by policy. - -## Concepts - -## Host endpoints - -Each host has one or more network interfaces that it uses to communicate externally. You can represent these interfaces in Calico using host endpoints and then use network policy to secure them. - -$[prodname] host endpoints can have labels, and they work the same as labels on workload endpoints. The network policy rules can apply to both workload and host endpoints using label selectors. - -Automatic host endpoints secure all of the host's interfaces (i.e. in Linux, all the interfaces in the host network namespace). They are created by setting `interfaceName: "*"`. - -## Automatic host endpoints - -$[prodname] creates a wildcard host endpoint for each node, with the host endpoint containing the same labels and IP addresses as its corresponding node. -$[prodname] will ensure these managed host endpoints maintain the same labels and IP addresses as its node by periodic syncs. -This means that policy targeting these automatic host endpoints will function correctly with the policy put in place to select those nodes, even if over time the node's IPs or labels change. - -Automatic host endpoints are differentiated from other host endpoints by the label `projectcalico.org/created-by: calico-kube-controllers`. -Enable or disable automatic host endpoints by configuring the default KubeControllersConfiguration resource. - -## Before you begin... - -Have a running $[prodname] cluster with `calicoctl` installed. - -## How to - -- [Enable automatic host endpoints](#enable-automatic-host-endpoints) -- [Apply network policy to automatic host endpoints](#apply-network-policy-to-automatic-host-endpoints) - -### Enable automatic host endpoints - -To enable automatic host endpoints, edit the default KubeControllersConfiguration instance, and set `spec.controllers.node.hostEndpoint.autoCreate` to `true`: - -```bash -calicoctl patch kubecontrollersconfiguration default --patch='{"spec": {"controllers": {"node": {"hostEndpoint": {"autoCreate": "Enabled"}}}}}' -``` - -If successful, host endpoints are created for each of your cluster's nodes: - -```bash -calicoctl get heps -owide -``` - -The output may look similar to this: - -``` -calicoctl get heps -owide -NAME NODE INTERFACE IPS PROFILES -ip-172-16-101-147.us-west-2.compute.internal-auto-hep ip-172-16-101-147.us-west-2.compute.internal * 172.16.101.147,192.168.228.128 projectcalico-default-allow -ip-172-16-101-54.us-west-2.compute.internal-auto-hep ip-172-16-101-54.us-west-2.compute.internal * 172.16.101.54,192.168.107.128 projectcalico-default-allow -ip-172-16-101-79.us-west-2.compute.internal-auto-hep ip-172-16-101-79.us-west-2.compute.internal * 172.16.101.79,192.168.91.64 projectcalico-default-allow -ip-172-16-101-9.us-west-2.compute.internal-auto-hep ip-172-16-101-9.us-west-2.compute.internal * 172.16.101.9,192.168.71.192 projectcalico-default-allow -ip-172-16-102-63.us-west-2.compute.internal-auto-hep ip-172-16-102-63.us-west-2.compute.internal * 172.16.102.63,192.168.108.192 projectcalico-default-allow -``` - -### Apply network policy to automatic host endpoints - -To apply policy that targets all Kubernetes nodes, first add a label to the nodes. -The label will be synced to their automatic host endpoints. - -For example, to add the label **kubernetes-host** to all nodes and their host endpoints: - -```bash -kubectl label nodes --all kubernetes-host= -``` - -And an example policy snippet: - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: all-nodes-policy -spec: - selector: has(kubernetes-host) - # -``` - -To select a specific set of host endpoints (and their corresponding Kubernetes nodes), use a policy selector that selects a label unique to that set of host endpoints. -For example, if we want to add the label **environment=dev** to nodes named node1 and node2: - -```bash -kubectl label node node1 environment=dev -kubectl label node node2 environment=dev -``` - -With the labels in place and automatic host endpoints enabled, host endpoints for node1 and node2 will be updated with the **environment=dev** label. -We can write policy to select that set of nodes with a combination of selectors: - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: some-nodes-policy -spec: - selector: has(kubernetes-host) && environment == 'dev' - # -``` - -## Tutorial - -This tutorial will lock down Kubernetes node ingress to only allow SSH and required ports for Kubernetes to function. -We will apply two policies: one for the control plane nodes. and one for the worker nodes. - -:::note - -Note: This tutorial was tested on a cluster created with kubeadm v1.18.2 on AWS, using a "stacked etcd" [topology](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/ha-topology/). Stacked etcd topology means the etcd pods are running on the masters. kubeadm uses stacked etcd by default. -If your Kubernetes cluster is on a different platform, is running a variant of Kubernetes, or is running a topology with an external etcd cluster, -please review the required ports for control plane and worker nodes in your cluster and adjust the policies in this tutorial as needed. - -::: - -First, let's restrict ingress traffic to the control plane nodes. The ingress policy below contains three rules. -The first rule allows access to the API server port from anywhere. The second rule allows all traffic to localhost, which -allows Kubernetes to access control plane processes. These control plane processes includes the etcd server client API, the scheduler, and the controller-manager. -This rule also allows localhost access to the kubelet API and calico/node health checks. -And the final rule allows the etcd pods to peer with each other and allows the masters to access each others kubelet API. - -If you have not modified the failsafe ports, you should still have SSH access to the nodes after applying this policy. -Now apply the ingress policy for the Kubernetes masters: - -``` -calicoctl apply -f - << EOF -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: ingress-k8s-masters -spec: - selector: has(node-role.kubernetes.io/control-plane) - # This rule allows ingress to the Kubernetes API server. - ingress: - - action: Allow - protocol: TCP - destination: - ports: - # kube API server - - 6443 - # This rule allows all traffic to localhost. - - action: Allow - destination: - nets: - - 127.0.0.0/8 - # This rule is required in multi-master clusters where etcd pods are colocated with the masters. - # Allow the etcd pods on the masters to communicate with each other. 2380 is the etcd peer port. - # This rule also allows the masters to access the kubelet API on other masters (including itself). - - action: Allow - protocol: TCP - source: - selector: has(node-role.kubernetes.io/control-plane) - destination: - ports: - - 2380 - - 10250 -EOF -``` - -Note that the above policy selects the standard **node-role.kubernetes.io/control-plane** label that kubeadm sets on control plane nodes. - -Next, we need to apply policy to restrict ingress to the Kubernetes workers. -Before adding the policy we will add a label to all of our worker nodes, which then gets added to its automatic host endpoint. -For this tutorial we will use **kubernetes-worker**. An example command to add the label to worker nodes: - -```bash -kubectl get node -l '!node-role.kubernetes.io/control-plane' -o custom-columns=NAME:.metadata.name | tail -n +2 | xargs -I{} kubectl label node {} kubernetes-worker= -``` - -The workers' ingress policy consists of two rules. The first rule allows all traffic to localhost. As with the masters, -the worker nodes need to access their localhost kubelet API and calico/node healthcheck. -The second rule allows the masters to access the workers kubelet API. Now apply the policy: - -``` -calicoctl apply -f - << EOF -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: ingress-k8s-workers -spec: - selector: has(kubernetes-worker) - # Allow all traffic to localhost. - ingress: - - action: Allow - destination: - nets: - - 127.0.0.0/8 - # Allow only the masters access to the nodes kubelet API. - - action: Allow - protocol: TCP - source: - selector: has(node-role.kubernetes.io/control-plane) - destination: - ports: - - 10250 -EOF -``` - -## Additional resources - -- [Protect hosts tutorial](protect-hosts-tutorial.mdx) -- [Apply policy to Kubernetes node ports](../services/kubernetes-node-ports.mdx) -- [Global network policy](../../reference/resources/globalnetworkpolicy.mdx) -- [Host endpoints](../../reference/resources/hostendpoint.mdx) diff --git a/calico_versioned_docs/version-3.29/network-policy/hosts/protect-hosts-tutorial.mdx b/calico_versioned_docs/version-3.29/network-policy/hosts/protect-hosts-tutorial.mdx deleted file mode 100644 index 4828bd55dc..0000000000 --- a/calico_versioned_docs/version-3.29/network-policy/hosts/protect-hosts-tutorial.mdx +++ /dev/null @@ -1,192 +0,0 @@ ---- -description: Learn how to secure incoming traffic from outside the cluster using Calico host endpoints with network policy, including allowing controlled access to specific Kubernetes services. ---- - -# Protect hosts tutorial - -Imagine that the administrator of a Kubernetes cluster wants to secure it as much as -possible against incoming traffic from outside the cluster. But suppose that -the cluster provides various useful services that are exposed as Kubernetes -NodePorts, i.e., as well-known TCP port numbers that appear to be available on -any node in the cluster. The administrator does want to expose some -of those NodePorts to traffic from outside. - -In this example we will use pre-DNAT policy applied to the external interfaces -of each cluster node: - -- to disallow incoming traffic from outside, in general - -- but then to allow incoming traffic to particular NodePorts. - -We use pre-DNAT policy for these purposes, instead of normal host endpoint -policy, because: - -1. We want the protection against general external traffic to apply regardless - of where that traffic is destined for - for example, to a locally hosted - pod, or to a pod on another node, or to a local server process running on - the host itself. Pre-DNAT policy is enforced in all of those cases - as we - want - whereas normal host endpoint policy is not enforced for traffic going - to a local pod. - -2. We want to write this policy in terms of the advertised NodePorts, not in - terms of whatever internal port numbers those may be transformed to. - kube-proxy on the ingress node will use a DNAT to change a NodePort number - and IP address to those of one of the pods that backs the relevant Service. - Our policy therefore needs to take effect _before_ that DNAT - and that - means that it must be a pre-DNAT policy. - -:::note - -Note: This tutorial is intended to be used with named host endpoints, i.e. host endpoints with `interfaceName` set to a specific interface name. -This tutorial does not work, as-is, with host endpoints with `interfaceName: "*"`. - -::: - -Here is the pre-DNAT policy that we need to disallow incoming external traffic -in general: - -```bash -calicoctl apply -f - < -``` - -and then using `host-endpoint==''` as the selector of the -`allow-nodeport` policy, instead of `has(host-endpoint)`. diff --git a/calico_versioned_docs/version-3.29/network-policy/hosts/protect-hosts.mdx b/calico_versioned_docs/version-3.29/network-policy/hosts/protect-hosts.mdx deleted file mode 100644 index 998e0561cd..0000000000 --- a/calico_versioned_docs/version-3.29/network-policy/hosts/protect-hosts.mdx +++ /dev/null @@ -1,186 +0,0 @@ ---- -description: Calico network policy not only protects workloads, but also hosts. Create a Calico network policies to restrict traffic to/from hosts. ---- - -# Protect hosts and VMs - -## Big picture - -Use $[prodname] network policy to restrict traffic to/from hosts and VMs. - -## Value - -Restricting traffic between hosts and the outside world is not unique to $[prodname]; many solutions provide this capability. However, the advantage of using $[prodname] to protect the host is you can use the same $[prodname] policy configuration as workloads. You only need to learn one tool. Write a cluster-wide policy, and it is immediately applied to every host. - -## Concepts - -### Hosts and workloads - -In the context of $[prodname] configuration, a *workload* is a containerized compute instance running in Kubernetes. -A *host* is a computer or virtual machine (VM) that acts as a node in a Kubernetes cluster or that runs application workloads outside of Kubernetes. -$[prodname] is unique in that it can enforce network policy and provide visibility in a consistent way for both workloads and hosts, even if those hosts are on-premises servers or VMs running in the public cloud. - -### Host endpoints - -Each host has one or more network interfaces that it uses to communicate externally. You can use $[prodname] network policy to secure these interfaces (called host endpoints). $[prodname] host endpoints can have labels, and they work the same as labels on workload endpoints. The network policy rules can apply to both workload and host endpoints using label selectors. - -### Failsafe rules - -It is easy to inadvertently cut all host connectivity because of nonexistent or misconfigured network policy. To avoid this, $[prodname] provides failsafe rules with default/configurable ports that are open on all host endpoints. - -### Default behavior of workload to host traffic - -By default, $[prodname] blocks all connections from a workload to its local host. You can control whether connections from a workload endpoint to its local host are dropped, returned, or accepted using a simple parameter. - -$[prodname] allows all connections from processes running on the host to guest workloads on the host. This allows host processes to run health checks and debug guest workloads. - -### Default behavior of external traffic to/from host - -If a host endpoint is added and network policy is not in place, the $[prodname] default is to deny traffic to/from that endpoint (except for traffic allowed by failsafe rules). For host endpoints, $[prodname] blocks traffic only to/from interfaces that it’s been explicitly told about in network policy. Traffic to/from other interfaces is ignored. - -### Other host protection - -In terms of design consistency in $[prodname], you may wonder about the following use cases. - -**Does $[prodname] protect a local host from workloads?**
    -Yes. DefaultEndpointToHostAction controls whether or not workloads can access their local host.
    - -**Does $[prodname] protect a workload from the host it is running on?**
    -No. $[prodname] allows connections the host makes to the workloads running on that host. Some orchestrators like Kubernetes depend on this connectivity for health checking the workload. Moreover, processes running on the local host are often privileged enough to override local $[prodname] policy. Be very cautious with the processes that you allow to run in the host's root network namespace. - -## Before you begin... - -If you are already running $[prodname] for Kubernetes, you are good to go. If you want to install $[prodname] on a non-cluster machine for host protection only, see [Non-cluster hosts](../../getting-started/bare-metal/index.mdx). - -## How to - -- [Avoid accidentally cutting all host connectivity ](#avoid-accidentally-cutting-all-host-connectivity) -- [Use policy to restrict host traffic](#use-policy-to-restrict-host-traffic) -- [Control default behavior of workload endpoint to host traffic](#control-default-behavior-of-workload-endpoint-to-host-traffic) - -### Avoid accidentally cutting all host connectivity - -To avoid inadvertently cutting all host connectivity because of nonexistent or misconfigured network policy, $[prodname] uses failsafe rules that open specific ports and CIDRs on all host endpoints. - -Review the following table to determine if the defaults work for your implementation. If not, change the default ports using the parameters, **FailsafeInboundHostPorts** and **FailsafeOutboundHostPorts** in [Configuring Felix](../../reference/felix/configuration.mdx#environment-variables). - -| Port | Protocol | CIDR | Direction | Purpose | -| ---- | -------- | --------- | ------------------ | ------------------------------------ | -| 22 | TCP | 0.0.0.0/0 | Inbound | SSH access | -| 53 | UDP | 0.0.0.0/0 | Outbound | DNS queries | -| 67 | UDP | 0.0.0.0/0 | Outbound | DHCP access | -| 68 | UDP | 0.0.0.0/0 | Inbound | DHCP access | -| 179 | TCP | 0.0.0.0/0 | Inbound & Outbound | BGP access ($[prodname] networking) | -| 2379 | TCP | 0.0.0.0/0 | Inbound & Outbound | etcd access | -| 2380 | TCP | 0.0.0.0/0 | Inbound & Outbound | etcd access | -| 6443 | TCP | 0.0.0.0/0 | Inbound & Outbound | Kubernetes API server access | -| 6666 | TCP | 0.0.0.0/0 | Inbound & Outbound | etcd self-hosted service access | -| 6667 | TCP | 0.0.0.0/0 | Inbound & Outbound | etcd self-hosted service access | - -### Use policy to restrict host traffic - -#### Step 1: Create policy to restrict host traffic - -Although failsafe rules provide protection from removing all connectivity to a host, you should create a GlobalNetworkPolicy policy that restricts host traffic. - -In the following example, we use a **GlobalNetworkPolicy** that applies to all worker nodes (defined by a label). Ingress SSH access is allowed from a defined "management" subnet. - -**Ingress traffic** is also allowed for ICMP, and on TCP port 10250 (default kubelet port). **Egress** traffic is allowed to etcd on a particular IP, and UDP on port 53 and 67 for DNS and DHCP. - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: k8s-worker -spec: - selector: "role == 'k8s-worker'" - order: 0 - ingress: - - action: Allow - protocol: TCP - source: - nets: - - '' - destination: - ports: [22] - - action: Allow - protocol: ICMP - - action: Allow - protocol: TCP - destination: - ports: [10250] - egress: - - action: Allow - protocol: TCP - destination: - nets: - - '/32' - ports: [2379] - - action: Allow - protocol: UDP - destination: - ports: [53, 67] -``` - -#### Step 2: Create host endpoints - -For each host point that you want to secure with policy, you must create a **HostEndpoint** object. To do that, you need the name of the $[prodname] node on the host that owns the interface; in most cases, it is the same as the hostname of the host. - -In the following example, we create a HostEndpoint for the host named **my-host** with the interface named **eth0**, with **IP 10.0.0.1**. Note that the value for **node:** must match the hostname used on the $[prodname] node object. - -When the HostEndpoint is created, traffic to or from the interface is dropped unless policy is in place. - -```yaml -apiVersion: projectcalico.org/v3 -kind: HostEndpoint -metadata: - name: my-host-eth0 - labels: - role: k8s-worker - environment: production -spec: - interfaceName: eth0 - node: my-host - expectedIPs: ['10.0.0.1'] -``` - -### Control default behavior of workload endpoint to host traffic - -The default $[prodname] behavior blocks all connections from workloads to their local host (after traffic passes any egress policy applied to the workload). You can change this behavior using the **DefaultEndpointToHostAction** parameter in Felix configuration. - -This parameter works at the IP table level, where you can specify packet behavior to **Drop** (default), **Accept**, or **Return**. - -To change this parameter for all hosts, edit the **FelixConfiguration** object named “default.” - -1. Get a copy of the object to edit. - - ```bash - calicoctl get felixconfiguration default --export -o yaml > default-felix-config.yaml - ``` - -1. Open the file in a text editor and add the parameter, **defaultEndpointToHostAction**. For example: - - ```yaml - apiVersion: projectcalico.org/v3 - kind: FelixConfiguration - metadata: - name: default - spec: - ipipEnabled: true - logSeverityScreen: Info - reportingInterval: 0s - defaultEndpointToHostAction: Accept - ``` - -1. Update the FelixConfiguration on the cluster. - ```bash - calicoctl apply -f default-felix-config.yaml - ``` - -## Additional resources - -- [Apply policy to Kubernetes node ports](../services/kubernetes-node-ports.mdx) -- [Protect Kubernetes nodes with host endpoints managed by $[prodname]](kubernetes-nodes.mdx) -- [Defend against DoS attacks](../extreme-traffic/defend-dos-attack.mdx) -- [Global network policy](../../reference/resources/globalnetworkpolicy.mdx) -- [Host endpoint](../../reference/resources/hostendpoint.mdx) diff --git a/calico_versioned_docs/version-3.29/network-policy/index.mdx b/calico_versioned_docs/version-3.29/network-policy/index.mdx deleted file mode 100644 index 4efca27c26..0000000000 --- a/calico_versioned_docs/version-3.29/network-policy/index.mdx +++ /dev/null @@ -1,99 +0,0 @@ ---- -description: Calico Network Policy and Calico Global Network Policy are the fundamental resources to secure workloads and hosts, and to adopt a zero trust security model. ---- - -import { DocCardLink, PaidProductDocCardLink, DocCardLinkLayout } from '/src/___new___/components'; - -# Network policy - -Writing network policies is how you restrict traffic to pods in your Kubernetes cluster. -$[prodname] extends the standard `NetworkPolicy` object to provide advanced network policy features, such as policies that apply to all namespaces. - -## Getting started - - - - - - - - - - - - -## Policy rules - - - - - - - - - - - -## Policy for hosts and VMs - - - - - - - - - -## Policy for services - - - - - - -## Policy for Istio - - - - - - - -## Securing component communications - - - - - - - - - -## Network policy options with Calico Cloud - - - - - - - \ No newline at end of file diff --git a/calico_versioned_docs/version-3.29/network-policy/istio/app-layer-policy.mdx b/calico_versioned_docs/version-3.29/network-policy/istio/app-layer-policy.mdx deleted file mode 100644 index 9c3d6c5712..0000000000 --- a/calico_versioned_docs/version-3.29/network-policy/istio/app-layer-policy.mdx +++ /dev/null @@ -1,510 +0,0 @@ ---- -description: Enforce network policy for Istio service mesh including matching on HTTP methods and paths. ---- -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - -# Enforce Calico network policy for Istio service mesh - -## Overview - -You can enforce $[prodname] network policy for Istio application layer policy using the Dikastes sidecar. Dikastes enables $[prodname] to integrate with Istio's Envoy proxy to enforce fine-grained Layer 7 (HTTP) policies. - -### Value - -- **Pod traffic controls for Istio-enabled apps**: Lets you restrict ingress traffic inside and outside pods and mitigate common threats to Istio-enabled apps. -- **Security alignment with zero trust**: Supports zero-trust network models through traffic encryption, multiple enforcement points, and multiple identity criteria for authentication. -- **Familiar policy language**: Apply Kubernetes network policies and $[prodname] network policies that you already know. - -## Before you begin - -**Required** - -- $[prodname] CNI is installed and configured -- `kubectl` and `istioctl` CLI tools are installed -- MutatingAdmissionWebhook admission controller is enabled - -**Supported Istio versions** - -- **Istio v1.28.1** (recommended) -- **Istio v1.22+** (minimum required for Kubernetes native sidecar support) - -:::note - -This guide requires Istio 1.22+ with Kubernetes native sidecars. Traditional sidecar injection is not supported. For legacy Istio versions (v1.15.2, v1.10.2), see [Legacy Installation](#legacy-installation-configmap-patching). - -::: - -**Required Kubernetes versions** - -- **Kubernetes v1.29+**: Required for native sidecar support - -## How to - -This guide covers the usage of [IstioOperator](https://istio.io/latest/docs/reference/config/istio.operator.v1alpha1/) - -For the ConfigMap patching method, see [Legacy Installation](#legacy-installation-configmap-patching). - -### 1. Enable application layer policy - -Enable the Policy Sync API in Felix to allow Dikastes to query policy decisions. - - - - -```bash -kubectl patch felixconfiguration default --type merge -p '{"spec":{"policySyncPathPrefix":"/var/run/nodeagent"}}' -``` - - - - -```bash -calicoctl patch FelixConfiguration default --patch \ - '{"spec": {"policySyncPathPrefix": "/var/run/nodeagent"}}' -``` - - - - -**Optional**: If using the $[prodname] operator, disable deprecated Flex Volumes: - -```bash -kubectl patch installation default --type=merge -p '{"spec": {"flexVolumePath": "None"}}' -``` - -### 2. Install Istio - -Follow the [upstream Istio installation documentation](https://istio.io/latest/docs/setup/getting-started/) to install Istio if not already installed. - -For testing, you can use: - -```bash -curl -L https://istio.io/downloadIstio -o install-istio.sh -# Review the script before running it, then install: -ISTIO_VERSION=1.28.1 sh install-istio.sh -cd istio-1.28.1 -export PATH=$PWD/bin:$PATH -``` - -:::note - -Do not run `istioctl install` yet if you want to configure Dikastes templates during installation. See the next step. - -::: - -### 3. Configure Istio with Dikastes injection templates - -#### Option A: use IstioOperator directly - -Create a file named `istio-operator-dikastes.yaml`: - -```yaml -apiVersion: install.istio.io/v1alpha1 -kind: IstioOperator -metadata: - name: istio-with-dikastes - namespace: istio-system -spec: - profile: minimal # or 'default' if you need gateways - - values: - sidecarInjectorWebhook: - templates: - # Template for workload pods - dikastes: | - spec: - containers: - - name: dikastes - image: quay.io/calico/dikastes:$[version] - args: - - server - - -l - - /var/run/dikastes/dikastes.sock - - -d - - /var/run/felix/nodeagent/socket - securityContext: - allowPrivilegeEscalation: false - runAsGroup: 999 - runAsNonRoot: true - runAsUser: 999 - livenessProbe: - exec: - command: - - /healthz - - liveness - initialDelaySeconds: 3 - periodSeconds: 3 - readinessProbe: - exec: - command: - - /healthz - - readiness - initialDelaySeconds: 3 - periodSeconds: 3 - volumeMounts: - - mountPath: /var/run/dikastes - name: dikastes-sock - - mountPath: /var/run/felix - name: felix-sync - initContainers: - - name: istio-proxy - volumeMounts: - - mountPath: /var/run/dikastes - name: dikastes-sock - volumes: - - name: dikastes-sock - emptyDir: - medium: Memory - - name: felix-sync - csi: - driver: csi.tigera.io - - # Template for gateway pods (runs as root) - dikastes-gateway: | - spec: - containers: - - name: dikastes - image: quay.io/calico/dikastes:$[version] - args: - - server - - -l - - /var/run/dikastes/dikastes.sock - - -d - - /var/run/felix/nodeagent/socket - securityContext: - allowPrivilegeEscalation: false - runAsGroup: 0 - runAsNonRoot: false - runAsUser: 0 - livenessProbe: - exec: - command: - - /healthz - - liveness - initialDelaySeconds: 3 - periodSeconds: 3 - readinessProbe: - exec: - command: - - /healthz - - readiness - initialDelaySeconds: 3 - periodSeconds: 3 - volumeMounts: - - mountPath: /var/run/dikastes - name: dikastes-sock - - mountPath: /var/run/felix - name: felix-sync - initContainers: - - name: istio-proxy - volumeMounts: - - mountPath: /var/run/dikastes - name: dikastes-sock - volumes: - - name: dikastes-sock - emptyDir: - medium: Memory - - name: felix-sync - csi: - driver: csi.tigera.io -``` - -**Install or update Istio** with the Dikastes templates: - -```bash -istioctl install -f istio-operator-dikastes.yaml -y -``` - -This will: -- Install Istio (if not already installed) -- Update the `istio-sidecar-injector` ConfigMap with the Dikastes templates -- Make the templates available for pod annotation-based injection - -**Verify the templates were loaded**: - -```bash -kubectl get configmap -n istio-system istio-sidecar-injector -o yaml | grep "dikastes:" -A 5 -``` - -You should see both `dikastes` and `dikastes-gateway` templates. - -#### Option B: Generate Manifests for GitOps - -If you prefer to generate Kubernetes manifests instead of applying directly: - -```bash -istioctl manifest generate -f istio-operator-dikastes.yaml > istio-with-dikastes.yaml -kubectl apply -f istio-with-dikastes.yaml -``` - -### 4. Add Envoy authorization services - -Configure Istio's Envoy proxies to use Dikastes as an external authorization service. - -```bash -kubectl apply -f $[manifestsUrl]/manifests/alp/istio-app-layer-policy-envoy-v3.yaml -``` - -[View sample manifest]($[manifestsUrl]/manifests/alp/istio-app-layer-policy-envoy-v3.yaml) - -This manifest creates: -- **ServiceEntry**: Defines `dikastes.calico.cluster.local` for Unix socket communication -- **DestinationRule**: Disables mTLS for local socket communication -- **EnvoyFilter**: Configures Envoy's External Authorization filter to call Dikastes - -### 5. Enable Istio injection for namespaces - -Label the namespace where you want to deploy Istio-enabled workloads: - -```bash -kubectl label namespace istio-injection=enabled -``` - -### 6. Annotate pods to inject Dikastes - -To inject the Dikastes sidecar into your pods, add the following annotation to your pod template: - -**For regular workloads**: - -```yaml -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp -spec: - template: - metadata: - annotations: - inject.istio.io/templates: sidecar,dikastes - spec: - # ... your pod spec -``` - -**For gateway workloads**: - -```yaml -metadata: - annotations: - inject.istio.io/templates: sidecar,dikastes-gateway -``` - -The key difference: -- `dikastes`: Runs as non-root user (999) - for application workloads -- `dikastes-gateway`: Runs as root (0) - for ingress/egress gateways - -### 7. Verify Dikastes injection - -After deploying a workload with the annotation: - -```bash -# Check that Dikastes container is present -kubectl get pod -l app= -n -o jsonpath='{.items[0].spec.containers[*].name}' -``` - -You should see: `dikastes ...` - -**Check pod status** (should show all containers ready): - -```bash -kubectl get pods -n -``` - -**Check Dikastes logs**: - -```bash -kubectl logs -n -l app= -c dikastes -``` - -You should see: -``` -Successfully connected to Policy Sync server -Starting synchronization with Policy Sync server -``` - -### 8. (Optional) Enable strict mTLS - -For enhanced security, enable strict mutual TLS between services: - -```yaml -apiVersion: security.istio.io/v1beta1 -kind: PeerAuthentication -metadata: - name: default-strict-mode - namespace: istio-system -spec: - mtls: - mode: STRICT -``` - -Apply: - -```bash -kubectl apply -f .yaml -``` - -## Create Calico network policies - -With Dikastes deployed, you can now create $[prodname] network policies to enforce Layer 7 access control. - -:::note - -The specific policy Custom Resource Definitions available depend on your $[prodname] distribution (OSS vs Enterprise). Consult your $[prodname] documentation for policy syntax. - -::: - -Example conceptual policy (syntax may vary): - -```yaml -apiVersion: projectcalico.org/v3 -kind: NetworkPolicy -metadata: - name: allow-http-get - namespace: default -spec: - selector: app == "myapp" - types: - - Ingress - ingress: - - action: Allow - protocol: TCP - destination: - ports: - - 80 -``` - -### Default behavior - -Without explicit allow policies, Dikastes enforces a **default-deny** posture for security. All HTTP requests will receive a `403 Forbidden` response until you create policies that explicitly allow traffic. - -## Troubleshooting - -### Dikastes container not injected - -**Check namespace label**: - -```bash -kubectl get namespace -o jsonpath='{.metadata.labels.istio-injection}' -``` - -Should show: `enabled` - -**Check pod annotation**: - -```bash -kubectl get pod -n -o yaml | grep inject.istio.io/templates -``` - -Should show: `inject.istio.io/templates: sidecar,dikastes` - -**Verify templates in ConfigMap**: - -```bash -kubectl get configmap -n istio-system istio-sidecar-injector -o jsonpath='{.data.values}' | grep -o "dikastes:" | wc -l -``` - -Should return `2` (one for each template). - -### Pod stuck in PodInitializing or CrashLoopBackOff - -**Check pod events**: - -```bash -kubectl describe pod -n -``` - -**Check Dikastes logs**: - -```bash -kubectl logs -n -c dikastes -``` - -**Check CSI driver** (automatically installed with $[prodname]): - -```bash -kubectl get pods -n calico-system -l k8s-app=csi-node-driver -``` - -All CSI driver pods should be `Running`. The CSI driver is required for Dikastes to access the Felix Policy Sync API. - -**Verify Felix Policy Sync API**: - -```bash -kubectl get felixconfiguration default -o yaml | grep policySyncPathPrefix -``` - -Should show: `policySyncPathPrefix: /var/run/nodeagent` - -### All requests returning 403 - -This is **expected behavior** when no allow policies are configured. Dikastes enforces default-deny for security. - -To allow traffic, create $[prodname] network policies that explicitly permit the desired traffic. - -### Envoy cannot reach istio-pilot - -If you have egress policies applied to your pods, Envoy needs access to the Istio control plane. - -Apply the allow policy: - -```bash -kubectl apply -f $[tutorialFilesURL]/allow-istio-pilot.yaml -``` - -### Warning about BPF load balancing - -If you see this warning during installation: - -``` -detected Calico CNI with 'bpfConnectTimeLoadBalancing=TCP'; -this must be set to 'bpfConnectTimeLoadBalancing=Disabled' -``` - -This may affect connection-level load balancing but does not prevent basic functionality. For production deployments, disable BPF connect-time load balancing: - -```bash -kubectl patch felixconfiguration default --type merge -p '{"spec":{"bpfConnectTimeLoadBalancing":"Disabled"}}' -``` - -## Legacy Installation (ConfigMap Patching) - -:::note - -This method is supported but not recommended for new deployments. Use the IstioOperator method instead. - -::: - -If you need to use the legacy ConfigMap patching method for Istio 1.15 or 1.10: - -### For Istio v1.15.x: - -```bash -curl $[manifestsUrl]/manifests/alp/istio-inject-configmap-1.15.yaml -o istio-inject-configmap.yaml -kubectl patch configmap -n istio-system istio-sidecar-injector --patch "$(cat istio-inject-configmap.yaml)" -``` - -[View sample manifest]($[manifestsUrl]/manifests/alp/istio-inject-configmap-1.15.yaml) - -### For Istio v1.10.x: - -```bash -curl $[manifestsUrl]/manifests/alp/istio-inject-configmap-1.10.yaml -o istio-inject-configmap.yaml -kubectl patch configmap -n istio-system istio-sidecar-injector --patch "$(cat istio-inject-configmap.yaml)" -``` - -[View sample manifest]($[manifestsUrl]/manifests/alp/istio-inject-configmap-1.10.yaml) - -**Drawbacks of ConfigMap patching**: - -- Not declarative (imperative command) -- Not version-controlled -- Must be re-applied after Istio upgrades -- Difficult to audit and review - -## Additional resources - -- [Enforce network policy using Istio tutorial](enforce-policy-istio.mdx) -- [Use HTTP methods and paths in policy rules](http-methods.mdx) -- [Istio Documentation](https://istio.io/latest/docs/) -- [IstioOperator API Reference](https://istio.io/latest/docs/reference/config/istio.operator.v1alpha1/) -- [Kubernetes Native Sidecars](https://kubernetes.io/blog/2023/08/25/native-sidecar-containers/) diff --git a/calico_versioned_docs/version-3.29/network-policy/istio/enforce-policy-istio.mdx b/calico_versioned_docs/version-3.29/network-policy/istio/enforce-policy-istio.mdx deleted file mode 100644 index 65319696e4..0000000000 --- a/calico_versioned_docs/version-3.29/network-policy/istio/enforce-policy-istio.mdx +++ /dev/null @@ -1,238 +0,0 @@ ---- -description: Learn how Calico integrates with Istio to provide fine-grained access control using Calico network policies enforced within the service mesh and network layer. ---- - -# Enforce Calico network policy using Istio (tutorial) - -This tutorial sets up a microservices application, then demonstrates how to use $[prodname] application layer policy to mitigate some common threats. - -:::note - -This tutorial was verified using Istio v1.10.2. Some content may not apply to the latest Istio version. - -::: - -## Prerequisites - -1. Build a Kubernetes cluster. -2. Install $[prodname] on Kubernetes: - -- If $[prodname] is not installed on Kubernetes, see [Calico on Kubernetes](../../getting-started/kubernetes/quickstart.mdx). -- If $[prodname] is already installed on Kubernetes, verify that [Calico networking](../../networking/index.mdx) (or a non-Calico CNI) and $[prodname] network policy are installed. - -3. Install the [calicoctl command line tool](../../operations/calicoctl/install.mdx). - **Note**: Ensure calicoctl is configured to connect with your datastore. -4. Enable [MutatingAdmissionWebhook](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook). -5. [Enable application layer policy](app-layer-policy.mdx). - **Note**: Label the default namespace for the Istio sidecar injection (`istio-injection=enabled`). - `kubectl label namespace default istio-injection=enabled` - -### Install the demo application - -We will use a simple microservice application to demonstrate $[prodname] -application layer policy. The [YAO Bank](https://github.com/projectcalico/yaobank) application creates a -customer-facing web application, a microservice that serves up account -summaries, and an [etcd](https://github.com/coreos/etcd) datastore. - -```bash -kubectl apply -f $[tutorialFilesURL]/10-yaobank.yaml -``` - -:::note - -You can also -[view the manifest in your browser](/files/10-yaobank.yaml). - -::: - -Verify that the application pods have been created and are ready. - -```bash -kubectl get pods -``` - -When the demo application has come up, you will see three pods. - -``` -NAME READY STATUS RESTARTS AGE -customer-2809159614-qqfnx 3/3 Running 0 21h -database-1601951801-m4w70 3/3 Running 0 21h -summary-2817688950-g1b3n 3/3 Running 0 21h -``` - -### Determining ingress IP and port - -You will use the `istio-ingressgateway` service to access the YAO Bank -application. Determine your ingress host and port [following the Istio instructions](https://istio.io/latest/docs/tasks/traffic-management/ingress/ingress-control/#determining-the-ingress-ip-and-ports). Once you have the `INGRESS_HOST` and `INGRESS_PORT` variables set, you can -set the `GATEWAY_URL` as follows. - -```bash -export GATEWAY_URL=$INGRESS_HOST:$INGRESS_PORT -``` - -Point your browser to `http://$GATEWAY_URL/` to confirm the YAO Bank application is functioning -correctly. It may take several minutes for all the services to come up and respond, during which -time you may see 404 or 500 errors. - -### The need for policy - -Although $[prodname] & Istio are running in the cluster, we have not defined any authentication -policy. Istio was configured to mutually authenticate traffic between the pods in your application, -so only connections with Istio-issued certificates are allowed, and all inter-pod traffic is encrypted with TLS. That's already a big step in the right direction. - -But, let's consider some deficiencies in this security architecture: - -- All incoming connections from workloads in the Istio mesh are equally trusted -- Possession of a key & certificate pair is the _only_ access credential considered. - -To understand why these might be a problem, let's take them one at a time. - -#### Trusting workloads - -Trusting connections from any workload in the Istio mesh is a poor security architecture because, -like Kubernetes, Istio is designed to host multiple applications. Some of those applications may -not be as trusted as others. They may be operated by different users or teams with wildly different -security requirements. We don't want our secure financial application microservices accessible from -some hacky prototype another developer is cooking up. - -Even within our own application, the best practice is to limit access as much -as possible. Only pods that need access to a service should get it. Consider -the YAO Bank application. The customer web service does not need, and should -not have direct access to the backend database. The customer web service needs -to directly interact with clients outside the cluster, some of whom may be -malicious. Unfortunately, vulnerabilities in web applications are all too -common. For example, an [unpatched vulnerability in Apache Struts](https://nvd.nist.gov/vuln/detail/CVE-2017-5638) - is what allowed -attackers their initial access into the Equifax network where they then -launched a devastating attack to steal millions of people's financial -information. - -Imagine what would happen if an attacker were to gain control of the customer web pod in our -application. Let's simulate this by executing a remote shell inside that pod. - -```bash -kubectl exec -ti customer- -c customer -- bash -``` - -Notice that from here, we get direct access to the backend database. For example, we can list all the entries in the database like this: - -```bash -curl http://database:2379/v2/keys?recursive=true | python -m json.tool -``` - -(Piping to `python -m json.tool` nicely formats the output.) - -#### Single-factor authentication - -The possession of a key and certificate pair is a very strong assertion that a -connection is authentic because it is based on cryptographic proofs that are -believed to be nearly impossible to forge. When we authenticate connections -this way we can say with extremely high confidence that the party on the other -end is in possession of the corresponding key. However, this is only a proxy -for what we actually want to be confident of: that the party on the other end -really is the authorized workload we want to communicate with. Keeping the -private key a secret is vital to this confidence, and occasionally attackers -can find ways to trick applications into giving up secrets they should not. -For example, the [Heartbleed](https://owasp.org/www-community/vulnerabilities/Heartbleed_Bug) vulnerability in OpenSSL allowed attackers to -trick an affected application into reading out portions of its memory, -compromising private keys. - -#### Network policy - -We can mitigate both of the above deficiencies with a $[prodname] policy. - -```bash -wget $[tutorialFilesURL]/30-policy.yaml -calicoctl create -f 30-policy.yaml -``` - -:::note - -You can also -[view the manifest in your browser](/files/30-policy.yaml). - -::: - -Let's examine this policy piece by piece. It consists of three policy objects, one for each -microservice. - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: customer -spec: - selector: app == 'customer' - ingress: - - action: Allow - http: - methods: ['GET'] - egress: - - action: Allow -``` - -This policy protects the customer web app. Since this application is customer facing, we do not -restrict what can communicate with it. We do, however, restrict its communications to HTTP `GET` -requests. - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: summary -spec: - selector: app == 'summary' - ingress: - - action: Allow - source: - serviceAccounts: - names: ['customer'] - egress: - - action: Allow -``` - -The second policy protects the account summary microservice. We know the only consumer of this -service is the customer web app, so we restrict the source of incoming connections to the service -account for the customer web app. - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: database -spec: - selector: app == 'database' - ingress: - - action: Allow - source: - serviceAccounts: - names: ["summary"] - egress: - - action: Allow -``` - -The third policy protects the database. Only the summary microservice should have direct access to -the database. - -Let's verify our policy is working as intended. First, return to your browser and refresh to -ensure policy enforcement has not broken the application. - -Next, return to the customer web app. Recall that we simulated an attacker gaining control of that -pod by executing a remote shell inside it. - -```bash -kubectl exec -ti customer- -c customer bash -``` - -Repeat our attempt to access the database. - -```bash -curl -I http://database:2379/v2/keys?recursive=true -``` - -We have left out the JSON formatting because we do not expect to get a valid JSON response. This -time we should get a `403 Forbidden` response. Only the account summary microservice has database -access according to our policy. - -## Additional resources -- [Hands-on workshop: Learn how to deploy access control, encryption & auth at the application level](https://www.tigera.io/tutorials/?_sf_s=Deploy%20Service%20Mesh) diff --git a/calico_versioned_docs/version-3.29/network-policy/istio/http-methods.mdx b/calico_versioned_docs/version-3.29/network-policy/istio/http-methods.mdx deleted file mode 100644 index 4d9b51bf66..0000000000 --- a/calico_versioned_docs/version-3.29/network-policy/istio/http-methods.mdx +++ /dev/null @@ -1,47 +0,0 @@ ---- -description: Create a Calico network policy for Istio-enabled apps to restrict ingress traffic matching HTTP methods or paths. ---- - -# Use HTTP methods and paths in policy rules - -## Big picture - -Use Calico network policy for Istio-enabled apps to restrict ingress traffic that matches HTTP methods or paths. - -## Value - -Istio is ideal for applying policy for operational goals and for security that operates at the application layer. However, for security goals inside and outside the cluster, Calico network policy is required. Using special Calico network policy designed for Istio-enabled apps, you can restrict ingress traffic inside and outside pods using HTTP methods (for example, GET requests). - -## Concepts - -### HTTP match criteria: ingress traffic only - -Calico network policy supports restricting traffic based on HTTP methods and paths only for ingress traffic. - -## Before you begin... - -[Enable application layer policy](app-layer-policy.mdx) - -## How to - -**Restrict ingress traffic using HTTP match criteria** - -In the following example, the trading app is allowed ingress traffic only for HTTP GET requests that match the exact path **/projects/calico**, or that begins with the prefix, **/users**. - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: customer -spec: - selector: app == 'tradingapp' - ingress: - - action: Allow - http: - methods: ['GET'] - paths: - - exact: '/projects/calico' - - prefix: '/users' - egress: - - action: Allow -``` diff --git a/calico_versioned_docs/version-3.29/network-policy/istio/index.mdx b/calico_versioned_docs/version-3.29/network-policy/istio/index.mdx deleted file mode 100644 index 26453af30c..0000000000 --- a/calico_versioned_docs/version-3.29/network-policy/istio/index.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: Configure the Calico "application layer policy" with application layer-specific attributes for Istio service mesh. -hide_table_of_contents: true ---- - -# Policy for Istio - -import DocCardList from '@theme/DocCardList'; -import { useCurrentSidebarCategory } from '@docusaurus/theme-common'; - - diff --git a/calico_versioned_docs/version-3.29/network-policy/policy-rules/external-ips-policy.mdx b/calico_versioned_docs/version-3.29/network-policy/policy-rules/external-ips-policy.mdx deleted file mode 100644 index 4632220d3f..0000000000 --- a/calico_versioned_docs/version-3.29/network-policy/policy-rules/external-ips-policy.mdx +++ /dev/null @@ -1,112 +0,0 @@ ---- -description: Limit egress and ingress traffic using IP address either directly within Calico network policy or managed as Calico network sets. ---- - -# Use external IPs or networks rules in policy - -## Big picture - -Use $[prodname] network policy to limit traffic to/from external non-$[prodname] workloads or networks. - -## Value - -Modern applications often integrate with third-party APIs and SaaS services that live outside Kubernetes clusters. To securely enable access to those integrations, network security teams must be able to limit IP ranges for egress and ingress traffic to workloads. This includes using IP lists or ranges to deny-list bad actors or embargoed countries. - -Using $[prodname] network policy, you can define IP addresses/CIDRs directly in policy to limit traffic to external networks. Or using $[prodname] network sets, you can easily scale out by using the same set of IPs in multiple policies. - -## Concepts - -### IP addresses/CIDRs - -IP addresses and CIDRs can be specified directly in both Kubernetes and $[prodname] network policy rules. $[prodname] network policy supports IPV4 and IPV6 CIDRs. - -### Network sets - -A **network set** resource is an arbitrary set of IP subnetworks/CIDRs that can be matched by standard label selectors in Kubernetes or $[prodname] network policy. This is useful to reference a set of IP addresses using a selector from a namespaced network policy resource. It is typically used when you want to scale/reuse the same set of IP addresses in policy. - -A **global network set** resource is similar, but can be selected only by $[prodname] global network policies. - -## How to - -- [Limit traffic to or from external networks, IPs in network policy](#limit-traffic-to-or-from-external-networks-ips-in-network-policy) -- [Limit traffic to or from external networks, global network set](#limit-traffic-to-or-from-external-networks-global-network-set) - -### Limit traffic to or from external networks, IPs in network policy - -In the following example, a $[prodname] NetworkPolicy allows egress traffic from pods with the label **color: red**, if it goes to an IP address in the 192.0.2.0/24 CIDR block. - -```yaml -apiVersion: projectcalico.org/v3 -kind: NetworkPolicy -metadata: - name: allow-egress-external - namespace: production -spec: - selector: color == 'red' - types: - - Egress - egress: - - action: Allow - destination: - nets: - - 192.0.2.0/24 -``` - -### Limit traffic to or from external networks, global network set - -In this example, we use a $[prodname] **GlobalNetworkSet** and reference it in a **GlobalNetworkPolicy**. - -In the following example, a $[prodname] **GlobalNetworkSet** deny-lists the CIDR ranges 192.0.2.55/32 and 203.0.113.0/24: - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkSet -metadata: - name: ip-protect - labels: - ip-deny-list: 'true' -spec: - nets: - - 192.0.2.55/32 - - 203.0.113.0/24 -``` - -Next, we create two $[prodname] **GlobalNetworkPolicy** objects. The first is a high “order” policy that allows traffic as a default for things that don’t match our second policy, which is low “order” and uses the **GlobalNetworkSet** label as a selector to deny ingress traffic (IP-deny-list in the previous step). In the label selector, we also include the term **!has(projectcalico.org/namespace)**, which prevents this policy from matching pods or NetworkSets that also have this label. To more quickly enforce the denial of forwarded traffic to the host at the packet level, use the **doNotTrack** and **applyOnForward** options. - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: forward-default-allow -spec: - selector: apply-ip-protect == 'true' - order: 1000 - doNotTrack: true - applyOnForward: true - types: - - Ingress - ingress: - - action: Allow ---- -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: ip-protect -spec: - selector: apply-ip-protect == 'true' - order: 0 - doNotTrack: true - applyOnForward: true - types: - - Ingress - ingress: - - action: Deny - source: - selector: ip-deny-list == 'true' && !has(projectcalico.org/namespace) -``` - -## Additional resources - -- To understand how to use global network sets to mitigate common threats, see [Defend against DoS attacks](../extreme-traffic/defend-dos-attack.mdx) -- [Global network sets](../../reference/resources/globalnetworkset.mdx) -- [Global network policy](../../reference/resources/globalnetworkpolicy.mdx) diff --git a/calico_versioned_docs/version-3.29/network-policy/policy-rules/icmp-ping.mdx b/calico_versioned_docs/version-3.29/network-policy/policy-rules/icmp-ping.mdx deleted file mode 100644 index be09c1aaf9..0000000000 --- a/calico_versioned_docs/version-3.29/network-policy/policy-rules/icmp-ping.mdx +++ /dev/null @@ -1,130 +0,0 @@ ---- -description: Control where ICMP/ping is used by creating a Calico network policy to allow and deny ICMP/ping messages for workloads and host endpoints. ---- - -# Use ICMP/ping rules in policy - -## Big picture - -Use $[prodname] network policy to allow and deny ICMP/ping messages. - -## Value - -The **Internet Control Message Protocol (ICMP)** provides valuable network diagnostic functions, but it can also be used maliciously. Attackers can use -it to learn about your network, or for DoS attacks. Using $[prodname] network policy, you can control where ICMP is used. For example, you can: - -- Allow ICMP ping, but only for workloads, host endpoints (or both) -- Allow ICMP for pods launched by operators for diagnostic purposes, but block other uses -- Temporarily enable ICMP to diagnose a problem, then disable it after the problem is resolved -- Deny/allow ICMPv4 and/or ICMPv6 - -## Concepts - -### ICMP packet type and code - -$[prodname] network policy also lets you deny and allow ICMP traffic based on specific types and codes. For example, you can specify ICMP type 5, code 2 to match specific ICMP redirect packets. - -For details, see [ICMP type and code](https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol#Control_messages). - -## How to - -- [Deny all ICMP, all workloads and host endpoints](#deny-all-icmp-all-workloads-and-host-endpoints) -- [Allow ICMP ping, all workloads and host endpoints](#allow-icmp-ping-all-workloads-and-host-endpoints) -- [Allow ICMP matching protocol type and code, all Kubernetes pods](#allow-icmp-matching-protocol-type-and-code-all-kubernetes-pods) - -### Deny all ICMP, all workloads and host endpoints - -In this example, we introduce a "deny all ICMP" **GlobalNetworkPolicy**. - -This policy **selects all workloads and host endpoints**. It enables a default deny for all workloads and host endpoints, in addition to the explicit ICMP deny rules specified in the policy. - -If your ultimate goal is to allow some traffic, have your regular "allow" policies in place before applying a global deny-all ICMP traffic policy. - -In this example, all workloads and host endpoints are blocked from sending or receiving **ICMPv4** and **ICMPv6** messages. - -If **ICMPv6** messages are not used in your deployment, it is still good practice to deny them specifically as shown below. - -In any "deny-all" $[prodname] network policy, be sure to specify a lower order (**order:200**) than regular policies that might allow traffic. - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: block-icmp -spec: - order: 200 - selector: all() - types: - - Ingress - - Egress - ingress: - - action: Deny - protocol: ICMP - - action: Deny - protocol: ICMPv6 - egress: - - action: Deny - protocol: ICMP - - action: Deny - protocol: ICMPv6 -``` - -### Allow ICMP ping, all workloads and host endpoints - -In this example, workloads and host endpoints can receive **ICMPv4 type 8** and **ICMPv6 type 128** ping requests that come from other workloads and host endpoints. - -All other traffic may be allowed by other policies. If traffic is not explicitly allowed, it will be denied by default. - -The policy applies only to **ingress** traffic. (Egress traffic is not affected, and default deny is not enforced for egress.) - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: allow-ping-in-cluster -spec: - selector: all() - types: - - Ingress - ingress: - - action: Allow - protocol: ICMP - source: - selector: all() - icmp: - type: 8 Ping request - - action: Allow - protocol: ICMPv6 - source: - selector: all() - icmp: - type: 128 Ping request -``` - -### Allow ICMP matching protocol type and code, all Kubernetes pods - -In this example, only Kubernetes pods that match the selector **projectcalico.org/orchestrator == 'kubernetes'** are allowed to receive ICMPv4 **code: 1 host unreachable** messages. - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: allow-host-unreachable -spec: - selector: projectcalico.org/orchestrator == 'kubernetes' - types: - - Ingress - ingress: - - action: Allow - protocol: ICMP - icmp: - type: 3 Destination unreachable - code: 1 Host unreachable -``` - -## Additional resources - -For more on the ICMP match criteria, see: - -- [Global network policy](../../reference/resources/globalnetworkpolicy.mdx) -- [Network policy](../../reference/resources/networkpolicy.mdx) diff --git a/calico_versioned_docs/version-3.29/network-policy/policy-rules/index.mdx b/calico_versioned_docs/version-3.29/network-policy/policy-rules/index.mdx deleted file mode 100644 index c035f8e7de..0000000000 --- a/calico_versioned_docs/version-3.29/network-policy/policy-rules/index.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: Control traffic to/from endpoints using Calico network policy rules. -hide_table_of_contents: true ---- - -# Policy rules - -import DocCardList from '@theme/DocCardList'; -import { useCurrentSidebarCategory } from '@docusaurus/theme-common'; - - diff --git a/calico_versioned_docs/version-3.29/network-policy/policy-rules/log-rules.mdx b/calico_versioned_docs/version-3.29/network-policy/policy-rules/log-rules.mdx deleted file mode 100644 index e60deef3a6..0000000000 --- a/calico_versioned_docs/version-3.29/network-policy/policy-rules/log-rules.mdx +++ /dev/null @@ -1,189 +0,0 @@ ---- -description: Debug your policies with Log rules. ---- - -# Use log rules to test network policy - -You can create network policies that log all network traffic that matches the policy. -With log rules, you can monitor all traffic in your cluster, test new policies before you enforce them, and troubleshoot policies that aren't behaving as expected. - -## About log rules - -A $[prodname] network policy with the action `Log` serves as a diagnostic tool that captures network traffic information based on the rules and criteria specified in the policy. -This helps cluster administrators see how traffic is evaluated by their policies. -Logs tell you where the traffic came from, where it was going, and whether that traffic was allowed or denied by the policy. - -Log rules are used mainly in the following situations: - -* To capture all traffic in a cluster. - Before setting up a default deny policy, you can see what traffic your cluster currently has. - This helps you when you create explicit allow rules for expected traffic. -* To test new network policy. - Before you enforce a new policy, you can set that policy to log real traffic to see if it does what you expect it to do. -* To troubleshoot existing policies. - If something isn't working as expected, you can use log rules to help debug your existing network policies. - -To effectively utilize Log actions, place them at the bottom of your policy tiers to capture any traffic not explicitly matched by lower-priority policies. -This approach helps identify unhandled traffic and reveals gaps in your policy configuration. -By analyzing the logged traffic, you can gain insights into its characteristics, such as source, destination, and protocol. -Use this information to create targeted policies that address the specific traffic patterns. -Once implemented, verify the changes by checking if the corresponding traffic no longer appears in the logs, indicating that your new policies are successfully handling it and remove your Log policies/rules since they can put a huge overhead on your cluster. - -To make the most of log actions, follow these guidelines: - - 1. **Order Matters:** Assign log actions a high `order` value to ensure they are evaluated after all lower-priority policies. - 1. **Explicit Allow Rule:** Always pair a log action with an explicit `Allow` rule immediately after it. Otherwise, traffic may be denied due to the tier's implicit default action. - 1. **Comprehensive Protection:** Ensure both namespaced and non-namespaced resources are covered by enabling `hostEndpoint` for protecting your host in addition to Pods and workloads. - -By strategically placing log actions at the bottom of your policy tiers, you can capture unhandled traffic and identify gaps in your policy configuration. -Analyze the logged traffic to gather insights about source, destination, and protocol, and use this data to create targeted policies. -Once implemented, validate by checking if the corresponding traffic is no longer logged, indicating the new policies are effective. - -### Understanding log output - -Calico's log output varies depending on which data plane you're using. - -#### Log output for iptables - -In the standard Linux data plane where `iptables` like backends are used to implement cluster security, the `Log` action logs the traffic at the first point of evaluation, before any subsequent actions (such as allowing or denying traffic) are applied. -This provides granular visibility into the matching traffic for specific rules or policies. - -Logs can be found in different locations, depending on your system. -You can often find Calico policy logs by: -* using the `journalctl` utility. -* searching in `/var/log/syslog`. -* searching in `/var/log/kern.log`. - -Example of iptables logs: - -```bash -2024-11-19T12:15:03.023805-08:00 c1-control kernel: calico-packet: IN=cali527b0801ecb OUT=eth0 MAC=ee:ee:ee:ee:ee:ee:1e:0a:36:33:f5:09:08:00 SRC=172.16.193.134 DST=69.147.80.15 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=58406 DF PROTO=TCP SPT=45588 DPT=80 WINDOW=64860 RES=0x00 SYN URGP=0 - -2024-11-19T12:15:28.648818-08:00 c1-control kernel: calico-packet: IN=cali527b0801ecb OUT=eth0 MAC=ee:ee:ee:ee:ee:ee:1e:0a:36:33:f5:09:08:00 SRC=172.16.193.134 DST=8.8.8.8 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=48210 DF PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=1 - -2024-11-19T12:15:02.990083-08:00 c1-control kernel: calico-packet: IN=cali527b0801ecb OUT=calid3446e883f0 MAC=ee:ee:ee:ee:ee:ee:1e:0a:36:33:f5:09:08:00 SRC=172.16.193.134 DST=172.16.193.133 LEN=96 TOS=0x00 PREC=0x00 TTL=63 ID=19241 DF PROTO=UDP SPT=42896 DPT=53 LEN=76 -``` - -#### Log output for eBPF - -BPF data plane logs the final verdict applied to the packet once it matched ANY log rule. -This means that the log entry reflects the ultimate decision (whether the traffic is allowed or denied) after evaluating the full set of applicable rules and policies. - -eBPF policy logs are sent to the trace pipe and can be viewed by using the following command: - -```bash -kubectl exec -n calico-system -it ds/calico-node -- bpftool prog tracelog -``` - -The precise format of the eBPF trace logs depends on your kernel and sysctl settings. -However, a typical log format includes information about the active process, a timestamp and then the IP header. - -Example of eBPF logs: - -```bash -curl-5288 [000] ..s2. 3055.982021: bpf_trace_printk: cali527b0801ecb-E: policy ALLOWED proto 6 src 172.16.193.131:56042 dest 69.147.80.12:80 - -<...>-4950 [001] ..s2. 2960.748464: bpf_trace_printk: cali527b0801ecb-E: policy ALLOWED proto 1 src 172.16.193.131:0 dest 8.8.8.8:8 - -<...>-5288 [000] ..s2. 3055.954466: bpf_trace_printk: cali527b0801ecb-E: policy ALLOWED proto 17 src 172.16.193.131:36325 dest 10.43.0.10:53 -``` - -$[prodname] eBPF logs use a custom format to output the information, here is the breakdown of this format: - -![curl](/img/calico/curl-bpf-log.svg) - -1. Process name and ID. - Be aware that the process name might not directly correspond to the responsible process for the traffic. -2. CPU number, Kernel flags, timestamp, BPF print function used to log this message. -3. Interface name. -4. Traffic type. - In this example, egress (`E`= egress, `X`= XDP, `I`= ingress). -5. Policy verdict (`ALLOWED`, `DENIED`). -6. IP protocol number. - In this example, 6 is for TCP (1 ICMP, 17 UDP). -7. Source IP and source port. -8. Destination IP and destination port. - -## Prerequisites - -* Your cluster is not a containerized Kubernetes environment such as Kind. -* If you're running $[prodname] with the eBPF data plane, your cluster node or VM host is running on a Linux distribution based on the Linux kernel 5.16 or later. - -## Log all traffic for a cluster - -Log rules can help you write network policy by showing you your cluster's current traffic. -When you know what traffic you want to allow, you can write policies to allow that traffic and restrict all other traffic. - -* To log all traffic across the entire cluster, create a `GlobalNetworkPolicy` resource with log actions for ingress and egress: - - ```yaml - apiVersion: projectcalico.org/v3 - kind: GlobalNetworkPolicy - metadata: - name: - spec: - order: 100000 - tier: default - types: - - Ingress - - Egress - egress: - - action: Log - ingress: - - action: Log - ``` - -## Log traffic for a namespace - -To monitor or troubleshoot traffic within a namespace, use a `NetworkPolicy` resource. -Apply the policy with the highest priority to capture traffic not handled by existing policies. -This provides visibility into unhandled traffic patterns specific to that namespace. - -* To log all traffic within a specific namespace, create a NetworkPolicy like this: - - ```yaml - apiVersion: projectcalico.org/v3 - kind: NetworkPolicy - metadata: - name: log-everything-in-ns - namespace: - spec: - order: 100001 - tier: default - types: - - Ingress - - Egress - egress: - - action: Log - ingress: - - action: Log - ``` - -## Log traffic for non-namespaced resources, hosts, and VMs - -By default, $[prodname] policies apply only to namespaced resources (for example, Pods, ServiceAccounts). -To use log rules for non-namespaced resources, hosts, and VMs, you can create [host endpoints](../../reference/host-endpoints/overview.mdx) for them. - -1. Create a `GlobalNetworkPolicy` resource to [log all traffic in your cluster](#log-all-traffic-for-a-cluster). - -1. Configure $[prodname] to automatically create host endpoints by running the following command: - - ```bash - kubectl patch kubecontrollersconfiguration default --type=merge --patch='{"spec": {"controllers": {"node": {"hostEndpoint": {"autoCreate": "Enabled"}}}}}' - ``` - - When the host endpoints are created, all traffic will be logged. - -1. When you have completed testing, remove the log policies. - Leaving them in place can significantly affect cluster performance. - -## Additional resources - -For a complete and efficient observability solution, consider exploring the use of [Flow Logs](/calico-enterprise/latest/observability/visualize-traffic) available in Calico Enterprise and Calico Cloud. - -For more on the match criteria and policy actions, see: - -- [Global network policy](../../reference/resources/globalnetworkpolicy.mdx) -- [Network policy](../../reference/resources/networkpolicy.mdx) -- [Host protection](../hosts/index.mdx) -- [eBPF troubleshooting](../../operations/ebpf/troubleshoot-ebpf.mdx) diff --git a/calico_versioned_docs/version-3.29/network-policy/policy-rules/namespace-policy.mdx b/calico_versioned_docs/version-3.29/network-policy/policy-rules/namespace-policy.mdx deleted file mode 100644 index 86c76bd268..0000000000 --- a/calico_versioned_docs/version-3.29/network-policy/policy-rules/namespace-policy.mdx +++ /dev/null @@ -1,89 +0,0 @@ ---- -description: Use namespaces and namespace selectors in Calico network policy to group or separate resources. Use network policies to allow or deny traffic to/from pods that belong to specific namespaces. ---- - -# Use namespace rules in policy - -## Big picture - -Use $[prodname] network policies to reference pods in other namespaces. - -## Value - -Kubernetes namespaces let you group/separate resources to meet a variety of use cases. For example, you can use namespaces to separate development, production, and QA environments, or allow different teams to use the same cluster. You can use namespace selectors in $[prodname] network policies to allow or deny traffic to/from pods in specific namespaces. - -## How to - -- [Control traffic to/from endpoints in a namespace](#control-traffic-tofrom-endpoints-in-a-namespace) -- [Use Kubernetes RBAC to control namespace label assignment](#use-kubernetes-rbac-to-control-namespace-label-assignment) - -### Control traffic to/from endpoints in a namespace - -In the following example, ingress traffic is allowed to endpoints in the **namespace: production** with label **color: red**, and only from a pod in the same namespace with **color: blue**, on **port 6379**. - -```yaml -apiVersion: projectcalico.org/v3 -kind: NetworkPolicy -metadata: - name: allow-tcp-6379 - namespace: production -spec: - selector: color == 'red' - ingress: - - action: Allow - protocol: TCP - source: - selector: color == 'blue' - destination: - ports: - - 6379 -``` - -To allow ingress traffic from endpoints in other namespaces, use a **namespaceSelector** in the policy rule. A namespaceSelector matches one or more namespaces based on the labels that are applied on the namespace. In the following example, ingress traffic is also allowed from endpoints with **color: blue** in namespaces with **shape: circle**. - -```yaml -apiVersion: projectcalico.org/v3 -kind: NetworkPolicy -metadata: - name: allow-tcp-6379 - namespace: production -spec: - selector: color == 'red' - ingress: - - action: Allow - protocol: TCP - source: - selector: color == 'blue' - namespaceSelector: shape == 'circle' - destination: - ports: - - 6379 -``` - -### Use Kubernetes RBAC to control namespace label assignment - -Network policies can be applied to endpoints using selectors that match labels on the endpoint, the endpoint's namespace, or the endpoint's service account. By applying selectors based on the endpoint's namespace, you can use Kubernetes RBAC to control which users can assign labels to namespaces. This allows you to separate groups who can deploy pods from those who can assign labels to namespaces. - -In the following example, users in the development environment can communicate only with pods that have a namespace labeled, `environment == "development"`. - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: restrict-development-access -spec: - namespaceSelector: 'environment == "development"' - ingress: - - action: Allow - source: - namespaceSelector: 'environment == "development"' - egress: - - action: Allow - destination: - namespaceSelector: 'environment == "development"' -``` - -## Additional resources - -- For more network policies, see [Network policy](../../reference/resources/networkpolicy.mdx) -- To apply policy to all namespaces, see [Global network policy](../../reference/resources/globalnetworkpolicy.mdx) diff --git a/calico_versioned_docs/version-3.29/network-policy/policy-rules/policy-rules-overview.mdx b/calico_versioned_docs/version-3.29/network-policy/policy-rules/policy-rules-overview.mdx deleted file mode 100644 index c313a002b6..0000000000 --- a/calico_versioned_docs/version-3.29/network-policy/policy-rules/policy-rules-overview.mdx +++ /dev/null @@ -1,22 +0,0 @@ ---- -description: Define network connectivity for Calico endpoints using policy rules and label selectors. ---- - -# Basic rules - -## Big picture - -Use Calico policy rules and label selectors that match Calico endpoints (pods, OpenStack VMs, and host interfaces) to define network connectivity. - -## Value - -Using label selectors to identify the endpoints (pods, OpenStack VMs, host interfaces) that a policy applies to, or that should be selected by policy rules, means you can define policy without knowing the IP addresses of the endpoints. This is ideal for handling dynamic workloads with ephemeral IPs (such as Kubernetes pods). - -## How to - -Read [Get started with Calico policy](../get-started/calico-policy/calico-network-policy.mdx) and [Kubernetes policy](../get-started/kubernetes-policy/kubernetes-network-policy.mdx), which cover all the basics of using label selectors in policies to select endpoints the policies apply to, or in policy rules. - -## Additional resources - -- [Global network policy](../../reference/resources/globalnetworkpolicy.mdx) -- [Network policy](../../reference/resources/networkpolicy.mdx) diff --git a/calico_versioned_docs/version-3.29/network-policy/policy-rules/service-accounts.mdx b/calico_versioned_docs/version-3.29/network-policy/policy-rules/service-accounts.mdx deleted file mode 100644 index 3741f75f61..0000000000 --- a/calico_versioned_docs/version-3.29/network-policy/policy-rules/service-accounts.mdx +++ /dev/null @@ -1,118 +0,0 @@ ---- -description: Use Kubernetes service accounts in policies to validate cryptographic identities and/or manage RBAC controlled high-priority rules across teams. ---- - -# Use service accounts rules in policy - -## Big picture - -Use $[prodname] network policy to allow/deny traffic for Kubernetes service accounts. - -## Value - -Using $[prodname] network policy, you can leverage Kubernetes service accounts with RBAC for flexible control over how policies are applied in a cluster. For example, the security team can have RBAC permissions to: - -- Control which service accounts the developer team can use within a namespace -- Write high-priority network policies for those service accounts (that the developer team cannot override) - -The network security team can maintain full control of security, while selectively allowing developer operations where it makes sense. - -Using **Istio-enabled apps** with $[prodname] network policy, the cryptographic identity associated with the service account is checked (along with the network identity) to achieve two-factor authentication. - -## Concepts - -### Use smallest set of permissions required - -Operations on service accounts are controlled by RBAC, so you can grant permissions only to trusted entities (code and/or people) to create, modify, or delete service accounts. To perform any operation in a workload, clients are required to authenticate with the Kubernetes API server. - -If you do not explicitly assign a service account to a pod, it uses the default ServiceAccount in the namespace. - -You should not grant broad permissions to the default service account for a namespace. If an application needs access to the Kubernetes API, create separate service accounts with the smallest set of permissions required. - -### Service account labels - -Like all other Kubernetes objects, service accounts have labels. You can use labels to create ‘groups’ of service accounts. $[prodname] network policy lets you select workloads by their service account using: - -- An exact match on service account name -- A service account label selector expression - -## Before you begin... - -Configure unique Kubernetes service accounts for your applications. - -## How to - -- [Limit ingress traffic for workloads by service account name](#limit-ingress-traffic-for-workloads-by-service-account-name) -- [Limit ingress traffic for workloads by service account label](#limit-ingress-traffic-for-workloads-by-service-account-label) -- [Use Kubernetes RBAC to control service account label assignment](#use-kubernetes-rbac-to-control-service-account-label-assignment) - -### Limit ingress traffic for workloads by service account name - -In the following example, ingress traffic is allowed from any workload whose service account matches the names **api-service** or **user-auth-service**. - -```yaml -apiVersion: projectcalico.org/v3 -kind: NetworkPolicy -metadata: - name: demo-calico - namespace: prod-engineering -spec: - ingress: - - action: Allow - source: - serviceAccounts: - names: - - api-service - - user-auth-service - selector: 'app == "db"' -``` - -### Limit ingress traffic for workloads by service account label - -In the following example, ingress traffic is allowed from any workload whose service account matches the label selector, **app == web-frontend**. - -```yaml -apiVersion: projectcalico.org/v3 -kind: NetworkPolicy -metadata: - name: allow-web-frontend - namespace: prod-engineering -spec: - ingress: - - action: Allow - source: - serviceAccounts: - selector: 'app == "web-frontend"' - selector: 'app == "db"' -``` - -### Use Kubernetes RBAC to control service account label assignment - -Network policies can be applied to endpoints using selectors that match labels on the endpoint, the endpoint's namespace, or the endpoint's service account. By applying selectors based on the endpoint's service account, you can use Kubernetes RBAC to control which users can assign labels to service accounts. This allows you to separate groups who can deploy pods from those who can assign labels to service accounts. - -In the following example, pods with an intern service account can communicate only with pods with service accounts labeled, `role: intern`. - -```yaml -apiVersion: projectcalico.org/v3 -kind: NetworkPolicy -metadata: - name: restrict-intern-access - namespace: prod-engineering -spec: - serviceAccountSelector: 'role == "intern"' - ingress: - - action: Allow - source: - serviceAccounts: - selector: 'role == "intern"' - egress: - - action: Allow - destination: - serviceAccounts: - selector: 'role == "intern"' -``` - -## Additional resources - -- [Network policy](../../reference/resources/networkpolicy.mdx) -- [Global network policy](../../reference/resources/globalnetworkpolicy.mdx) diff --git a/calico_versioned_docs/version-3.29/network-policy/policy-rules/service-policy.mdx b/calico_versioned_docs/version-3.29/network-policy/policy-rules/service-policy.mdx deleted file mode 100644 index 103692c8e7..0000000000 --- a/calico_versioned_docs/version-3.29/network-policy/policy-rules/service-policy.mdx +++ /dev/null @@ -1,125 +0,0 @@ ---- -description: Use Kubernetes Service names in policy rules. ---- - -# Use service rules in policy - -## Big picture - -Use $[prodname] network policy to allow/deny traffic for Kubernetes services. - -## Value - -Using $[prodname] network policy, you can leverage Kubernetes Service names to easily define access to Kubernetes services. Using service names in policy enables you to: - -- Allow or deny access to the Kubernetes API service. -- Reference port information already declared by the application, making it easier to keep policy up-to-date as application requirements change. - -## How to - -- [Allow access to the Kubernetes API for a specific namespace](#allow-access-to-the-kubernetes-api-for-a-specific-namespace) -- [Allow access to Kubernetes DNS for the entire cluster](#allow-access-to-kubernetes-dns-for-the-entire-cluster) -- [Allow access from a specified service](#allow-access-from-a-specified-service) - -### Allow access to the Kubernetes API for a specific namespace - -In the following example, egress traffic is allowed to the `kubernetes` service in the `default` namespace for all pods in the namespace `my-app`. This service is the typical -access point for the Kubernetes API server. - -```yaml -apiVersion: projectcalico.org/v3 -kind: NetworkPolicy -metadata: - name: allow-api-access - namespace: my-app -spec: - selector: all() - egress: - - action: Allow - destination: - services: - name: kubernetes - namespace: default -``` - -Endpoint addresses and ports to allow will be automatically detected from the service. - -### Allow access to Kubernetes DNS for the entire cluster - -In the following example, a GlobalNetworkPolicy is used to select all pods in the cluster to apply a rule which ensures -all pods can access the Kubernetes DNS service. - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: allow-kube-dns -spec: - selector: all() - egress: - - action: Allow - destination: - services: - name: kube-dns - namespace: kube-system -``` - -:::note - -This policy also enacts a default-deny behavior for all pods, so make sure any other required application traffic is allowed by a policy. - -::: - -:::tip - -You may see examples elsewhere that use a label selector (for example, `selector: 'k8s-app == "kube-dns"'`) with explicit protocol and port rules to allow DNS traffic. That approach can be useful when you need to target pods directly without a backing Kubernetes Service, or when you need to restrict traffic to only a subset of a Service's ports or protocols. The service match syntax shown above is preferred in the common case because it is simpler and automatically resolves the correct endpoints and ports. - -::: - -## Allow access from a specified service - -In the following example, ingress traffic is allowed from the `frontend-service` service in the `frontend` namespace for all pods in the namespace `backend`. -This allows all pods that back the `frontend-service` service to send traffic to all pods in the `backend` namespace. - -```yaml -apiVersion: projectcalico.org/v3 -kind: NetworkPolicy -metadata: - name: allow-frontend-service-access - namespace: backend -spec: - selector: all() - ingress: - - action: Allow - source: - services: - name: frontend-service - namespace: frontend -``` - -We can also further specify the ports that the `frontend-service` service is allowed to access. The following example limits access from the `frontend-service` -service to port 80. - -```yaml -apiVersion: projectcalico.org/v3 -kind: NetworkPolicy -metadata: - name: allow-frontend-service-access - namespace: backend -spec: - selector: all() - ingress: - - action: Allow - protocol: TCP - source: - services: - name: frontend-service - namespace: frontend - destination: - ports: [80] -``` - -## Additional resources - -- [Network policy](../../reference/resources/networkpolicy.mdx) -- [Global network policy](../../reference/resources/globalnetworkpolicy.mdx) diff --git a/calico_versioned_docs/version-3.29/network-policy/policy-tiers/index.mdx b/calico_versioned_docs/version-3.29/network-policy/policy-tiers/index.mdx deleted file mode 100644 index 9e9dc39a52..0000000000 --- a/calico_versioned_docs/version-3.29/network-policy/policy-tiers/index.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: Learn how policy tiers allow diverse teams to securely manage Kubernetes policy. -hide_table_of_contents: true ---- - -# Policy tiers - -import DocCardList from '@theme/DocCardList'; -import { useCurrentSidebarCategory } from '@docusaurus/theme-common'; - - diff --git a/calico_versioned_docs/version-3.29/network-policy/policy-tiers/rbac-tiered-policies.mdx b/calico_versioned_docs/version-3.29/network-policy/policy-tiers/rbac-tiered-policies.mdx deleted file mode 100644 index 3403cf158d..0000000000 --- a/calico_versioned_docs/version-3.29/network-policy/policy-tiers/rbac-tiered-policies.mdx +++ /dev/null @@ -1,485 +0,0 @@ ---- -description: Configure RBAC to control access to policies and tiers. ---- - -# Configure RBAC for tiered policies - -## Big picture - -Configure fine-grained user access controls for tiered policies. - -## Value - -Self-service is an important part of CI/CD processes for containerization and microservices. $[prodname] provides fine-grained access control (RBAC) for: - -- $[prodname] policy and tiers -- Kubernetes network policy - -## Concepts - -### Standard Kubernetes RBAC - -$[prodname] implements the standard **Kubernetes RBAC Authorization APIs** with `Role` and `ClusterRole` types. The $[prodname] API server integrates with Kubernetes RBAC Authorization APIs as an extension API server. - -### RBAC for policies and tiers - -In $[prodname], global network policy and network policy resources are associated with a specific tier. Admins can configure access control for these $[prodname] policies using standard Kubernetes `Role` and `ClusterRole` resource types. This makes it easy to manage RBAC for both Kubernetes network policies and $[prodname] tiered network policies. RBAC permissions include managing resources using the $[prodname] web console, and `kubectl`. - -### RBAC definitions for Calico network policy - - -To specify per-tier RBAC for the $[prodname] network policy and $[prodname] global network policy, use pseudo resource kinds and names in the `Role` and `ClusterRole` definitions. For example, - -```yaml -kind: ClusterRole -apiVersion: rbac.authorization.k8s.io/v1 -metadata: - name: tier-default-reader -rules: - - apiGroups: ['projectcalico.org'] - resources: ['tiers'] - resourceNames: ['default'] - verbs: ['get'] - - apiGroups: ['projectcalico.org'] - resources: ['tier.networkpolicies'] - resourceNames: ['default.*'] - verbs: ['get', 'list'] -``` - -Where: - -- **resources**: `tier.globalnetworkpolicies` and `tier.networkpolicies` -- **resourceNames**: - - Blank - any policy of the specified kind across all tiers. - - `.*` - any policy of the specified kind within the named tier. - - `` - the specific policy of the specified kind. Because the policy name is prefixed with the tier name, this also specifies the tier. - -## Before you begin... - -**Required** - -A **cluster-admin** role with full permissions to create and modify resources. - -**Recommended** - -A rough idea of your tiered policy workflow, and who should access what. See [Configure tiered policies](tiered-policy.mdx). - -## How to - -- [Create Admin users, full permissions](#create-admin-users-full-permissions) - -:::note - -` kubectl auth can-i` cannot be used to check RBAC for tiered policy. - -::: - -### Create Admin users, full permissions - -Create an Admin user with full access to the $[prodname] web console (as well as everything else in the cluster) using the following command. See the Kubernetes documentation to identify users based on your chosen [authentication method](https://kubernetes.io/docs/reference/access-authn-authz/authentication/), and how to use the [RBAC resources](https://kubernetes.io/docs/reference/access-authn-authz/rbac/). - -```bash -kubectl create clusterrolebinding permissive-binding \ - --clusterrole=cluster-admin \ - --user= -``` - -## Tutorial - -This tutorial shows how to use RBAC to control access to resources and CRUD actions for a non-Admin user, John, with the username **john**. - -The RBAC examples shown will include: - -- [User cannot read policies in any tier](#user-cannot-read-policies-in-any-tier) -- [User can view all policies, and modify policies in the default namespace and tier](#user-can-view-all-policies-and-modify-policies-in-the-default-namespace-and-tier) -- [User can read policies only in both the default tier and namespace](#user-can-read-policies-only-in-both-the-default-tier-and-namespace) -- [User can read policies only in both a specific tier and in the default namespace](#user-can-read-policies-only-in-both-a-specific-tier-and-in-the-default-namespace) -- [User can only view a specific tier](#user-can-only-view-a-specific-tier) -- [User can read all policies across all tiers and namespaces](#user-can-read-all-policies-across-all-tiers-and-namespaces) -- [User has full control over policies only in both a specific tier and in the default namespace](#user-has-full-control-over-policies-only-in-both-a-specific-tier-and-in-the-default-namespace) - -### User cannot read policies in any tier - -User 'john' is forbidden from reading policies in any tier (**default** tier, and **net-sec** tier). - -When John issues the following command: - -```bash -kubectl get networkpolicies.p -``` - -It returns: - -``` -Error from server (Forbidden): networkpolicies.projectcalico.org is forbidden: User "john" cannot list networkpolicies.projectcalico.org in tier "default" and namespace "default" (user cannot get tier) -``` - -Similarly, when John issues this command: - -```bash -kubectl get networkpolicies.p -l projectcalico.org/tier==net-sec -``` - -It returns: - -``` -Error from server (Forbidden): networkpolicies.projectcalico.org is forbidden: User "john" cannot list networkpolicies.projectcalico.org in tier "net-sec" and namespace "default" (user cannot get tier) -``` - -:::note - -The .p' extension (`networkpolicies.p`) is short -for "networkpolicies.projectcalico.org" and used to -differentiate it from the Kubernetes NetworkPolicy resource and -the underlying CRDs (if using the Kubernetes Datastore Driver). - -::: - -:::note - -The label for selecting a tier is `projectcalico.org/tier`. -When a label selector is not specified, the server defaults the selection to the -`default` tier. Alternatively, a field selector (`spec.tier`) may be used to select -a tier. - -```bash -kubectl get networkpolicies.p --field-selector spec.tier=net-sec -``` - -::: - -### User can view all policies, and modify policies in the default namespace and tier - -1. Download the [`read-all-crud-default-rbac.yaml` manifest]($[tutorialFilesURL]/read-all-crud-default-rbac.yaml). - -1. Run the following command to replace `` with the `name or email` of - the user you are providing permissions to: - - ```bash - sed -i -e 's///g' read-all-crud-default-rbac.yaml - ``` - -1. Use the following command to install the bindings: - - ```bash - kubectl apply -f read-all-crud-default-rbac.yaml - ``` - -The roles and bindings in this file provide the permissions to read all policies across all tiers and to fully manage -policies in the **default** tier and **default** namespace. This file includes the minimum required `ClusterRole` and `ClusterRoleBinding` definitions for all UI users (see `min-ui-user-rbac.yaml` above). - -### User can read policies only in both the default tier and namespace - -In this example, we give user 'john' permission to read policies only in both the **default** tier and namespace. - -```yaml -kind: ClusterRole -apiVersion: rbac.authorization.k8s.io/v1 -metadata: - name: tigera-example-get-default-tier -rules: - # To access Calico policy in a tier, the user requires "get" access to that tier. -- apiGroups: ["projectcalico.org"] - resources: ["tiers"] - resourceNames: ["default"] - verbs: ["get"] - ---- - -kind: ClusterRole -apiVersion: rbac.authorization.k8s.io/v1 -metadata: - name: tigera-example-read-policies-in-default-tier -rules: - # This allows "get" and "list" of the Calico NetworkPolicy resources in the default tier. -- apiGroups: ["projectcalico.org"] - resources: ["tier.networkpolicies"] - resourceNames: ["default.*"] - verbs: ["get", "list"] - ---- - -# tigera-example-get-default-tier is applied globally -kind: ClusterRoleBinding -apiVersion: rbac.authorization.k8s.io/v1 -metadata: - name: john-can-get-default-tier -subjects: -- kind: User - name: john - apiGroup: rbac.authorization.k8s.io -roleRef: - kind: ClusterRole - name: tigera-example-get-default-tier - apiGroup: rbac.authorization.k8s.io - ---- - -# tigera-example-read-policies-in-default-tier is applied per-namespace -kind: RoleBinding -apiVersion: rbac.authorization.k8s.io/v1 -metadata: - name: john-can-read-policies-in-default-tier-and-namespace -subjects: -- kind: User - name: john - apiGroup: rbac.authorization.k8s.io -roleRef: - kind: ClusterRole - name: tigera-example-read-policies-in-default-tier - apiGroup: rbac.authorization.k8s.io -``` - -With the above, user john is able to list all NetworkPolicy resources in the **default** tier: - -```bash -kubectl get networkpolicies.p --all-namespaces -``` - -With some example policies on the cluster, returns: - -``` -NAMESPACE NAME CREATED AT -blue default.calico-np-blue-ns-default-tier 2021-07-26T09:05:11Z -default default.calico-np-default-ns-default-tier 2021-07-26T09:05:11Z -green default.calico-np-green-ns-default-tier 2021-07-26T09:05:13Z -red default.calico-np-red-ns-default-tier 2021-07-26T09:05:12Z -yellow default.calico-np-yellow-ns-default-tier 2021-07-26T09:05:13Z -``` - -As intended, user john can only examine those in the **default** namespace: - -```bash -kubectl get networkpolicies.p default.calico-np-green-ns-default-tier -o yaml -n=green -``` - -Correctly returns: - -``` -Error from server (Forbidden): networkpolicies.projectcalico.org "default.calico-np-green-ns-default-tier" is forbidden: User "john" cannot get networkpolicies.projectcalico.org in tier "default" and namespace "green" -``` - -John also still cannot access tier **net-sec**, as intended: - -```bash -kubectl get networkpolicies.p -l projectcalico.org/tier==net-sec -``` - -This returns: - -``` -Error from server (Forbidden): networkpolicies.projectcalico.org is forbidden: User "john" cannot list networkpolicies.projectcalico.org in tier "net-sec" and namespace "default" (user cannot get tier) -``` - -### User can read policies only in both a specific tier and in the default namespace - -Let's assume that the kubernetes-admin gives user 'john' the permission to list the policies in tier **net-sec**, but only examine the detail of the policies that are also in the **default** namespace. -To provide these permissions to user 'john', use the following `ClusterRoles`,`ClusterRoleBinding` and `RoleBinding`. - -```yaml -kind: ClusterRole -apiVersion: rbac.authorization.k8s.io/v1 -metadata: - name: tigera-example-get-net-sec-tier -rules: - # To access Calico policy in a tier, the user requires "get" access to that tier. -- apiGroups: ["projectcalico.org"] - resources: ["tiers"] - resourceNames: ["net-sec"] - verbs: ["get"] - ---- - -kind: ClusterRole -apiVersion: rbac.authorization.k8s.io/v1 -metadata: - name: tigera-example-read-policies-in-net-sec-tier -rules: - # This allows "get" and "list" of the Calico NetworkPolicy resources in the net-sec tier. -- apiGroups: ["projectcalico.org"] - resources: ["tier.networkpolicies"] - resourceNames: ["net-sec.*"] - verbs: ["get", "list"] - ---- - -# tigera-example-get-net-sec-tier is applied globally -kind: ClusterRoleBinding -apiVersion: rbac.authorization.k8s.io/v1 -metadata: - name: john-can-get-net-sec-tier -subjects: -- kind: User - name: john - apiGroup: rbac.authorization.k8s.io -roleRef: - kind: ClusterRole - name: tigera-example-get-net-sec-tier - apiGroup: rbac.authorization.k8s.io - ---- - -# tigera-example-read-policies-in-net-sec-tier is applied per-namespace -kind: RoleBinding -apiVersion: rbac.authorization.k8s.io/v1 -metadata: - name: john-can-read-policies-in-net-sec-tier-and-namespace -subjects: -- kind: User - name: john - apiGroup: rbac.authorization.k8s.io -roleRef: - kind: ClusterRole - name: tigera-example-read-policies-in-net-sec-tier - apiGroup: rbac.authorization.k8s.io -``` - -### User can only view a specific tier - -In this example, the following `ClusterRole` and `ClusterRoleBinding` can be used to provide 'get' access to the **net-sec** -tier. This has the effect of making the **net-sec** tier visible in the $[prodname] web console (including listing the names of the policies it contains). - -However, to modify or view the details of policies within the **net-sec** tier, additional RBAC permissions would be required. - -```yaml -kind: ClusterRole -apiVersion: rbac.authorization.k8s.io/v1 -metadata: - name: tigera-example-make-net-sec-tier-visible -rules: - # To access Calico policy in a tier, the user requires "get" access to that tier. -- apiGroups: ["projectcalico.org"] - resources: ["tiers"] - resourceNames: ["net-sec"] - verbs: ["get"] - ---- - -# tigera-example-make-net-sec-tier-visible is applied globally -kind: ClusterRoleBinding -apiVersion: rbac.authorization.k8s.io/v1 -metadata: - name: john-can-view-the-net-sec-tier -subjects: -- kind: User - name: john - apiGroup: rbac.authorization.k8s.io -roleRef: - kind: ClusterRole - name: tigera-example-make-net-sec-tier-visible - apiGroup: rbac.authorization.k8s.io -``` - -### User can read all policies across all tiers and namespaces - -In this example, a single `ClusterRole` is used to provide read access to all policy resource types across all tiers. In this case, there is no need to use both `ClusterRoleBindings` and `RoleBindings` to map these abilities to the target user, because the intention is to for the policy to apply to all current and future namespaces on the cluster, so a `ClusterRoleBinding` provides the desired granularity. - -```yaml -kind: ClusterRole -apiVersion: rbac.authorization.k8s.io/v1 -metadata: - name: tigera-example-all-tiers-and-namespaces-policy-reader -rules: - # To access Calico policy in a tier, the user requires "get" access to that tier. - # Not specifying any specific "resourceNames" provides access to all tiers. -- apiGroups: ["projectcalico.org"] - resources: ["tiers"] - verbs: ["get"] - # This allows read access to the Kubernetes NetworkPolicy resources (these are always in the default tier). -- apiGroups: ["networking.k8s.io", "extensions"] - resources: ["networkpolicies"] - verbs: ["get","watch","list"] - # This allows read access to the Calico NetworkPolicy and GlobalNetworkPolicies. - # Not specifying any specific "resourceNames" provides access to them in all tiers. -- apiGroups: ["projectcalico.org"] - resources: ["tier.networkpolicies","tier.globalnetworkpolicies"] - verbs: ["get","watch","list"] - ---- - -# tigera-example-all-tiers-and-namespaces-policy-reader is applied globally, with a single ClusterRoleBinding, -# since all the rules it contains apply to all current and future namespaces on the cluster. -kind: ClusterRoleBinding -apiVersion: rbac.authorization.k8s.io/v1 -metadata: - name: read-all-tier -subjects: -- kind: User - name: john - apiGroup: rbac.authorization.k8s.io -roleRef: - kind: ClusterRole - name: tigera-example-all-tiers-and-namespaces-policy-reader - apiGroup: rbac.authorization.k8s.io -``` - -### User has full control over policies only in both a specific tier and in the default namespace - -In this example, two `ClusterRole` objects are used to provide full access control of Calico NetworkPolicy -resource types in the **net-sec** tier: - -- The `tiers` resource is bound to a user using a `ClusterRoleBinding`, because it is a global resource. - This results in the user having the ability to read the contents of the tier across all namespaces. -- The `networkpolicies` resources are bound to a user using a `RoleBinding`, because the aim in this - case was to make them CRUD-able only in the default namespace. - You only need this one `ClusterRole` to be defined, but it can be applied to different namespaces - using additional `RoleBinding` objects. If the intention was to apply it to all current and future namespaces, - a `ClusterRoleBinding` could be used. - -```yaml -kind: ClusterRole -apiVersion: rbac.authorization.k8s.io/v1 -metadata: - name: tigera-example-get-net-sec-tier -rules: - # To access Calico policy in a tier, the user requires "get" access to that tier. -- apiGroups: ["projectcalico.org"] - resources: ["tiers"] - resourceNames: ["net-sec"] - verbs: ["get"] - ---- - -kind: ClusterRole -apiVersion: rbac.authorization.k8s.io/v1 -metadata: - name: tigera-example-crud-policies-in-net-sec-tier -rules: - # This allows full CRUD access to the Calico NetworkPolicy resources in the net-sec tier. -- apiGroups: ["projectcalico.org"] - resources: ["tier.networkpolicies"] - resourceNames: ["net-sec.*"] - verbs: ["*"] - ---- - -# tigera-example-get-net-sec-tier is applied globally -kind: ClusterRoleBinding -apiVersion: rbac.authorization.k8s.io/v1 -metadata: - name: john-can-get-net-sec-tier -subjects: -- kind: User - name: john - apiGroup: rbac.authorization.k8s.io -roleRef: - kind: ClusterRole - name: tigera-example-get-net-sec-tier - apiGroup: rbac.authorization.k8s.io - ---- - -# tigera-example-crud-policies-in-net-sec-tier is applied per-namespace -kind: RoleBinding -apiVersion: rbac.authorization.k8s.io/v1 -metadata: - name: john-can-crud-policies-in-net-sec-tier-and-namespace -subjects: -- kind: User - name: john - apiGroup: rbac.authorization.k8s.io -roleRef: - kind: ClusterRole - name: tigera-example-crud-policies-in-net-sec-tier - apiGroup: rbac.authorization.k8s.io -``` diff --git a/calico_versioned_docs/version-3.29/network-policy/policy-tiers/tiered-policy.mdx b/calico_versioned_docs/version-3.29/network-policy/policy-tiers/tiered-policy.mdx deleted file mode 100644 index 7cabe80226..0000000000 --- a/calico_versioned_docs/version-3.29/network-policy/policy-tiers/tiered-policy.mdx +++ /dev/null @@ -1,181 +0,0 @@ ---- -description: Understand how tiered policy works and supports microsegmentation. ---- - -# Get started with policy tiers - -## Seamless network policy integration - -**Network policy** is the primary tool for securing a Kubernetes network. It lets you restrict network traffic in your cluster so only the traffic that you want to flow is allowed. $[prodname] provides more robust policy than Kubernetes, but you can use them together -- seamlessly. $[prodname] supports: - -- $[prodname] network policy, (namespaced) -- $[prodname] global network policy (non-namespaced, global) -- Kubernetes network policy - -## Tiers: what and why? - -**Tiers** are a hierarchical construct used to group policies and enforce higher precedence policies that cannot be circumvented by other teams. As you will learn in this tutorial, tiers have built-in features that support workload microsegmentation. - -All $[prodname] and Kubernetes network policies reside in tiers. You can start "thinking in tiers" by grouping your teams and types of policies within each group. For example, we recommend these three tiers (platform, security, and application). - -![policy-types](/img/calico-enterprise/policy-types.png) - -Next, you can determine the priority of policies in tiers (from top to bottom). In the following example, the platform and security tiers use $[prodname] global network policies that apply to all pods, while developer teams can safely manage pods within namespaces using Kubernetes network policy for their applications and microservices. - -![policy-tiers](/img/calico-enterprise/policy-tiers.png) - -## Create a tier - -The following is a sample YAML that creates a security tier and uses `kubectl` to apply it. - -```yaml -apiVersion: projectcalico.org/v3 -kind: Tier -metadata: - name: security -spec: - order: 300 -``` - -```bash -kubectl apply -f security.yaml -``` - -## The default tier: - -The default tier is created during installation and has the order of 1,000,000. This value is fixed, and cannot be changed. The desire is to evaluate policies in the default tier as last. - -The default tier is where: - -- You manage all Kubernetes network policies -- All network and global network policies without an explicit tier are placed. -- Network and global network policies are placed when you upgrade from Project Calico without tier support to $[prodname] release with tier support. - -## AdminNetworkPolicy tier: - -The AdminNetworkPolicy tier is where all [Kubernetes admin network policies](https://network-policy-api.sigs.k8s.io/reference/examples/) reside. It is automatically created during installation and has the order of 1,000. This value is fixed, and cannot be changed. - -## Tier order - -Tiers are sorted by their orders, starting from the lowest order (the highest priority) tiers. - -## Policy processing - -Policies are processed in sequential order from lowest order (highest priority) to highest order (lowest priority). - -Two mechanisms drive how traffic is processed across tiered policies: - -- Labels and selectors -- Policy action rules - -It is important to understand the roles they play. - -### Labels and selectors - -Instead of IP addresses and IP ranges, network policies in Kubernetes depend on labels and selectors to determine which workloads can talk to each other. Workload identity is the same for Kubernetes and $[prodname] network policies: as pods dynamically come and go, network policy is enforced based on the labels and selectors that you define. - -The following diagrams show the relationship between all of the elements that affect traffic flow: - -- **Tiers** group and order policies -- **Policy action rules** define how to process traffic in and across tiers, and policy labels and selectors specify how groups of pods are allowed to communicate with each other and other network endpoints -- The **CNI**, **$[prodname] components**, and underlying **data plane** (iptables/eBPF) all make use of labels and selectors as part of routing traffic. - -![tier-funnel](/img/calico-enterprise/tier-funnel.png) - -### Policy action rules - -$[prodname] network policy uses action rules to specify how to process traffic/packets: - -- **Allow or Deny** - traffic is allowed or denied and the packet is handled accordingly. No further rules are processed. -- **Pass** - skips to the next tier that contains a policy that applies to the endpoint, and processes the packet. If the tier applies to the endpoint but no action is taken on the packet, the packet is dropped. -- **Log** - creates a log, and evaluation continues processing to the next rule - -### Implicit default deny - -As shown in the following diagram, at the end of each tier is an implicit default deny. This is a safeguard that helps mitigate against unsecured policy. -Because of this safeguard, you must either explicitly update tier's default action to **Pass** or apply a Pass action rule when you want traffic evaluation to continue. -In the following example, the Pass action in a policy ensures that traffic evaluation continues, and overrides the implicit default deny. - -![implicit-deny](/img/calico-enterprise/implicit-deny.svg) - -Let’s look at a Dev/Ops global network policy in a high precedence tier (Platform). The policy denies ingress and egress traffic to workloads that match selector, `env == "stage"`. To ensure that policies continue to evaluate traffic after this policy, the policy adds a Pass action for both ingress and egress. - -**Pass action rule example** - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: devops.stage-env -spec: - tier: devops - order: 255 - selector: env == "stage" - ingress: - - action: Deny - source: - selector: env != "stage" - - action: Pass - egress: - - action: Deny - destination: - selector: env != "stage" - - action: Pass - types: - - Ingress - - Egress -``` - -The other option, is to update tier's default action to **Pass** to override the implicit default deny. - -**Pass default action tier example** - -```yaml -apiVersion: projectcalico.org/v3 -kind: Tier -metadata: - name: devops -spec: - order: 300 - defaultAction: Pass -``` - -### Policy endpoint matching across tiers - -Whoever is responsible for tier creation, also needs to understand how policy selects matching endpoints across tiers. For normal policy processing (without apply-on-forward, pre-DNAT, and do-not-track), if no policies within a tier apply to endpoints, the tier is skipped, and the tier's implicit deny behavior is not executed. - -In the following example, **policy D** in the Security tier includes a Pass action rule because we want traffic evaluation to continue to the next tier in sequence. In the Platform tier, there are no selectors in policies that match endpoints so the tier is skipped, including the end of tier deny. Evaluation continues to the Application tier. **Policy J** is the first policy with a matching endpoint. - -![endpoint-match](/img/calico-enterprise/endpoint-match.svg) - -### Default endpoint behavior - -Also, tier managers need to understand the default behavior for endpoints based on whether the endpoint is known or unknown, and the endpoint type. As shown in the following table: - -- **Known endpoints** - $[prodname] resources that are managed by Felix -- **Unknown endpoints** - interfaces/resources not recognizable as part of our data model - -| Endpoint type | Default behavior for known endpoints | Default behavior for unknown endpoints (outside of our data model) | -| ---------------------- | ----------------------------------------------------------------------- | ------------------------------------------------------------------ | -| Workload, $[prodname] | Deny | Deny | -| Workload, Kubernetes | Allow ingress from same Kubernetes namespace; allow all egress | Deny | -| Host | Deny. With exception of auto host endpoints, which get `default-allow`. | Fall through and use iptables rules | - -## Best practices for tiered policy - -To control and authorize access to $[prodname] tiers, policies, and Kubernetes network policies, you use Kubernetes RBAC. Security teams can prevent unauthorized viewing or modification of higher precedence (lower order) tiers, while still allowing developers or service owners to manage the detailed policies related to their workloads. - -We recommend: - -- Limit tier creation permissions to Admin users only; creating and reordering tiers affects your policy processing workflow - -- Limit full CRUD operations on tiers and policy management to select Admin users - -- Review your policy processing whenever you add/reorder tiers - - For example, you may need to update Pass action rules to policies before or after the new tier. Intervening tiers may require changes to policies before and after, depending on the endpoints. - - -## Additional resources - -- For details on using RBAC for fine-grained access to tiers and policies, see [Configure RBAC for tiered policies](rbac-tiered-policies.mdx). diff --git a/calico_versioned_docs/version-3.29/network-policy/services/index.mdx b/calico_versioned_docs/version-3.29/network-policy/services/index.mdx deleted file mode 100644 index 9a8084c99b..0000000000 --- a/calico_versioned_docs/version-3.29/network-policy/services/index.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: Apply Calico policy to Kubernetes node ports, and to services that are exposed externally as cluster IPs. -hide_table_of_contents: true ---- - -# Policy for Kubernetes services - -import DocCardList from '@theme/DocCardList'; -import { useCurrentSidebarCategory } from '@docusaurus/theme-common'; - - diff --git a/calico_versioned_docs/version-3.29/network-policy/services/kubernetes-node-ports.mdx b/calico_versioned_docs/version-3.29/network-policy/services/kubernetes-node-ports.mdx deleted file mode 100644 index c870f71de1..0000000000 --- a/calico_versioned_docs/version-3.29/network-policy/services/kubernetes-node-ports.mdx +++ /dev/null @@ -1,135 +0,0 @@ ---- -description: Restrict access to Kubernetes node ports using Calico global network policy. Follow the steps to secure the host, the node ports, and the cluster. ---- - -# Apply Calico policy to Kubernetes node ports - -## Big picture - -Restrict access to node ports to specific external clients. - -## Value - -Exposing services to external clients using node ports is a standard Kubernetes feature. However, if you want to restrict access to node ports to specific external clients, you need to use Calico global network policy. - -## Concepts - -### Network policy with preDNAT field - -In a Kubernetes cluster, kube-proxy will DNAT a request to the node's port and IP address to one of the pods that backs the service. For Calico global network policy to both allow normal ingress cluster traffic and deny other general ingress traffic, it must take effect before DNAT. To do this, you simply add a **preDNAT** field to a Calico global network policy. The preDNAT field: - -- Applies before DNAT -- Applies only to ingress rules -- Enforces all ingress traffic through a host endpoint, regardless of destination - The destination can be a locally hosted pod, a pod on another node, or a process running on the host. - -## Before you begin... - -For services that you want to expose to external clients, configure Kubernetes services with type **NodePort**. - -## How to - -To securely expose a Kubernetes service to external clients, you must implement all of the following steps. - -- [Allow cluster ingress traffic, but deny general ingress traffic](#allow-cluster-ingress-traffic-but-deny-general-ingress-traffic) -- [Allow local host egress traffic](#allow-local-host-egress-traffic) -- [Create host endpoints with appropriate network policy](#create-host-endpoints-with-appropriate-network-policy) -- [Allow ingress traffic to specific node ports](#allow-ingress-traffic-to-specific-node-ports) - -### Allow cluster ingress traffic but deny general ingress traffic - -In the following example, we create a global network policy to allow cluster ingress traffic (**allow-cluster-internal-ingress**): for the nodes’ IP addresses (**1.2.3.4/16**), and for pod IP addresses assigned by Kubernetes (**100.100.100.0/16**). By adding a preDNAT field, Calico global network policy is applied before regular DNAT on the Kubernetes cluster. - -In this example, we use the **selector: has(kubernetes-host)** -- so the policy is applicable to any endpoint with a **kubernetes-host** label (but you can easily specify particular nodes). - -Finally, when you specify a preDNAT field, you must also add the **applyOnForward: true** field. - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: allow-cluster-internal-ingress-only -spec: - order: 20 - preDNAT: true - applyOnForward: true - ingress: - - action: Allow - source: - nets: [1.2.3.4/16, 100.100.100.0/16] - - action: Deny - selector: has(kubernetes-host) -``` - -### Allow local host egress traffic - -We also need a global network policy to allow egress traffic through each node's external interface. Otherwise, when we define host endpoints for those interfaces, no egress traffic will be allowed from local processes (except for traffic that is allowed by the [Failsafe rules](../../reference/host-endpoints/failsafe.mdx). - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: allow-outbound-external -spec: - order: 10 - egress: - - action: Allow - selector: has(kubernetes-host) -``` - -### Create host endpoints with appropriate network policy - -In this example, we assume that you have already defined Calico host endpoints with network policy that is appropriate for the cluster. (For example, you wouldn’t want a host endpoint with a “default deny all traffic to/from this host” network policy because that is counter to the goal of allowing/denying specific traffic.) For help, see [host endpoints](../../reference/resources/hostendpoint.mdx). - -All of our previously-defined global network policies have a selector that makes them applicable to any endpoint with a **kubernetes-host label**; so we will include that label in our definitions. For example, for **eth0** on **node1**. - -```yaml -apiVersion: projectcalico.org/v3 -kind: HostEndpoint -metadata: - name: node1-eth0 - labels: - kubernetes-host: ingress -spec: - interfaceName: eth0 - node: node1 - expectedIPs: - - INSERT_IP_HERE -``` - -When creating each host endpoint, replace `INSERT_IP_HERE` with the IP address on eth0. The `expectedIPs` field is required so that any selectors within ingress or egress rules can properly match the host endpoint. - -### Allow ingress traffic to specific node ports - -Now we can allow external access to the node ports by creating a global network policy with the preDNAT field. In this example, **ingress traffic is allowed** for any host endpoint with **port: 31852**. - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: allow-nodeport -spec: - preDNAT: true - applyOnForward: true - order: 10 - ingress: - - action: Allow - protocol: TCP - destination: - selector: has(kubernetes-host) - ports: [31852] - selector: has(kubernetes-host) -``` - -To make the NodePort accessible only through particular nodes, give the nodes a particular label. For example: - -```yaml -nodeport-external-ingress: true -``` - -Then, use **nodeport-external-ingress: true** as the selector of the **allow-nodeport** policy, instead of **has(kubernetes-host)**. - -## Additional resources - -- [Global network policy](../../reference/resources/globalnetworkpolicy.mdx) -- [Host endpoints](../../reference/resources/hostendpoint.mdx) diff --git a/calico_versioned_docs/version-3.29/network-policy/services/services-cluster-ips.mdx b/calico_versioned_docs/version-3.29/network-policy/services/services-cluster-ips.mdx deleted file mode 100644 index 20f6e7d5ed..0000000000 --- a/calico_versioned_docs/version-3.29/network-policy/services/services-cluster-ips.mdx +++ /dev/null @@ -1,193 +0,0 @@ ---- -description: Expose Kubernetes service cluster IPs over BGP using Calico, and restrict who can access them using Calico network policy. ---- - -# Apply Calico policy to services exposed externally as cluster IPs - -## Big picture - -Control access to services exposed through clusterIPs that are advertised outside the cluster using BGP. - -## Value - -$[prodname] network policy uses standard Kubernetes Services that allow you to expose services within clusters to external clients in the following ways: - -- [Apply policy to Kubernetes nodeports](kubernetes-node-ports.mdx) -- Using cluster IPs over BGP (described in this article) - -## Concepts - -### Advertise cluster IPs outside the cluster - -A **cluster IP** is a virtual IP address that represents a Kubernetes Service. Kube Proxy on each host translates the clusterIP into a pod IP for one of the pods backing the service, acting as a reverse proxy and load balancer. - -Cluster IPs were originally designed for use within the Kubernetes cluster. $[prodname] allows you to advertise Cluster IPs externally -- so external clients can use them to access services hosted inside the cluster. This means that $[prodname] ingress policy can be applied at **one or both** of the following locations: - -- Host interface, when the traffic destined for the clusterIP first ingresses the cluster -- Pod interface of the backend pod - -### Traffic routing: local versus cluster modes - -$[prodname] implements [Kubernetes service external traffic policy](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip), which controls whether external traffic is routed to node-local or cluster-wide endpoints. The following table summarizes key differences between these settings. The default is **cluster mode**. - -| **Service setting** | **Traffic is load balanced...** | **Pros and cons** | **Required service type** | -| ------------------------------------------- | --------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- | -| **externalTrafficPolicy: Cluster**(default) | Across all nodes in the cluster | Equal distribution of traffic among all pods running a service.

    Possible unnecessary network hops between nodes for ingress external traffic.When packets are rerouted to pods on another node, traffic is SNAT’d (source network address translation).

    Destination pod can see the proxying node’s IP address rather than the actual client IP. | **ClusterIP** | -| **externalTrafficPolicy: Local** | Across the nodes with the endpoints for the service | Avoids extra hops so better for apps that ingress a lot external traffic.

    Traffic is not SNAT’d so actual client IPs are preserved.

    Traffic distributed among pods running a service may be imbalanced. | **LoadBalancer** (for cloud providers), or **NodePort** (for node’s static port) | - -## Before you begin... - -[Configure Calico to advertise cluster IPs over BGP](../../networking/configuring/advertise-service-ips.mdx). - -## How to - -Selecting which mode to use depends on your goals and resources. At an operational level, **local mode** simplifies policy, but load balancing may be uneven in certain scenarios. **Cluster mode** requires more work to manage clusterIPs, SNAT, and create policies that reference specific IP addresses, but you always get even load balancing. - -- [Secure externally exposed cluster IPs, local mode](#secure-externally-exposed-cluster-ips-local-mode) -- [Secure externally exposed cluster IPs, cluster mode](#secure-externally-exposed-cluster-ips-cluster-mode) - -### Secure externally exposed cluster IPs, local mode - -Using **local mode**, the original source address of external traffic is preserved, and you can define policy directly using standard $[prodname] network policy. - -1. Create $[prodname] **NetworkPolicies** or **GlobalNetworkPolicies** that select the same set of pods as your Kubernetes Service. -1. Add rules to allow the external traffic. -1. If desired, add rules to allow in-cluster traffic. - -### Secure externally exposed cluster IPs, cluster mode - -In the following steps, we define **GlobalNetworkPolicy** and **HostEndpoints**. - -#### Step 1: Verify Kubernetes Service manifest - -Ensure that your Kubernetes Service manifest explicitly lists the clusterIP; do not allow Kubernetes to automatically assign the clusterIP because you need it for your policies in the following steps. - -#### Step 2: Create global network policy at the host interface - -In this step, you create a **GlobalNetworkPolicy** that selects all **host endpoints**. It controls access to the cluster IP, and prevents unauthorized clients from outside the cluster from accessing it. The hosts then forwards only authorized traffic. - -**Set policy to allow external traffic for cluster IPs** - -Add rules to allow the external traffic for each clusterIP. The following example allows connections to two cluster IPs. Make sure you add **applyOnForward** and **preDNAT** rules. - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: allow-cluster-ips -spec: - selector: k8s-role == 'node' - types: - - Ingress - applyOnForward: true - preDNAT: true - ingress: - # Allow 50.60.0.0/16 to access Cluster IP A - - action: Allow - source: - nets: - - 50.60.0.0/16 - destination: - nets: - - 10.20.30.40/32 Cluster IP A - # Allow 70.80.90.0/24 to access Cluster IP B - - action: Allow - source: - nets: - - 70.80.90.0/24 - destination: - nets: - - 10.20.30.41/32 Cluster IP B -``` - -**Add a rule to allow traffic destined for the pod CIDR** - -Without this rule, normal pod-to-pod traffic is blocked because the policy applies to forwarded traffic. - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: allow-to-pods -spec: - selector: k8s-role == 'node' - types: - - Ingress - applyOnForward: true - preDNAT: true - ingress: - # Allow traffic forwarded to pods - - action: Allow - destination: - nets: - - 192.168.0.0/16 Pod CIDR -``` - -**Add a rule to allow traffic destined for all host endpoints** - -Or, you can add rules that allow specific host traffic including Kubernetes and $[prodname]. Without this rule, normal host traffic is blocked. - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: allow-traffic-hostendpoints -spec: - selector: k8s-role == 'node' - types: - - Ingress - # Allow traffic to the node (not nodePorts, TCP) (not nodePorts, TCP) - - action: Allow - protocol: TCP - destination: - selector: k8s-role == 'node' - notPorts: ["30000:32767"] #nodePort range - # Allow traffic to the node (not nodePorts, TCP) (not nodePorts, UDP) - - action: Allow - protocol: UDP - destination: - selector: k8s-role == 'node' - notPorts: ["30000:32767"] #nodePort range -``` - -#### Step 3: Create a global network policy that selects pods - -In this step, you create a **GlobalNetworkPolicy** that selects the **same set of pods as your Kubernetes Service**. Add rules that allow host endpoints to access the service ports. - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: allow-nodes-svc-a -spec: - selector: k8s-svc == 'svc-a' - types: - - Ingress - ingress: - - action: Allow - protocol: TCP - source: - selector: k8s-role == 'node' - destination: - ports: [80, 443] - - action: Allow - protocol: UDP - source: - selector: k8s-role == 'node' - destination: - ports: [80, 443] -``` - -#### Step 4: (Optional) Create network polices or global network policies that allow in-cluster traffic to access the service - -#### Step 5: Create HostEndpoints - -Create HostEndpoints for the interface of each host that will receive traffic for the clusterIPs. Be sure to label them so they are selected by the policy in Step 2 (Add a rule to allow traffic destined for the pod CIDR), and the rules in Step 3. - -In the previous example policies, the label **k8s-role: node** is used to identify these HostEndpoints. - -## Additional resources - -- [Enable service IP advertisement](../../networking/configuring/advertise-service-ips.mdx) -- [Defend against DoS attacks](../extreme-traffic/defend-dos-attack.mdx) -- [Global network policy](../../reference/resources/globalnetworkpolicy.mdx) diff --git a/calico_versioned_docs/version-3.29/networking/configuring/advertise-service-ips.mdx b/calico_versioned_docs/version-3.29/networking/configuring/advertise-service-ips.mdx deleted file mode 100644 index 2ab90bec24..0000000000 --- a/calico_versioned_docs/version-3.29/networking/configuring/advertise-service-ips.mdx +++ /dev/null @@ -1,247 +0,0 @@ ---- -description: Configure Calico to advertise Kubernetes service cluster IPs and external IPs outside the cluster using BGP. ---- - -# Advertise Kubernetes service IP addresses - -## Big picture - -Enable $[prodname] to advertise Kubernetes service IPs outside a cluster. $[prodname] supports advertising a service’s cluster IPs and external IPs. - -## Value - -Typically, Kubernetes service cluster IPs are accessible only within the cluster, so external access to the service requires a dedicated load balancer or ingress controller. In cases where a service’s cluster IP is not routable, the service can be accessed using its external IP. - -Just as $[prodname] supports advertising **pod IPs** over BGP, it also supports advertising Kubernetes **service IPs** outside a cluster over BGP. This avoids the need for a dedicated load balancer. This feature also supports equal cost multi-path (ECMP) load balancing across nodes in the cluster, as well as source IP address preservation for local services when you need more control. - -## Concepts - -### BGP makes it easy - -In Kubernetes, all requests for a service are redirected to an appropriate endpoint (pod) backing that service. Because $[prodname] uses BGP, external traffic can be routed directly to Kubernetes services by advertising Kubernetes service IPs into the BGP network. - -If your deployment is configured to peer with BGP routers outside the cluster, those routers (plus any other upstream places the routers propagate to) can send traffic to a Kubernetes service IP for routing to one of the available endpoints for that service. - -### Advertising service IPs: quick glance - -$[prodname] implements the Kubernetes **externalTrafficPolicy** using kube-proxy to direct incoming traffic to a correct pod. Advertisement is handled differently based on the service type that you configure for your service. - -| **Service mode** | **Cluster IP advertisement** | **Traffic is...** | Source IP address is... | -| ----------------- | ------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------- | -| Cluster (default) | All nodes in the cluster statically advertise a route to the service CIDR. | Load balanced across nodes in the cluster using ECMP, then forwarded to appropriate pod in the service using SNAT. May incur second hop to another node, but good overall load balancing. | Obscured by SNAT | -| Local | The nodes with a pod backing the service advertise a specific route (/32 or /128) to the service's IP. | Load balanced across nodes with endpoints for the service. Avoids second hop for LoadBalancer and NodePort type services, traffic may be unevenly load balanced. (Other traffic is load balanced across nodes in the cluster.) | Preserved | - -If your $[prodname] deployment is configured to peer with BGP routers outside the cluster, those routers - plus any further upstream places that those routers propagate to - will be able to send traffic to a Kubernetes service cluster IP, and that traffic is routed to one of the available endpoints for that service. - -### Tips for success - -- Generally, we recommend using “Local” for the following reasons: - - If any of your network policy uses rules to match by specific source IP addresses, using Local is the obvious choice because the source IP address is not altered, and the policy will still work. - - Return traffic is routed directly to the source IP because “Local” services do not require undoing the source NAT (unlike “Cluster” services). -- Cluster IP advertisement works best with a ToR that supports ECMP. Otherwise, all traffic for a given route is directed to a single node. - -## Before you begin... - -**Required** - -- [Configure BGP peering](bgp.mdx) between $[prodname] and your network infrastructure -- For ECMP load balancing to services, the upstream routers must be configured to use BGP multipath. -- You need at least one external node outside the cluster that acts as a router, route reflector, or ToR that is peered with calico nodes inside the cluster. -- Services must be configured with the correct service mode (“Cluster” or “Local”) for your implementation. For `externalTrafficPolicy: Local`, the service must be type `LoadBalancer` or `NodePort`. - -**Limitations** - -- OpenShift, versions 4.5 and 4.6 - There is a [bug](https://github.com/kubernetes/kubernetes/issues/91374) where the source IP is not preserved by NodePort services or traffic via a Service ExternalIP with externalTrafficPolicy:Local. - - OpenShift users on v4.5 or v4.6 can use this [workaround to avoid SNAT with ExternalIP](https://docs.openshift.com/container-platform/4.7/nodes/clusters/nodes-cluster-enabling-features.html): - - ``` - oc edit featuregates.config.openshift.io cluster - spec: - customNoUpgrade: - enabled: - - ExternalPolicyForExternalIP - ``` - - Kubernetes users on version v1.18 or v1.19 can enable source IP preservation for NodePort services using the ExternalPolicyForExternalIP feature gate. - - Source IP preservation for NodePort and services and ExternalIPs is enabled by default in OpenShift v4.7+, and Kubernetes v1.20+. - -## How to - -- [Advertise service cluster IP addresses](#advertise-service-cluster-ip-addresses) -- [Advertise service external IP addresses](#advertise-service-external-ip-addresses) -- [Advertise service load balancer IP addresses](#advertise-service-load-balancer-ip-addresses) -- [Exclude certain nodes from advertisement](#exclude-certain-nodes-from-advertisement) - -### Advertise service cluster IP addresses - -1. Determine the service cluster IP range. (Or ranges, if your cluster is [dual stack](../ipam/ipv6.mdx).) - - The range(s) for your cluster can be inferred from the `--service-cluster-ip-range` option passed to the Kubernetes API server. For help, see the [Kubernetes API server reference guide](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/). - -1. Check to see if you have a default BGPConfiguration. - - ```bash - calicoctl get bgpconfig default - ``` - -1. Based on above results, update or create a BGPConfiguration. - - **Update default BGPConfiguration** - Patch the BGPConfiguration using the following command, using your own service cluster IP CIDR in place of "10.0.0.0/24": - - ```bash - calicoctl patch bgpconfig default --patch \ - '{"spec": {"serviceClusterIPs": [{"cidr": "10.0.0.0/24"}]}}' - ``` - - **Create default BGPConfiguration** - Use the following sample command to create a default BGPConfiguration. Add your CIDR blocks, covering the cluster IPs to be advertised, in the `serviceClusterIPs` field, for example: - - ```bash - calicoctl create -f - < 100). - -For a deeper look at common on-premises deployment models, see [Calico over IP Fabrics](../../reference/architecture/design/l2-interconnect-fabric.mdx). - -## Before you begin... - -[calicoctl](../../operations/calicoctl/install.mdx) must be installed and configured. - -## How to - -:::note - -Significantly changing $[prodname]'s BGP topology, such as changing from full-mesh to peering with ToRs, may result in temporary loss of pod network connectivity during the reconfiguration process. It is recommended to only make such changes during a maintenance window. - -::: - -- [Configure a global BGP peer](#configure-a-global-bgp-peer) -- [Configure a per-node BGP peer](#configure-a-per-node-bgp-peer) -- [Configure a node to act as a route reflector](#configure-a-node-to-act-as-a-route-reflector) -- [Disable the default BGP node-to-node mesh](#disable-the-default-bgp-node-to-node-mesh) -- [Change from node-to-node mesh to route reflectors without any traffic disruption](#change-from-node-to-node-mesh-to-route-reflectors-without-any-traffic-disruption) -- [View BGP peering status for a node](#view-bgp-peering-status-for-a-node) -- [Change the default global AS number](#change-the-default-global-as-number) -- [Change AS number for a particular node](#change-as-number-for-a-particular-node) -- [Configure a BGP filter](#configure-a-bgp-filter) -- [Configure a BGP peer with a BGP filter](#configure-a-bgp-peer-with-a-bgp-filter) - -### Configure a global BGP peer - -Global BGP peers apply to all nodes in your cluster. This is useful if your network topology includes BGP speakers that will be peered with every $[prodname] node in your deployment. - -The following example creates a global BGP peer that configures every $[prodname] node to peer with **192.20.30.40** in AS **64567**. - -```yaml -apiVersion: projectcalico.org/v3 -kind: BGPPeer -metadata: - name: my-global-peer -spec: - peerIP: 192.20.30.40 - asNumber: 64567 -``` - -### Configure a per-node BGP peer - -Per-node BGP peers apply to one or more nodes in the cluster. You can choose which nodes by specifying the node’s name exactly, or using a label selector. - -The following example creates a BGPPeer that configures every $[prodname] node with the label, **rack: rack-1** to peer with **192.20.30.40** in AS **64567**. - -```yaml -apiVersion: projectcalico.org/v3 -kind: BGPPeer -metadata: - name: rack1-tor -spec: - peerIP: 192.20.30.40 - asNumber: 64567 - nodeSelector: rack == 'rack-1' -``` - -### Configure a node to act as a route reflector - -$[prodname] nodes can be configured to act as route reflectors. To do this, each node that you want to act as a route reflector must have a cluster ID - typically an unused IPv4 address. - -To configure a node to be a route reflector with cluster ID 244.0.0.1, run the following command. - - - - -```bash -kubectl annotate node my-node projectcalico.org/RouteReflectorClusterID=244.0.0.1 -``` - - - - -```bash -calicoctl patch node my-node -p '{"spec": {"bgp": {"routeReflectorClusterID": "244.0.0.1"}}}' -``` - - - - -Typically, you will want to label this node to indicate that it is a route reflector, allowing it to be easily selected by a BGPPeer resource. You can do this with kubectl. For example: - -```bash -kubectl label node my-node route-reflector=true -``` - -Now it is easy to configure route reflector nodes to peer with each other and other non-route-reflector nodes using label selectors. For example: - -```yaml -kind: BGPPeer -apiVersion: projectcalico.org/v3 -metadata: - name: peer-with-route-reflectors -spec: - nodeSelector: all() - peerSelector: route-reflector == 'true' -``` - -:::note - -Adding `routeReflectorClusterID` to a node spec will remove it from the node-to-node mesh immediately, tearing down the -existing BGP sessions. Adding the BGP peering will bring up new BGP sessions. This will cause a short (about 2 seconds) -disruption to data plane traffic of workloads running in the nodes where this happens. To avoid this, make sure no -workloads are running on the nodes, by provisioning new nodes or by running `kubectl drain` on the node (which may -itself cause a disruption as workloads are drained). - -::: - -### Disable the default BGP node-to-node mesh - -The default **node-to-node BGP mesh** may be turned off to enable other BGP topologies. To do this, modify the default **BGP configuration** resource. - -Run the following command to disable the BGP full-mesh: - -```bash -calicoctl patch bgpconfiguration default -p '{"spec": {"nodeToNodeMeshEnabled": false}}' -``` - -:::note - -If the default BGP configuration resource does not exist, you need to create it first. See [BGP configuration](../../reference/resources/bgpconfig.mdx) for more information. - -::: - -:::note - -Disabling the node-to-node mesh will break pod networking until/unless you configure replacement BGP peerings using BGPPeer resources. -You may configure the BGPPeer resources before disabling the node-to-node mesh to avoid pod networking breakage. - -::: - -### Change from node-to-node mesh to route reflectors without any traffic disruption - -Switching from node-to-node BGP mesh to BGP route reflectors involves tearing down BGP sessions and bringing up new ones. This causes a short -data plane network disruption (of about 2 seconds) for workloads running on the nodes in the cluster. To avoid this, you may provision -route reflector nodes and bring their BGP sessions up before tearing down the node-to-node mesh sessions. - -Follow these steps to do so: - -1. [Provision new nodes to be route reflectors.](#configure-a-node-to-act-as-a-route-reflector) The nodes [should not be schedulable](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) - and they should have `routeReflectorClusterID` in their spec. These won't be part of the existing - node-to-node BGP mesh, and will be the route reflectors when the mesh is disabled. These nodes should also have a label like - `route-reflector` to select them for the BGP peerings. [Alternatively](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/), - you can drain workloads from existing nodes in your cluster by running `kubectl drain ` to configure them to be route reflectors, - but this will cause a disruption on the workloads on those nodes as they are drained. - -2. Also set up a [BGPPeer](#configure-a-node-to-act-as-a-route-reflector) spec to configure route reflector nodes to peer with each other and other non-route-reflector nodes - using label selectors. - -3. Wait for these peerings to be established. This can be [verified](#view-bgp-peering-status-for-a-node) by running `sudo calicoctl node status` on the nodes. Alternatively, you can create a [`CalicoNodeStatus` resource](../../reference/resources/caliconodestatus.mdx) to get BGP session status for the node. - -4. [Disable the BGP node-to-node mesh for the cluster.](#disable-the-default-bgp-node-to-node-mesh) - -5. If you did drain workloads from the nodes or created them as unschedulable, mark the nodes as schedulable again (e.g. by running `kubectl uncordon `). - -### View BGP peering status for a node - -Create a [CalicoNodeStatus resource](../../reference/resources/caliconodestatus.mdx) to monitor BGP session status for the node. - -Alternatively, you can run the `calicoctl node status` command on a given node to learn more about its BGP status. - -:::note - -This command communicates with the local $[prodname] agent, so you must execute it on the node whose status you are attempting to view. - -::: - -### Change the default global AS number - -By default, all Calico nodes use the 64512 autonomous system, unless a per-node AS has been specified for the node. You can change the global default for all nodes by modifying the default **BGPConfiguration** resource. The following example command sets the global default AS number to **64513**. - -```bash -calicoctl patch bgpconfiguration default -p '{"spec": {"asNumber": "64513"}}' -``` - -:::note - -If the default BGP configuration resource does not exist, you need to create it first. See [BGP configuration](../../reference/resources/bgpconfig.mdx) for more information. - -::: - -### Change AS number for a particular node - -You can configure an AS for a particular node by modifying the node object using `calicoctl`. For example, the following command changes the node named **node-1** to belong to **AS 64514**. - -```bash -calicoctl patch node node-1 -p '{"spec": {"bgp": {"asNumber": "64514"}}}' -``` - -### Configure a BGP filter - -BGP filters control which routes are imported and exported between BGP peers. - -The BGP filter rules (importVX, exportVX) are applied sequentially, taking the -`action` of the first matching rule. When no rules are matched, the default -`action` is `Accept`. - -In order for a BGPFilter to be used in a BGP peering, its `name` -must be added to `filters` of the corresponding BGPPeer resource. - -The following example creates a BGPFilter - -```yaml -apiVersion: projectcalico.org/v3 -kind: BGPFilter -metadata: - name: my-filter -spec: - exportV4: - - action: Accept - matchOperator: In - cidr: 77.0.0.0/16 - - action: Reject - source: RemotePeers - - action: Reject - interface: '*.calico' - importV4: - - action: Reject - matchOperator: NotIn - cidr: 44.0.0.0/16 - exportV6: - - action: Reject - source: RemotePeers - - action: Reject - interface: '*.calico' - importV6: - - action: Accept - matchOperator: Equal - cidr: 5000::0/64 - - action: Reject -``` - -### Configure a BGP peer with a BGP filter - -BGP peers can use BGP filters to control which routes are imported or exported between them. - -The following example creates a BGPFilter and associates it with a BGPPeer -:::note - -BGPFilters are applied in the order listed on a BGPPeer - -::: - -```yaml -kind: BGPFilter -apiVersion: projectcalico.org/v3 -metadata: - name: first-bgp-filter -spec: - exportV4: - - action: Accept - matchOperator: In - cidr: 77.0.0.0/16 - source: RemotePeers - importV4: - - action: Reject - matchOperator: NotIn - cidr: 44.0.0.0/16 - exportV6: - - action: Reject - interface: '*.calico' - importV6: - - action: Accept - matchOperator: Equal - cidr: 5000::0/64 ---- -kind: BGPFilter -apiVersion: projectcalico.org/v3 -metadata: - name: second-bgp-filter -spec: - exportV4: - - action: Accept - matchOperator: In - cidr: 77.0.0.0/16 - interface: '*.calico' - importV4: - - action: Reject - matchOperator: NotIn - cidr: 44.0.0.0/16 - exportV6: - - action: Reject - source: RemotePeers - importV6: - - action: Reject ---- -kind: BGPPeer -apiVersion: projectcalico.org/v3 -metadata: - name: peer-with-filter -spec: - peerSelector: has(filter-bgp) - filters: - - first-bgp-filter - - second-bgp-filter -``` - -## Additional resources - -- [Node resource](../../reference/resources/node.mdx) -- [BGP configuration resource](../../reference/resources/bgpconfig.mdx) -- [BGP peer resource](../../reference/resources/bgppeer.mdx) -- [BGP filter resource](../../reference/resources/bgpfilter.mdx) diff --git a/calico_versioned_docs/version-3.29/networking/configuring/index.mdx b/calico_versioned_docs/version-3.29/networking/configuring/index.mdx deleted file mode 100644 index d37320632e..0000000000 --- a/calico_versioned_docs/version-3.29/networking/configuring/index.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: Configure Calico networking options, including overlay, non-overlay, BGP, service advertisement, MTU, NAT, and using kube-proxy in IPVS mode. -hide_table_of_contents: true ---- - -# Configure Networking - -import DocCardList from '@theme/DocCardList'; -import { useCurrentSidebarCategory } from '@docusaurus/theme-common'; - - diff --git a/calico_versioned_docs/version-3.29/networking/configuring/mtu.mdx b/calico_versioned_docs/version-3.29/networking/configuring/mtu.mdx deleted file mode 100644 index 0e9499a05a..0000000000 --- a/calico_versioned_docs/version-3.29/networking/configuring/mtu.mdx +++ /dev/null @@ -1,142 +0,0 @@ ---- -description: Optimize network performance for workloads by configuring the MTU in Calico to best suit your underlying network. ---- - -# Configure MTU to maximize network performance - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - -## Big picture - -Configure the maximum transmission unit (MTU) for your $[prodname] environment. - -## Value - -Optimize network performance for workloads by configuring the MTU in $[prodname] to best suit your underlying network. - -Increasing the MTU can improve performance, and decreasing the MTU can resolve packet loss and fragmentation problems when it is too high. - -## Concepts - -### MTU and $[prodname] defaults - -The maximum transmission unit (MTU) setting determines the largest packet size that can be transmitted through your network. MTU is configured on the veth attached to each workload, and tunnel devices (if you enable IP in IP, VXLAN, or WireGuard). - -In general, maximum performance is achieved by using the highest MTU value that does not cause fragmentation or dropped packets on the path. Maximum bandwidth increases and CPU consumption may drop for a given traffic rate. The improvement is often more significant when pod to pod traffic is being encapsulated (IP in IP, VXLAN, or WireGuard), and splitting and combining such traffic cannot be offloaded to your NICs. - -By default, $[prodname] will auto-detect the correct MTU for your cluster based on node configuration and enabled networking modes. This guide explains how you can override auto-detection -of MTU by providing an explicit value if needed. - -To ensure auto-detection of MTU works correctly, make sure that the correct encapsulation modes are set in your [felix configuration](../../reference/resources/felixconfig.mdx). Disable any unused encapsulations (`vxlanEnabled`, `ipipEnabled`, `wireguardEnabled` and `wireguardEnabledV6`) in your felix configuration to ensure that auto-detection can pick the optimal MTU for your cluster. - -## Before you begin... - -For help on using IP in IP and/or VXLAN overlays, see [Configure overlay networking](vxlan-ipip.mdx). - -For help on using WireGuard encryption, see [Configure WireGuard encryption](../../network-policy/encrypt-cluster-pod-traffic.mdx). - -## How to - -- [Determine MTU size](#determine-mtu-size) -- [Configure MTU](#configure-mtu) -- [View current tunnel MTU values](#view-current-tunnel-mtu-values) - -### Determine MTU size - -The following table lists common MTU sizes for $[prodname] environments. Because MTU is a global property of the network path between endpoints, you should set the MTU to the minimum MTU of any path that packets may take. - -**Common MTU sizes** - -| Network MTU | $[prodname] MTU | $[prodname] MTU with IP-in-IP (IPv4) | $[prodname] MTU with VXLAN (IPv4) | $[prodname] MTU with VXLAN (IPv6) | $[prodname] MTU with WireGuard (IPv4) | $[prodname] MTU with WireGuard (IPv6) | -| ---------------------- | ---------------- | ------------------------------------- | ---------------------------------- | ---------------------------------- | -------------------------------------- | -------------------------------------- | -| 1500 | 1500 | 1480 | 1450 | 1430 | 1440 | 1420 | -| 9000 | 9000 | 8980 | 8950 | 8930 | 8940 | 8920 | -| 1500 (AKS) | 1500 | 1480 | 1450 | 1430 | 1340 | 1320 | -| 1460 (GCE) | 1460 | 1440 | 1410 | 1390 | 1400 | 1380 | -| 9001 (AWS Jumbo) | 9001 | 8981 | 8951 | 8931 | 8941 | 8921 | -| 1450 (OpenStack VXLAN) | 1450 | 1430 | 1400 | 1380 | 1390 | 1370 | - -**Recommended MTU for overlay networking** - -The extra overlay header used in IP in IP, VXLAN and WireGuard protocols, reduces the minimum MTU by the size of the header. (IP in IP uses a 20-byte header, IPv4 VXLAN uses a 50-byte header, IPv6 VXLAN uses a 70-byte header, IPv4 WireGuard uses a 60-byte header and IPv6 WireGuard uses an 80-byte header). - -When using AKS, the underlying network has an [MTU of 1400](https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-tcpip-performance-tuning#azure-and-vm-mtu), even though the network interface will have an MTU of 1500. -WireGuard sets the Don't Fragment (DF) bit on its packets, and so the MTU for WireGuard on AKS needs to be set to 60 bytes below (or 80 bytes for IPv6) the 1400 MTU of the underlying network to avoid dropped packets. - -If you have a mix of WireGuard and either IP in IP or VXLAN in your cluster, you should configure the MTU to be the smallest of the values of each encap type. The reason for this is that only WireGuard encapsulation will be used between any nodes where both have WireGuard enabled, and IP in IP or VXLAN will then be used between any nodes where both do not have WireGuard enabled. This could be the case if, for example, you are in the process of installing WireGuard on your nodes. - -Therefore, we recommend the following: - -- If you use IPv4 WireGuard encryption anywhere in your pod network, configure MTU size as “physical network MTU size minus 60”. -- If you use IPv6 WireGuard encryption anywhere in your pod network, configure MTU size as “physical network MTU size minus 80”. -- If you don't use WireGuard, but use IPv4 VXLAN anywhere in your pod network, configure MTU size as “physical network MTU size minus 50”. -- If you don't use WireGuard, but use IPv6 VXLAN anywhere in your pod network, configure MTU size as “physical network MTU size minus 70”. -- If you don't use WireGuard, but use only IP in IP, configure MTU size as “physical network MTU size minus 20” -- Set the workload endpoint MTU and the tunnel MTUs to the same value (so all paths have the same MTU) - -**eBPF mode** - -Implementation of NodePorts uses VXLAN tunnel to hand off packets from one node to another, therefore VXLAN MTU setting -is used to set the MTUs of workloads (veths) and should be “physical network MTU size minus 50” (see above). - -**MTU for flannel networking** - -When using flannel for networking, the MTU for network interfaces should match the MTU of the flannel interface. - -- If using flannel with VXLAN, use the “$[prodname] MTU with VXLAN” column in the table above for common sizes. - -### Configure MTU - -:::note - -The updated MTU used by $[prodname] only applies to new workloads. - -::: - -Instructions for configuring MTU vary based on install method. - - - - -For Operator installations, edit the $[prodname] operator `Installation` resource to set the `mtu` -field in the `calicoNetwork` section of the `spec`. For example: - -```bash -kubectl patch installation.operator.tigera.io default --type merge -p '{"spec":{"calicoNetwork":{"mtu":1440}}}' -``` - -Similarly, for OpenShift: - -```bash -oc patch installation.operator.tigera.io default --type merge -p '{"spec":{"calicoNetwork":{"mtu":1440}}}' -``` - - - - -For manifest based installations (i.e. ones that do not use the operator) edit the `calico-config` ConfigMap. For example: - -```bash -kubectl patch configmap/calico-config -n kube-system --type merge \ - -p '{"data":{"veth_mtu": "1440"}}' -``` - -After updating the ConfigMap, perform a rolling restart of all calico/node pods. For example: - -```bash -kubectl rollout restart daemonset calico-node -n kube-system -``` - - - - -### View current tunnel MTU values - -To view the current tunnel size, use the following command: - -`ip link show` - -The IP in IP tunnel appears as tunlx (for example, tunl0), along with the MTU size. For example: - -![Tunnel MTU](/img/calico/tunnel.png) diff --git a/calico_versioned_docs/version-3.29/networking/configuring/node-local-dns-cache.mdx b/calico_versioned_docs/version-3.29/networking/configuring/node-local-dns-cache.mdx deleted file mode 100644 index 9a3999d64f..0000000000 --- a/calico_versioned_docs/version-3.29/networking/configuring/node-local-dns-cache.mdx +++ /dev/null @@ -1,69 +0,0 @@ ---- -description: Install NodeLocal DNSCache ---- - -# Use NodeLocal DNSCache in your cluster - -## Big picture - -Set up NodeLocal DNSCache to improve DNS lookup latency. - -## Before you begin - -### Required - -Follow these [steps](https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/) to enable NodeLocal DNSCache connectivity. - -### Unsupported - -- OpenShift - -NodeLocal DNSCache does not support OpenShift. OpenShift has its own DNS caching mechanism which deploys CoreDNS pods as DaemonSets. -For more information, see [OpenShift DNS setup](https://docs.openshift.com/container-platform/4.10/networking/dns-operator.html). - -## Create a policy to allow traffic from NodeLocal DNSCache - -The following is a sample network policy that allows all incoming TCP traffic (including incoming traffic from -`node-local-dns` pods) on port 53 on `kube-dns`. - -```yaml -apiVersion: projectcalico.org/v3 -kind: NetworkPolicy -metadata: - name: default.local-dns-to-core-dns - namespace: kube-system -spec: - tier: default - selector: k8s-app == "kube-dns" - ingress: - - action: Allow - protocol: TCP - destination: - selector: k8s-app == "kube-dns" - ports: - - '53' - types: - - Ingress -``` - -To refine the sources permitted by this policy, take into account that NodeLocal DNSCache pods are host networked, -and make sure to allow traffic from the addresses of your hosts. -If you're using encapsulation, you will need to allow connectivity from the tunnel IPs. - -The Tigera Operator creates policy to allow Tigera components to connect to NodeLocal DNSCache when detected. -Felix accounts for the NodeLocal DNSCache in creating DNS Logs and enforcing DNS Policy. - -## Enable NodeLocal DNSCache on $[prodname] using the eBPF data plane - -If your $[prodname] installation uses the eBPF data plane, then you need to annotate the `kube-dns` service. -Without this, the `kube-proxy` replacement will improperly resolve traffic going to a specific service IP. - -Annotate the `kube-dns` service by running the following command: - -```bash -kubectl annotate service kube-dns -n kube-system projectcalico.org/natExcludeService=true -``` - -## Additional resources - -- [Blog: Optimizing Kubernetes DNS with NodeLocal DNSCache and Calico eBPF: A Practitioner’s Guide](https://www.tigera.io/blog/optimizing-kubernetes-dns-with-nodelocal-dnscache-and-calico-ebpf-a-practitioners-guide/) diff --git a/calico_versioned_docs/version-3.29/networking/configuring/pod-mac-address.mdx b/calico_versioned_docs/version-3.29/networking/configuring/pod-mac-address.mdx deleted file mode 100644 index eafb428d66..0000000000 --- a/calico_versioned_docs/version-3.29/networking/configuring/pod-mac-address.mdx +++ /dev/null @@ -1,35 +0,0 @@ ---- -description: Specify the MAC address for a pod instead of allowing the operating system to assign one ---- - -# Use a specific MAC address for a pod - -## Big picture - -Choose the MAC address for a pod instead of allowing the operating system to assign one. - -## Value - -Some applications bind software licenses to networking interface MAC addresses. - -## Concepts - -### Container MAC address - -The MAC address configured by the annotation described here will be visible from within the container on the eth0 interface. Since it is isolated to the container it will not collide with any other MAC addresses assigned to other pods on the same node. - -## Before you begin... - -Your cluster must be using Calico CNI to use this feature. - -[Configuring the Calico CNI Plugins](../../reference/configure-cni-plugins.mdx) - -## How to - -Annotate the pod with cni.projectcalico.org/hwAddr set to the desired MAC address. For example: - -``` - "cni.projectcalico.org/hwAddr": "1c:0c:0a:c0:ff:ee" -``` - -The annotation must be present when the pod is created; adding it later has no effect. diff --git a/calico_versioned_docs/version-3.29/networking/configuring/sidecar-acceleration.mdx b/calico_versioned_docs/version-3.29/networking/configuring/sidecar-acceleration.mdx deleted file mode 100644 index cfcb69775c..0000000000 --- a/calico_versioned_docs/version-3.29/networking/configuring/sidecar-acceleration.mdx +++ /dev/null @@ -1,72 +0,0 @@ ---- -description: Use Calico to accelerate network performance of traffic through the Istio Envoy sidecar using eBPF. ---- - -# Accelerate Istio network performance - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - -## Big picture - -Use Calico to accelerate network performance of routing network traffic via Istio Envoy sidecar. - -:::caution - -This feature is experimental and should not be used in production clusters. It uses a recent Linux kernel feature (eBPF SOCKMAP), which our testing confirms requires upstream kernel enhancements to reliably and securely support production clusters. We are contributing fixes to the kernel where needed. - -::: - -## Value - -Istio directs all application network traffic through an Envoy sidecar in each pod, which introduces network overhead for all traffic. Calico can greatly reduce this network overhead by automatically optimizing the Linux network path for this traffic. - -## Concepts - -### Sidecar acceleration - -The Sidecar acceleration process bypasses several layers of kernel networking, allowing data to flow between the sockets unobstructed. This makes the Envoy proxy (sidecar) to container network path as fast and efficient as possible. - -## Before you begin... - -- [Enable application layer policy](../../network-policy/istio/app-layer-policy.mdx) -- Verify that hosts installed with Calico are using Linux kernel 4.19 and above - -### Sidecar acceleration: experimental technology - -The sidecar app acceleration feature is disabled by default in Calico because the technology is currently not production ready. Use only in test environments until the technology is hardened for production security. - -## How to - -To enable sidecar acceleration for Istio-enabled apps using Calico: - - - - -```bash -kubectl patch felixconfiguration default --type merge --patch '{"spec":{"sidecarAccelerationEnabled": true}}' -``` - -You should see an output like below: - -``` -felixconfiguration.projectcalico.org/default patched -``` - - - - -```bash -calicoctl patch felixconfiguration default --patch '{"spec":{"sidecarAccelerationEnabled": true}}' -``` - -You should see an output like below: - -``` -Successfully patched 1 'FelixConfiguration' resource -``` - - - - -That’s it! Network traffic that is routed between apps and the Envoy sidecar is automatically accelerated at this point. Note that if you have an existing Istio/Calico implementation and you enable sidecar acceleration, existing connections do not benefit from acceleration. diff --git a/calico_versioned_docs/version-3.29/networking/configuring/use-ipvs.mdx b/calico_versioned_docs/version-3.29/networking/configuring/use-ipvs.mdx deleted file mode 100644 index 3a7f468993..0000000000 --- a/calico_versioned_docs/version-3.29/networking/configuring/use-ipvs.mdx +++ /dev/null @@ -1,55 +0,0 @@ ---- -description: Use IPVS kube-proxy for performance improvements. ---- - -# Use IPVS kube-proxy - -## Big picture - -Use IPVS kube-proxy mode for load balancing traffic across pods. - -## Value - -No matter where you are on your journey with container networking, iptables will serve you well. However, if you are scaling above 1,000 services, it’s worth looking at potential performance improvements using kube-proxy IPVS mode. - -## Concepts - -### Kubernetes kube-proxy - -Kube-proxy process handles everything related to Services on each node. It ensures that connections to the service cluster IP and port go to a pod that backs the service. If backed by more than one pod, kube-proxy load-balances traffic across pods. - -Kube-proxy runs in three modes: **userspace**, **iptables**, and **ipvs**. (Userspace is old, slow and not recommended.) Here’s a quick summary of iptables and ipvs modes. - -| **kube-proxy mode** | **Designed to be...** | **Linux kernel hooks** | **Connection processing overhead...** | -| ------------------- | ---------------------------------------------------------------------------------------------------------- | -------------------------------------- | ------------------------------------------- | -| iptables | An efficient firewall | NAT pre-routing using sequential rules | Grows proportional to cluster size | -| ipvs | A load balancer with scheduling options like round-robin, shortest-expected delay, least connections, etc. | Optimized lookup routine | Stays constant, independent of cluster size | - -If you are wondering about the performance differences between iptables and ipvs, the answers are definitely not straightforward. For a comparison between iptables (including $[prodname]’s own use of iptables) and ipvs modes, see [Comparing kube-proxy modes: iptables or IPVS?](https://www.projectcalico.org/comparing-kube-proxy-modes-iptables-or-ipvs/). - -### IPVS mode and NodePort ranges - -Kube-proxy IPVS mode supports NodePort services and cluster IPs. $[prodname] also uses NodePorts for routing traffic to the cluster, including the same default Kubernetes NodePort range (30000:32767). If you change your default NodePort range in Kubernetes, you must also change it on $[prodname] to maintain ipvs coverage. - -### iptables: when to change mark bits - -To police traffic in IPVS mode, $[prodname] uses additional iptables mark bits to store an ID for each local $[prodname] endpoint. If you are planning to run more than 1,022 pods per host with IPVS enabled, you may need to adjust the mark bit size using the `IptablesMarkMask` parameter in $[prodname] [FelixConfiguration](../../reference/felix/configuration.mdx). - -### $[prodname] auto detects ipvs mode - -When $[prodname] detects that kube-proxy is running in IPVS mode (during or after installation), IPVS support is automatically activated. Detection happens when calico-node starts up, so if you change kube-proxy's mode in a running cluster, you will need to restart your calico-node instances. - -## Before you begin... - -**Required** - -- kube-proxy is configured to use IPVS mode -- Services for ipvs mode are type, NodePort - -## How to - -As previously discussed, there is nothing you need to do in $[prodname] to use IPVS mode; if enabled, the mode is automatically detected. However, if your default Kubernetes NodePort range changes, use the following instructions to update $[prodname] nodeport ranges to stay in sync. Detection happens when calico-node starts up, so if you change kube-proxy's mode in a running cluster, you will need to restart your calico-node instances. - -### Change $[prodname] default nodeport range - -In the FelixConfiguration resource, change the configuration parameter for the default node port range (`KubeNodePortRange`,) in $[prodname] to match your new default range in Kubernetes. For help, see [FelixConfiguration](../../reference/felix/configuration.mdx). diff --git a/calico_versioned_docs/version-3.29/networking/configuring/vxlan-ipip.mdx b/calico_versioned_docs/version-3.29/networking/configuring/vxlan-ipip.mdx deleted file mode 100644 index 3b2c336339..0000000000 --- a/calico_versioned_docs/version-3.29/networking/configuring/vxlan-ipip.mdx +++ /dev/null @@ -1,156 +0,0 @@ ---- -description: Configure Calico to use IP in IP or VXLAN overlay networking so the underlying network doesn’t need to understand pod addresses. ---- - -# Overlay networking - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - -## Big picture - -Enable inter workload communication across networks that are not aware of workload IPs. - -## Value - -In general, we recommend running Calico without network overlay/encapsulation. This gives you the highest performance and simplest network; the packet that leaves your workload is the packet that goes on the wire. - -However, selectively using overlays/encapsulation can be useful when running on top of an underlying network that cannot easily be made aware of workload IPs. A common example is if you are using Calico networking in AWS across multiple VPCs/subnets. In this case, Calico can selectively encapsulate only the traffic that is routed between the VPCs/subnets, and run without encapsulation within each VPC/subnet. You might also decide to run your entire Calico network with encapsulation as an overlay network -- as a quick way to get started without setting up BGP peering or other routing information in your underlying network. - -## Concepts - -### Routing workload IP addresses - -Networks become aware of workload IP addresses through layer 3 routing techniques like static routes or BGP route distribution, or layer 2 address learning. As such, they can route unencapsulated traffic to the right host for the endpoint that is the ultimate destination. However, not all networks are able to route workload IP addresses. For example, public cloud environments where you don’t own the hardware, AWS across VPC subnet boundaries, and other scenarios where you cannot peer Calico over BGP to the underlay, or easily configure static routes. This is why Calico supports encapsulation, so you can send traffic between workloads without requiring the underlying network to be aware of workload IP addresses. - -### Encapsulation types - -Calico supports two types of encapsulation: VXLAN and IP in IP. VXLAN is supported in some environments where IP in IP is not (for example, Azure). VXLAN has a slightly higher per-packet overhead because the header is larger, but unless you are running very network intensive workloads the difference is not something you would typically notice. The other small difference between the two types of encapsulation is that Calico's VXLAN implementation does not use BGP, whereas Calico's IP in IP implementation uses BGP between Calico nodes. - -### Cross-subnet - -Encapsulation of workload traffic is typically required only when traffic crosses a router that is unable to route workload IP addresses on its own. Calico can perform encapsulation on: all traffic, no traffic, or only on traffic that crosses a subnet boundary. - -## Before you begin - -**Not supported** - -- Calico for OpenStack (i.e. when Calico is used as the Neutron plugin) - -**Limitations** - -- IP in IP supports only IPv4 addresses -- VXLAN in IPv6 is only supported for kernel versions ≥ 4.19.1 or redhat kernel version ≥ 4.18.0 - -## How to - -- [Configure default IP pools at install time](#configure-default-ip-pools-at-install-time) -- [Configure IP in IP encapsulation for only cross-subnet traffic](#configure-ip-in-ip-encapsulation-for-only-cross-subnet-traffic) -- [Configure IP in IP encapsulation for all inter workload traffic](#configure-ip-in-ip-encapsulation-for-all-inter-workload-traffic) -- [Configure VXLAN encapsulation for only cross-subnet traffic](#configure-vxlan-encapsulation-for-only-cross-subnet-traffic) -- [Configure VXLAN encapsulation for all inter workload traffic](#configure-vxlan-encapsulation-for-all-inter-workload-traffic) - -### Best practice - -Calico has an option to selectively encapsulate only traffic that crosses subnet boundaries. We recommend using the **cross-subnet** option with IP in IP or VXLAN to minimize encapsulation overhead. Cross-subnet mode provides better performance in AWS multi-AZ deployments, Azure VNets, and on networks where routers are used to connect pools of nodes with L2 connectivity. - -Be aware that switching encapsulation modes can cause disruption to in-progress connections. Plan accordingly. - -### Configure default IP pools at install time - -Default IP pools are configured at install-time automatically by Calico. You can configure these default IP pools based on install method. - - - - -For operator managed clusters, you can configure encapsulation in the IP pools section of the default Installation. For example, the following installation snippet will enable VXLAN across subnets. - -```yaml -kind: Installation -apiVersion: operator.tigera.io/v1 -metadata: - name: default -spec: - calicoNetwork: - ipPools: - - cidr: 192.168.0.0/16 - encapsulation: VXLANCrossSubnet -``` - - - - -For manifest installations of Calico, you can control the default IP pool encapsulation mode using the `CALICO_IPV4POOL_VXLAN` and `CALICO_IPV4POOL_IPIP` (and `CALICO_IPV6POOL_VXLAN` for IPv6) environment variables in the environment of the `calico-node` daemon set. - - - - -### Configure IP in IP encapsulation for only cross-subnet traffic - -IP in IP encapsulation can be performed selectively, and only for traffic crossing subnet boundaries. - -To enable this feature, set `ipipMode` to `CrossSubnet`. - -```yaml -apiVersion: projectcalico.org/v3 -kind: IPPool -metadata: - name: ippool-ipip-cross-subnet-1 -spec: - cidr: 192.168.0.0/16 - ipipMode: CrossSubnet - natOutgoing: true -``` - -### Configure IP in IP encapsulation for all inter workload traffic - -With `ipipMode` set to `Always`, Calico routes traffic using IP in IP for all traffic originating from a Calico enabled-host, to all Calico networked containers and VMs within the IP pool. - -```yaml -apiVersion: projectcalico.org/v3 -kind: IPPool -metadata: - name: ippool-ipip-1 -spec: - cidr: 192.168.0.0/16 - ipipMode: Always - natOutgoing: true -``` - -### Configure VXLAN encapsulation for only cross subnet traffic - -VXLAN encapsulation can be performed selectively, and only for traffic crossing subnet boundaries. - -To enable this feature, set `vxlanMode` to `CrossSubnet`. - -```yaml -apiVersion: projectcalico.org/v3 -kind: IPPool -metadata: - name: ippool-vxlan-cross-subnet-1 -spec: - cidr: 192.168.0.0/16 - vxlanMode: CrossSubnet - natOutgoing: true -``` - -### Configure VXLAN encapsulation for all inter workload traffic - -With `vxlanMode` set to `Always`, Calico routes traffic using VXLAN for all traffic originating from a Calico enabled host, to all Calico networked containers and VMs within the IP pool. - -```yaml -apiVersion: projectcalico.org/v3 -kind: IPPool -metadata: - name: ippool-vxlan-1 -spec: - cidr: 192.168.0.0/16 - vxlanMode: Always - natOutgoing: true -``` - -If you use only VXLAN pools, BGP networking is not required. You can disable BGP to reduce the moving parts in your cluster by [Customizing the manifests](../../getting-started/kubernetes/self-managed-onprem/config-options.mdx). Set the `calico_backend` setting to `vxlan`, and disable the BGP readiness check. - -## Additional resources - -For details on IP pool resource options, see [IP pool](../../reference/resources/ippool.mdx). diff --git a/calico_versioned_docs/version-3.29/networking/configuring/workloads-outside-cluster.mdx b/calico_versioned_docs/version-3.29/networking/configuring/workloads-outside-cluster.mdx deleted file mode 100644 index 2436b22c16..0000000000 --- a/calico_versioned_docs/version-3.29/networking/configuring/workloads-outside-cluster.mdx +++ /dev/null @@ -1,64 +0,0 @@ ---- -description: Configure networking to perform outbound NAT for connections from pods to outside of the cluster. ---- - -# Configure outgoing NAT - -## Big picture - -Configure $[prodname] networking to perform outbound NAT for connections from pods to outside of the cluster. $[prodname] optionally source NATs the pod IP to the node IP. - -## Value - -The $[prodname] NAT outbound connection option is flexible; it can be enabled, disabled, and applied to $[prodname] IP pools with public IPs, private IPs, or a specific range of IP addresses. This article describes some use cases for enabling and disabling outgoing NAT. - -## Concepts - -### $[prodname] IP pools and NAT - -When a pod with an IP address in the pool initiates a network connection to an IP address to outside of $[prodname]’s IP pools, the outgoing packets will have their source IP address changed from the pod IP address to the node IP address using SNAT (Source Network Address Translation). Any return packets on the connection automatically get this change reversed before being passed back to the pod. - -### Enable NAT: for pods with IP addresses that are not routable beyond the cluster - -A common use case for enabling NAT outgoing, is to allow pods in an overlay network to connect to IP addresses outside of the overlay, or pods with private IP addresses to connect to public IP addresses outside the cluster/the internet (subject to network policy allowing the connection, of course). When NAT is enabled, traffic is NATed from pods in that pool to any destination outside of all other $[prodname] IP pools. - -### Disable NAT: For on-premises deployments using physical infrastructure - -If you choose to implement $[prodname] networking with [BGP peered with your physical network infrastructure](bgp.mdx), you can use your own infrastructure to NAT traffic from pods to the internet. In this case, you should disable the $[prodname] `natOutgoing` option. For example, if you want your pods to have public internet IPs, you should: - -- Configure $[prodname] to peer with your physical network infrastructure -- Create an IP pool with public IP addresses for those pods that are routed to your network with NAT disabled (`natOutgoing: false`) -- Verify that other network equipment does not NAT the pod traffic - -## How to - -- [Create an IP pool with NAT outgoing enabled](#create-an-ip-pool-with-nat-outgoing-enabled) -- [Use additional IP pools to specify addresses that can be reached without NAT](#use-additional-ip-pools-to-specify-addresses-that-can-be-reached-without-nat) - -### Create an IP pool with NAT outgoing enabled - -In the following example, we create a $[prodname] IPPool with natOutgoing enabled. Outbound NAT is performed locally on the node where each workload in the pool is hosted. - -```yaml -apiVersion: projectcalico.org/v3 -kind: IPPool -metadata: - name: default-ipv4-ippool -spec: - cidr: 192.168.0.0/16 - natOutgoing: true -``` - -### Use additional IP pools to specify addresses that can be reached without NAT - -Because $[prodname] performs outgoing NAT only when connecting to an IP address that is not in a $[prodname] IPPool, you can create additional IPPools that are not used for pod IP addresses, but prevent NAT to certain CIDR blocks. This is useful if you want nodes to NAT traffic to the internet, but not to IPs in certain internal ranges. For example, if you did not want to NAT traffic from pods to 10.0.0.0/8, you could create the following pool. You must ensure that the network between the cluster and 10.0.0.0/8 can route pod IPs. - -```yaml -apiVersion: projectcalico.org/v3 -kind: IPPool -metadata: - name: no-nat-10.0.0.0-8 -spec: - cidr: 10.0.0.0/8 - disabled: true -``` diff --git a/calico_versioned_docs/version-3.29/networking/determine-best-networking.mdx b/calico_versioned_docs/version-3.29/networking/determine-best-networking.mdx deleted file mode 100644 index 9d9c1365c8..0000000000 --- a/calico_versioned_docs/version-3.29/networking/determine-best-networking.mdx +++ /dev/null @@ -1,289 +0,0 @@ ---- -description: Learn about the different networking options Calico supports so you can choose the best option for your needs. ---- - -# Determine best networking option - -## Big picture - -Learn about the different networking options $[prodname] supports so you can choose the best option for your needs. - -## Value - -$[prodname]’s flexible modular architecture supports a wide range of deployment options, so you can select the best networking approach for your specific environment and needs. This includes the ability to run with a variety of CNI and IPAM plugins, and underlying network types, in non-overlay or overlay modes, with or without BGP. - -## Concepts - -If you want to fully understand the network choices available to you, we recommend you make sure you are familiar with and understand the following concepts. If you would prefer to skip the learning and get straight to the choices and recommendations, you can jump ahead to [Networking Options](#networking-options). - -### Kubernetes networking basics - -The Kubernetes network model defines a “flat” network in which: - -- Every pod get its own IP address. -- Pods on any node can communicate with all pods on all other nodes without NAT. - -This creates a clean, backwards-compatible model where pods can be treated much like VMs or physical hosts from the perspectives of port allocation, naming, service discovery, load balancing, application configuration, and migration. Network segmentation can be defined using network policies to restrict traffic within these base networking capabilities. - -Within this model there’s quite a lot of flexibility for supporting different networking approaches and environments. The details of exactly how the network is implemented depend on the combination of CNI, network, and cloud provider plugins being used. - -### CNI plugins - -CNI (Container Network Interface) is a standard API which allows different network implementations to plug into Kubernetes. Kubernetes calls the API any time a pod is being created or destroyed. There are two types of CNI plugins: - -- CNI network plugins: responsible for adding or deleting pods to/from the Kubernetes pod network. This includes creating/deleting each pod’s network interface and connecting/disconnecting it to the rest of the network implementation. -- CNI IPAM plugins: responsible for allocating and releasing IP addresses for pods as they are created or deleted. Depending on the plugin, this may include allocating one or more ranges of IP addresses (CIDRs) to each node, or obtaining IP addresses from an underlying public cloud’s network to allocate to pods. - -### Cloud provider integrations - -Kubernetes cloud provider integrations are cloud-specific controllers that can configure the underlying cloud network to help provide Kubernetes networking. Depending on the cloud provider, this could include automatically programming routes into the underlying cloud network so it knows natively how to route pod traffic. - -### kubenet - -kubenet is an extremely basic network plugin built into Kubernetes. It does not implement cross-node networking or network policy. It is typically used together with a cloud provider integration that sets up routes in the cloud provider network for communication between nodes, or in single node environments. kubenet is not compatible with $[prodname]. - -### Overlay networks - -An overlay network is a network that is layered on top of another network. In the context of Kubernetes, an overlay network can be used to handle pod-to-pod traffic between nodes on top of an underlying network that is not aware of pod IP addresses or which pods are running on which nodes. Overlay networks work by encapsulating network packets that an underlying network doesn’t know how to handle (for example using pod IP addresses) within an outer packet which the underlying network does know how to handle (for example node IP addresses). Two common network protocols used for encapsulation are VXLAN and IP-in-IP. - -The main advantage of using an overlay network is that it reduces dependencies on the underlying network. For example, you can run a VXLAN overlay on top of almost any underlying network, without needing to integrate with or make any changes to the underlying network. - -The main disadvantages of using an overlay network are: - -- A slight performance impact. The process of encapsulating packets takes a small amount of CPU, and the extra bytes required in the packet to encode the encapsulation (VXLAN or IP-in-IP headers) reduces the maximum size of inner packet that can be sent, which in turn can mean needing to send more packets for the same amount of total data. -- The pod IP addresses are not routable outside of the cluster. More on this below! - -### Cross-subnet overlays - -In addition to standard VXLAN or IP-in-IP overlays, $[prodname] also supports “cross-subnet” modes for VXLAN and IP-in-IP. In this mode, within each subnet, the underlying network acts as an L2 network. Packets sent within a single subnet are not encapsulated, so you get the performance of a non-overlay network. Packets sent across subnets are encapsulated, like a normal overlay network, reducing dependencies on the underlying network (without the need to integrate with or make any changes to the underlying network). - -Just like with a standard overlay network, the underlying network is not aware of pod IP addresses and the pod IP addresses are not routable outside of the cluster. - -### Pod IP routability outside of the cluster - -An important distinguishing feature of different Kubernetes network implementations is whether or not pod IP addresses are routable outside of the cluster across the broader network. - -**Not routable** - -If the pod IP addresses are not routable outside of the cluster then when a pod tries to establish a network connection to an IP address that is outside of the cluster, Kubernetes uses a technique called SNAT (Source Network Address Translation) to change the source IP address from the IP address of the pod, to the IP address of the node hosting the pod. Any return packets on the connection get automatically mapped back to the pod IP address. So the pod is unaware the SNAT is happening, the destination for the connection sees the node as the source of the connection, and the underlying broader network never sees pod IP addresses. - -For connections in the opposite direction, where something outside of the cluster needs to connect to a pod, this can only be done via Kubernetes services or Kubernetes ingress. Nothing outside of the cluster can directly connect to a pod IP address, because the broader network doesn’t know how to route packets to pod IP addresses. - -**Routable** - -If the pod IP addresses are routable outside of the cluster then pods can connect to the outside world without SNAT, and the outside world can connect directly to pods without going via a Kubernetes service or Kubernetes ingress. - -The advantage of pod IP addresses that are routable outside the cluster are: - -- Avoiding SNAT for outbound connections may be essential for integrating with existing broader security requirements. It can also simplify debugging and understandability of operation logs. -- If you have specialized workloads that mean some pods need to be directly accessible without going via Kubernetes services or Kubernetes ingress, then routable pod IPs can be operationally simpler than the alternative of using host networked pods. - -The main disadvantage of pod IP addresses that are routable outside the cluster is that the pod IPs must be unique across the broader network. So for example, if running multiple clusters you will need to use a different IP address range (CIDR) for pods in each cluster. This in turn can lead to IP address range exhaustion challenges when running at scale, or if there are other significant existing enterprise demands on IP address space. - -**What determines routability?** - -If you are using an overlay network for your cluster, then pod IPs are not normally routable outside of the cluster. - -If you aren’t using an overlay network, then whether pod IPs are routable outside of the cluster depends on what combination of CNI plugins, cloud provider integrations, or (for on-prem) BGP peering with the physical network, is being used. - -### BGP - -BGP (Border Gateway Protocol) is a standards based networking protocol for sharing routes across a network. It’s one of the fundamental building blocks of the internet, with exceptional scaling characteristics. - -$[prodname] has built in support for BGP. In an on-prem deployment, this allows $[prodname] to peer with the physical network (typically to Top of Rack routers) to exchange routes, making a non-overlay network where pod IP addresses routable across the broader network, just like any other workload attached to the network. - -## About $[prodname] Networking - -$[prodname]’s flexible modular architecture for networking includes the following. - -**$[prodname] CNI network plugin** - -The $[prodname] CNI network plugin connects pods to the host network namespace’s L3 routing using a pair of virtual Ethernet devices (veth pair). This L3 architecture avoids the unnecessary complexity and performance overheads of additional L2 bridges that feature in many other Kubernetes networking solutions. - -**$[prodname] CNI IPAM plugin** - -The $[prodname] CNI IPAM plugin allocates IP addresses for pods out of one or more configurable IP address ranges, dynamically allocating small blocks of IPs per node as required. The result is a more efficient IP address space usage compared to many other CNI IPAM plugins, including the host local IPAM plugin which is used in many networking solutions. - -**Overlay network modes** - -$[prodname] can provide both VXLAN or IP-in-IP overlay networks, including cross-subnet only modes. - -**Non-overlay network modes** - -$[prodname] can provide non-overlay networks running on top of any underlying L2 network, or an L3 network that is either a public cloud network with appropriate cloud provider integration, or a BGP capable network (typically an on-prem network with standard Top-of-Rack routers). - -**Network policy enforcement** - -$[prodname]’s network policy enforcement engine implements the full range of Kubernetes Network Policy features, plus the extended features of $[prodname] Network Policy. This works in conjunction with $[prodname]’s built in networking modes, or any other $[prodname] compatible network plugins and cloud provider integrations. - -## $[prodname] compatible CNI plugins and cloud provider integrations - -In addition to the $[prodname] CNI plugins and built in networking modes, $[prodname] is also compatible with a number of third party CNI plugins and cloud provider integrations. - -**Amazon VPC CNI** - -The Amazon VPC CNI plugin allocates pod IPs from the underlying AWS VPC and uses AWS elastic network interfaces to provide VPC native pod networking (pod IPs that are routable outside of the cluster). It is the default networking used in [Amazon EKS](https://aws.amazon.com/eks/), with Calico for network policy enforcement. - -**Azure CNI** - -The Azure CNI plugin allocates pod IPs from the underlying Azure VNet configures the Azure virtual network to provide VNet native pod networking (pod IPs that are routable outside of the cluster). It is the default networking used in [Microsoft AKS](https://azure.microsoft.com/en-us/products/kubernetes-service/), with Calico for network policy enforcement. - -**Azure cloud provider** - -The Azure cloud provider integration can be used as an alternative to the Azure CNI plugin. It uses the host-local IPAM CNI plugin to allocate pod IPs, and programs the underlying Azure VNet subnet with corresponding routes. Pod IPs are only routable within the VNet subnet (which often equates to meaning they are not routable outside of the cluster). - -**Google cloud provider** - -The Google cloud provider integration uses host-local IPAM CNI plugin to allocate pod IPs, and programs the Google cloud network Alias IP ranges to provide VPC native pod networking on Google cloud (pod IPs that are routable outside of the cluster). It is the default for Google Kubernetes Engine (GKE), with Calico for network policy enforcement. - -**Host local IPAM** - -The host local CNI IPAM plugin is a commonly used IP address management CNI plugin, which allocates a fixed size IP address range (CIDR) to each node, and then allocates pod IP addresses from within that range. The default address range size is 256 IP addresses (a /24), though two of those IP addresses are reserved for special purposes and not assigned to pods. The simplicity of host local CNI IPAM plugin makes it easy to understand, but results in less efficient IP address space usage compared to $[prodname] CNI IPAM plugin. - -**Flannel** - -Flannel routes pod traffic using static per-node CIDRs obtained from the host-local IPAM CNI plugin. Flannel provides a number of networking backends, but is predominantly used with its VXLAN overlay backend. $[prodname] CNI and $[prodname] network policy can be combined with flannel and the host-local IPAM plugin to provide a VXLAN network with policy enforcement. This combination is sometimes referred to as “Canal”. - -:::note - -$[prodname] now has built in support for VXLAN, which we generally recommend for simplicity in preference to using the Calico+Flannel combination. - -::: - -## Networking options - -### On-prem - -The most common network setup for $[prodname] on-prem is non-overlay mode using [BGP to peer](configuring/bgp.mdx) with the physical network (typically top of rack routers) to make pod IPs routable outside of the cluster. (You can of course configure the rest of your on-prem network to limit the scope of pod IP routing outside of the cluster if desired.) This setup provides a rich range of advanced $[prodname] features, including the ability to advertise Kubernetes service IPs (cluster IPs or external IPs), and the ability to control IP address management at the pod, namespace, or node level, to support a wide range of possibilities for integrating with existing enterprise network and security requirements. - - - -If peering BGP to the physical network is not an option, you can also run non-overlay mode if the cluster is within a single L2 network, with Calico just peering BGP between the nodes in the cluster. Even though this is not strictly an overlay network, the pod IPs are not routable outside of the cluster, because the broader network does not have routes for the pod IPs. - - - -Alternatively you can run $[prodname] in either VXLAN or IP-in-IP overlay mode, with cross-subnet overlay mode to optimize performance within each L2 subnet. - -_Recommended:_ - - - -_Alternative:_ - - - -### AWS - -If you would like pod IP addresses to be routable outside of the cluster then you must use the Amazon VPC CNI plugin. This is the default networking mode for [EKS](https://aws.amazon.com/eks/), with Calico for network policy. Pod IP addresses are allocated from the underlying VPC and the maximum number of pods per node is dependent on the [instance type](https://github.com/aws/amazon-vpc-cni-k8s#eni-allocation). - - - -If you prefer to avoid dependencies on a specific cloud provider, or allocating pod IPs from the underlying VPC is problematic due to IP address range exhaustion challenges, or if the maximum number of pods supported per node by the Amazon VPC CNI plugin is not sufficient for your needs, we recommend using $[prodname] networking in cross-subnet overlay mode. Pod IPs will not be routable outside of the cluster, but you can scale the cluster up to the limits of Kubernetes with no dependencies on the underlying cloud network. - - - -### Azure - -If you would like pod IP addresses to be routable outside of the cluster then you must use the Azure CNI plugin. This is supported by [AKS](https://azure.microsoft.com/en-us/products/kubernetes-service/), with Calico for network policy. Pod IP addresses are allocated from the underlying VNet. - - - -Alternatively you can run $[prodname] in Azure CNI overlay mode. - - - -If you want to use AKS but allocating pod IPs from the underlying VNet is problematic due to IP address range exhaustion challenges, you can use $[prodname] in conjunction with the Azure cloud provider integration. This uses host-local IPAM to allocate /24 per node, and programs routes within the cluster’s underlying VNet subnet for those /24. Pod IPs are not routable outside of the cluster / VNet subnet, so the same pod IP address range (CIDR) can be used across multiple clusters if desired. - -:::note - -This is referred to as kubenet + Calico in some AKS docs, but it is actually Calico CNI with Azure cloud provider, and does not use the kubenet plugin. - -::: - - - -If you aren’t using AKS, and prefer to avoid dependencies on a specific cloud provider or allocating pod IPs from the underlying VNet is problematic due to IP address range exhaustion challenges, we recommend using $[prodname] networking in cross-subnet overlay mode. Pod IPs will not be routable outside of the cluster, but you can scale the cluster up to the limits of Kubernetes with no dependencies on the underlying cloud network. - - - -### Google Cloud - -If you would like pod IP addresses to be routable outside of the cluster then you must use the Google cloud provider integration in conjunction with host-local IPAM CNI plugin. This is supported by [GKE](https://cloud.google.com/kubernetes-engine), with Calico for network policy. Pod IP addresses are allocated from the underlying VPC, and corresponding Alias IP addresses are automatically assigned to nodes. - - - -If you prefer to avoid dependencies on a specific cloud provider, or allocating pod IPs from the underlying VPC is problematic due to IP address range exhaustion challenges, we recommend using $[prodname] networking in overlay mode. As Google cloud network is a pure L3 network, cross-subnet mode is not supported. Pod IPs will not be routable outside of the cluster, but you can scale the cluster up to the limits of Kubernetes with no dependencies on the underlying cloud network. - -_Recommended:_ - - - -_Alternative:_ - - - -### IBM Cloud - -If you are using IBM Cloud then we recommend using [IKS](https://www.ibm.com/products/kubernetes-service/), which has Calico built in to provide cross-subnet IP-in-IP overlay. In addition to providing network policy for pods, IKS also uses Calico network policies to [secure the hosts nodes](https://cloud.ibm.com/docs/containers?topic=containers-network_policies#default_policy) within the cluster. - - - -### Anywhere - -The above list of environments is obviously not exhaustive. Understanding the concepts and explanations in this guide has hopefully helped you figure out what is right for your environment. If you still aren't sure then you can ask for advice through the Calico Users's Slack or Discourse forum. And remember you can run Calico in VXLAN overlay mode in almost any environment if you want to get started without worrying too deeply about the different options. - - - -## Additional resources - -- [Video playlist: Everything you need to know about Kubernetes networking](https://www.youtube.com/playlist?list=PLoWxE_5hnZUZMWrEON3wxMBoIZvweGeiq) -- [Configure BGP peering](configuring/bgp.mdx) -- [Configure overlay networking](configuring/vxlan-ipip.mdx) -- [Advertise Kubernetes service IP addresses](configuring/advertise-service-ips.mdx) -- [Customize IP address management](ipam/index.mdx) -- [Interoperate with legacy firewalls using IP ranges](ipam/legacy-firewalls.mdx) diff --git a/calico_versioned_docs/version-3.29/networking/index.mdx b/calico_versioned_docs/version-3.29/networking/index.mdx deleted file mode 100644 index 20acc28dc1..0000000000 --- a/calico_versioned_docs/version-3.29/networking/index.mdx +++ /dev/null @@ -1,82 +0,0 @@ ---- -description: Calico's flexible networking options reduce the barriers to adopting a CaaS platform solution. Determine the best networking option for your implementation. ---- - -import { DocCardLink, PaidProductDocCardLink, DocCardLinkLayout } from '/src/___new___/components'; - -# Networking - -The $[prodname] network plugins provide a range of networking options to fit your implementation and maximize performance. - -## Getting started - - - - - - - -## Configuring networking - - - - - - - - - - - - - -## IP address management - - - - - - - - - - - - - - - - -## Networking for OpenStack - - - - - - - - - - - - - - - - -## Networking options with Calico Cloud - - - - - \ No newline at end of file diff --git a/calico_versioned_docs/version-3.29/networking/ipam/add-floating-ip.mdx b/calico_versioned_docs/version-3.29/networking/ipam/add-floating-ip.mdx deleted file mode 100644 index 2f4b1ff93a..0000000000 --- a/calico_versioned_docs/version-3.29/networking/ipam/add-floating-ip.mdx +++ /dev/null @@ -1,117 +0,0 @@ ---- -description: Configure one or more floating IPs to use as additional IP addresses for reaching a Kubernetes pod. ---- - -# Add a floating IP to a pod - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - -## Big picture - -Configure one or more floating IPs that can be used as additional IP addresses for reaching a Kubernetes pod. - -## Value - -Like Kubernetes Services, a floating IP provides a stable IP address to reach some network service that might be backed by different pods at different times. The primary advantage over Kubernetes services is that floating IPs work on all protocols: not just TCP, UDP, and SCTP. Unlike Kubernetes services, a floating IP fronts a single pod at a time and cannot be used for load balancing. - -## Concepts - -A **floating IP** is an additional IP address assigned to a workload endpoint. These IPs “float” in the sense that they can be moved around the cluster and front different workload endpoints at different times. The workload itself is generally unaware of the floating IP; the host uses network address translation (NAT) on incoming traffic to change the floating IP to the workload’s real IP before delivering packets to the workload. - -A Kubernetes Service assigns a **cluster IP** that allows other endpoints on the network (and may also assign a nodePort and/or an external load balancer IP) to access a set of pods, using network address translation. In many circumstances, a Kubernetes Service can handle similar use cases as a floating IP, and is generally recommended for Kubernetes users because it is a native Kubernetes concept. One thing you cannot do with Kubernetes Services is use protocols other than UDP, TCP, and SCTP (use of such protocols is fairly rare). - -## Before you begin... - -The features in this How to require: - -- $[prodname] CNI plugin - -To verify, ssh to one of the Kubernetes nodes and look for at the CNI plugin configuration, usually located at `/etc/cni/net.d/`. If you see the file, `10-calico.conflist`, you are using the $[prodname] CNI plugin. - -## How to - -- [Enable floating IPs](#enable-floating-ips) -- [Configure a pod to use a floating IP](#configure-a-pod-to-use-a-floating-ip) - -### Enable floating IPs - - - - -Floating IPs for Kubernetes pods are not currently supported for operator-managed Calico clusters. - - - - -By default, floating IPs are disabled. To enable floating IPs, follow these steps. - -Modify the calico-config ConfigMap in the kube-system namespace. In the `cni_network_config` section, add the following stanza to the “calico” plugin config section. - -``` - "feature_control": { - "floating_ips": true - } -``` - -For example, your `cni_network_config` will look similar to the following after the update. - -``` - cni_network_config: |- - { - "name": "k8s-pod-network", - "cniVersion": "0.3.0", - "plugins": [ - { - "type": "calico", - "log_level": "info", - "datastore_type": "kubernetes", - "nodename": "__KUBERNETES_NODE_NAME__", - "mtu": __CNI_MTU__, - "ipam": { - "type": "calico-ipam" - }, - "policy": { - "type": "k8s" - }, - "kubernetes": { - "kubeconfig": "__KUBECONFIG_FILEPATH__" - }, - "feature_control": { - "floating_ips": true - } - }, - { - "type": "portmap", - "snat": true, - "capabilities": {"portMappings": true} - } - ] - } -``` - - - - -### Configure a pod to use a floating IP - - - - -Floating IPs for Kubernetes pods are not currently supported for operator-managed Calico clusters. - - - - -Annotate the pod with the key `cni.projectcalico.org/floatingIPs` and the value set to a list of IP addresses enclosed in square brackets. For correct advertisement to the rest of the cluster, all floating IPs must be within the range of a configured [IP pool](../../reference/resources/ippool.mdx). - -For example: - -``` -"cni.projectcalico.org/floatingIPs": "[\"10.0.0.1\"]" -``` - -Note the use of the escaped `\"` for the inner double quotes around the addresses. - - - diff --git a/calico_versioned_docs/version-3.29/networking/ipam/assign-ip-addresses-topology.mdx b/calico_versioned_docs/version-3.29/networking/ipam/assign-ip-addresses-topology.mdx deleted file mode 100644 index e94d09955c..0000000000 --- a/calico_versioned_docs/version-3.29/networking/ipam/assign-ip-addresses-topology.mdx +++ /dev/null @@ -1,181 +0,0 @@ ---- -description: Configure Calico to use specific IP pools for different topologies including zone, rack, or region. ---- - -# Assign IP addresses based on topology - -## Big picture - -Assign blocks of IP addresses from an IP pool for different topological areas. - -## Value - -If you have workloads in different regions, zones, or rack, you may want them to get IP addresses from the same IP pool. This strategy is useful for reducing the number of routes that are required in the network, or to meet requirements imposed by an external firewall device or policy. $[prodname] makes it easy to do this using an IP pool resource with node labels and node selectors. - -## Concepts - -### IP address assignment - -Topology-based IP address assignment requires addresses to be per-host (node). -As such, Kubernetes annotations cannot be used because annotations are only per-namespace and per-pod. And although you can configure IP addresses for nodes in the CNI configuration, you are making changes within the host’s file system. The best option is to use node-selection IP address assignment using IP pools. - -### Node-selection IP address management - -Node selection-based IP address assignment is exactly what it sounds like: node labels are set, and Calico uses node selectors to decide which IP pools to use when assigning IP addresses to the node. - -### Best practice - -Nodes only assign workload addresses from IP pools which select them. To avoid having a workload not get an IP and fail to start, it is important to ensure that all nodes are selected by at least one IP pool. - -## How to - -### Create an IP pool, specific nodes - -In the following example, we create an IP pool that only allocates IP addresses for nodes with the label, **zone=west**. - -```yaml -apiVersion: projectcalico.org/v3 -kind: IPPool -metadata: - name: zone-west-ippool -spec: - cidr: 192.168.0.0/24 - ipipMode: Always - natOutgoing: true - nodeSelector: zone == "west" -``` - -Then, we label a node with zone=west. For example: - -```bash -kubectl label nodes kube-node-0 zone=west -``` - -## Tutorial - -In this tutorial, we create a cluster with four nodes across two racks (two nodes/rack). - -``` - ------------------- - | router | - ------------------- - | | ---------------- --------------- -| rack-0 | | rack-1 | ---------------- --------------- -| kube-node-0 | | kube-node-2 | -- - - - - - - - - - - - - - - - -| kube-node-1 | | kube-node-3 | -- - - - - - - - - - - - - - - - -``` - -Using the pod IP range `192.168.0.0/16`, we target the following setup: reserve -the `192.168.0.0/24` and `192.168.1.0/24` pools for `rack-0`, `rack-1`. Let's -get started. - -By installing $[prodname] without setting the default IP pool to match, -running `calicoctl get ippool -o wide` shows that $[prodname] created its -default IP pool of `192.168.0.0/16`: - -``` -NAME CIDR NAT IPIPMODE DISABLED SELECTOR -default-ipv4-ippool 192.168.0.0/16 true Always false all() -``` - -1. Delete the default IP pool. - - Since the `default-ipv4-ippool` IP pool resource already exists and accounts - for the entire `/16` block, we will have to delete this first: - - ```bash - calicoctl delete ippools default-ipv4-ippool - ``` - -2. Label the nodes. - - To assign IP pools to specific nodes, these nodes must be labelled - using [kubectl label](https://kubernetes.io/docs/tasks/configure-pod-container/assign-pods-nodes/#add-a-label-to-a-node). - - ```bash - kubectl label nodes kube-node-0 rack=0 - kubectl label nodes kube-node-1 rack=0 - kubectl label nodes kube-node-2 rack=1 - kubectl label nodes kube-node-3 rack=1 - ``` - -3. Create an IP pool for each rack. - - ```bash - calicoctl create -f -< - nginx-5c7588df-s7qw6 1/1 Running 0 6m7s 192.168.0.129 kube-node-1 - nginx-5c7588df-w7r7g 1/1 Running 0 6m3s 192.168.1.65 kube-node-2 - nginx-5c7588df-62lnf 1/1 Running 0 6m3s 192.168.1.1 kube-node-3 - nginx-5c7588df-pnsvv 1/1 Running 0 6m3s 192.168.1.64 kube-node-2 - ``` - - The grouping of IP addresses assigned to the workloads differ based on what - node that they were scheduled to. Additionally, the assigned address for - each workload falls within the respective IP pool that selects the rack that - they run on. - -:::note - -$[prodname] IPAM will not reassign IP addresses to workloads -that are already running. To update running workloads with IP addresses from -a newly configured IP pool, they must be recreated. We recommend doing this -before going into production or during a maintenance window. - -::: - -## Additional resources - -[Calico IPAM](../../reference/configure-cni-plugins.mdx) diff --git a/calico_versioned_docs/version-3.29/networking/ipam/change-block-size.mdx b/calico_versioned_docs/version-3.29/networking/ipam/change-block-size.mdx deleted file mode 100644 index d3c740b581..0000000000 --- a/calico_versioned_docs/version-3.29/networking/ipam/change-block-size.mdx +++ /dev/null @@ -1,258 +0,0 @@ ---- -description: Expand or shrink the IP pool block size to efficiently manage IP pool addresses. ---- - -# Change IP pool block size - -import DetermineIpam from '@site/calico_versioned_docs/version-3.29/_includes/content/_determine-ipam.mdx'; - -## Big picture - -Change the IP pool block size to efficiently manage IP pool addresses. - -## Value - -Changing IP pool block size after installation requires ordered steps to minimize pod connectivity disruption. - -## Concepts - -### About IP pools - -By default, $[prodname] uses an IPAM block size of 64 addresses – /26 for IPv4, and /122 for IPv6. However, the block size can be changed depending on the IP pool address family. - -- IPv4: 20-32, inclusive -- IPv6: 116-128, inclusive - -You can have **only one default IP pool for per protocol** in your installation manifest. In this example, there is one IP pool for IPv4 (/26), and one IP pool for IPv6 (/122). - -```yaml -apiVersion: operator.tigera.io/v1 -kind: Installation -metadata: - name: default -spec: - # Configures Calico networking. - calicoNetwork: - ipPools: - - blockSize: 26 - cidr: 10.48.0.0/21 - encapsulation: IPIP - natOutgoing: Enabled - nodeSelector: all() - - blockSize: 122 - cidr: 2001::00/64 - encapsulation: None - natOutgoing: Enabled - nodeSelector: all() -``` - -However, the following is invalid because it has two IP pools for IPv4. - -```yaml -apiVersion: operator.tigera.io/v1 -kind: Installation -metadata: - name: default -spec: - # Configures Calico networking. - calicoNetwork: - ipPools: - - blockSize: 26 - cidr: 10.48.0.0/21 - encapsulation: IPIP - natOutgoing: Enabled - nodeSelector: all() - - blockSize: 31 - cidr: 10.48.8.0/21 - encapsulation: IPIP - natOutgoing: Enabled - nodeSelector: all() -``` - -### Expand or shrink IP pool block sizes - -By default, the $[prodname] IPAM block size for an IP pool is /26. To expand from the default size /26, lower the `blockSize` (for example, /24). To shrink the `blockSize` from the default /26, raise the number (for example, /28). - -### Best practice: change IP pool block size before installation - -Because the `blockSize` field cannot be edited directly after $[prodname] installation, it is best to change the IP pool block size before installation to minimize disruptions to pod connectivity. - -## Before you begin... - -**Required** - -Verify that you are using $[prodname] IPAM. - - - -## How to - -:::note - -Follow the steps to minimize pod connectivity disruption. Pods may lose connectivity when they are redeployed, and may lose external connectivity while in the temporary pool. Also, when pods are deleted, applications may be temporarily unavailable (depending on the type of application). Plan your changes accordingly. - -::: - -The high-level steps to follow are: - -1. [Create a temporary IP pool](#create-a-temporary-ip-pool) - **Note**: The temporary IP pool must not overlap with the existing one. -1. [Disable the existing IP pool](#disable-the-existing-ip-pool) - **Note**: When you disable an IP pool, only new IP address allocations are prevented; networking of existing pods are not affected. -1. [Delete pods from the existing IP pool](#delete-pods-from-the-existing-ip-pool) - This includes any new pods that may have been created with the existing IP pool prior to disabling the pool. Verify that new pods get an address from the temporary IP pool. -1. [Delete the existing IP pool](#delete-the-existing-ip-pool) -1. [Create a new IP pool with the desired block size](#create-a-new-ip-pool-with-the-desired-block-size) -1. [Disable the temporary IP pool](#disable-the-temporary-ip-pool) -1. [Delete pods from the temporary IP pool](#delete-pods-from-the-temporary-ip-pool) -1. [Delete the temporary IP pool](#delete-the-temporary-ip-pool) - -## Tutorial - -In the following steps, our Kubernetes cluster has a default CIDR block size of /26. We want to shrink the block size to /28 to use the pool more efficiently. - -### Create a temporary IP pool - -We add a new IPPool with the CIDR range, 10.0.0.0/16. - -Create a temporary-pool.yaml. - -```yaml -apiVersion: projectcalico.org/v3 -kind: IPPool -metadata: - name: temporary-pool -spec: - cidr: 10.0.0.0/16 - ipipMode: Always - natOutgoing: true -``` - -Apply the changes. - -```bash -calicoctl apply -f temporary-pool.yaml -``` - -Let’s verify the temporary IP pool. - -```bash -calicoctl get ippool -o wide -``` - -``` -NAME CIDR NAT IPIPMODE DISABLED -default-ipv4-ippool 192.168.0.0/16 true Always false -temporary-pool 10.0.0.0/16 true Always false -``` - -### Disable the existing IP pool - -Disable allocations in the default pool. - -```bash -calicoctl patch ippool default-ipv4-ippool -p '{"spec": {"disabled": true}}' -``` - -Verify the changes. - -```bash -calicoctl get ippool -o wide -``` - -``` -NAME CIDR NAT IPIPMODE DISABLED -default-ipv4-ippool 192.168.0.0/16 true Always true -temporary-pool 10.0.0.0/16 true Always false -``` - -### Delete pods from the existing IP pool - -In our example, **coredns** is our only pod; for multiple pods you would trigger a deletion for all pods in the cluster. - -```bash -kubectl delete pod -n kube-system coredns-6f4fd4bdf-8q7zp -``` - -Restart all pods with just one command. - -:::caution - -The following command is disruptive and may take several minutes depending on the number of pods deployed. - -::: - -```bash -kubectl delete pod -A --all -``` - -### Delete the existing IP pool - -Now that you’ve verified that pods are getting IPs from the new range, you can safely delete the existing pool. - -```bash -calicoctl delete ippool default-ipv4-ippool -``` - -### Create a new IP pool with the desired block size - -In this step, we update the IPPool with the new block size of (/28). - -```yaml -apiVersion: projectcalico.org/v3 -kind: IPPool -metadata: - name: default-ipv4-ippool -spec: - blockSize: 28 - cidr: 192.0.0.0/16 - ipipMode: Always - natOutgoing: true -``` - -Apply the changes. - -```bash -calicoctl apply -f pool.yaml -``` - -### Disable the temporary IP pool - -```bash -calicoctl patch ippool temporary-pool -p '{"spec": {"disabled": true}}' -``` - -### Delete pods from the temporary IP pool - -In our example, **coredns** is our only pod; for multiple pods you would trigger a deletion for all pods in the cluster. - -```bash -kubectl delete pod -n kube-system coredns-6f4fd4bdf-8q7zp -``` - -Restart all pods with just one command. - -:::caution - -The following command is disruptive and may take several minutes depending on the number of pods deployed. - -::: - -```bash -kubectl delete pod -A --all -``` - -Validate your pods and block size are correct by running the following commands: - -```bash -kubectl get pods --all-namespaces -o wide -calicoctl ipam show --show-blocks -``` - -### Delete the temporary IP pool - -Clean up the IP pools by deleting the temporary IP pool. - -```bash -calicoctl delete pool temporary-pool -``` diff --git a/calico_versioned_docs/version-3.29/networking/ipam/get-started-ip-addresses.mdx b/calico_versioned_docs/version-3.29/networking/ipam/get-started-ip-addresses.mdx deleted file mode 100644 index b0c933773e..0000000000 --- a/calico_versioned_docs/version-3.29/networking/ipam/get-started-ip-addresses.mdx +++ /dev/null @@ -1,88 +0,0 @@ ---- -description: Configure Calico to use Calico IPAM or host-local IPAM, and when to use one or the other. ---- - -# Get started with IP address management - -## Big picture - -Understand how IP address management (IPAM) functions in a Kubernetes cluster using Calico. - -## Value - -Different IPAM techniques provide different feature sets. Calico’s IPAM provides additional IP allocation efficiency and flexibility compared to other address management approaches. - -## Concepts - -### IPAM in Kubernetes - -Kubernetes uses IPAM plugins to allocate and manage IP addresses assigned to pods. Different IPAM plugins provide different feature sets. Calico provides its own IPAM plugin called **calico-ipam** which is designed to work well with Calico and includes a number of features. - -### Calico IPAM - -The **calico-ipam** plugin uses Calico’s IP pool resource to control how IP addresses are allocated to pods within the cluster. This is the default plugin used by most Calico installations. - -By default, Calico uses a single IP pool for the entire Kubernetes pod CIDR, but you can divide the pod CIDR into several pools. You can assign separate IP pools to particular selections of **nodes**, or to teams, users, or applications within a cluster using **namespaces**. - -:::tip - -Because Calico IPAM does not use the Kubernetes node CIDR allocations (`Node.spec.podCIDR`), you can set `--allocate-node-cidrs=false` on the kube-controller-manager. -This prevents Kubernetes from allocating unused node CIDRs and avoids `CIDRNotAvailable` events on nodes. - -If you bootstrapped your cluster with kubeadm and passed `--pod-network-cidr`, kubeadm enables node CIDR allocation automatically. -See the [Kubernetes documentation](https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure/) for instructions on reconfiguring the controller manager after cluster creation. - -::: - -You can control which pools Calico uses for each pod using - -- node selectors -- an annotation on the pod’s namespace, or -- an annotation on the pod - -Calico also supports the **host-local** IPAM plugin. However, when using the host-local IPAM plugin some Calico features are not available. - -### Calico IPAM blocks - -In Calico IPAM, IP pools are subdivided into blocks -- smaller chunks that are associated with a particular node in the cluster. Each node in the cluster can have one or more blocks associated with it. Calico will automatically create and destroy blocks as needed as the number of nodes and pods in the cluster grows or shrinks. - -Blocks allow Calico to efficiently aggregate addresses assigned to pods on the same node, reducing the size of the routing table. By default Calico will try to allocate IP addresses from within an associated block, creating a new block if necessary. Calico can also assign addresses to pods on a node that are not within a block associated with that node. This allows for IP allocations independent of the node on which a pod is launched. - -By default, Calico creates blocks with room for 64 addresses (a /26), but you can control block sizes for each IP pool. - -### Host-local IPAM - -The host-local plugin is a simple IP address management plugin. It uses predetermined CIDRs statically allocated to each node to choose addresses for pods. Once set, the CIDR for a node cannot be modified. Pods can be assigned addresses only from within the CIDR allocated to the node. - -Calico can use the host-local IPAM plugin, using the **Node.Spec.PodCIDR** field in the Kubernetes API to determine the CIDR to use for each node. However, per-node, per-pod, and per-namespace IP allocation features are not available using the host-local plugin. - -The host-local IPAM plugin is primarily used by other methods of routing pod traffic from one host to another. For example, it is used when installing Calico for policy enforcement with flannel networking, as well as when using Calico in Google Kubernetes Engine (GKE). - -## How to - -### Install Calico with calico-ipam - -Follow one of the [getting started guides](../../getting-started/index.mdx) to install Calico. - -### Install Calico with host-local IPAM - -Follow one of the [getting started guides](../../getting-started/index.mdx) to install Calico with flannel networking, or on GKE. - -Or, see the [reference documentation on host-local IPAM](../../reference/configure-cni-plugins.mdx#using-host-local-ipam). - -## Tutorial - -For a blog/tutorial on IP pools, see [Calico IPAM: Explained and Enhanced](https://www.tigera.io/blog/calico-ipam-explained-and-enhanced/). - -## Additional resources - -- [IP Pool](../../reference/resources/ippool.mdx) - -There are several other ways to leverage Calico IPAM including: - -- [Assign addresses based on topology](assign-ip-addresses-topology.mdx) -- [Use a specific address for a pod](use-specific-ip.mdx) -- [Migrate from one IP pool to another](migrate-pools.mdx) -- [Interoperate with legacy firewalls using IP ranges](legacy-firewalls.mdx) -- [View IP address utilization](../../reference/calicoctl/ipam/show.mdx) -- [Change IP address block size](../../reference/resources/ippool.mdx) diff --git a/calico_versioned_docs/version-3.29/networking/ipam/index.mdx b/calico_versioned_docs/version-3.29/networking/ipam/index.mdx deleted file mode 100644 index 834d48a7fd..0000000000 --- a/calico_versioned_docs/version-3.29/networking/ipam/index.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: Calico IPAM is flexible and efficient. Learn how to interoperate with legacy firewalls using IP address ranges, advertise Kubernetes service IPs, and more. -hide_table_of_contents: true ---- - -# IP address management - -import DocCardList from '@theme/DocCardList'; -import { useCurrentSidebarCategory } from '@docusaurus/theme-common'; - - diff --git a/calico_versioned_docs/version-3.29/networking/ipam/ip-autodetection.mdx b/calico_versioned_docs/version-3.29/networking/ipam/ip-autodetection.mdx deleted file mode 100644 index e67d5936d2..0000000000 --- a/calico_versioned_docs/version-3.29/networking/ipam/ip-autodetection.mdx +++ /dev/null @@ -1,308 +0,0 @@ ---- -description: Calico IP autodetection ensures the correct IP address is used for routing. Learn how to customize it. ---- - -# Configure IP autodetection - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - -## Big picture - -Configure IP autodetection for $[prodname] nodes to ensure the correct IP address is used for routing. - -## Value - -When you install $[prodname] on a node, an IP address and subnet is automatically detected. $[prodname] provides several ways to configure IP/subnet autodetection, and supports configuring specific IPs for: - -- Hosts with multiple external interfaces -- Host interfaces with multiple IP addresses -- [Changes to cross subnet packet encapsulation](../configuring/vxlan-ipip.mdx) -- Changes to host IP address - -## Concepts - -### Autodetecting node IP address and subnet - -For internode routing, each $[prodname] node must be configured with an IPv4 address and/or an IPv6 address. When you install $[prodname] on a node, a node resource is automatically created using routing information that is detected from the host. For some deployments, you may want to update autodetection to ensure nodes get the correct IP address. - -**Sample default node resource after installation** - -```yaml -apiVersion: projectcalico.org/v3 -kind: Node -metadata: - name: node-hostname -spec: - bgp: - asNumber: 64512 - ipv4Address: 10.244.0.1/24 - ipv6Address: 2000:db8:85a3::8a2e:370:7335/120 - ipv4IPIPTunnelAddr: 192.168.0.1 -``` - -### Autodetection methods - -By default, $[prodname] uses the **first-found** method; the first valid IP address on the first interface (excluding local interfaces such as the docker bridge). However, you can change the default method to any of the following: - -- Address assigned to Kubernetes node (**kubernetes-internal-ip**) -- Address used by the node to reach a particular IP or domain (**can-reach**) -- Regex to include matching interfaces (**interface**) -- Regex to exclude matching interfaces (**skip-interface**) -- A list of IP ranges in CIDR format to determine valid IP addresses on the node to choose from (**cidrs**) - -For more details on autodetection methods, see [node configuration](../../reference/configure-calico-node.mdx) reference. - -## How to - -- [Change the autodetection method](#change-the-autodetection-method) -- [Manually configure IP address and subnet for a node](#manually-configure-ip-address-and-subnet-for-a-node) - -### Change the autodetection method - - - - -As noted previously, the default autodetection method is **first valid interface found** (first-found). To use a different autodetection method, edit the default [Installation](../../reference/installation/api.mdx#installation) custom resource, specifying the method. Below are examples of the supported autodetection methods: - -:::note - -To configure the default autodetection method for IPv6 for any of the below methods, use the field `nodeAddressAutodetectionV6`. - -::: - -- **Kubernetes Node IP** - - $[prodname] will select the first internal IP address listed in the Kubernetes node's `Status.Addresses` field. - - ```yaml - kind: Installation - apiVersion: operator.tigera.io/v1 - metadata: - name: default - spec: - calicoNetwork: - nodeAddressAutodetectionV4: - kubernetes: NodeInternalIP - ``` - -- **Source address used to reach an IP or domain name** - - $[prodname] will choose the IP address that is used to reach the given "can reach" IP address or domain. For example: - - ```yaml - kind: Installation - apiVersion: operator.tigera.io/v1 - metadata: - name: default - spec: - calicoNetwork: - nodeAddressAutodetectionV4: - canReach: 8.8.8.8 - ``` - -- **Including matching interfaces** - - $[prodname] will choose an address on each node from an interface that matches the given [regex](https://pkg.go.dev/regexp). - For example: - - ```yaml - kind: Installation - apiVersion: operator.tigera.io/v1 - metadata: - name: default - spec: - calicoNetwork: - nodeAddressAutodetectionV4: - interface: eth.* - ``` - -- **Excluding matching interfaces** - - $[prodname] will choose an address on each node from an interface that does not match the given [regex](https://pkg.go.dev/regexp). - For example: - - ```yaml - kind: Installation - apiVersion: operator.tigera.io/v1 - metadata: - name: default - spec: - calicoNetwork: - nodeAddressAutodetectionV4: - skipInterface: eth.* - ``` - -- **Including CIDRs** - - $[prodname] will select any IP address from the node that falls within the given CIDRs. For example: - - ```yaml - kind: Installation - apiVersion: operator.tigera.io/v1 - metadata: - name: default - spec: - calicoNetwork: - nodeAddressAutodetectionV4: - cidrs: - - '192.168.200.0/24' - ``` - - - - -As noted previously, the default autodetection method is **first valid interface found** (first-found). To use a different autodetection method, use the following `kubectl set env` command, specifying the method: - -- **IPv4** - - ```bash - kubectl set env daemonset/calico-node -n kube-system IP_AUTODETECTION_METHOD= - ``` - -- **IPv6** - - ```bash - kubectl set env daemonset/calico-node -n kube-system IP6_AUTODETECTION_METHOD= - ``` - -Where autodetection methods are based on: - -- **Kubernetes Node IP** - - $[prodname] will select the first internal IP address listed in the Kubernetes node's `Status.Addresses` field. - - ```bash - kubectl set env daemonset/calico-node -n kube-system IP_AUTODETECTION_METHOD=kubernetes-internal-ip - ``` - -- **Source address used to reach an IP or domain name** - - $[prodname] will choose the IP address that is used to reach the given "can reach" IP address or domain. For example: - - ```bash - kubectl set env daemonset/calico-node -n kube-system IP_AUTODETECTION_METHOD=can-reach=www.google.com - ``` - -- **Including matching interfaces** - - $[prodname] will choose an address on each node from an interface that matches the given [regex](https://pkg.go.dev/regexp). - For example: - - ```bash - kubectl set env daemonset/calico-node -n kube-system IP_AUTODETECTION_METHOD=interface=eth.* - ``` - -- **Excluding matching interfaces** - - $[prodname] will choose an address on each node from an interface that does not match the given [regex](https://pkg.go.dev/regexp). - For example: - - ```bash - kubectl set env daemonset/calico-node -n kube-system IP_AUTODETECTION_METHOD=skip-interface=eth.* - ``` - -- **Including CIDRs** - - $[prodname] will select any IP address from the node that falls within the given CIDRs. For example: - - ```bash - kubectl set env daemonset/calico-node -n kube-system IP_AUTODETECTION_METHOD=cidr=192.168.200.0/24,172.15.0.0/24 - ``` - - - - -### Manually configure IP address and subnet for a node - -In the following scenarios, you may want to configure a specific IP and subnet: - -- Hosts with multiple external interfaces -- Host interfaces with multiple IP addresses -- Changes to cross subnet packet encapsulation -- Changes to host IP address - - - - -You can configure specific IP address and subnet for a node by disabling IP autodetection and then updating the [Node resource](../../reference/resources/node.mdx). - -#### Disable autodetection - -To disable autodetection method, update the proper `NodeAddressAutodetection` field in the Installation resource: - -```yaml -apiVersion: operator.tigera.io/v1 -kind: Installation -metadata: - name: default -spec: - calicoNetwork: - nodeAddressAutodetectionV4: {} - nodeAddressAutodetectionV6: {} -``` - -#### Configure IP and subnet using node resource - -You can configure the IP address and subnet on a Node resource. - -Use `calicoctl patch` to update the current node configuration. For example: - -```bash -calicoctl patch node kind-control-plane \ - --patch='{"spec":{"bgp": {"ipv4Address": "10.0.2.10/24", "ipv6Address": "fd80:24e2:f998:72d6::/120"}}}' -``` - - - - -You can configure specific IP address and subnet for a node using environment variables or by updating the [Node resource](../../reference/resources/node.mdx). Because you can configure IP address and subnet using either environment variables or node resource, the following table describes how values are synchronized. - -| **If this environment variable...** | **Is...** | **Then...** | -| ----------------------------------- | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | -| IP/IP6 | Explicitly set | The specified values are used, and the Node resource is updated. | -| | Set to autodetect | The requested method is used (first-found, can-reach, interface, skip-interface, kubernetes-internal-ip), and the Node resource is updated. | -| | Not set, but Node resource has IP/IP6 values | Node resource value is used. | -| IP | Not set, and there is no IP value in Node resource | Autodetects an IPv4 address and subnet, and updates Node resource. | -| IP6 | Not set, and there is a no IP6 value in Node resource | No IP6 routing is performed on the node. | - -#### Configure IP and subnet using environment variables - -To configure IP and subnet values using environment variables, use a `kubectl set env` command. For example: - -```bash -kubectl set env daemonset/calico-node -n kube-system IP=10.0.2.10/24 IP6=fd80:24e2:f998:72d6::/120 -``` - -:::note - -If the subnet is omitted, the defaults are: /32 (IPv4) and /128 (IPv6). We recommend that you include the subnet information for clarity when specifying IP addresses. - -::: - -#### Configure IP and subnet using node resource - -You can also configure the IP address and subnet on a Node resource. - -:::note - -When configuring the IP address on a Node resource, you may want to disable IP address options or environment variables on the node. IP options on the container take precedence, and will overwrite the values you configure on the node resource. - -::: - -Use `calicoctl patch` to update the current node configuration. For example: - -```bash -calicoctl patch node kind-control-plane \ - --patch='{"spec":{"bgp": {"ipv4Address": "10.0.2.10/24", "ipv6Address": "fd80:24e2:f998:72d6::/120"}}}' -``` - - - - -## Additional resources - -- For details on autodetection methods, see the [node configuration](../../reference/configure-calico-node.mdx) reference. -- For calicoctl environment variables, see [Configuring $[nodecontainer]](../../reference/configure-calico-node.mdx) -- [Node resource](../../reference/resources/node.mdx) -- [Reference documentation for calicoctl patch](../../reference/calicoctl/patch.mdx) diff --git a/calico_versioned_docs/version-3.29/networking/ipam/ippools.mdx b/calico_versioned_docs/version-3.29/networking/ipam/ippools.mdx deleted file mode 100644 index 1426dda3bf..0000000000 --- a/calico_versioned_docs/version-3.29/networking/ipam/ippools.mdx +++ /dev/null @@ -1,117 +0,0 @@ ---- -description: Create multiple IP pools ---- - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - -# Create multiple IP pools - -## Understanding multiple IP pools - -By default when you install $[prodname], a single IPv4 pool is created. This IP pool is used for allocating IP addresses to pods and, if needed, -tunnels within your cluster. - -Sometimes you may want to configure additional IP pools. For example: - -- If the IP address space available for pods in your cluster is disjointed. -- You want to [assign IP addresses based on cluster topology](assign-ip-addresses-topology.mdx). - -## Create multiple IP pools when installing Calico - - - - -You can edit the Installation resource within `custom-resources.yaml` to include multiple unique IP pools. The following -example creates two IP pools assigned to different sets of nodes. - -```yaml -apiVersion: operator.tigera.io/v1 -kind: Installation -metadata: - name: default -spec: - calicoNetwork: - ipPools: - - name: pool-zone-1 - cidr: 192.168.0.0/24 - encapsulation: VXLAN - nodeSelector: "zone == 'zone-1'" - - name: pool-zone-2 - cidr: 192.168.1.0/24 - encapsulation: VXLAN - nodeSelector: "zone == 'zone-2'" -``` - -After installing $[prodname], you can confirm the IP pools were created by using the following command: - -```bash -kubectl get ippools -``` - -## Prevent the operator from managing IP pools - -In some cases, you may want to disable IP pool management within the operator and instead use calicoctl or kubectl to -create and delete IP pools. To do this, you can edit the **Installation** resource with `custom-resources.yaml` to specify -an empty list of IP pools. - -```yaml -apiVersion: operator.tigera.io/v1 -kind: Installation -metadata: - name: default -spec: - calicoNetwork: - ipPools: [] -``` - -With this configuration, the operator will wait for you to create IP pools before installing $[prodname] components. - - - - -When using manifests to install $[prodname], you can use calicoctl to manage multiple IP pools. For complete control, you can disable -creation of the default IP pool before doing so. - -1. Disable the default IP pool by adding the following environment variable to the calico-node DaemonSet in `calico.yaml`. - - ```yaml - env: - - name: NO_DEFAULT_POOLS - value: "true" - ``` - -1. Then, install `calico.yaml`. - -1. Create the desired IP pools. For example, the following commands create two IP pools assigned to different sets of nodes. - - ```bash - calicoctl create -f -< - diff --git a/calico_versioned_docs/version-3.29/networking/ipam/ipv6-control-plane.mdx b/calico_versioned_docs/version-3.29/networking/ipam/ipv6-control-plane.mdx deleted file mode 100644 index 4b0a6c0556..0000000000 --- a/calico_versioned_docs/version-3.29/networking/ipam/ipv6-control-plane.mdx +++ /dev/null @@ -1,27 +0,0 @@ ---- -description: Configure the Kubernetes control plane to operate over IPv6 for dual stack or IPv6 only. ---- - -# Configure Kubernetes control plane to operate over IPv6 - -## Big picture - -If you have IPv6 connectivity between your nodes and workloads, you may also want to configure the Kubernetes control plane to operate over IPv6, instead of IPv4. - -## How to - -To configure Kubernetes components for IPv6 only, set the following flags. - -| Component | **Flag** | **Value/Content** | -| --------------------------- | --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | -| **kube-apiserver** | `--bind-address` or `--insecure-bind-address` | Set to the appropriate IPv6 address or `::` for all IPv6 addresses on the host. | -| | `--advertise-address` | Set to the IPv6 address that nodes should use to access the `kube-apiserver`. | -| **kube-controller-manager** | `--master` | Set with the IPv6 address where the `kube-apiserver` can be accessed. | -| **kube-scheduler** | `--master` | Set with the IPv6 address where the `kube-apiserver` can be accessed. | -| **kubelet** | `--address` | Set to the appropriate IPv6 address or `::` for all IPv6 addresses. | -| | `--cluster-dns` | Set to the IPv6 address that will be used for the service DNS; this must be in the range used for `--service-cluster-ip-range`. | -| | `--node-ip` | Set to the IPv6 address of the node. | -| **kube-proxy** | `--bind-address` | Set to the appropriate IPv6 address or `::` for all IPv6 addresses on the host. | -| | `--master` | Set with the IPv6 address where the `kube-apiserver` can be accessed. | - -For dual stack settings, see [Enable IPv4/IPv6 dual-stack](https://kubernetes.io/docs/concepts/services-networking/dual-stack/#prerequisites). diff --git a/calico_versioned_docs/version-3.29/networking/ipam/ipv6.mdx b/calico_versioned_docs/version-3.29/networking/ipam/ipv6.mdx deleted file mode 100644 index bb01f006aa..0000000000 --- a/calico_versioned_docs/version-3.29/networking/ipam/ipv6.mdx +++ /dev/null @@ -1,231 +0,0 @@ ---- -description: Configure dual stack or IPv6 only for workloads. ---- - -# Configure dual stack or IPv6 only - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - -## Big picture - -Configure $[prodname] IP address allocation to use dual stack or IPv6 only for workload communications. - -## Value - -Workload communication over IPv6 is increasingly desirable, as well as or instead of IPv4. $[prodname] supports: - -- **IPv4 only** (default) - - Each workload gets an IPv4 address, and can communicate over IPv4. - -- **Dual stack** - - Each workload gets an IPv4 and an IPv6 address, and can communicate over IPv4 or IPv6. - -- **IPv6 only** - - Each workload gets an IPv6 address, and can communicate over IPv6. - -## Before you begin - -**$[prodname] requirements** - -- $[prodname] IPAM - -**Kubernetes version requirements** - -- For dual stack, 1.16 and later -- For one IP stack at a time (IPv4 or IPv6), any Kubernetes version - -**Kubernetes IPv6 host requirements** - -- An IPv6 address that is reachable from the other hosts -- The sysctl setting, `net.ipv6.conf.all.forwarding`, is set to `1`. - This ensures both Kubernetes service traffic and $[prodname] traffic is forwarded appropriately. -- A default IPv6 route - -**Kubernetes IPv4 host requirements** - -- An IPv4 address that is reachable from the other hosts -- The sysctl setting, `net.ipv4.conf.all.forwarding`, is set to `1`. - This ensures both Kubernetes service traffic and $[prodname] traffic is forwarded appropriately. -- A default IPv4 route - -## How to - -:::note - -The following tasks are only for new clusters. - -::: - -- [Enable IPv6 only](#enable-ipv6-only) -- [Enable dual stack](#enable-dual-stack) - -### Enable IPv6 only - - - - -To configure an IPv6-only cluster using the operator, edit your default Installation at install time to include a single IPv6 pool, and no IPv4 pools. For example: - -```yaml -apiVersion: operator.tigera.io/v1 -kind: Installation -metadata: - name: default -spec: - calicoNetwork: - ipPools: - - blockSize: 122 - cidr: 2001::00/64 - encapsulation: None - natOutgoing: Enabled - nodeSelector: all() -``` - - - - -1. Set up a new Kubernetes cluster with an IPv6 pod CIDR and service IP range. - -1. Using the [$[prodname] Kubernetes install guide](../../getting-started/kubernetes/self-managed-onprem/onpremises.mdx), download the correct $[prodname] manifest for the cluster and datastore type. - -1. Edit the CNI config (calico-config ConfigMap in the manifest) to disable IPv4 assignments and enable IPv6 assignments. - - ```json - "ipam": { - "type": "calico-ipam", - "assign_ipv4": "false", - "assign_ipv6": "true" - }, - ``` - -1. Configure IPv6 support by adding the following variable settings to the environment for the `calico-node` container: - - | Variable name | Value | - | ------------------- | ------------ | - | `IP6` | `autodetect` | - | `FELIX_IPV6SUPPORT` | `true` | - - :::note - - If your IPv6 IP pools include private IP addresses, pods that are assigned private IP addresses cannot perform outbound NAT by default. - - To enable outbound NAT for these pods, add `CALICO_IPV6POOL_NAT_OUTGOING: true` to the environment of the `calico-node` container. - - ::: - -1. For clusters **not** provisioned with kubeadm (see note below), configure the default IPv6 IP pool by adding the following variable setting to the environment for the `calico-node` container: - - | Variable name | Value | - | ---------------------- | ------------------------------------------------------------------------------------------------------- | - | `CALICO_IPV6POOL_CIDR` | the same as the IPv6 range you configured as the cluster CIDR to kube-controller-manager and kube-proxy | - - :::note - - For clusters provisioned with kubeadm, $[prodname] autodetects the IPv4 and IPv6 pod CIDRs and does not require configuration. - - ::: - -1. Apply the edited manifest with `kubectl apply -f`. - - New pods will get IPv6 addresses, and can communicate with each other and the outside world over IPv6. - -**(Optional) Update host to not look for IPv4 addresses** - -If you want your workloads to have IPv6 addresses only, because you do not have IPv4 addresses or connectivity -between your nodes, complete these additional steps to tell $[prodname] not to look for any IPv4 addresses. - -1. Disable [IP autodetection of IPv4](ip-autodetection.mdx) by setting `IP` to `none`. -1. Calculate the $[prodname] BGP router ID for IPv6 using either of the following methods. - - Set the environment variable `CALICO_ROUTER_ID=hash` on $[nodecontainer]. - This configures $[prodname] to calculate the router ID based on the hostname. - - Pass a unique value for `CALICO_ROUTER_ID` to each node individually. - - - - -### Enable dual stack - -1. Set up a new cluster following the Kubernetes [prerequisites](https://kubernetes.io/docs/concepts/services-networking/dual-stack/#prerequisites) and [enablement steps](https://kubernetes.io/docs/concepts/services-networking/dual-stack/#enable-ipv4-ipv6-dual-stack). - - - - -To configure dual-stack cluster using the operator, edit your default Installation at install time to include both an IPv4 and IPv6 pool. For example: - -```yaml -apiVersion: operator.tigera.io/v1 -kind: Installation -metadata: - name: default -spec: - # Configures Calico networking. - calicoNetwork: - ipPools: - - blockSize: 26 - cidr: 10.48.0.0/21 - encapsulation: IPIP - natOutgoing: Enabled - nodeSelector: all() - - blockSize: 122 - cidr: 2001::00/64 - encapsulation: None - natOutgoing: Enabled - nodeSelector: all() -``` - - - - -1. Using the [$[prodname] Kubernetes install guide](../../getting-started/kubernetes/self-managed-onprem/onpremises.mdx), download the correct $[prodname] manifest for the cluster and datastore type. - -1. Edit the CNI config (`calico-config` ConfigMap in the manifest), and enable IPv4 and IPv6 address allocation by setting both fields to true. - - ```json - "ipam": { - "type": "calico-ipam", - "assign_ipv4": "true", - "assign_ipv6": "true" - }, - ``` - -1. Configure IPv6 support by adding the following variable settings to the environment for the `calico-node` container: - - | Variable name | Value | - | ------------------- | ------------ | - | `IP6` | `autodetect` | - | `FELIX_IPV6SUPPORT` | `true` | - - :::note - - If your IPv6 IP pools include private IP addresses, pods that are assigned private IP addresses cannot perform outbound NAT by default. - - To enable outbound NAT for these pods, add `CALICO_IPV6POOL_NAT_OUTGOING: true` to the environment of the `calico-node` container. - - ::: - -1. For clusters **not** provisioned with kubeadm (see note below), configure the default IPv6 IP pool by adding the following variable setting to the environment for the `calico-node` container: - - | Variable name | Value | - | ---------------------- | ------------------------------------------------------------------------------------------------------------ | - | `CALICO_IPV6POOL_CIDR` | the same as the IPv6 range you configured as the IPv6 cluster CIDR to kube-controller-manager and kube-proxy | - - :::note - - For clusters provisioned with kubeadm, $[prodname] autodetects the IPv4 and IPv6 pod CIDRs and does not require configuration. - - ::: - -1. Apply the edited manifest with `kubectl apply -f`. - - New pods will get both IPv4 and IPv6 addresses, and can communicate with each other and the outside world over IPv4 or IPv6. - - - - -## Additional resources - -- [Configure Kubernetes control plane to operate over IPv6](ipv6-control-plane.mdx) diff --git a/calico_versioned_docs/version-3.29/networking/ipam/legacy-firewalls.mdx b/calico_versioned_docs/version-3.29/networking/ipam/legacy-firewalls.mdx deleted file mode 100644 index 5f853ea844..0000000000 --- a/calico_versioned_docs/version-3.29/networking/ipam/legacy-firewalls.mdx +++ /dev/null @@ -1,66 +0,0 @@ ---- -description: Restrict the IP address chosen for a pod to a specific range of IP addresses. ---- - -# Restrict a pod to use an IP address in a specific range - -import DetermineIpam from '@site/calico_versioned_docs/version-3.29/_includes/content/_determine-ipam.mdx'; - -## Big picture - -Restrict the IP address chosen for a pod to a specific range of IP addresses. - -## Value - -When Kubernetes pods interact with external systems that make decisions based on IP ranges (for example legacy firewalls), it can be useful to define several IP ranges and explicitly assign pods to those ranges. Using $[prodname] IP Address Management (IPAM), you can restrict a pod to use an address from within a specific range. - -## Concepts - -### Kubernetes pod CIDR - -The **Kubernetes pod CIDR** is the range of IPs Kubernetes expects pod IPs to be assigned from. It is defined for the entire cluster and is used by various Kubernetes components to determine whether an IP belongs to a pod. For example, kube-proxy treats traffic differently if that traffic is from a pod than if it is not. All pod IPs must be in the CIDR range for Kubernetes to function correctly. - -### IP Pool - -**IP pools** are ranges of IP addresses from which $[prodname] assigns pod IPs. By default, $[prodname] creates an IP pool for the entire Kubernetes pod CIDR, but you can change this to break the pod CIDR up into several pools. You can control which pool $[prodname] uses for each pod using node selectors, or annotations on the pod or the pod’s namespace. - -## Before you begin... - -The features in this How to guide require: - -- $[prodname] IPAM - - - -Additionally, cluster administrators must have [configured IP pools](../../reference/resources/ippool.mdx) to define the valid IP ranges to use for allocating pod IP addresses. - -## How to - -### Restrict a pod to use an IP address range - -Annotate the pod with key `cni.projectcalico.org/ipv4pools` and/or `cni.projectcalico.org/ipv6pools` and value set to a list of IP pool names, enclosed in brackets. For example: - -``` -cni.projectcalico.org/ipv4pools: '["pool-1", "pool-2"]' -``` - -Note the use of the escaped \" for the inner double quotes around the pool names. - -### Restrict all pods within a namespace to use an IP address range - -Annotate the namespace with key `cni.projectcalico.org/ipv4pools` and/or `cni.projectcalico.org/ipv6pools` and value set to a list of IP pool names, enclosed in brackets. For example: - -``` -cni.projectcalico.org/ipv4pools: '["pool-1", "pool-2"]' - -``` - -Note the use of the escaped `\"` for the inner double quotes around the pool names. - -If both the pod and the pod’s namespace have the annotation, the pod annotation takes precedence. - -The annotation must be present at the time the pod is created. Adding it to an existing pod has no effect. - -## Additional resources - -For help configuring $[prodname] IPAM, see [Configuring the $[prodname] CNI Plugins](../../reference/configure-cni-plugins.mdx). diff --git a/calico_versioned_docs/version-3.29/networking/ipam/migrate-pools.mdx b/calico_versioned_docs/version-3.29/networking/ipam/migrate-pools.mdx deleted file mode 100644 index 6234611b46..0000000000 --- a/calico_versioned_docs/version-3.29/networking/ipam/migrate-pools.mdx +++ /dev/null @@ -1,338 +0,0 @@ ---- -description: Migrate pods from one IP pool to another on a running cluster without network disruption. ---- - -# Migrate from one IP pool to another - -import DetermineIpam from '@site/calico_versioned_docs/version-3.29/_includes/content/_determine-ipam.mdx'; -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - -## Big picture - -Migrate pods from one IP pool to another on a running cluster without network disruption. - -## Value - -Pods are assigned IP addresses from IP pools that you configure in $[prodname]. As the number of pods increase, you may need to increase the number of addresses available for pods to use. Or, you may need to move pods from a CIDR that was used by mistake. $[prodname] lets you migrate from one IP pool to another one on a running cluster without network disruption. - -## Concepts - -### IP pools and cluster CIDRs - -$[prodname] supports using multiple disjoint IP pool CIDRs within the cluster. However, Kubernetes expects that all pods have addresses within the same cluster CIDR. This means that although it is technically feasible to create an IP pool outside of the cluster CIDR, we do not recommend it. Pods allocated addresses outside of the Kubernetes cluster CIDR will lose network connectivity. - -## Before you begin... - -**Verify that you are using $[prodname] IPAM**. - - - -**Verify orchestrator support for changing the pod network CIDR**. - -Although Kubernetes supports changing the pod network CIDR, not all orchestrators do. Check your orchestrator documentation to verify. - -## How to - -### Migrate from one IP pool to another - -Follow these steps to migrate pods from one IP pool to another pool. - -:::note - -If you follow these steps, existing pod connectivity will not be affected. (If you delete the old IP pool before you create and verify the new pool, existing pods will be affected.) When pods are deleted, applications may be temporarily unavailable (depending on the type of application); plan accordingly. - -::: - -1. Add a new IP pool. - - :::note - - It is highly recommended that your Calico IP pools are within the Kubernetes cluster CIDR. If pods IPs are allocated from outside of the Kubernetes cluster CIDR, some traffic flows may have NAT applied unnecessarily causing unexpected behavior. - - ::: - -1. Disable the old IP pool. - - :::note - - Disabling an IP pool only prevents new IP address allocations; it does not affect the networking of existing pods. - - ::: - -1. Delete pods from the old IP pool. This includes any new pods that may have been created with the old IP pool prior to disabling the pool. - -1. Verify that new pods get an address from the new IP pool. - -1. Delete the old IP pool. - -## Tutorial - -In the following example, we created a Kubernetes cluster using **kubeadm**. But the IP pool CIDR we configured (192.168.0.0/16) doesn't match the -Kubernetes cluster CIDR. Let's change the CIDR to **10.0.0.0/16**, which for the purposes of this example falls within the cluster CIDR. - - - - -Let’s run `kubectl get ippools` to see the IP pool `default-ipv4-ippool`. - -``` -NAME CREATED AT -default-ipv4-ippool 2024-03-28T16:14:28Z -``` - -### Step 1: Add a new IP pool - -We add a new `IPPool` resource with the CIDR range `10.0.0.0/16`. - -Add the following to your `default` installation, below the existing IP pool. - -```bash -kubectl edit installation default -``` - -```yaml -- name: new-ipv4-pool - cidr: 10.0.0.0/16 - encapsulation: IPIP -``` - -Let’s verify the new IP pool. - -```bash -kubectl get ippools -``` - -``` -NAME CREATED AT -default-ipv4-ippool 2024-03-28T16:14:28Z -test-pool 2024-03-28T18:30:15Z -``` - -### Step 2: Disable the old IP pool - -Edit the `default` installation, and modify `default-ipv4-ippool` so it no longer selects -any nodes. This prevents IP allocation from the pool. - -```bash -kubectl edit installation default -``` - -```yaml -- name: 192.168.0.0-16 - allowedUses: - - Workload - - Tunnel - blockSize: 26 - cidr: 192.168.0.0/16 - disableBGPExport: false - encapsulation: VXLANCrossSubnet - natOutgoing: Enabled -- nodeSelector: all() -+ nodeSelector: "!all()" -``` - -Apply the changes. - -Remember, disabling a pool only affects new IP allocations; networking for existing pods is not affected. - -### Step 3: Delete pods from the old IP pool - -Next, we delete all of the existing pods from the old IP pool. (In our example, `coredns` is our only pod; for multiple pods you would trigger a deletion for all pods in the cluster.) - -```bash -kubectl delete pod -n kube-system coredns-6f4fd4bdf-8q7zp -``` - -### Step 4: Verify that new pods get an address from the new IP pool - -1. Create a test namespace and nginx pod. - - ```bash - kubectl create ns ippool-test - ``` - -1. Create an nginx pod. - - ```bash - kubectl -n ippool-test create deployment nginx --image nginx - ``` - -1. Verify that the new pod gets an IP address from the new range. - - ```bash - kubectl -n ippool-test get pods -l app=nginx -o wide - ``` - -1. Clean up the `ippool-test` namespace. - - ```bash - kubectl delete ns ippool-test - ``` - -### Step 5: Delete the old IP pool - -Now that you've verified that pods are getting IPs from the new range, you can safely delete the old pool. To do this, -remove it from the default installation, leaving only the newly create IP pool. - - - - -Let’s run `calicoctl get ippool -o wide` to see the IP pool, `default-ipv4-ippool`. - -``` -NAME CIDR NAT IPIPMODE VXLANMODE DISABLED -default-ipv4-ippool 192.168.0.0/16 true Always Never false -``` - -When we run `calicoctl get wep --all-namespaces`, we see that a pod is created using the default range (192.168.52.130/32). - -``` -NAMESPACE WORKLOAD NODE NETWORKS INTERFACE -kube-system coredns-6f4fd4bdf-8q7zp vagrant 192.168.52.130/32 cali800a63073ed -``` - -Let’s get started changing this pod to the new IP pool (10.0.0.0/16). - -### Step 1: Add a new IP pool - -We add a new **IPPool** with the CIDR range, **10.0.0.0/16**. - -```yaml -apiVersion: projectcalico.org/v3 -kind: IPPool -metadata: - name: new-pool -spec: - cidr: 10.0.0.0/16 - ipipMode: Always - natOutgoing: true -``` - -Let’s verify the new IP pool. - -```bash -calicoctl get ippool -o wide - -``` - -``` -NAME CIDR NAT IPIPMODE DISABLED -default-ipv4-ippool 192.168.0.0/16 true Always false -new-pool 10.0.0.0/16 true Always false -``` - -### Step 2: Disable the old IP pool - -List the existing IP pool definition. - -```bash -calicoctl get ippool -o yaml > pools.yaml - -``` - -```yaml -apiVersion: projectcalico.org/v3 -items: - - apiVersion: projectcalico.org/v3 - kind: IPPool - metadata: - name: default-ipv4-ippool - spec: - cidr: 192.0.0.0/16 - ipipMode: Always - natOutgoing: true - - apiVersion: projectcalico.org/v3 - kind: IPPool - metadata: - name: new-pool - spec: - cidr: 10.0.0.0/16 - ipipMode: Always - natOutgoing: true -``` - -Edit pools.yaml. - -Disable this IP pool by setting: `disabled: true` - -```yaml -apiVersion: projectcalico.org/v3 -kind: IPPool -metadata: - name: default-ipv4-ippool -spec: - cidr: 192.0.0.0/16 - ipipMode: Always - natOutgoing: true - disabled: true -``` - -Apply the changes. - -Remember, disabling a pool only affects new IP allocations; networking for existing pods is not affected. - -```bash -calicoctl apply -f pools.yaml -``` - -Verify the changes. - -```bash -calicoctl get ippool -o wide -``` - -``` -NAME CIDR NAT IPIPMODE DISABLED -default-ipv4-ippool 192.168.0.0/16 true Always true -new-pool 10.0.0.0/16 true Always false -``` - -### Step 3: Delete pods from the old IP pool - -Next, we delete all of the existing pods from the old IP pool. (In our example, **coredns** is our only pod; for multiple pods you would trigger a deletion for all pods in the cluster.) - -```bash -kubectl delete pod -n kube-system coredns-6f4fd4bdf-8q7zp -``` - -### Step 4: Verify that new pods get an address from the new IP pool - -1. Create a test namespace and nginx pod. - - ```bash - kubectl create ns ippool-test - ``` - -1. Create an nginx pod. - - ```bash - kubectl -n ippool-test create deployment nginx --image nginx - ``` - -1. Verify that the new pod gets an IP address from the new range. - - ```bash - kubectl -n ippool-test get pods -l app=nginx -o wide - ``` - -1. Clean up the `ippool-test` namespace. - - ```bash - kubectl delete ns ippool-test - ``` - -### Step 5: Delete the old IP pool - -Now that you've verified that pods are getting IPs from the new range, you can safely delete the old pool. - -```bash -calicoctl delete pool default-ipv4-ippool -``` - - - - -## Additional resources - -- [IP pools reference](../../reference/resources/ippool.mdx) diff --git a/calico_versioned_docs/version-3.29/networking/ipam/use-specific-ip.mdx b/calico_versioned_docs/version-3.29/networking/ipam/use-specific-ip.mdx deleted file mode 100644 index 44a7001c8b..0000000000 --- a/calico_versioned_docs/version-3.29/networking/ipam/use-specific-ip.mdx +++ /dev/null @@ -1,65 +0,0 @@ ---- -description: Specify the IP address for a pod instead of allowing Calico to automatically choose one. ---- - -# Use a specific IP address with a pod - -import DetermineIpam from '@site/calico_versioned_docs/version-3.29/_includes/content/_determine-ipam.mdx'; - -## Big picture - -Choose the IP address for a pod instead of allowing Calico to choose automatically. - -## Value - -Some applications require the use of stable IP addresses. Also, you may want to create entries in external DNS servers that point directly to pods, and this requires static IPs. - -## Concepts - -### Kubernetes pod CIDR - -The **Kubernetes pod CIDR** is the range of IPs Kubernetes expects pod IPs to be assigned from. It is defined for the entire cluster and is used by various Kubernetes components to determine whether an IP belongs to a pod. For example, kube-proxy treats traffic differently if an IP is from a pod than if it is not. All pod IPs must be in the CIDR range for Kubernetes to function correctly. - -**IP Pools** - -IP pools are ranges of IP addresses from which Calico assigns pod IPs. Static IPs must be in an IP pool. - -## Before you begin... - -Your cluster must be using Calico IPAM to use this feature. - - - -## How to - -Annotate the pod with cni.projectcalico.org/ipAddrs set to a list of IP addresses to assign, enclosed in brackets. For example: - -``` - "cni.projectcalico.org/ipAddrs": "[\"192.168.0.1\", \"2001:db8::1\"]" -``` - -Note the use of the escaped `\"` for the inner double quotes around the addresses. - -The address must be within a configured Calico IP pool and not currently in use. The annotation must be present when the pod is created; adding it later has no effect. - -Note that currently only a single IP address per IP family is supported per-pod using this annotation. - -### Reserving IPs for manual assignments - -The `cni.projectcalico.org/ipAddrs` annotation requires the IP address to be within an IP pool. This means that, -by default, $[prodname] may decide to use the IP address that you select for another workload or for an internal -tunnel address. To prevent this, there are several options: - -- To reserve a whole IPPool for manual allocations, you can set its [node selector](../../reference/resources/ippool.mdx) to `"!all()"`. Since the `!all()` - cannot match any nodes, the IPPool will not be used for any automatic assignments. - -- To reserve part of a pool, you can create an [`IPReservation` resource](../../reference/resources/ipreservation.mdx). This allows for certain IPs to be reserved so - that Calico IPAM will not use them automatically. However, manual assignments (using the annotation) can still use - IPs that are "reserved". - -- To prevent $[prodname] from using IPs from a certain pool for internal IPIP and/or VXLAN tunnel addresses, you - can set the `allowedUses` field on the [IPPool](../../reference/resources/ippool.mdx) to `["Workload"]`. - -## Additional resources - -For help configuring Calico CNI and Calico IPAM, see [Configuring the Calico CNI Plugins](../../reference/configure-cni-plugins.mdx). diff --git a/calico_versioned_docs/version-3.29/networking/openstack/configuration.mdx b/calico_versioned_docs/version-3.29/networking/openstack/configuration.mdx deleted file mode 100644 index 3d1326e958..0000000000 --- a/calico_versioned_docs/version-3.29/networking/openstack/configuration.mdx +++ /dev/null @@ -1,87 +0,0 @@ ---- -description: Configure OpenStack components for Calico. ---- - -# Configure systems for use with Calico - -When running $[prodname] with OpenStack, you also need to configure various -OpenStack components, as follows. - -## Nova (/etc/nova/nova.conf) - -$[prodname] uses the Nova metadata service to provide metadata to VMs, -without any proxying by Neutron. To make that work: - -- An instance of the Nova metadata API must run on every compute node. -- `/etc/nova/nova.conf` must not set `service_neutron_metadata_proxy` - or `service_metadata_proxy` to `True`. (The default `False` value is - correct for a $[prodname] cluster.) - -## Neutron server (/etc/neutron/neutron.conf) - -In `/etc/neutron/neutron.conf` you need the following settings to -configure the Neutron service. - -| Setting | Value | Meaning | -| -------------------- | --------- | ---------------------------------------- | -| core_plugin | calico | Use the $[prodname] core plugin | -| -------------------- | --------- | ---------------------------------------- | - -$[prodname] can operate either as a core plugin or as an ML2 mechanism driver. The -function is the same both ways, except that floating IPs are only supported -when operating as a core plugin; hence the recommended setting here. - -However, if you don't need floating IPs and have other reasons for using ML2, -you can, instead, set - -| Setting | Value | Meaning | -| -------------------- | -------------------------------------- | ---------------------- | -| core_plugin | neutron.plugins.ml2.plugin.ML2Plugin | Use ML2 plugin | -| -------------------- | -------------------------------------- | ---------------------- | - -and then the further ML2-specific configuration as covered below. - -The following options in the `[calico]` section of `/etc/neutron/neutron.conf` govern how -the $[prodname] plugin/driver and DHCP agent connect to the $[prodname] etcd -datastore. You should set `etcd_host` to the IP of your etcd server, and `etcd_port` if -that server is using a non-standard port. If the etcd server is TLS-secured, also set: - -- `etcd_cert_file` to a client certificate, which must be signed by a Certificate - Authority that the server trusts - -- `etcd_key_file` to the corresponding private key file - -- `etcd_ca_cert_file` to a file containing data for the Certificate Authorities that you - trust to sign the etcd server's certificate. - -| Setting | Default Value | Meaning | -| ----------------- | ------------- | ------------------------------------------------------------ | -| etcd_host | 127.0.0.1 | The hostname or IP of the etcd server | -| etcd_port | 2379 | The port to use for the etcd node/proxy | -| etcd_key_file | | The path to the TLS key file to use with etcd | -| etcd_cert_file | | The path to the TLS client certificate file to use with etcd | -| etcd_ca_cert_file | | The path to the TLS CA certificate file to use with etcd | - -In a [multi-region deployment](multiple-regions.mdx), -`[calico] openstack_region` configures the name of the region that the local compute or controller -node belongs to. - -| Setting | Default Value | Meaning | -| ------------------ | ------------- | ---------------------------------------------------------------------------- | -| `openstack_region` | none | The name of the region that the local compute of controller node belongs to. | - -When specified, the value of `openstack_region` must be a string of lower case alphanumeric -characters or '-', starting and ending with an alphanumeric character, and must match the value of -[`OpenStackRegion`](../../reference/felix/configuration.mdx) -configured for the Felixes in the same region. - -## ML2 (.../ml2_conf.ini) - -In `/etc/neutron/plugins/ml2/ml2_conf.ini` you need the following -settings to configure the ML2 plugin. - -| Setting | Value | Meaning | -| -------------------- | ----------- | --------------------------------- | -| mechanism_drivers | calico | Use $[prodname] | -| type_drivers | local, flat | Allow 'local' and 'flat' networks | -| tenant_network_types | local, flat | Allow 'local' and 'flat' networks | diff --git a/calico_versioned_docs/version-3.29/networking/openstack/connectivity.mdx b/calico_versioned_docs/version-3.29/networking/openstack/connectivity.mdx deleted file mode 100644 index 5690a4f49c..0000000000 --- a/calico_versioned_docs/version-3.29/networking/openstack/connectivity.mdx +++ /dev/null @@ -1,255 +0,0 @@ ---- -description: Configure OpenStack networking for Calico. ---- - -# IP addressing and connectivity - -An OpenStack deployment is of limited use if its VMs cannot reach and be -reached by the outside world. This document will explain how to -configure your $[prodname]-based OpenStack deployment to ensure that you have -the desired connectivity with the outside world. - -## Major differences from standard OpenStack - -If you've deployed OpenStack before you'll be thinking in terms of -routers, floating IPs, and external networks. $[prodname]'s focus on -simplicity means that it doesn't use any of these concepts. This section -is mostly a warning: even if you think you know what you're doing, -please read the rest of this article. You might be surprised! - -## Setting up connectivity - -### Part 0: Deciding your address ranges - -For $[prodname], it's best to pick up to three address ranges you're going to -use from the following three options. If it's possible, use all three. - -The first option is an IPv6 address range, assuming you want your VMs to -have IPv6 connectivity. Note that you can only use this range if your -data center network can route IPv6 traffic. All IPv6 addresses should be -considered 'externally reachable', so this needs to be a range that will -be routed to your gateway router: ideally globally scoped. - -The second option is a 'private' IPv4 range, assuming you want your VMs -to have IPv4 connectivity. This is the most likely range for you to -configure. This range will contain all VMs that cannot be reached by -traffic that originates from outside the data center. - -The third option is a 'public' IPv4 range, assuming you want your VMs to -have IPv4 connectivity. This range will contain all the VMs that want to -be reachable by traffic that originates from outside the data center. -Make sure that traffic destined for this range from outside the data -center will be routed to your gateway, or nothing will work! - -The minimum requirement is one of those address ranges. - -### Part 1: Configuring the fabric - -Your $[prodname] deployment will require a gateway router. In most -non-trivial cases this will be a heavy-duty router, but if you're -deploying a smaller network (maybe for testing purposes) and don't have -access to one you can use a Linux server in the role. - -The gateway router needs to be on the default route for all of your -compute hosts. This is to ensure that all traffic destined to leave the -data center goes via the gateway. That means that in a flat L3 topology -the gateway router needs to be set as the next hop. In a more complex -setup such as a multi-tier L3 topology the next hop may need to be -slightly shorter, for example to a top-of-rack router, which will in -turn need to route towards the gateway router. - -Then, the gateway router needs to be a BGP peer of the $[prodname] network. -This could be a peer of one or more route reflectors, or in smaller -topologies directly peering with the compute hosts. This is to ensure it -knows the routes to all the VMs, so that it knows which way to route -traffic destined for them. Instructions for configuring your gateway -(and potentially BGP route reflectors) are beyond the scope of this -document. If you don't know how to do this or want to know how $[prodname] -fits into your existing deployment, please get in touch on our mailing -list: it is difficult to add a generic solution to this problem to this -article. - -If your gateway uses eBGP to advertise routes externally, you'll need to -configure the BGP policy on the gateway to ensure that it does not -export routes to the private IPv4 address range you configured above. -Otherwise, in smaller deployments, you just need to make sure that -external traffic destined for your VMs will get routed to the gateway. -How you do this is outside the scope of this document: please ask for -assistance on our mailing list. - -Finally, configure your gateway to do stateful PNAT for any traffic -coming from the IPv4 internal range. This ensures that even VMs that -cannot be directly reached from the external network can still contact -servers themselves, to do things like request software updates. -Again, the actual manner in which this is configured depends on your -router. - -### Part 2: Set up OpenStack - -In OpenStack, you want to set up two shared Neutron networks. For the -first, add one IPv4 subnet containing the 'external' IPv4 range. Make -sure the subnet has a gateway IP, and that DHCP is enabled. -Additionally, add one IPv6 subnet containing half your IPv6 range, again -with a gateway IP and DHCP enabled. Make sure this network has a name -that makes it clear that it's for your 'externally accessible' VMs. -Maybe even mark it an 'external' network, though that has no effect on -what $[prodname] does. - -For the second network, add one IPv4 subnet containing the 'private' -IPv4 range and one IPv6 subnet containing the other half of your IPv6 -range, both with gateway IPs and DHCP enabled. Make sure this network -has a name that makes it clear that it's for your 'private' VMs. Note -that if you give this network part of your IPv6 range these VMs will all -be reachable over IPv6. It is expected that all users will want to -deploy in this way, but if you don't, either don't give these VMs IPv6 -addresses or give them private ones that are not advertised by your -gateway. - -Then, configure the default network, subnet, router and floating IP -quota for all tenants to be 0 to prevent them from creating more -networks and confusing themselves! - -A sample configuration is below, showing the networks and two of the -four subnets (as they differ only in their address ranges, all other -configuration is the same). - -From the controller, issue the following Neutron CLI command. - -```bash -neutron net-list -``` - -It returns a list of the networks. - -``` -+--------------------------------------+----------+----------------------------------------------------------+ -| id | name | subnets | -+--------------------------------------+----------+----------------------------------------------------------+ -| 8d5dec25-a6aa-4e18-8706-a51637a428c2 | external | 54db559c-5e1d-4bdc-83b0-c479ef2a0ead 172.18.208.0/24 | -| | | cf6ceea0-dde0-4018-ab9a-f8f68935622b 2001:db8:a41:2::/64 | -| fa52b704-7b3c-4c83-8698-244807352711 | internal | 301b3e63-5324-4d62-8e22-ed8dddd50689 10.65.0.0/16 | -| | | bf94ccb1-c57c-4c9a-a873-c20cbfa4ecaf 2001:db8:a41:3::/64 | -+--------------------------------------+----------+----------------------------------------------------------+ -``` - -Next, check the details of the `external` network. - -```bash -neutron net-show external -``` - -It should return something like the following. - -``` -+---------------------------+--------------------------------------+ -| Field | Value | -+---------------------------+--------------------------------------+ -| admin_state_up | True | -| id | 8d5dec25-a6aa-4e18-8706-a51637a428c2 | -| name | external | -| provider:network_type | local | -| provider:physical_network | | -| provider:segmentation_id | | -| router:external | True | -| shared | True | -| status | ACTIVE | -| subnets | 54db559c-5e1d-4bdc-83b0-c479ef2a0ead | -| | cf6ceea0-dde0-4018-ab9a-f8f68935622b | -| tenant_id | ed34337f935745bb911eeb741bc4374b | -+---------------------------+--------------------------------------+ -``` - -Check the details of the `internal` network. - -```bash -neutron net-show internal -``` - -It should return something like the following. - -``` -+---------------------------+--------------------------------------+ -| Field | Value | -+---------------------------+--------------------------------------+ -| admin_state_up | True | -| id | fa52b704-7b3c-4c83-8698-244807352711 | -| name | internal | -| provider:network_type | local | -| provider:physical_network | | -| provider:segmentation_id | | -| router:external | False | -| shared | True | -| status | ACTIVE | -| subnets | 301b3e63-5324-4d62-8e22-ed8dddd50689 | -| | bf94ccb1-c57c-4c9a-a873-c20cbfa4ecaf | -| tenant_id | ed34337f935745bb911eeb741bc4374b | -+---------------------------+--------------------------------------+ -``` - -Check the `external4` subnet. - -```bash -neutron subnet-show external4 -``` - -It should return something like the following. - -``` -+------------------+----------------------------------------------------+ -| Field | Value | -+------------------+----------------------------------------------------+ -| allocation_pools | {"start": "172.18.208.2", "end": "172.18.208.255"} | -| cidr | 172.18.208.0/24 | -| dns_nameservers | | -| enable_dhcp | True | -| gateway_ip | 172.18.208.1 | -| host_routes | | -| id | 54db559c-5e1d-4bdc-83b0-c479ef2a0ead | -| ip_version | 4 | -| name | external4 | -| network_id | 8d5dec25-a6aa-4e18-8706-a51637a428c2 | -| tenant_id | ed34337f935745bb911eeb741bc4374b | -+------------------+----------------------------------------------------+ -``` - -Check the `external6` subnet. - -```bash -neutron subnet-show external6 -``` - -It should return something like the following. - -``` -+------------------+-----------------------------------------------------------------------------+ -| Field | Value | -+------------------+-----------------------------------------------------------------------------+ -| allocation_pools | {"start": "2001:db8:a41:2::2", "end": "2001:db8:a41:2:ffff:ffff:ffff:fffe"} | -| cidr | 2001:db8:a41:2::/64 | -| dns_nameservers | | -| enable_dhcp | True | -| gateway_ip | 2001:db8:a41:2::1 | -| host_routes | | -| id | cf6ceea0-dde0-4018-ab9a-f8f68935622b | -| ip_version | 6 | -| name | external6 | -| network_id | 8d5dec25-a6aa-4e18-8706-a51637a428c2 | -| tenant_id | ed34337f935745bb911eeb741bc4374b | -+------------------+-----------------------------------------------------------------------------+ -``` - -## Part 3: Start using your networks - -At this stage, all configuration is done! When you spin up a new VM, you -have to decide if you want it to be contactable from outside the data -center. If you do, give it a network interface on the `external` -network: otherwise, give it one on the `internal` network. Obviously, a -machine that originally wasn't going to be reachable can be made -reachable by plugging a new interface into it on the `external` network. - -Right now we don't support address mobility, so an address is tied to a -single port until that port is no longer in use. We plan to address this -in the future. - -The next step in configuring your OpenStack deployment is to configure -security. We'll have a document addressing this shortly. diff --git a/calico_versioned_docs/version-3.29/networking/openstack/dev-machine-setup.mdx b/calico_versioned_docs/version-3.29/networking/openstack/dev-machine-setup.mdx deleted file mode 100644 index da5573e374..0000000000 --- a/calico_versioned_docs/version-3.29/networking/openstack/dev-machine-setup.mdx +++ /dev/null @@ -1,133 +0,0 @@ ---- -description: Configure Calico networking for OpenStack VMs. ---- - -# Set up a development machine - -In this example, a user wants to spin up a machine to use as a Linux -development environment. This user has a straightforward use-case: they -want a GUI and SSH access, but relatively little else. - -This user is provisioned with a single OpenStack user and single -OpenStack tenant. Neutron will automatically provision them with a -single security group, `default`, that contains the following rules: - -- allow all inbound traffic from machines in the `default` security - group -- allow all outbound traffic to anywhere - -Per the instructions in [IP addressing and connectivity](connectivity.mdx), this user cannot create -Neutron networks or subnets, but they do have access to the networks -created by the administrator: `external` and `internal`. - -Because the user wants to be able to reach the machine from their own -laptop, they need the machine to be reachable from outside the data -center. In vanilla Neutron, this would mean provisioning it with a -floating IP, but in $[prodname] they instead want to make sure the VM is -attached to the `external` network. To add themselves to this network, -the user needs to find out the UUID for it. - -```bash -neutron net-list -``` - -This should return something like the following. - -``` -+--------------------------------------+----------+----------------------------------------------------------+ -| id | name | subnets | -+--------------------------------------+----------+----------------------------------------------------------+ -| 8d5dec25-a6aa-4e18-8706-a51637a428c2 | external | 54db559c-5e1d-4bdc-83b0-c479ef2a0ead 172.18.208.0/24 | -| | | cf6ceea0-dde0-4018-ab9a-f8f68935622b 2001:db8:a41:2::/64 | -| fa52b704-7b3c-4c83-8698-244807352711 | internal | 301b3e63-5324-4d62-8e22-ed8dddd50689 10.65.0.0/16 | -| | | bf94ccb1-c57c-4c9a-a873-c20cbfa4ecaf 2001:db8:a41:3::/64 | -+--------------------------------------+----------+----------------------------------------------------------+ -``` - -In the example above, the `external` network has the UUID -`8d5dec25-a6aa-4e18-8706-a51637a428c2`. Thus, the machine can be created -with the following `nova boot` command. - -```bash -nova boot --flavor m1.medium \ - --image debian-wheezy-amd64 \ - --security-groups default \ - --nic "netid=8d5dec25-a6aa-4e18-8706-a51637a428c2" \ - development-server -``` - -This places the VM with a single NIC in the `external` network. The VM -starts to boot, and Neutron allocates it an IP address in the `external` -network: in this case, both an IPv4 and IPv6 address, as you can see -below: - -``` -+--------------------------------------+-----------------------------------------------------------+ -| Property | Value | -+--------------------------------------+-----------------------------------------------------------+ -| external network | 2001:db8:a41:2::1c, 172.18.208.85 | -| flavor | m1.medium (3) | -| hostId | b80247c27400fc9048ca569c8635f00801654bf676a00d8f08887215 | -| id | e36f4e62-0efa-4188-87b8-8c96dc6e6028 | -| name | development-server | -| security_groups | default | -+--------------------------------------+-----------------------------------------------------------+ -``` - -While the machine boots, the security group can be configured. It needs -four extra rules: one for SSH and three for VNC. In this example, -developer's personal machine has the IPv4 address 191.64.52.12, and -that's the only machine they'd like to be able to access their machine. -For that reason, they add the four security group rules as follows. - -To add the SSH ingress rule: - -```bash -neutron security-group-rule-create --protocol tcp \ - --port-range-min 22 \ - --port-range-max 22 \ - --direction ingress \ - --remote-ip-prefix 191.64.52.12/32 \ - --ethertype IPv4 \ - default -``` - -To add the first VNC rule: - -```bash -neutron security-group-rule-create --protocol tcp \ - --port-range-min 5800 \ - --port-range-max 5801 \ - --direction ingress \ - --remote-ip-prefix 191.64.52.12/32 \ - --ethertype IPv4 \ - default -``` - -To add the second VNC rule: - -```bash -neutron security-group-rule-create --protocol tcp \ - --port-range-min 5900 \ - --port-range-max 5901 \ - --direction ingress \ - --remote-ip-prefix 191.64.52.12/32 \ - --ethertype IPv4 \ - default -``` - -To add the third VNC rule: - -```bash -neutron security-group-rule-create --protocol tcp \ - --port-range-min 6000 \ - --port-range-max 6001 \ - --direction ingress \ - --remote-ip-prefix 191.64.52.12/32 \ - --ethertype IPv4 \ - default -``` - -At this stage, the developer's machine is up and running. It can be -reached on its public IP (172.18.208.85), and the developer confirms -this by SSHing into their box. They're now ready to go. diff --git a/calico_versioned_docs/version-3.29/networking/openstack/floating-ips.mdx b/calico_versioned_docs/version-3.29/networking/openstack/floating-ips.mdx deleted file mode 100644 index a1d33122c5..0000000000 --- a/calico_versioned_docs/version-3.29/networking/openstack/floating-ips.mdx +++ /dev/null @@ -1,129 +0,0 @@ ---- -description: Configure floating IPs in Calico for OpenStack. ---- - -# Floating IPs - -Calico includes beta support for floating IPs. Currently this -requires running $[prodname] as a Neutron core plugin (i.e. `core_plugin = calico`) instead of as an ML2 mechanism driver. - -:::note - -We would like it to work as an ML2 mechanism driver too—patches -and/or advice welcome! - -::: - -To set up a floating IP, you need the same pattern of Neutron data model -objects as you do for Neutron in general, which means: - -- a tenant network, with an instance attached to it, that will be the target of - the floating IP - -- a Neutron router, with the tenant network connected to it - -- a provider network with `router:external True` that is set as the - router's gateway (e.g. with `neutron router-gateway-set`), and with a - subnet with a CIDR that floating IPs will be allocated from - -- a floating IP, allocated from the provider network subnet, that maps onto the - instance attached to the tenant network. - -For example: - -1. Create tenant network and subnet. - - ```bash - neutron net-create --shared calico - neutron subnet-create --gateway 10.65.0.1 --enable-dhcp --ip-version 4 --name calico-v4 calico 10.65.0.0/24 - ``` - -1. Boot a VM on that network. - - ```bash - nova boot [...] - ``` - -1. Find its Neutron port ID. - - ```bash - neutron port-list - ``` - -1. Create an external network and subnet; this is where floating - IPs will be allocated from. - - ```bash - neutron net-create public --router:external True - neutron subnet-create public 172.16.1.0/24 - ``` - -1. Create a router connecting the tenant and external networks. - - ```bash - neutron router-create router1 - neutron router-interface-add router1 - neutron router-gateway-set router1 public - ``` - -1. Create a floating IP and associate it with the target VM. - - ```bash - neutron floatingip-create public - neutron floatingip-associate - ``` - - Then the $[prodname] agents will arrange that the floating IP is routed to the - instance's compute host, and then DNAT'd to the instance's fixed IP address. - -1. From a compute node, issue the following command. - - ```bash - ip r - ``` - - It should return the routing table. - - ``` - default via 10.240.0.1 dev eth0 - 10.65.0.13 dev tap9a7e0868-da scope link - 10.65.0.14 via 192.168.8.4 dev l2tpeth8-3 proto bird - 10.65.0.23 via 192.168.8.4 dev l2tpeth8-3 proto bird - 10.240.0.1 dev eth0 scope link - 172.16.1.3 dev tap9a7e0868-da scope link - 192.168.8.0/24 dev l2tpeth8-3 proto kernel scope link src 192.168.8.3 - 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 - ``` - -1. Issue the following command to review iptables. - - ```bash - sudo iptables -L -n -v -t nat - ``` - - It should return something like the following. - - ``` - [...] - Chain felix-FIP-DNAT (2 references) - pkts bytes target prot opt in out source destination - 0 0 DNAT all -- * * 0.0.0.0/0 172.16.1.3 to:10.65.0.13 - - Chain felix-FIP-SNAT (1 references) - pkts bytes target prot opt in out source destination - 0 0 SNAT all -- * * 10.65.0.13 10.65.0.13 to:172.16.1.3 - - Chain felix-OUTPUT (1 references) - pkts bytes target prot opt in out source destination - 1 60 felix-FIP-DNAT all -- * * 0.0.0.0/0 0.0.0.0/0 - - Chain felix-POSTROUTING (1 references) - pkts bytes target prot opt in out source destination - 1 60 felix-FIP-SNAT all -- * * 0.0.0.0/0 0.0.0.0/0 - - Chain felix-PREROUTING (1 references) - pkts bytes target prot opt in out source destination - 0 0 felix-FIP-DNAT all -- * * 0.0.0.0/0 0.0.0.0/0 - 0 0 DNAT tcp -- * * 0.0.0.0/0 169.254.169.254 tcp dpt:80 to:127.0.0.1:8775 - [...] - ``` diff --git a/calico_versioned_docs/version-3.29/networking/openstack/host-routes.mdx b/calico_versioned_docs/version-3.29/networking/openstack/host-routes.mdx deleted file mode 100644 index ce8470c391..0000000000 --- a/calico_versioned_docs/version-3.29/networking/openstack/host-routes.mdx +++ /dev/null @@ -1,85 +0,0 @@ ---- -description: Options for host routing with Calico. ---- - -# Host routes - -Neutron allows "host routes" to be configured on a subnet, with each host route -comprising - -- an IP destination prefix -- a next hop IP for routing to that prefix. - -When an instance is launched and gets an IP from that subnet, Neutron arranges, -via DHCP, that the instance's routing table gets those routes. - -## With $[prodname], a host route's next hop IP should be the local host - -Calico supports host routes, but it's important to note that a host -route is only consistent with $[prodname] when its next hop IP represents the local -hypervisor. This is because the local hypervisor, in a $[prodname] setup, _always_ -routes all data from an instance and so is always the next hop IP for data to -any destination. If the instance's routing table has a route with some other -next hop IP, that next hop IP address will effectively be ignored, and the data -will likely _not_ pass through the implied router; instead the data will go -first to the hypervisor, and then the hypervisor's routing table will determine -its next IP hop from there. - -Specifically, each host route's next hop IP should be the gateway IP of the -subnet that the desired instance NIC is attached to, and from which it got its -IP address - where 'desired instance NIC' means the one that you want data for -that host route to go through. In Calico's usage, subnet gateway -IPs represent the local hypervisor, because data sent by an instance is always -routed there. - -:::note - -Calico avoids unnecessary IP usage by using the subnet -gateway IP to represent the local compute host, on every compute host where -that subnet is being used. Although that might initially sound odd, it works -because no data is ever sent to or from the gateway IP address; the gateway -IP is only used as the next hop address for the first IP hop from an instance -to its compute host, and then the compute host routes the data again, -according to its routing table, to wherever it needs to go. This also means -that the gateway IP address really is functioning as each instance's default -gateway, in the generally understood sense. - -::: - -## When are host routes useful with $[prodname]? - -Host routes are useful with $[prodname] when an instance has multiple NICs and you -want to specify which NIC should be used for data to particular prefixes. - -When an instance has multiple NICs, it should have a default route through only -one of those NICs, and use non-default routes to direct appropriate traffic -through the other NICs. Neutron host routes can be used to establish those -non-default routes; alternatively they can also be programmed manually in the -instance. - -For example, suppose an instance has eth0 attached to a subnet with gateway -10.65.0.1, eth1 attached to a subnet with gateway 11.8.0.1, and a default route -via eth0. Then a host route like - -```bash -11.11.0.0/16,11.8.0.1 -``` - -can be configured for the subnet, to say that data to 11.11.0.0/16 should go -out through eth1. The instance's routing table will then be: - -```bash -default via 10.65.0.1 dev eth0 -10.65.0.0/24 dev eth0 -11.8.0.0/24 dev eth1 -11.11.0.0/16 via 11.8.0.1 dev eth1 -``` - -When an instance only has a single network attachment, and so a single NIC, -host routes cannot make any difference to how data is routed, so it is -unhelpful (although also harmless) to configure them. Regardless of what the -instance's routing table says, data must exit over the single NIC, and is -always layer-2-terminated and rerouted by the host according to the host's -routing table. It's required for the host's routing table to cover whatever -destinations instances may want to send to, and host routes don't add anything -to that. diff --git a/calico_versioned_docs/version-3.29/networking/openstack/index.mdx b/calico_versioned_docs/version-3.29/networking/openstack/index.mdx deleted file mode 100644 index 372f82ee43..0000000000 --- a/calico_versioned_docs/version-3.29/networking/openstack/index.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: Configure Calico networking in an OpenStack deployment. -hide_table_of_contents: true ---- - -# Calico networking for OpenStack - -import DocCardList from '@theme/DocCardList'; -import { useCurrentSidebarCategory } from '@docusaurus/theme-common'; - - diff --git a/calico_versioned_docs/version-3.29/networking/openstack/ipv6.mdx b/calico_versioned_docs/version-3.29/networking/openstack/ipv6.mdx deleted file mode 100644 index 7a26c3244c..0000000000 --- a/calico_versioned_docs/version-3.29/networking/openstack/ipv6.mdx +++ /dev/null @@ -1,56 +0,0 @@ ---- -description: Prepare a VM guest OS for IPv6. ---- - -# Prepare a VM guest OS for IPv6 - -## Big picture - -Prepare a VM guest OS for IPv6. - -## How to - -OpenStack (not $[prodname]) controls whether a VM gets IPv4, IPv6, or both addresses. Calico simply honors the addresses that OpenStack specifies. The following extra steps are required for **IPv6 only** and **dual stack** deployments -- so the guest OS can learn its IPv6 address (if assigned by OpenStack). - -1. Verify that the guest VM image meets these requirements for IPv6 connectivity. - - - When booting up, the VM must issue a DHCPv6 request for each of its interfaces, so that it can learn the IPv6 addresses that OpenStack allocates for it. If the VM uses the widely-deployed **DHCP client from ISC**, it must have a fix/workaround for [this known issue](https://kb.isc.org/docs/aa-01141). - - The VM must be configured to accept router advertisements. - - Although not all common cloud images meet these requirements yet, it is easy to remedy by launching an image, making appropriate changes to its configuration files, taking a snapshot, and then using the snapshot thereafter instead of the original image. - - For example, starting from an **Ubuntu cloud image**, the following changes meet the requirements listed. - - - In `/etc/network/interfaces.d/eth0.cfg`, add: - ```bash - iface eth0 inet6 dhcp - accept_ra 1 - ``` - - - In `/sbin/dhclient-script`, add at the start of the script: - ```bash - `new_ip6_prefixlen=128` - ``` - - - In `/etc/sysctl.d`, create a file named `30-eth0-rs-delay.conf` with - contents: - ```bash - `net.ipv6.conf.eth0.router_solicitation_delay = 10` - ``` - - For **CentOS**, these additions to a cloud-init script have been reported to be effective: - - runcmd: - - - `sed -i -e '$a'"IPV6INIT=yes" /etc/sysconfig/network-scripts/ifcfg-eth0` - - `sed -i -e '$a'"DHCPV6C=yes" /etc/sysconfig/network-scripts/ifcfg-eth0` - - `sed -i '/PATH/i\new_ip6_prefixlen=128' /sbin/dhclient-script` - - `systemctl restart network` - -1. Configure IPv6 support in $[prodname] by defining an IPv6 subnet in each Neutron network with: - - - The IPv6 address range that you want your VMs to use - - DHCP enabled - - IPv6 address mode set to DHCPv6 stateful - - We suggest that you initially configure both IPv4 and IPv6 subnets in each network. This allows handling VM images that support only IPv4 alongside those that support both IPv4 and IPv6, and allows a VM to be accessed over IPv4 in case this is needed to troubleshoot any issues with its IPv6 configuration. In principle, though, we are not aware of any problems with configuring and using IPv6-only networks in OpenStack. diff --git a/calico_versioned_docs/version-3.29/networking/openstack/kuryr.mdx b/calico_versioned_docs/version-3.29/networking/openstack/kuryr.mdx deleted file mode 100644 index a6d1274974..0000000000 --- a/calico_versioned_docs/version-3.29/networking/openstack/kuryr.mdx +++ /dev/null @@ -1,40 +0,0 @@ ---- -description: Use Kuryr with Calico networking. ---- - -# Kuryr - -Calico works with Kuryr; this means using Neutron, with the $[prodname] -ML2 driver, to provide networking for container workloads. - -You can use DevStack to install a single node $[prodname]/Kuryr system, with a -`local.conf` file like this: - -```bash -[[local|localrc]] -ADMIN_PASSWORD=015133ea2bdc46ed434c -DATABASE_PASSWORD=d0060b07d3f3631ece78 -RABBIT_PASSWORD=6366743536a8216bde26 -SERVICE_PASSWORD=91eb72bcafb4ddf246ab -SERVICE_TOKEN=c5680feca5e2c9c8f820 - -enable_plugin calico https://github.com/projectcalico/calico -enable_plugin kuryr git://git.openstack.org/openstack/kuryr -enable_service kuryr -enable_service etcd-server -enable_service docker-engine - -LOGFILE=stack.log -LOG_COLOR=False -``` - -Please follow general Kuryr instructions for creating a Docker network that -uses Kuryr as its backend, and for launching containers on that network. Then -if you look at the IP routing table and iptables, you will see $[prodname] routes to -the containers. - -## $[prodname] for containers without Kuryr - -The $[prodname] project also provides networking for containers more directly, -without Neutron and Kuryr as intermediaries. Please see [Getting Started](../../getting-started/index.mdx) - for details. diff --git a/calico_versioned_docs/version-3.29/networking/openstack/labels.mdx b/calico_versioned_docs/version-3.29/networking/openstack/labels.mdx deleted file mode 100644 index 9d3fcc1852..0000000000 --- a/calico_versioned_docs/version-3.29/networking/openstack/labels.mdx +++ /dev/null @@ -1,141 +0,0 @@ ---- -description: Use Calico labels to define policy for OpenStack VMs. ---- - -# Endpoint labels and operator policy - -When $[prodname] represents an OpenStack VM as a $[prodname] WorkloadEndpoint, -it puts labels on the WorkloadEndpoint to identify the project, network, security -groups and namespace that the VM belongs to. The deployment operator can use these -labels to configure $[prodname] policy that is additional to the policy defined -by OpenStack security groups, and that cannot be overridden by user-level security -group config. - -## VM endpoint labels - -For the VM's OpenStack project (previously known as 'tenant') and network, those -labels are: - -| Label Name | Value | -| ------------------------------------------------- | -------------------------------- | -| `projectcalico.org/openstack-project-id` | `` | -| `projectcalico.org/openstack-project-name` | `` | -| `projectcalico.org/openstack-project-parent-id` | `` | -| `projectcalico.org/openstack-network-name` | `` | - -For each security group that the VM belongs to, those labels are: - -| Label Name | Value | -| ------------------------------------------------------------- | ------------------------- | -| `sg.projectcalico.org/openstack-` | `` | -| `sg-name.projectcalico.org/openstack-` | `` | - -For the VM's $[prodname] namespace, the label is: - -| Label Name | Value | -| --------------------------------- | ---------------------- | -| `projectcalico.org/namespace` | `` | - -When `[calico] openstack_region` has been configured in `/etc/neutron/neutron.conf` (as -recommended for [multiple region deployments](multiple-regions.mdx)) the namespace will be -"openstack-region-" followed by the configured region name. Otherwise it is simply -"openstack". - -:::note - -To allow $[prodname] to provide the project name and parent ID labels, -you must give Neutron the 'admin' role within your cluster: - -``` -openstack role add --project service --user neutron admin -``` - -or some equivalent privilege that allows the Neutron server to do admin-level queries of -the Keystone database. This is because $[prodname]'s driver runs as part of the -Neutron server, and needs to query the Keystone database for the information for those -labels. If Neutron isn't sufficiently privileged, $[prodname] will fall back to -not generating those labels. - -::: - -:::note - -$[prodname] only allows certain characters in label names and values -(alphanumerics, '-', '\_', '.' and '/'), so if a project or security group name normally -has other characters, those will be replaced here by '\_'. Also there is a length -limit, so particularly long names may be truncated. - -::: - -:::note - -$[prodname] does not support changing project name or security group -name for a given ID associated with a VM after the VM has been created. It is -recommended that operators avoid any possible confusion here by not changing project -name for a particular project ID or security group name for particular security group -ID, post-creation. - -::: - -## Configuring operator policy - -Configuring operator policy requires the `calicoctl` executable, so you should -[install](../../operations/calicoctl/install.mdx) and -[configure calicoctl](../../operations/calicoctl/configure/overview.mdx) - if you -haven't done so already. - -- Calico for OpenStack deployments use an etcd datastore, so you should follow the - instructions for an etcd datastore. - -- The settings you need for etcd endpoints, and TLS credentials if your deployment uses - those, should match what you have in your - [`neutron.conf`](configuration.mdx) - and [Felix](../../reference/felix/configuration.mdx) - configurations. - -## Example - -Now you can configure $[prodname] operator policy that will apply before the policy -that is derived from OpenStack security groups. For example, to prevent any possible -communication between the "superman" and "lexluthor" projects, you could configure the -following. - -```bash -calicoctl apply -f - < - ``` - - where `` is the name of the region that the compute host belongs to. - -1. In `/etc/neutron/neutron.conf` on each controller and compute node, add - - ```conf - [calico] - openstack_region = - ``` - - where `` is the name of the region that the node belongs to. - -:::note - -the value specified for `OpenStackRegion` and `openstack_region` -must be a string of lower case alphanumeric characters or '-', starting and -ending with an alphanumeric character. - -::: - -:::caution - -If the Felix and Neutron values here do not match, OpenStack -will not be able to launch any VMs in that region, because the Neutron server -for the region will think that there are no working compute nodes. - -::: - -### Configuring OpenStack - -You should now create networks in your OpenStack regions as normal. e.g. - -```bash - neutron net-create --shared calico - neutron subnet-create --gateway 10.65.0.1 --enable-dhcp --ip-version 4 --name calico-v4 calico 10.65.0.0/24 -``` - -:::note - -that Calico networking provides a flat L3 network, -so _subnets across all regions must not overlap_. -For example, having 10.1.0.0/16 in one region and 10.2.0.0/16 in another -would be fine, but 10.1.0.0/16 and 10.1.200.0/24 would not. - -::: - -## Configuring cross-region policy - -Suppose that: - -- you have two regions - -- you have a set of VMs in one region belonging to security group - a7734e61-b545-452d-a3cd-0189cbd9747a - -- you have a set of VMs in another region belonging to security group - 85cc3048-abc3-43cc-89b3-377341426ac5 - -- you want to allow the second set of VMs to connect to port 80 of the first - set. - -You need to have [calicoctl installed and configured for your cluster](labels.mdx#configuring-operator-policy) -. Once that is in place, -you could achieve the desired connectivity by using calicoctl to -configure this $[prodname] policy: - -```bash -calicoctl apply -f - < -
    host_routes
    -
    These have no effect, as the compute nodes will route traffic - immediately after it egresses the VM.
    - - -## Ports - -In vanilla Neutron, a port represents a connection from a VM to a single -layer 2 Neutron network. Obviously, the meaning of this object changes -in a $[prodname] deployment: instead, a port is a connection from a VM to the -shared layer 3 network that $[prodname] builds in Neutron. - -All properties on a port work as normal, except for the following: - -
    -
    network_id
    -
    The network ID still controls which Neutron network the port is - attached to, and therefore still controls which Neutron subnets it - will be placed in. However, as per the note above, - the Neutron network that a port is placed in does not affect which - machines in the deployment it can contact.
    -
    - -### Extended Attributes: Port Binding Attributes - -The `binding:host-id` attribute works as normal. The following notes -apply to the other attributes: - -
    -
    binding:profile
    -
    This is unused in $[prodname].
    -
    binding:vnic_type
    -
    This field, if used, must be set to normal. If set to any - other value, $[prodname] will not correctly function!
    -
    - -## Quotas - -Neutron quotas function unchanged. - -In most deployments we recommend setting non-administrator tenant quotas -for almost all Neutron objects to zero. For more information, see [Set up OpenStack](connectivity.mdx#part-2-set-up-openstack). - -## Security Groups - -Security groups in vanilla OpenStack provide packet filtering processing -to individual ports. They can be used to limit the traffic a port may -issue. - -In $[prodname], security groups have all the same function. Additionally, -they serve to provide the connectivity-limiting function that in vanilla -OpenStack is provided by Neutron networks. - -All the attributes of security groups remain unchanged in $[prodname]. - -## Floating IPs - -Floating IPs are supported at beta level. For more information, see [Floating IPs](floating-ips.mdx). - -## Neutron Routers - -Calico provides connectivity by default between all Neutron networks, -regardless of whether there are Router objects between them in the Neutron data -model. See [Detailed semantics](semantics.mdx) for a -fuller explanation. Where isolation of a particular Neutron network is -desired, we recommend expressing that through security group rules. - -## QoS - -Calico for OpenStack implements some Neutron QoS policy fields: the `max_kbps` -and `max_burst_kbps` fields of bandwidth limit rules, and the `max_kpps` field -of packet rate limit rules. Calico also honours the `direction` field of these -rules, so these limits can be set independently for both ingress and egress -directions. - -:::note - -There is uncertainty as to whether `max_burst_kbps` is intended to configure -the burst *rate* or the burst *size*. Calico interprets it as the burst *rate* -and honours `neutron.conf` fields for configuring the burst *size*. - -::: - -There are also new Calico Neutron driver settings (cluster-wide, set in `neutron.conf`): - -- `[calico] max_ingress_connections_per_port` for imposing a maximum number of - ingress connections per Neutron port, and - -- `[calico] max_egress_connections_per_port` for imposing a maximum number of - egress connections per Neutron port. - -- `[calico] ingress_burst_kbits`, if non-zero, configures the maximum allowed - burst at peakrate, in the ingress direction. - -- `[calico] egress_burst_kbits`, if non-zero, configures the maximum allowed - burst at peakrate, in the egress direction. - -- `[calico] ingress_minburst_bytes`, if non-zero, configures the minimum burst - size for peakrate data, in the ingress direction. - -- `[calico] egress_minburst_bytes`, if non-zero, configures the minimum burst - size for peakrate data, in the egress direction. - -## Load Balancer as a Service - -Load Balancer as a Service (LBaaS) does not function in a $[prodname] network. Any -attempt to create one will fail. - -:::note - -It is possible that in a future version of $[prodname] LBaaS may be -functional. Watch this space. - -::: - -## Horizon - -Horizon makes many provisioning actions available that mirror options on -the Neutron API. This section lists them, and indicates whether they can -be used or not, and any subtleties that might be present in them. - -Much of the detail has been left out of this section, and is instead -present in the relevant Neutron API sections above: please consult them -for more. - -### Section: Project - -#### Tab: Compute -> Instances - -When launching instances, remember that security groups are used to -determine reachability, not networks. Choose networks based on whether -you need an external or an internal IP address, and choose security -groups based on the machines you'd like to talk to in the cloud. See -[IP addressing and connectivity](connectivity.mdx) for more. - -#### Tab: Compute -> Access & Security - -As noted above, tenants should ensure they configure their security -groups to set up their connectivity appropriately. - -#### Tab: Network -> Network Topology - -For the 'Create Network' button, see the [Networks](#networks) section. -For the 'Create Router' button, see the [Layer 3 Routing](#neutron-routers) section. - -#### Tab: Network -> Networks - -For networks and subnets, see the sections on [Networks](#networks) and -[Subnets](#subnets). - -#### Tab: Network -> Routers - -Tenants should be prevented from creating routers, as they serve no -purpose in a $[prodname] network. See [Layer 3 Routing](#neutron-routers) for more. - -### Section: Admin - -#### Tab: System Panel -> Networks - -In the course of general operation administrators are not expected to -make changes to their networking configuration. However, for initial -network setup, this panel may be used to make changes. See -[IP addressing and connectivity](connectivity.mdx) for details on how to achieve this setup. - -#### Tab: System Panel -> Routers - -Administrators should not create routers, as they serve no purpose in a -$[prodname] network. See [Layer 3 Routing](#neutron-routers) for more. diff --git a/calico_versioned_docs/version-3.29/networking/openstack/semantics.mdx b/calico_versioned_docs/version-3.29/networking/openstack/semantics.mdx deleted file mode 100644 index 2fbd3788ff..0000000000 --- a/calico_versioned_docs/version-3.29/networking/openstack/semantics.mdx +++ /dev/null @@ -1,122 +0,0 @@ ---- -description: Calico provides connectivity that is different from traditional Neutron API semantics. ---- - -# Detailed semantics - -A $[prodname] network is a Neutron network (either provider or tenant) whose -connectivity is implemented, on every compute host with instances attached to -that network, by the `calico` plugin or ML2 mechanism driver. There can be -just one $[prodname] network, or any number of them. This page describes the -connectivity that $[prodname] provides between instances attached to the same -network, and between instances attached to different $[prodname] networks, and -between instances and the Internet; and explains how and why this connectivity -is in some details different from traditional Neutron API semantics. - -## Connectivity between instances on the same network - -$[prodname] provides IP connectivity, but not layer 2 (L2) adjacency, between -instances attached to the same $[prodname] network. This means that: - -- An instance can ping the IP of another instance, and make other IP-based - connections to other instances. (Unless restricted by security group - configuration.) - -- If an instances probe the IP path to another instance, it will find that - there are intermediate IP hops in the path; or in other words, that the - instances are not directly connected. - -- Applications or protocols that actually require L2 adjacency - such as - routing protocols like OSPF - will not run successfully on instances on a - $[prodname] network. But the vast majority of applications that are IP-based will - be just fine. - -Traditionally, a Neutron network has always provided L2 adjacency between its -instances, so this is the first way that $[prodname] differs from traditional -Neutron semantics. Up to and including the Mitaka release, L2 adjacency was an -assumed property of a Neutron network; so deployments using $[prodname] simply had -to _understand_ that $[prodname] networks were different in this detail. - -As of the Newton release, $[prodname]'s IP-only connectivity is expressible in the -Neutron API, as a Network whose `l2_adjacency` property is `False`. -However work is still needed to make $[prodname] networks report `l2_adjacency False`, so at the moment - unfortunately - it _still_ has to be understood that -$[prodname] networks do not provide L2 adjacency, even though they report -`l2_adjacency True` when queried on the API. - -:::note - -$[prodname]'s connectivity design, based on IP routing, allows unicast IP and -anycast IP. Anycast IP can be achieved using Neutron floating IPs or -allowed-address-pairs, if you also configure your routing to process multiple -paths for a CIDR (`add_paths` in BIRD) and to program ECMP routes into the -local kernel (`merge_paths` in BIRD). Multicast IP is not supported. -Broadcast IP is not possible because it depends on L2 adjacency. - -::: - -## Connectivity between different $[prodname] networks - -$[prodname] provides _exactly_ the same connectivity between instances on different -$[prodname] networks, as it does between instances on the same $[prodname] network. - -It is important to note that this is equally true for 'provider' and 'tenant' -$[prodname] networks (i.e. for networks that are provisioned by the cloud operator, -or by a particular tenant or project), and for connectivity between any mix of -those networks. There is no way, with $[prodname], to get a tenant network that is -isolated by default at the connectivity level, per standard Neutron API -semantics for a tenant network that is not connected to a router, even if the -$[prodname] tenant network is _not_ connected to a Neutron router, or if there are -no Neutron routers in the deployment at all. - -$[prodname] works this way because it targets use cases where instances are attached -either to provider networks directly, or (in Neutron data model terms) to -tenant networks that _are_ attached through a router to a provider network. -One reason for the latter case is to use floating IPs with $[prodname], because in -current Neutron the target of a floating IP has to be an instance attached to a -tenant network. For more on this, see [Floating IPs](floating-ips.mdx). - -## Flat IP addressing - -An implication of that connectivity between networks is that $[prodname] assumes -that the IP addresses it handles are all in a single, flat address space. For -example, if one network has a subnet with CIDR 10.65.0.0/24, and another -network has a subnet with CIDR 172.18.0.0/16, an instance with IP 10.65.0.2 can -directly address an instance on the other network with IP 172.18.3.23, and the -IP packet will travel all the way between them with source IP 10.65.0.2 and -destination IP 172.18.3.23. There is no NAT anywhere along this datapath. - -## Evaluation against Neutron semantics - -$[prodname] targets use cases that correspond to two Neutron data model patterns. - -Firstly, where instances are attached directly to provider networks: - -![Diagram showing VMs on compute hosts connected directly to a Calico provider network with access to the physical network](/img/calico/networking-calico/calico-provider.png) - -Secondly, where instances are attached to an externally-connected tenant -network: - -![Diagram showing VMs on compute hosts connected to a Calico tenant network, routed through a Neutron router to a provider network and the physical network](/img/calico/networking-calico/calico-tenant.png) - -In the general case those patterns may be combined - so in general there may be -any number of $[prodname] provider networks, and any number of $[prodname] tenant -networks, so long as each of the tenant networks is connected through some -router to a provider network. The purpose of using tenant networks - instead -of always using provider networks - is only so as to enable floating IPs. The -purpose of provisioning multiple networks of either kind - instead of just -one - is typically to allow the user to control what kind of fixed IP an -instance gets. - -However many $[prodname] networks there are, all their IP addresses (in associated -Neutron subnet or subnet pool objects) must be defined or understood as -belonging to a single, flat address space. - -Finally it must be understood that there is no L2 adjacency between any -instances, even those that are attached to the same network. In a future -OpenStack release, we hope to make this explicit, by arranging for $[prodname] -networks to report `l2_adjacency False`. - -Subject to those restrictions and understandings, we believe that -Calico fully implements Neutron semantics, i.e. that it provides the -connectivity that an operator would expect for a given sequence of Neutron API -setup calls. diff --git a/calico_versioned_docs/version-3.29/networking/openstack/service-ips.mdx b/calico_versioned_docs/version-3.29/networking/openstack/service-ips.mdx deleted file mode 100644 index 5ae3389c12..0000000000 --- a/calico_versioned_docs/version-3.29/networking/openstack/service-ips.mdx +++ /dev/null @@ -1,536 +0,0 @@ ---- -description: Use a floating or fixed IP for a Calico-networked VM. ---- - -# Service IPs - -$[prodname] supports two approaches for assigning a service IP to a -$[prodname]-networked VM: - -- using a floating IP - -- using an additional fixed IP on the relevant Neutron port. - -Both of these are standard Neutron practice - in other words, operations that -have long been supported on the Neutron API. They are not $[prodname]-specific, -except insofar as the $[prodname] driver needs to implement some of the low-level -operations that are needed to make the expected semantics work. - -The key semantic difference between those approaches is that: - -- With a floating IP, the target VM itself is not aware of the service IP. - Instead, data sent to the floating IP is DNAT'd, to the target VM's fixed IP, - before that data reaches the target VM. So the target VM only ever sees data - addressed to its fixed IP. - -- With the service IP as an additional fixed IP, the target VM is (and must be) - aware of the service IP, because data addressed to the service IP reaches the - target VM without any DNAT. - -The use of floating IPs is already well known, so we won't labour how to use -those here. For some additional information on how $[prodname] supports floating -IPs, see [Floating IPs](floating-ips.mdx). - -The use and maintenance of additional fixed IPs, however, is not so well -known, so in the following transcripts we demonstrate this approach for -assigning a service IP to a $[prodname]-networked VM. - -We begin by creating a test VM that will be the target of the service IP. - -## Creating a test VM - -1. Check the name of the available CirrOS image. - - ```bash - nova image-list - ``` - - It should return a list of the images and their names. - - ``` - WARNING: Command image-list is deprecated and will be removed after Nova 15.0.0 is released. Use python-glanceclient or openstackclient instead. - +--------------------------------------+---------------------+--------+--------+ - | ID | Name | Status | Server | - +--------------------------------------+---------------------+--------+--------+ - | b69ab3bd-2bbc-4086-b4ae-f01d9f6b5078 | cirros-0.3.2-x86_64 | ACTIVE | | - | 866879b9-532b-44c6-a547-ac59de68df2d | ipv6_enabled_image | ACTIVE | | - +--------------------------------------+---------------------+--------+--------+ - ``` - -1. Boot a VM. - - ```bash - nova boot --flavor m1.tiny --image cirros-0.3.2-x86_64 --nic net-name=demo-net testvm1 - ``` - - The response should look similar to the following. - - ``` - +--------------------------------------+------------------------------------------------------------+ - | Property | Value | - +--------------------------------------+------------------------------------------------------------+ - | OS-DCF:diskConfig | MANUAL | - | OS-EXT-AZ:availability_zone | nova | - | OS-EXT-SRV-ATTR:host | - | - | OS-EXT-SRV-ATTR:hypervisor_hostname | - | - | OS-EXT-SRV-ATTR:instance_name | instance-0000000d | - | OS-EXT-STS:power_state | 0 | - | OS-EXT-STS:task_state | scheduling | - | OS-EXT-STS:vm_state | building | - | OS-SRV-USG:launched_at | - | - | OS-SRV-USG:terminated_at | - | - | accessIPv4 | | - | accessIPv6 | | - | adminPass | HKLzcUT5L52B | - | config_drive | | - | created | 2017-01-13T13:50:32Z | - | flavor | m1.tiny (1) | - | hostId | | - | id | b6d8a3c4-9674-4972-9151-11107b60d622 | - | image | cirros-0.3.2-x86_64 (b69ab3bd-2bbc-4086-b4ae-f01d9f6b5078) | - | key_name | - | - | metadata | {} | - | name | testvm1 | - | os-extended-volumes:volumes_attached | [] | - | progress | 0 | - | security_groups | default | - | status | BUILD | - | tenant_id | 26778b0f745143c5a9b0c7e1a621bb80 | - | updated | 2017-01-13T13:50:32Z | - | user_id | 7efbea74c20a4eeabc00b7740aa4d353 | - +--------------------------------------+------------------------------------------------------------+ - ``` - -1. Check when the VM has booted: - - ```bash - nova list - ``` - - You should see your VM with the following statuses. - - ``` - +--------------------------------------+---------+--------+------------+-------------+----------------------------------------------+ - | ID | Name | Status | Task State | Power State | Networks | - +--------------------------------------+---------+--------+------------+-------------+----------------------------------------------+ - | b6d8a3c4-9674-4972-9151-11107b60d622 | testvm1 | ACTIVE | - | Running | demo-net=10.28.0.13, fd5f:5d21:845:1c2e:2::d | - +--------------------------------------+---------+--------+------------+-------------+----------------------------------------------+ - ``` - -1. Use the following command to obtain the status of the VM. - - ```bash - nova show testvm1 - ``` - - It should return something like the following. - - ``` - +--------------------------------------+------------------------------------------------------------+ - | Property | Value | - +--------------------------------------+------------------------------------------------------------+ - | OS-DCF:diskConfig | MANUAL | - | OS-EXT-AZ:availability_zone | neil-fv-0-ubuntu-kilo-compute-node01 | - | OS-EXT-SRV-ATTR:host | neil-fv-0-ubuntu-kilo-compute-node01 | - | OS-EXT-SRV-ATTR:hypervisor_hostname | neil-fv-0-ubuntu-kilo-compute-node01 | - | OS-EXT-SRV-ATTR:instance_name | instance-0000000d | - | OS-EXT-STS:power_state | 1 | - | OS-EXT-STS:task_state | - | - | OS-EXT-STS:vm_state | active | - | OS-SRV-USG:launched_at | 2017-01-13T13:50:39.000000 | - | OS-SRV-USG:terminated_at | - | - | accessIPv4 | | - | accessIPv6 | | - | config_drive | | - | created | 2017-01-13T13:50:32Z | - | demo-net network | 10.28.0.13, fd5f:5d21:845:1c2e:2::d | - | flavor | m1.tiny (1) | - | hostId | bf3ce3c7146ba6cafd43be03886de8755e2b5c8e9f71aa9bfafde9a0 | - | id | b6d8a3c4-9674-4972-9151-11107b60d622 | - | image | cirros-0.3.2-x86_64 (b69ab3bd-2bbc-4086-b4ae-f01d9f6b5078) | - | key_name | - | - | metadata | {} | - | name | testvm1 | - | os-extended-volumes:volumes_attached | [] | - | progress | 0 | - | security_groups | default | - | status | ACTIVE | - | tenant_id | 26778b0f745143c5a9b0c7e1a621bb80 | - | updated | 2017-01-13T13:50:39Z | - | user_id | 7efbea74c20a4eeabc00b7740aa4d353 | - +--------------------------------------+------------------------------------------------------------+ - ``` - - In this example, the VM has been given a fixed IP of 10.28.0.13. - -1. Let's look at the corresponding Neutron port. - - ```bash - neutron port-list - ``` - - It should look something like the following. - - ``` - +--------------------------------------+------+-------------------+------------------------------------------------------------------------------------------------+ - | id | name | mac_address | fixed_ips | - +--------------------------------------+------+-------------------+------------------------------------------------------------------------------------------------+ - | 656b3617-570d-473e-a5dd-90b61cb0c49f | | fa:16:3e:4d:d5:25 | | - | 9a7e0868-da7a-419e-a7ad-9d37e11091b8 | | fa:16:3e:28:a9:a4 | {"subnet_id": "0a1221f2-e6ed-413d-a040-62a266bd0d8f", "ip_address": "10.28.0.13"} | - | | | | {"subnet_id": "345fec2e-6493-44de-a489-97b755c16dd4", "ip_address": "fd5f:5d21:845:1c2e:2::d"} | - | a4b26bcc-ba94-4033-a9fc-edaf151c0c20 | | fa:16:3e:74:46:bd | | - | a772a5e1-2f13-4fc3-96d5-fa1c29717637 | | fa:16:3e:c9:c6:8f | | - +--------------------------------------+------+-------------------+------------------------------------------------------------------------------------------------+ - ``` - -## Adding a service IP to the Neutron port as an extra fixed IP - -Now we want to set up a service IP - let's say `10.28.0.23` - that -initially points to that VM, `testvm1`. - -1. One way to do that is to add the service IP as a second 'fixed IP' on the Neutron port. - - ```bash - neutron port-update --fixed-ip subnet_id=0a1221f2-e6ed-413d-a040-62a266bd0d8f,ip_address=10.28.0.13 \ - --fixed-ip subnet_id=0a1221f2-e6ed-413d-a040-62a266bd0d8f,ip_address=10.28.0.23 9a7e0868-da7a-419e-a7ad-9d37e11091b8 - ``` - -1. It should return a confirmation message. - - ``` - Updated port: 9a7e0868-da7a-419e-a7ad-9d37e11091b8 - ``` - -1. Use the following command to get more information about the port. - - ```bash - neutron port-show 9a7e0868-da7a-419e-a7ad-9d37e11091b8 - ``` - - It should return a table like the following. - - ``` - +-----------------------+-----------------------------------------------------------------------------------+ - | Field | Value | - +-----------------------+-----------------------------------------------------------------------------------+ - | admin_state_up | True | - | allowed_address_pairs | | - | binding:host_id | neil-fv-0-ubuntu-kilo-compute-node01 | - | binding:profile | {} | - | binding:vif_details | {"port_filter": true, "mac_address": "00:61:fe:ed:ca:fe"} | - | binding:vif_type | tap | - | binding:vnic_type | normal | - | device_id | b6d8a3c4-9674-4972-9151-11107b60d622 | - | device_owner | compute:None | - | extra_dhcp_opts | | - | fixed_ips | {"subnet_id": "0a1221f2-e6ed-413d-a040-62a266bd0d8f", "ip_address": "10.28.0.13"} | - | | {"subnet_id": "0a1221f2-e6ed-413d-a040-62a266bd0d8f", "ip_address": "10.28.0.23"} | - | id | 9a7e0868-da7a-419e-a7ad-9d37e11091b8 | - | mac_address | fa:16:3e:28:a9:a4 | - | name | | - | network_id | 60651076-af2a-4c6d-8d64-500b53a4e547 | - | security_groups | 75fccd0a-ef3d-44cd-91ec-ef22941f50f5 | - | status | ACTIVE | - | tenant_id | 26778b0f745143c5a9b0c7e1a621bb80 | - +-----------------------+-----------------------------------------------------------------------------------+ - ``` - -1. Now look at local IP routes. - - ```bash - ip r - ``` - - We see that we have a route to `10.28.0.23`. - - ``` - default via 10.240.0.1 dev eth0 proto static metric 100 - 10.28.0.13 via 192.168.8.3 dev l2tpeth8-1 proto bird - 10.28.0.23 via 192.168.8.3 dev l2tpeth8-1 proto bird - [...] - ``` - - Note that, on the machine where we're running these commands: - - - BIRD is running, peered with the BIRDs that $[prodname] runs on each compute node. - That is what causes VM routes (including `10.28.0.23`) to appear here. - - - 192.168.8.3 is the IP of the compute node that is hosting `testvm1`. - -1. We can also double check that `10.28.0.23` has appeared as a local device - route on the relevant compute node. - - ```bash - ip r - ``` - - It should return something like the following. - - ``` - default via 10.240.0.1 dev eth0 - 10.28.0.13 dev tap9a7e0868-da scope link - 10.28.0.23 dev tap9a7e0868-da scope link - 10.240.0.1 dev eth0 scope link - 192.168.8.0/24 dev l2tpeth8-3 proto kernel scope link src 192.168.8.3 - 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 - ``` - - We also need - because with this approach, data that is addressed to - `10.28.0.23` will be routed to the VM without any NAT - to tell the VM - itself that it has the extra `10.28.0.23` address. - -1. SSH into the VM. - - ```bash - core@access-node$ ssh cirros@10.28.0.13 - cirros@10.28.0.13's password: - ``` - -1. From inside the VM, issue the following command to list the interfaces. - - ```bash - ip a - ``` - - It should return something like the following. - - ``` - 1: lo: mtu 16436 qdisc noqueue - link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 - inet 127.0.0.1/8 scope host lo - inet6 ::1/128 scope host - valid_lft forever preferred_lft forever - 2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 - link/ether fa:16:3e:28:a9:a4 brd ff:ff:ff:ff:ff:ff - inet 10.28.0.13/16 brd 10.28.255.255 scope global eth0 - inet6 fe80::f816:3eff:fe28:a9a4/64 scope link - valid_lft forever preferred_lft forever - ``` - -1. Next, issue the following command. - - ```bash - sudo ip a a 10.28.0.23/16 dev eth0 - ``` - -1. List the interfaces again. - - ```bash - ip a - ``` - - The interfaces should now look more like the following. - - ``` - 1: lo: mtu 16436 qdisc noqueue - link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 - inet 127.0.0.1/8 scope host lo - inet6 ::1/128 scope host - valid_lft forever preferred_lft forever - 2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 - link/ether fa:16:3e:28:a9:a4 brd ff:ff:ff:ff:ff:ff - inet 10.28.0.13/16 brd 10.28.255.255 scope global eth0 - inet 10.28.0.23/16 scope global secondary eth0 - inet6 fe80::f816:3eff:fe28:a9a4/64 scope link - valid_lft forever preferred_lft forever - ``` - -1. Exit the SSH session. - - ``` - Connection to 10.28.0.13 closed. - ``` - -1. And now we can access the VM on its service IP, as shown below. - - ```bash - core@access-node$ ssh cirros@10.28.0.23 - The authenticity of host '10.28.0.23 (10.28.0.23)' can't be established. - RSA key fingerprint is 65:a5:b0:0c:e2:c4:ac:94:2a:0c:64:b8:bc:5a:aa:66. - Are you sure you want to continue connecting (yes/no)? yes - - Warning: Permanently added '10.28.0.23' (RSA) to the list of known hosts. - cirros@10.28.0.23's password: - $ - ``` - - Note that we already have security set up that allows SSH to the instance from - our access machine (`192.168.8.1`). - -1. You can check this by listing the security groups. - - ```bash - neutron security-group-list - ``` - - It should return something like the following. - - ``` - +--------------------------------------+---------+----------------------------------------------------------------------+ - | id | name | security_group_rules | - +--------------------------------------+---------+----------------------------------------------------------------------+ - | 75fccd0a-ef3d-44cd-91ec-ef22941f50f5 | default | egress, IPv4 | - | | | egress, IPv6 | - | | | ingress, IPv4, 22/tcp, remote_ip_prefix: 192.168.8.1/32 | - | | | ingress, IPv4, remote_group_id: 75fccd0a-ef3d-44cd-91ec-ef22941f50f5 | - | | | ingress, IPv6, remote_group_id: 75fccd0a-ef3d-44cd-91ec-ef22941f50f5 | - | 903d9936-ce72-4756-a2cc-7c95a846e7e5 | default | egress, IPv4 | - | | | egress, IPv6 | - | | | ingress, IPv4, 22/tcp, remote_ip_prefix: 192.168.8.1/32 | - | | | ingress, IPv4, remote_group_id: 903d9936-ce72-4756-a2cc-7c95a846e7e5 | - | | | ingress, IPv6, remote_group_id: 903d9936-ce72-4756-a2cc-7c95a846e7e5 | - +--------------------------------------+---------+----------------------------------------------------------------------+ - ``` - -## Moving the service IP to another VM - -Service IPs are often used for HA, so need to be moved to target a different VM -if the first one fails for some reason (or if the HA system just decides to -cycle the active VM). - -1. To demonstrate that we create a second test VM. - - ```bash - nova boot --flavor m1.tiny --image cirros-0.3.2-x86_64 --nic net-name=demo-net testvm2 - ``` - -1. List the VMs. - - ```bash - nova list - ``` - - You should see the new VM in the list. - - ``` - +--------------------------------------+---------+--------+------------+-------------+----------------------------------------------+ - | ID | Name | Status | Task State | Power State | Networks | +--------------------------------------+---------+--------+------------+-------------+----------------------------------------------+ - | b6d8a3c4-9674-4972-9151-11107b60d622 | testvm1 | ACTIVE | - | Running | demo-net=10.28.0.13, 10.28.0.23 | - | bb4ef5e3-dc77-472e-af6f-3f0d8c3e5a6d | testvm2 | ACTIVE | - | Running | demo-net=10.28.0.14, fd5f:5d21:845:1c2e:2::e | - +--------------------------------------+---------+--------+------------+-------------+----------------------------------------------+ - ``` - -1. Check the ports. - - ```bash - neutron port-list - ``` - - It should return something like the following. - - ``` - +--------------------------------------+------+-------------------+------------------------------------------------------------------------------------------------+ - | id | name | mac_address | fixed_ips | - +--------------------------------------+------+-------------------+------------------------------------------------------------------------------------------------+ - | 656b3617-570d-473e-a5dd-90b61cb0c49f | | fa:16:3e:4d:d5:25 | | - | 7627a298-a2db-4a1a-bc07-9f0f10f58363 | | fa:16:3e:8e:dc:33 | {"subnet_id": "0a1221f2-e6ed-413d-a040-62a266bd0d8f", "ip_address": "10.28.0.14"} | - | | | | {"subnet_id": "345fec2e-6493-44de-a489-97b755c16dd4", "ip_address": "fd5f:5d21:845:1c2e:2::e"} | - | 9a7e0868-da7a-419e-a7ad-9d37e11091b8 | | fa:16:3e:28:a9:a4 | {"subnet_id": "0a1221f2-e6ed-413d-a040-62a266bd0d8f", "ip_address": "10.28.0.13"} | - | | | | {"subnet_id": "0a1221f2-e6ed-413d-a040-62a266bd0d8f", "ip_address": "10.28.0.23"} | - | a4b26bcc-ba94-4033-a9fc-edaf151c0c20 | | fa:16:3e:74:46:bd | | - | a772a5e1-2f13-4fc3-96d5-fa1c29717637 | | fa:16:3e:c9:c6:8f | | - +--------------------------------------+------+-------------------+------------------------------------------------------------------------------------------------+ - ``` - -1. Remove the service IP from the first VM. - - ```bash - neutron port-update --fixed-ip subnet_id=0a1221f2-e6ed-413d-a040-62a266bd0d8f,ip_address=10.28.0.13 9a7e0868-da7a-419e-a7ad-9d37e11091b8 - ``` - -1. And add it to the second. - - ```bash - neutron port-update --fixed-ip subnet_id=0a1221f2-e6ed-413d-a040-62a266bd0d8f,ip_address=10.28.0.14 \ - --fixed-ip subnet_id=0a1221f2-e6ed-413d-a040-62a266bd0d8f,ip_address=10.28.0.23 7627a298-a2db-4a1a-bc07-9f0f10f58363 - ``` - -1. SSH into `testvm2`. - - ```bash - core@access-node$ ssh cirros@10.28.0.14 - The authenticity of host '10.28.0.14 (10.28.0.14)' can't be established. - RSA key fingerprint is 6a:02:7f:3a:bf:0c:91:de:c4:d6:e7:f6:81:3f:6a:85. - Are you sure you want to continue connecting (yes/no)? yes - - Warning: Permanently added '10.28.0.14' (RSA) to the list of known hosts. - cirros@10.28.0.14's password: - ``` - -1. Tell `testvm2` that it now has the service IP `10.28.0.23`. - - ```bash - sudo ip a a 10.28.0.23/16 dev eth0 - ``` - -1. Now connections to `10.28.0.23` go to `testvm2` - - ```bash - core@access-node$ ssh cirros@10.28.0.23 - @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ - @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ - @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ - IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! - Someone could be eavesdropping on you right now (man-in-the-middle attack)! - It is also possible that a host key has just been changed. - The fingerprint for the RSA key sent by the remote host is - 6a:02:7f:3a:bf:0c:91:de:c4:d6:e7:f6:81:3f:6a:85. - Please contact your system administrator. - Add correct host key in /home/core/.ssh/known_hosts to get rid of this message. - Offending RSA key in /home/core/.ssh/known_hosts:4 - RSA host key for 10.28.0.23 has changed and you have requested strict checking. - Host key verification failed. - ``` - -1. Remove the `known_hosts` files. - - ```bash - rm ~/.ssh/known_hosts - ``` - -1. Try again to SSH into the VM. - - ```bash - core@access-node$ ssh cirros@10.28.0.23 - The authenticity of host '10.28.0.23 (10.28.0.23)' can't be established. - RSA key fingerprint is 6a:02:7f:3a:bf:0c:91:de:c4:d6:e7:f6:81:3f:6a:85. - Are you sure you want to continue connecting (yes/no)? yes - - Warning: Permanently added '10.28.0.23' (RSA) to the list of known hosts. - cirros@10.28.0.23's password: - ``` - -1. Check the host name. - - ```bash - hostname - ``` - - It should return: - - ``` - testvm2 - ``` - -1. Check the interfaces. - - ``` - ip a - ``` - - They should look something like the following. - - ``` - 1: lo: mtu 16436 qdisc noqueue - link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 - inet 127.0.0.1/8 scope host lo - inet6 ::1/128 scope host - valid_lft forever preferred_lft forever - 2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 - link/ether fa:16:3e:8e:dc:33 brd ff:ff:ff:ff:ff:ff - inet 10.28.0.14/16 brd 10.28.255.255 scope global eth0 - inet 10.28.0.23/16 scope global secondary eth0 - inet6 fe80::f816:3eff:fe8e:dc33/64 scope link - valid_lft forever preferred_lft forever - $ - ``` diff --git a/calico_versioned_docs/version-3.29/operations/calicoctl/configure/etcd.mdx b/calico_versioned_docs/version-3.29/operations/calicoctl/configure/etcd.mdx deleted file mode 100644 index 8e3012d43f..0000000000 --- a/calico_versioned_docs/version-3.29/operations/calicoctl/configure/etcd.mdx +++ /dev/null @@ -1,190 +0,0 @@ ---- -description: Sample configuration files etcd. ---- - -# Configure calicoctl to connect to an etcd datastore - -## Big picture - -Learn how to configure the calicoctl CLI tool for an etcd cluster. - -## Value - -The `calicoctl` CLI tool provides helpful administrative commands for interacting with a $[prodname] cluster. - -## Concepts - -### calicoctl vs kubectl - -In previous releases, calicoctl has been required to manage Calico API resources in the `projectcalico.org/v3` API group. The calicoctl CLI tool provides important validation and defaulting on these APIs. - -In newer releases, the Calico API server performs that defaulting and validation server-side, exposing the same API semantics without a dependency on calicoctl. For this reason, we recommend -[installing the Calico API server](../../install-apiserver.mdx) and using `kubectl` instead of `calicoctl` for most operations. - -calicoctl is still required for the following subcommands: - -- [calicoctl node](../../../reference/calicoctl/node/index.mdx) -- [calicoctl ipam](../../../reference/calicoctl/ipam/index.mdx) -- [calicoctl convert](../../../reference/calicoctl/convert.mdx) -- [calicoctl version](../../../reference/calicoctl/version.mdx) - -calicoctl is also required for non-Kubernetes platforms such as OpenStack. - -## How to - -### Complete list of etcd configuration options - -| Configuration file option | Environment variable | Description | Schema | -| ------------------------- | -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------- | -| `datastoreType` | `DATASTORE_TYPE` | Indicates the datastore to use. If unspecified, defaults to `kubernetes`. (optional) | `kubernetes`, `etcdv3` | -| `etcdEndpoints` | `ETCD_ENDPOINTS` | A comma-separated list of etcd endpoints. Example: `http://127.0.0.1:2379,http://127.0.0.2:2379` (required) | string | -| `etcdDiscoverySrv` | `ETCD_DISCOVERY_SRV` | Domain name to discover etcd endpoints via SRV records. Mutually exclusive with `etcdEndpoints`. Example: `example.com` (optional) | string | -| `etcdUsername` | `ETCD_USERNAME` | User name for RBAC. Example: `user` (optional) | string | -| `etcdPassword` | `ETCD_PASSWORD` | Password for the given user name. Example: `password` (optional) | string | -| `etcdKeyFile` | `ETCD_KEY_FILE` | Path to the file containing the private key matching the `calicoctl` client certificate. Enables `calicoctl` to participate in mutual TLS authentication and identify itself to the etcd server. Example: `/etc/calicoctl/key.pem` (optional) | string | -| `etcdCertFile` | `ETCD_CERT_FILE` | Path to the file containing the client certificate issued to `calicoctl`. Enables `calicoctl` to participate in mutual TLS authentication and identify itself to the etcd server. Example: `/etc/calicoctl/cert.pem` (optional) | string | -| `etcdCACertFile` | `ETCD_CA_CERT_FILE` | Path to the file containing the root certificate of the certificate authority (CA) that issued the etcd server certificate. Configures `calicoctl` to trust the CA that signed the root certificate. The file may contain multiple root certificates, causing `calicoctl` to trust each of the CAs included. Example: `/etc/calicoctl/ca.pem` (optional) | string | -| `etcdKey` | | The private key matching the `calicoctl` client certificate. Enables `calicoctl` to participate in mutual TLS authentication and identify itself to the etcd server. For example, please see below.(optional) | string | -| `etcdCert` | | The client certificate issued to `calicoctl`. Enables `calicoctl` to participate in mutual TLS authentication and identify itself to the etcd server. For example, please see below.(optional) | string | -| `etcdCACert` | | The root certificate of the certificate authority (CA) that issued the etcd server certificate. Configures `calicoctl` to trust the CA that signed the root certificate. The config file may contain multiple root certificates, causing `calicoctl` to trust each of the CAs included. For example, please see below.(optional) | string | - -:::note - -- If you are running with TLS enabled, ensure your endpoint addresses use HTTPS. -- When specifying through environment variables, the `DATASTORE_TYPE` environment - is required for etcdv3. -- All environment variables may also be prefixed with `CALICO_`, for example - `CALICO_DATASTORE_TYPE` and `CALICO_ETCD_ENDPOINTS` etc. may also be used. - This is useful if the non-prefixed names clash with existing environment - variables defined on your system -- The Configuration file options `etcdCACert`, `etcdCert` and `etcdKey` does not have - corresponding environment variables. -- Previous versions of `calicoctl` supported `ETCD_SCHEME` and `ETC_AUTHORITY` environment - variables as a mechanism for specifying the etcd endpoints. These variables are - no longer supported. Use `ETCD_ENDPOINTS` instead. - -::: - -### Example configuration file - -```yaml -apiVersion: projectcalico.org/v3 -kind: CalicoAPIConfig -metadata: -spec: - etcdEndpoints: https://etcd1:2379,https://etcd2:2379,https://etcd3:2379 - etcdKeyFile: /etc/calico/key.pem - etcdCertFile: /etc/calico/cert.pem - etcdCACertFile: /etc/calico/ca.pem -``` - -### Example configuration file with inline CA certificate, client certificate and key - -```yaml -apiVersion: projectcalico.org/v3 -kind: CalicoAPIConfig -metadata: -spec: - datastoreType: etcdv3 - etcdEndpoints: 'https://127.0.0.1:2379' - etcdCACert: | - -----BEGIN CERTIFICATE----- - MIICKzCCAZSgAwIBAgIBAzANBgkqhkiG9w0BAQQFADA3MQswCQYDVQQGEwJVUzER - MA8GA1UEChMITmV0c2NhcGUxFTATBgNVBAsTDFN1cHJpeWEncyBDQTAeFw05NzEw - MTgwMTM2MjVaFw05OTEwMTgwMTM2MjVaMEgxCzAJBgNVBAYTAlVTMREwDwYDVQQK - EwhOZXRzY2FwZTENMAsGA1UECxMEUHViczEXMBUGA== - -----END CERTIFICATE----- - etcdCert: | - -----BEGIN CERTIFICATE----- - gI6iLXgMsp2EOlD56I6FA1jrCtNb01XQvX3eyFuA6g5T1jWGYBDtvQb0WRVkdUy9 - L/uK+sHQwtloCSuakcQAsWV9bajCQtHX8XGu25Yz56kpJ/OJjcishxT6pc/sthum - A5PX739JsNUi/p5aG+H/6eNx+ukJP7QaM646YCfS5i8S9DJUvim+/BSlKi2ZiOCd - 0MYH4Xb7lmAOTNmTvSYpKo9J2fZ9erw0MYSBTyjh6F7PRbHBiivgUnJfGQ== - -----END CERTIFICATE----- - etcdKey: | - -----BEGIN RSA PRIVATE KEY----- - k0dWj16h9P6TvfcNl2iwT4VIwx0uy2faWBED1DrCJcuQCy5nPrts2ZIaAWPi1t3t - VbDKQvs+KXBEeqh0qYcYkejUXqIF0uKUFLjiQmZssjpL5RHqqWuYKbO87n+Jod1L - TjGRHdbP0zF2U0LdjM17rc2hpJ3qrmgJ7pOLzbXMcOr+NP1ojRCArXhQ4iLs7D8T - eHw9QH4luJYtnmk7x03izLMQdLWcKnUbqh/xOVPyazgJHXwRxwNXpMsBVGY= - -----END RSA PRIVATE KEY----- -``` - -### Example using environment variables - -```bash -ETCD_ENDPOINTS=http://myhost1:2379 calicoctl get bgppeers -``` - -### Example using etcd DNS discovery - -```bash -ETCD_DISCOVERY_SRV=example.com calicoctl get nodes -``` - -### Example using IPv6 - -Create a single node etcd cluster listening on IPv6 localhost `[::1]`. - -```bash -etcd --listen-client-urls=http://[::1]:2379 --advertise-client-urls=http://[::1]:2379 -``` - -Use the etcd IPv6 cluster: - -```bash -ETCD_ENDPOINTS=http://[::1]:2379 calicoctl get bgppeers -``` - -### Example using mixed IPv4/IPv6 - -Create a single node etcd cluster listening on IPv4 and IPv6 localhost `[::1]`. - -```bash -etcd --listen-client-urls=http://[::1]:2379,http://127.0.0.1:2379 --advertise-client-urls=http://[::1]:2379 -``` - -Use the IPv6 endpoint: - -```bash -ETCD_ENDPOINTS=http://[::1]:2379 calicoctl get bgppeers -``` - -Use the IPv4 endpoint: - -```bash -ETCD_ENDPOINTS=http://127.0.0.1:2379 calicoctl get bgppeers -``` - -### $[nodecontainer] - -It is important to note that not only will calicoctl will use the specified keys directly -on the host to access etcd, **it will also pass on these environment variables -and volume mount the keys into the started `$[noderunning]` container.** - -Therefore, configuring `$[nodecontainer]` for etcd is easily accomplished by running -`calicoctl node run` with the parameters set correctly. - -### Checking the configuration - -Here is a simple command to check that the installation and configuration is -correct. - -```bash -calicoctl get nodes -``` - -A correct setup will yield a list of the nodes that have registered. If an -empty list is returned you are either pointed at the wrong datastore or no -nodes have registered. If an error is returned then attempt to correct the -issue then try again. - -## Next steps - -Now you are ready to read and configure most aspects of $[prodname]. You can -find the full list of commands in the -[Command Reference](../../../reference/calicoctl/overview.mdx). - -The full list of resources that can be managed, including a description of each, -can be found in the -[Resource Definitions](../../../reference/resources/overview.mdx). diff --git a/calico_versioned_docs/version-3.29/operations/calicoctl/configure/index.mdx b/calico_versioned_docs/version-3.29/operations/calicoctl/configure/index.mdx deleted file mode 100644 index 6aabb3c936..0000000000 --- a/calico_versioned_docs/version-3.29/operations/calicoctl/configure/index.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: Configure the calicoctl to access your datastore. -hide_table_of_contents: true ---- - -# Configure calicoctl - -import DocCardList from '@theme/DocCardList'; -import { useCurrentSidebarCategory } from '@docusaurus/theme-common'; - - diff --git a/calico_versioned_docs/version-3.29/operations/calicoctl/configure/kdd.mdx b/calico_versioned_docs/version-3.29/operations/calicoctl/configure/kdd.mdx deleted file mode 100644 index 574dfc76d2..0000000000 --- a/calico_versioned_docs/version-3.29/operations/calicoctl/configure/kdd.mdx +++ /dev/null @@ -1,124 +0,0 @@ ---- -description: Sample configuration files for kdd. ---- - -# Configure calicoctl to connect to the Kubernetes API datastore - -## Big picture - -Learn how to configure the calicoctl CLI tool for your Kubernetes cluster. - -## Value - -The `calicoctl` CLI tool provides helpful administrative commands for interacting with a $[prodname] cluster. - -## Concepts - -### calicoctl vs kubectl - -In previous releases, calicoctl has been required to manage Calico API resources in the `projectcalico.org/v3` API group. The calicoctl CLI tool provides important validation and defaulting on these APIs. - -In newer releases, the Calico API server performs that defaulting and validation server-side, exposing the same API semantics without a dependency on calicoctl. For this reason, we recommend -[installing the Calico API server](../../install-apiserver.mdx) and using `kubectl` instead of `calicoctl` for most operations. - -calicoctl is still required for the following subcommands: - -- [calicoctl node](../../../reference/calicoctl/node/index.mdx) -- [calicoctl ipam](../../../reference/calicoctl/ipam/index.mdx) -- [calicoctl convert](../../../reference/calicoctl/convert.mdx) -- [calicoctl version](../../../reference/calicoctl/version.mdx) - -### Default configuration - -By default, calicoctl will attempt to read from the Kubernetes API using the default kubeconfig located at `$(HOME)/.kube/config`. - -If the default kubeconfig does not exist, or you would like to specify alternative API access information, you can do so using the following configuration options. - -## How to - -### Complete list of Kubernetes API connection configuration - -| Configuration file option | Environment variable | Description | Schema | -| ------------------------- | -------------------- | --------------------------------------------------------------------------------------------------------- | ---------------------- | -| `datastoreType` | `DATASTORE_TYPE` | Indicates the datastore to use. [Default: `kubernetes`] | `kubernetes`, `etcdv3` | -| `kubeconfig` | `KUBECONFIG` | When using the Kubernetes datastore, the location of a kubeconfig file to use, e.g. /path/to/kube/config. | string | -| `k8sAPIEndpoint` | `K8S_API_ENDPOINT` | Location of the Kubernetes API. Not required if using kubeconfig. [Default: `https://kubernetes-api:443`] | string | -| `k8sCertFile` | `K8S_CERT_FILE` | Location of a client certificate for accessing the Kubernetes API, e.g., `/path/to/cert`. | string | -| `k8sKeyFile` | `K8S_KEY_FILE` | Location of a client key for accessing the Kubernetes API, e.g., `/path/to/key`. | string | -| `k8sCAFile` | `K8S_CA_FILE` | Location of a CA for accessing the Kubernetes API, e.g., `/path/to/ca`. | string | -| `k8sToken` | | Token to be used for accessing the Kubernetes API. | string | - -:::note - -All environment variables may also be prefixed with `"CALICO_"`, for -example `"CALICO_DATASTORE_TYPE"` and `"CALICO_KUBECONFIG"` etc. may be used. -This is useful if the non-prefixed names clash with existing environment -variables defined on your system. - -::: - -### Kubernetes command line - -```bash -DATASTORE_TYPE=kubernetes KUBECONFIG=~/.kube/config calicoctl get nodes -``` - -### Example configuration file - -```yaml -apiVersion: projectcalico.org/v3 -kind: CalicoAPIConfig -metadata: -spec: - datastoreType: 'kubernetes' - kubeconfig: '/path/to/.kube/config' -``` - -### Example using environment variables - -```bash -export DATASTORE_TYPE=kubernetes -export KUBECONFIG=~/.kube/config -calicoctl get workloadendpoints -``` - -And using `CALICO_` prefixed names: - -```bash -export CALICO_DATASTORE_TYPE=kubernetes -export CALICO_KUBECONFIG=~/.kube/config -calicoctl get workloadendpoints -``` - -With multiple `kubeconfig` files: - -```bash -export DATASTORE_TYPE=kubernetes -export KUBECONFIG=~/.kube/main:~/.kube/auxy -calicoctl get --context main workloadendpoints -calicoctl get --context auxy workloadendpoints -``` - -### Checking the configuration - -Here is a simple command to check that the installation and configuration is -correct. - -```bash -calicoctl get nodes -``` - -A correct setup will yield a list of the nodes that have registered. If an -empty list is returned you are either pointed at the wrong datastore or no -nodes have registered. If an error is returned then attempt to correct the -issue then try again. - -## Next steps - -Now you are ready to read and configure most aspects of $[prodname]. You can -find the full list of commands in the -[Command Reference](../../../reference/calicoctl/overview.mdx). - -The full list of resources that can be managed, including a description of each, -can be found in the -[Resource Definitions](../../../reference/resources/overview.mdx). diff --git a/calico_versioned_docs/version-3.29/operations/calicoctl/configure/overview.mdx b/calico_versioned_docs/version-3.29/operations/calicoctl/configure/overview.mdx deleted file mode 100644 index a60f6c2b97..0000000000 --- a/calico_versioned_docs/version-3.29/operations/calicoctl/configure/overview.mdx +++ /dev/null @@ -1,74 +0,0 @@ ---- -description: Configure calicoctl for datastore access. ---- - -# Configure calicoctl - -## Big picture - -Learn how to configure the calicoctl CLI tool for your cluster. - -## Value - -The `calicoctl` CLI tool provides helpful administrative commands for interacting with a $[prodname] cluster. - -## Concepts - -### calicoctl vs kubectl - -In previous releases, calicoctl has been required to manage Calico API resources in the `projectcalico.org/v3` API group. The calicoctl CLI tool provides important validation and defaulting on these APIs. - -In newer releases, the Calico API server performs that defaulting and validation server-side, exposing the same API semantics without a dependency on calicoctl. For this reason, we recommend -[installing the Calico API server](../../install-apiserver.mdx) and using `kubectl` instead of `calicoctl` for most operations. - -calicoctl is still required for the following subcommands: - -- [calicoctl node](../../../reference/calicoctl/node/index.mdx) -- [calicoctl ipam](../../../reference/calicoctl/ipam/index.mdx) -- [calicoctl convert](../../../reference/calicoctl/convert.mdx) -- [calicoctl version](../../../reference/calicoctl/version.mdx) - -calicoctl is also required for non-Kubernetes platforms such as OpenStack. - -### Default calicoctl behavior - -Most `calicoctl` commands require access to the $[prodname] datastore. By default, calicoctl -will attempt to read from the Kubernetes API based on the default kubeconfig. - -## How to - -### Configure access using a Configuration file - -By default, `calicoctl` will look for a configuration file at `/etc/calico/calicoctl.cfg`. You can override this using the `--config` option with commands that require datastore access. -The file can be in either YAML or JSON format. It must be valid and readable by `calicoctl`. For example: - -```yaml noValidation -apiVersion: projectcalico.org/v3 -kind: CalicoAPIConfig -metadata: -spec: - datastoreType: "etcdv3" - etcdEndpoints: "http://etcd1:2379,http://etcd2:2379" - ... -``` - -### Configure access using environment variables - -If `calicoctl` cannot locate, read, or access a configuration file, it will check a specific set of environment variables. - -Refer to the section that corresponds to your datastore type for a full set of options -and examples. - -- [Kubernetes API datastore](kdd.mdx) - -- [etcd datastore](etcd.mdx) - -:::note - -When running `calicoctl` inside a container, any environment variables and -configuration files must be passed to the container so they are available to -the process inside. It can be useful to keep a running container (that sleeps) configured -for your datastore, then it is possible to `exec` into the container and have an -already configured environment. - -::: diff --git a/calico_versioned_docs/version-3.29/operations/calicoctl/index.mdx b/calico_versioned_docs/version-3.29/operations/calicoctl/index.mdx deleted file mode 100644 index ab048e5496..0000000000 --- a/calico_versioned_docs/version-3.29/operations/calicoctl/index.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: Install and configure the Calico CLI for managing resources. -hide_table_of_contents: true ---- - -# calicoctl - -import DocCardList from '@theme/DocCardList'; -import { useCurrentSidebarCategory } from '@docusaurus/theme-common'; - - diff --git a/calico_versioned_docs/version-3.29/operations/calicoctl/install.mdx b/calico_versioned_docs/version-3.29/operations/calicoctl/install.mdx deleted file mode 100644 index 5c39bf12d2..0000000000 --- a/calico_versioned_docs/version-3.29/operations/calicoctl/install.mdx +++ /dev/null @@ -1,202 +0,0 @@ ---- -description: Install the CLI for Calico. ---- - -# Install calicoctl - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; -import CodeBlock from '@theme/CodeBlock'; - -import { releaseTitle } from '../../variables.js'; - -export function buildUrl() { - const url = - releaseTitle === 'master' - ? 'https://github.com/projectcalico/calico/releases/latest/download' - : `https://github.com/projectcalico/calico/releases/download/${releaseTitle}`; - return url; -} - -export const url = buildUrl(); - -## Big picture - -This guide helps you install the `calicoctl` command line tool to manage $[prodname] resources -and perform administrative functions. - -## Value - -The `calicoctl` command line tool is required to use many of $[prodname]'s features. It -is used to manage $[prodname] policies and configuration, as well as view detailed cluster status. - -## Concepts - -### API groups - -All Kubernetes resources belong to an API group. The API group is indicated by the resource's `apiVersion`. For example, $[prodname] -uses resources in the `projectcalico.org/v3` API group for configuration, and the operator uses resources in the `operator.tigera.io/v1` API group. - -You can read more about API groups in [the Kubernetes documentation](https://kubernetes.io/docs/reference/using-api/#api-groups). - -### calicoctl and kubectl - -To manage $[prodname] APIs in the `projectcalico.org/v3` API group, you should use `calicoctl`. This is because -`calicoctl` provides important validation and defaulting for these resources that is not available in `kubectl`. However, `kubectl` -should still be used to manage other Kubernetes resources. - -:::note - -If you would like to use `kubectl` to manage `projectcalico.org/v3` API resources, you can use the -[Calico API server](../install-apiserver.mdx). - -::: - -:::caution - -Never modify resources in the `crd.projectcalico.org` API group directly. These are internal data representations -and modifying them directly may result in unexpected behavior. -In addition to resource management, `calicoctl` also enables other $[prodname] administrative tasks such as viewing IP pool utilization -and BGP status. - -::: - -### Datastore - -$[prodname] objects are stored in one of two datastores, either etcd or Kubernetes. The choice of datastore is determined at the time $[prodname] -is installed. Typically for Kubernetes installations the Kubernetes datastore is the default. - -You can run `calicoctl` on any host with network access to the $[prodname] datastore as either a binary or a container. -For step-by-step instructions, refer to the section that corresponds to your desired deployment. - -{/*- Change download URL to latest release if user browsing master branch. -*/} - -{/*- For master, we hard-code a version since we don't host master releases of calicoctl. -*/} - -## How to - -:::note - -Make sure you always install the version of `calicoctl` that matches the version of $[prodname] running on your cluster. - -::: - -- [Install calicoctl as a binary on a single host](#install-calicoctl-as-a-binary-on-a-single-host) -- [Install calicoctl as a container on a single host](#install-calicoctl-as-a-container-on-a-single-host) - -### Install calicoctl as a binary on a single host - - - - -1. Log into the host, open a terminal prompt, and navigate to the location where - you want to install the binary. - - :::tip - - Consider navigating to a location that's in your `PATH`. For example, - `/usr/local/bin/`. - - ::: - -1. Use the following commands to download the `calicoctl` binary. - - - AMD64: - - curl -L {url}/calicoctl-linux-amd64 -o calicoctl - - - ARM64: - - curl -L {url}/calicoctl-linux-arm64 -o calicoctl - - - PPC64le: - - curl -L {url}/calicoctl-linux-ppc64le -o calicoctl - -1. Set the file to be executable. - - ```bash - chmod +x ./calicoctl - ``` - - :::note - - If the location of `calicoctl` is not already in your `PATH`, move the file - to one that is or add its location to your `PATH`. This will allow you to invoke it - without having to prepend its location. - - ::: - - - - -1. Log into the host, open a terminal prompt, and navigate to the location where - you want to install the binary. - - :::tip - - Consider navigating to a location that's in your `PATH`. For example, - `/usr/local/bin/`. - - ::: - -1. Use the following commands to download the `calicoctl` binary. - - - ARM64 (Apple Silicon): - - curl -L {url}/calicoctl-darwin-arm64 -o calicoctl - - - AMD64 (Intel): - - curl -L {url}/calicoctl-darwin-amd64 -o calicoctl - -1. Set the file to be executable. - - ```bash - chmod +x calicoctl - ``` - - :::note - - If you are faced with `cannot be opened because the developer cannot be verified` error when using `calicoctl` for the first time. - go to `Applications > System Preferences > Security & Privacy` in the `General` tab at the bottom of the window click `Allow anyway`. - - ::: - - :::note - - If the location of `calicoctl` is not already in your `PATH`, move the file - to one that is or add its location to your `PATH`. This will allow you to invoke it - without having to prepend its location. - - ::: - - - - -1. Use the following PowerShell command to download the `calicoctl` binary. - - :::tip - - Consider running PowerShell as administrator and navigating - to a location that's in your `PATH`. For example, `C:\Windows`. - - ::: - -Invoke-WebRequest -Uri "{url}/calicoctl-windows-amd64.exe" -OutFile "calicoctl.exe" - - - - -### Install calicoctl as a container on a single host - -To install `calicoctl` as a container on a single host, log into the -target host and issue the following command. - -```bash -docker pull $[registry]$[imageNames.calicoctl]:$[releaseTitle] -``` - -**Next step**: - -[Configure `calicoctl` to connect to your datastore](configure/index.mdx). diff --git a/calico_versioned_docs/version-3.29/operations/certificate-management.mdx b/calico_versioned_docs/version-3.29/operations/certificate-management.mdx deleted file mode 100644 index d19f32d301..0000000000 --- a/calico_versioned_docs/version-3.29/operations/certificate-management.mdx +++ /dev/null @@ -1,136 +0,0 @@ ---- -description: Control the issuer of certificates used by Calico ---- - -# Manage TLS certificates used by Calico - -## Big picture - -Enable custom workflows for issuing and signing certificates used to secure communication between $[prodname] components. - -## Value - -Some deployments have security requirements that strictly minimize or eliminate the access to private keys and/or -requirements to control the trusted certificates throughout clusters. Using the Kubernetes Certificates API that automates -certificate issuance, $[prodname] provides a simple configuration option that you add to your installation. - -## Before you begin - -**Supported algorithms** - -- Private Key Pair: RSA (size: 2048, 4096, 8192), ECDSA (curve: 256, 384, 521) -- Certificate Signature: RSA (sha: 256, 384, 512), ECDSA (sha: 256, 384, 512) - -## How to - -- [Enable certificate management](#enable-certificate-management) -- [Verify and monitor](#verify-and-monitor) -- [Implement your own signing/approval process](#implement-your-own-signing-and-approval-process) - -### Enable certificate management - -1. Modify your [the installation resource](../reference/installation/api.mdx#installation) - resource and add the `certificateManagement` section. Apply the following change to your cluster. - -```yaml -apiVersion: operator.tigera.io/v1 -kind: Installation -metadata: - name: default -spec: - certificateManagement: - caCert: - signerName: / - signatureAlgorithm: SHA512WithRSA - keyAlgorithm: RSAWithSize4096 -``` - -Done! If you have an automatic signer and approver, there is nothing left to do. The next section explains in more detail -how to verify and monitor the status. - -### Verify and monitor - -1. Monitor your pods as they come up: - -```bash -kubectl get pod -n calico-system -w -NAMESPACE NAME READY STATUS RESTARTS AGE -calico-system calico-node-5ckvq 0/1 Pending 0 0s -calico-system calico-typha-688c9957f5-h9c5w 0/1 Pending 0 0s -calico-system calico-node-5ckvq 0/1 Init:0/3 0 1s -calico-system calico-typha-688c9957f5-h9c5w 0/1 Init:0/1 0 1s -calico-system calico-node-5ckvq 0/1 PodInitializing 0 2s -calico-system calico-typha-688c9957f5-h9c5w 0/1 PodInitializing 0 2s -calico-system calico-node-5ckvq 1/1 Running 0 3s -calico-system calico-typha-688c9957f5-h9c5w 1/1 Running 0 3s -``` - -During the `Init` phase a certificate signing request (CSR) is created by an init container of the pod. It will be stuck in the -`Init` phase. Once the CSR has been approved and signed by the certificate authority, the pod continues with `PodInitializing` -and eventually `Running`. - -1. Monitor certificate signing requests: - -```bash -kubectl get csr -w -NAME AGE REQUESTOR CONDITION -calico-system:calico-node-5ckvq:9a3a10 0s system:serviceaccount:calico-system:calico-node Pending -calico-system:calico-node-5ckvq:9a3a10 0s system:serviceaccount:calico-system:calico-node Pending,Issued -calico-system:calico-node-5ckvq:9a3a10 0s system:serviceaccount:calico-system:calico-node Approved,Issued -calico-system:typha-688c9957f5-h9c5w:2b0d82 0s system:serviceaccount:calico-system:calico-typha Pending -calico-system:typha-688c9957f5-h9c5w:2b0d82 0s system:serviceaccount:calico-system:calico-typha Pending,Issued -calico-system:typha-688c9957f5-h9c5w:2b0d82 0s system:serviceaccount:calico-system:calico-typha Approved,Issued -``` - -A CSR will be `Pending` until it has been `Issued` and `Approved`. The name of a CSR is based on the namespace, the pod -name and the first 6 characters of the pod's UID. The pod will be `Pending` until the CSR has been `Approved`. - -1. Monitor the status of this feature using the `TigeraStatus`: - -```bash -kubectl get tigerastatus -NAME AVAILABLE PROGRESSING DEGRADED SINCE -calico True False False 2m40s -``` - -### Implement your own signing and approval process - -**Required steps** - -This feature uses api version `certificates.k8s.io/v1beta1` for [certificate signing requests](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/). -To automate the signing and approval process, run a server that performs the following actions: - -1. Watch `CertificateSigningRequests` resources with status `Pending` and `spec.signerName=`. - - :::note - - You can skip this step if you are using a version before Kubernetes v1.18; (the signerName field was not available). - - ::: - -1. For each `Pending` CSR perform (security) checks (see next heading) -1. Issue a certificate and update `.spec.status.certificate` -1. Approve the CSR and update `.spec.status.conditions` - -**Security requirements** - -Based on your requirements you may want to implement custom checks to make sure that no certificates are issued for a malicious user. -When a CSR is created, the kube-apiserver adds immutable fields to the spec to help you perform checks: - -- `.spec.username`: username of the requester -- `.spec.groups`: user groups of the requester -- `.spec.request`: certificate request in pem format - -Verify that the user and/or group match with the requested certificate subject (alt) names. - -**Implement your signer and approver using golang** - -- Use [client-go](https://github.com/kubernetes/client-go) to create a clientset -- To watch CSRs, use `clientset.CertificatesV1().CertificateSigningRequests().Watch(..)` -- To issue the certificate use `clientset.CertificatesV1().CertificateSigningRequests().UpdateStatus(...)` -- To approve the CSR use `clientset.CertificatesV1().CertificateSigningRequests().UpdateApproval(...)` - -### Additional resources - -- Read [kubernetes certificate signing requests](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/) for more information on CSRs -- Use [client-go](https://github.com/kubernetes/client-go) to implement a controller to sign and approve a CSR diff --git a/calico_versioned_docs/version-3.29/operations/datastore-migration.mdx b/calico_versioned_docs/version-3.29/operations/datastore-migration.mdx deleted file mode 100644 index f81f009902..0000000000 --- a/calico_versioned_docs/version-3.29/operations/datastore-migration.mdx +++ /dev/null @@ -1,146 +0,0 @@ ---- -description: Migrate your cluster from using an etcdv3 datastore to a Kubernetes datastore. ---- - -# Migrate Calico data from an etcdv3 datastore to a Kubernetes datastore - -## Big picture - -Switch your $[prodname] datastore from etcdv3 to Kubernetes on a live cluster. - -## Value - -Using Kubernetes as your datastore provides a number of benefits over using etcdv3 -directly, including fewer components and better support for role based access -control. For most users, using the Kubernetes data store will provide a better -experience. We provide a seamless way to migrate your data from an existing -cluster with an etcdv3 datastore to a Kubernetes datastore. For the -complete set of advantages of using a Kubernetes datastore over an etcd datastore, see -[$[prodname] Datastore](../getting-started/kubernetes/hardway/the-calico-datastore.mdx#using-kubernetes-as-the-datastore) -documentation. - -## Before you begin - -- Ensure that your Calico installation is configured to use an etcdv3 datastore. This guide does not apply to clusters installed using the Kubernetes API datastore. - -- The **latest version of calicoctl** must be [installed and configured to access etcd](calicoctl/install.mdx). - - :::note - - Since the steps below require modifying calicoctl configuration, we do not recommend using calicoctl installed - as a Kubernetes pod for this procedure. Instead, install the binary directly on a host with access to etcd and the Kubernetes API. - - ::: - -## How to - -### Migrate the datastore - -To migrate contents of the datastore, we will be using the `calicoctl datastore migrate` -command and subcommands. For more information, see the -[calicoctl datastore migrate](../reference/calicoctl/datastore/migrate/overview.mdx) -documentation. - -1. Lock the etcd datastore for migration. This prevents any changes to the data from - affecting the cluster. - - ``` - calicoctl datastore migrate lock - ``` - - :::note - - After running the above command, you cannot make changes to the configuration of your cluster until the - migration is complete. New pods will not be started until after the migration. - - ::: - -1. Export the datastore contents to a file. - - ``` - calicoctl datastore migrate export > etcd-data - ``` - -1. Configure `calicoctl` to access the - [Kubernetes datastore](calicoctl/configure/kdd.mdx). - -1. Import the datastore contents from your exported file. - - ``` - calicoctl datastore migrate import -f etcd-data - ``` - -1. Verify that the datastore was properly imported. This can be accomplished by using - `calicoctl` to query for any $[prodname] resources that exist in the etcd - datastore (e.g. networkpolicy). - - ``` - calicoctl get networkpolicy - ``` - -1. Configure $[prodname] to read from the Kubernetes datastore. Follow the - directions to install $[prodname] with the Kubernetes datastore. The - installation instructions contain the relevant version of the - `calico.yaml` file to apply. - - ```bash - kubectl apply -f calico.yaml - ``` - -1. Wait for Calico to perform a rolling update before continuing by monitoring the following command - - ```bash - kubectl rollout status daemonset calico-node -n kube-system - ``` - -1. Unlock the datastore. This allows the $[prodname] resources to affect the cluster again. - - ``` - calicoctl datastore migrate unlock - ``` - - :::note - - Once the Kubernetes datastore is unlocked, the datastore migration - cannot be rolled back. Make sure that the Kubernetes datastore is populated with - all of the expected $[prodname] resources prior to unlocking the datastore. - - ::: - -### Roll back the datastore migration - -Rolling back the datastore migration can only be done if the original etcd datastore still exists -and the Kubernetes datastore was not unlocked after the datastore resources were imported. The -following steps delete the $[prodname] resources imported into the Kubernetes datastore and -configure the cluster to once again read from the original etcd datastore. - -1. Lock the Kubernetes datastore. - - ``` - calicoctl datastore migrate lock - ``` - -1. Delete all of the $[prodname] CRDs. This will remove all of the data imported into - the Kubernetes datastore. - - ```bash - kubectl delete $(kubectl get crds -o name | grep projectcalico.org) - ``` - -1. Configure $[prodname] to read from the etcd datastore. Follow the - directions to install $[prodname] with the etcd datastore. The - installation instructions contain the relevant version of the - `calico.yaml` file to apply. - - ```bash - kubectl apply -f calico.yaml - ``` - -1. Configure `calicoctl` to access the - [etcd datastore](calicoctl/configure/etcd.mdx). - -1. Unlock the etcd datastore. This allows the $[prodname] resources to affect the cluster again. - - ``` - calicoctl datastore migrate unlock - ``` diff --git a/calico_versioned_docs/version-3.29/operations/decommissioning-a-node.mdx b/calico_versioned_docs/version-3.29/operations/decommissioning-a-node.mdx deleted file mode 100644 index 9c477a36d3..0000000000 --- a/calico_versioned_docs/version-3.29/operations/decommissioning-a-node.mdx +++ /dev/null @@ -1,93 +0,0 @@ ---- -description: Manually remove a node from a cluster that is installed with Calico. ---- - -# Decommission a node - -## About decommissioning nodes - -If you are running the [node controller](../reference/kube-controllers/configuration.mdx) -or using the Kubernetes API datastore in policy-only mode, you do not need to manually decommission nodes. - -In other configurations, you may need to manually decommission a node for one -of the following reasons. - -- You are decommissioning a host running `$[nodecontainer]` or removing it from your - cluster. -- You are renaming a node. -- You are receiving an error about an IP address already in use. -- Readiness checks are failing due to unreachable peers that are no longer in the - cluster. -- Hosts are regularly added and removed from your cluster. - -## Purpose of this page - -Provide guidance on how to remove a host that is part of a $[prodname] cluster -and clean up the associated [node resource reference](../reference/resources/node.mdx) -information. - -## Prerequisites - -- Prior to removing any Node resource from the datastore the `$[nodecontainer]` - container should be stopped on the corresponding host and it should be - ensured that it will not be restarted. -- You must have [calicoctl configured](calicoctl/install.mdx) and operational to run - the commands listed here. - -## Removing a node resource - -Removing a Node resource will also remove the Workload Endpoint, Host -Endpoint, and IP Address resources and any other sub configuration items -associated with that Node. - -:::note - -- Deleting a Node resource may be service impacting if the host is still in - service. Ensure that the host is no longer in service before deleting the - Node resource. -- Any configuration specific to the node will be removed. This would be - configuration like node BGP peerings or custom Felix configs. - -::: - -## Removing a single node resource - -See the example below for how to remove a node with the calicoctl command. - -See [Removing a Node resource](#removing-a-node-resource) above. - -```bash -calicoctl delete node -``` - -## Removing multiple node resources - -To remove several Nodes, a file can be created with several Node resources and -then be passed to the `calicoctl delete` command with the `-f` flag. -Below is an example of how to create a file of Nodes and delete them. - -1. Create a file with the [Node resources](../reference/resources/node.mdx) that need - to be removed. For example: - - ```yaml - - apiVersion: projectcalico.org/v3 - kind: Node - metadata: - name: node-02 - - apiVersion: projectcalico.org/v3 - kind: Node - metadata: - name: node-03 - ``` - -2. To delete the nodes listed in the file pass it like below. - - :::caution - - See [Removing a Node resource](#removing-a-node-resource) above. - - ::: - - ```bash - calicoctl delete -f nodes_to_delete.yaml - ``` \ No newline at end of file diff --git a/calico_versioned_docs/version-3.29/operations/ebpf/enabling-ebpf.mdx b/calico_versioned_docs/version-3.29/operations/ebpf/enabling-ebpf.mdx deleted file mode 100644 index e58ce1a8fa..0000000000 --- a/calico_versioned_docs/version-3.29/operations/ebpf/enabling-ebpf.mdx +++ /dev/null @@ -1,411 +0,0 @@ ---- -description: Step-by-step instructions for enabling the eBPF data plane. ---- - -# Enable the eBPF data plane - -import EbpfValue from '@site/calico_versioned_docs/version-3.29/_includes/content/_ebpf-value.mdx'; - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - -## Big picture - -Enable the eBPF data plane on an existing cluster. - -## Value - - - -## Concepts - -### eBPF - -eBPF (or "extended Berkeley Packet Filter"), is a technology that allows safe mini programs to be attached to various low-level hooks in the Linux kernel. eBPF has a wide variety of uses, including networking, security, and tracing. You’ll see a lot of non-networking projects leveraging eBPF, but for $[prodname] our focus is on networking, and in particular, pushing the networking capabilities of the latest Linux kernels to the limit. - -## Before you begin - -### Supported - -- x86-64 -- arm64 (little endian) - -- Kubernetes datastore driver. - -- Distributions: - - - Generic or kubeadm - - kOps - - OpenShift - - EKS - - AKS with limitations: - - [AKS with Azure CNI and Calico network policy](../../getting-started/kubernetes/managed-public-cloud/aks.mdx#install-aks-with-azure-cni-for-networking-and-self-managed-calico-for-network-policy) works, but it is not possible to disable kube-proxy resulting in wasted resources and suboptimal performance. - - [AKS with $[prodname] networking](../../getting-started/kubernetes/managed-public-cloud/aks.mdx#install-aks-with-self-managed-calico-for-networking-and-network-policy) is in testing with the eBPF data plane. This should be a better solution overall but, at time of writing, the testing was not complete. - - RKE (RKE2 recommended because it supports disabling `kube-proxy`) - - MKE - -- Linux distribution/kernel: - - - Ubuntu 20.04. - - Red Hat v8.2 with Linux kernel v4.18.0-193 or above (Red Hat have backported the required features to that build). - - Another [supported distribution](../../getting-started/kubernetes/requirements.mdx) with Linux kernel v5.3 or above. Kernel v5.8 or above with CO-RE enabled is recommended for better performance. - -- An underlying network fabric that allows VXLAN traffic between hosts. In eBPF mode, VXLAN is used to forward Kubernetes NodePort traffic. - -- IPv6 - -Limitations: - - - IPIP is not supported ($[prodname] iptables does not support it either). VXLAN is the recommended overlay for eBPF mode. - -To enable IPv6 in eBPF mode, see [Configure dual stack or IPv6 only](../../networking/ipam/ipv6.mdx). You may be able to run with non-Calico IPAM. eks-cni is known to work. - -### Not supported - -- Other processor architectures. - -- etcd datastore driver. The etcd datastore driver doesn't support watching Kubernetes services, which is required for some features in eBPF mode. - -- Distributions: - - - GKE. This is because of an incompatibility with the GKE CNI plugin. - -- Clusters with some eBPF nodes and some standard data plane and/or Windows nodes. -- Floating IPs. -- SCTP (either for policy or services). This is due to lack of kernel support for the SCTP checksum in BPF. -- VLAN-based traffic. - :::tip - Under some circumstances, you can use a VLAN device to connect a node to the cluster by using the `bpfDataIfacePattern` Felix configuration variable. - For more information, see [Debugging Connectivity in Calico eBPF](https://www.tigera.io/blog/deep-dive/debugging-connectivity-in-calico-ebpf-the-mysterious-bpfdataifaceregexp-co/). - ::: - -### Performance - -For best pod-to-pod performance, we recommend using an underlying network that doesn't require Calico to use an overlay. For example: - -- A cluster within a single AWS subnet. -- A cluster using a compatible cloud provider's CNI (such as the AWS VPC CNI plugin). -- An on-prem cluster with BGP peering configured. - -If you must use an overlay, we recommend that you use VXLAN, not IPIP. VXLAN has much better performance than IPIP in -eBPF mode due to various kernel optimisations. - -## How to - -- [Verify that your cluster is ready for eBPF mode](#verify-that-your-cluster-is-ready-for-ebpf-mode) -- [Configure $[prodname] to talk directly to the API server](#configure-calico-to-talk-directly-to-the-api-server) -- [Configure kube-proxy](#configure-kube-proxy) -- [Enable eBPF mode](#enable-ebpf-mode) -- [Try out DSR mode](#try-out-direct-server-return-mode) -- [Reversing the process](#reversing-the-process) - -### Verify that your cluster is ready for eBPF mode - -This section explains how to make sure your cluster is suitable for eBPF mode. - -To check that the kernel on a node is suitable, you can run - -```bash -uname -rv -``` - -The output should look like this: - -``` -5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 -``` - -In this case the kernel version is v5.4, which is suitable. - -On Red Hat-derived distributions, you may see something like this: - -``` -4.18.0-193.el8.x86_64 (mockbuild@x86-vm-08.build.eng.bos.redhat.com) -``` - -Since the Red Hat kernel is v4.18 with at least build number 193, this kernel is suitable. - -### Configure $[prodname] to talk directly to the API server - -In eBPF mode, $[prodname] implements Kubernetes service networking directly (rather than relying on `kube-proxy`). -Of course, this makes it highly desirable to disable `kube-proxy` when running in eBPF mode to save resources -and avoid confusion over which component is handling services. - -To be able to disable `kube-proxy`, $[prodname] needs to communicate to the API server _directly_ rather than -going through `kube-proxy`. To make _that_ possible, we need to find a persistent, static way to reach the API server. -The best way to do that varies by Kubernetes distribution: - -- If you created a cluster manually (for example by using `kubeadm`) then the right address to use depends on whether you - opted for a high-availability cluster with multiple API servers or a simple one-node API server. - - - If you opted to set up a high availability cluster then you should use the address of the load balancer that you - used in front of your API servers. As noted in the Kubernetes documentation, a load balancer is required for a - HA set-up but the precise type of load balancer is not specified. - - If you opted for a single control plane node then you can use the address of the control plane node itself. However, - it's important that you use a _stable_ address for that node such as a dedicated DNS record, or a static IP address. - If you use a dynamic IP address (such as an EC2 private IP) then the address may change when the node is restarted - causing $[prodname] to lose connectivity to the API server. - -- `kops` typically sets up a load balancer of some sort in front of the API server. You should use - the FQDN and port of the API load balancer, for example `api.internal.` as the `KUBERNETES_SERVICE_HOST` - below and 443 as the `KUBERNETES_SERVICE_PORT`. -- OpenShift requires various DNS records to be created for the cluster; one of these is exactly what we need: - `api-int..` should point to the API server or to the load balancer in front of the - API server. Use that (filling in the `` and `` as appropriate for your cluster) for the - `KUBERNETES_SERVICE_HOST` below. OpenShift uses 6443 for the `KUBERNETES_SERVICE_PORT`. -- MKE runs a reverse proxy in each node that can be used to reach the API server. You should use `proxy.local` - as the `KUBERNETES_SERVICE_HOST` and `6444` as the `KUBERNETES_SERVICE_PORT`. -- For AKS and EKS clusters you should use the FQDN of the API server's load balancer. This can be found with - ``` - kubectl cluster-info - ``` - which gives output like the following: - ``` - Kubernetes master is running at https://60F939227672BC3D5A1B3EC9744B2B21.gr7.us-west-2.eks.amazonaws.com - ... - ``` - In this example, you would use `60F939227672BC3D5A1B3EC9744B2B21.gr7.us-west-2.eks.amazonaws.com` for - `KUBERNETES_SERVICE_HOST` and `443` for `KUBERNETES_SERVICE_PORT` when creating the config map. - - -**The next step depends on whether you installed $[prodname] using the operator, or a manifest:** - - - - -If you installed $[prodname] using the operator, create the following config map in the `tigera-operator` namespace using the host and port determined above: - -```yaml -kind: ConfigMap -apiVersion: v1 -metadata: - name: kubernetes-services-endpoint - namespace: tigera-operator -data: - KUBERNETES_SERVICE_HOST: '' - KUBERNETES_SERVICE_PORT: '' -``` - -The operator will pick up the change to the config map automatically and do a rolling update of $[prodname] to pass on the change. Confirm that pods restart and then reach the `Running` state with the following command: - -``` -watch kubectl get pods -n calico-system -``` - -If you do not see the pods restart then it's possible that the `ConfigMap` wasn't picked up (sometimes Kubernetes is slow to propagate `ConfigMap`s (see Kubernetes [issue #30189](https://github.com/kubernetes/kubernetes/issues/30189))). You can try restarting the operator. - - - - -If you installed $[prodname] using a manifest, create the following config map in the `kube-system` namespace using the host and port determined above: - -```yaml -kind: ConfigMap -apiVersion: v1 -metadata: - name: kubernetes-services-endpoint - namespace: kube-system -data: - KUBERNETES_SERVICE_HOST: '' - KUBERNETES_SERVICE_PORT: '' -``` - -Wait 60s for kubelet to pick up the `ConfigMap` (see Kubernetes [issue #30189](https://github.com/kubernetes/kubernetes/issues/30189)); then, restart the $[prodname] pods to pick up the change: - -``` -kubectl delete pod -n kube-system -l k8s-app=calico-node -kubectl delete pod -n kube-system -l k8s-app=calico-kube-controllers -``` - -And, if using Typha: - -``` -kubectl delete pod -n kube-system -l k8s-app=calico-typha -``` - -Confirm that pods restart and then reach the `Running` state with the following command: - -``` -watch "kubectl get pods -n kube-system | grep calico" -``` - -You can verify that the change was picked up by checking the logs of one of the $[nodecontainer] pods. - -``` -kubectl get po -n kube-system -l k8s-app=calico-node -``` - -Should show one or more pods: - -``` -NAME READY STATUS RESTARTS AGE -$[noderunning]-d6znw 1/1 Running 0 48m -... -``` - -Then, to search the logs, choose a pod and run: - -``` -kubectl logs -n kube-system | grep KUBERNETES_SERVICE_HOST -``` - -You should see the following log, with the correct `KUBERNETES_SERVICE_...` values. - -``` -2020-08-26 12:26:29.025 [INFO][7] daemon.go 182: Kubernetes server override env vars. KUBERNETES_SERVICE_HOST="172.16.101.157" KUBERNETES_SERVICE_PORT="6443" -``` - - - - -### Configure kube-proxy - -In eBPF mode $[prodname] replaces `kube-proxy` so it wastes resources (and reduces performance) to run both. -This section explains how to disable `kube-proxy` in some common environments. - -:::caution - -If you are running `kube-proxy` in IPVS mode, you must switch it to iptables mode before disabling `kube-proxy` or enabling eBPF mode. This applies to all platforms and is required for a successful migration. After switching to iptables mode, restart your nodes before proceeding. - -::: - -#### Clusters that run `kube-proxy` with a `DaemonSet` (such as `kubeadm`) - -For a cluster that runs `kube-proxy` in a `DaemonSet` (such as a `kubeadm`-created cluster), you can disable `kube-proxy` reversibly by adding a node selector to `kube-proxy`'s `DaemonSet` that matches no nodes, for example: - -``` -kubectl patch ds -n kube-system kube-proxy -p '{"spec":{"template":{"spec":{"nodeSelector":{"non-calico": "true"}}}}}' -``` - -Then, should you want to start `kube-proxy` again, you can simply remove the node selector. - -:::note - -This approach is not suitable for AKS with Azure CNI since that platform makes use of the Kubernetes add-on manager. -The change will be reverted by the system. For AKS, you should follow [Avoiding conflicts with kube-proxy](#avoiding-conflicts-with-kube-proxy) -below. - -::: - -#### OpenShift - -If you are running OpenShift, you can disable `kube-proxy` as follows: - -``` -kubectl patch networks.operator.openshift.io cluster --type merge -p '{"spec":{"deployKubeProxy": false}}' -``` - -To re-enable it: - -``` -kubectl patch networks.operator.openshift.io cluster --type merge -p '{"spec":{"deployKubeProxy": true}}' -``` - -#### MKE - -If you are running MKE, you can disable `kube-proxy` as follows: - -Follow the step procedure in [Modify an existing MKE configuration](https://docs.mirantis.com/mke/current/ops/administer-cluster/configure-an-mke-cluster/use-an-mke-configuration-file.html#modify-an-existing-mke-configuration) to download, edit, and upload your MKE configuration. During the editing step, add the following configuration: -`kube_proxy_mode=disabled` and `kube_default_drop_masq_bits=true`. - - -### Avoiding conflicts with kube-proxy - -If you cannot disable `kube-proxy` (for example, because it is managed by your Kubernetes distribution), then you _must_ change Felix configuration parameter `BPFKubeProxyIptablesCleanupEnabled` to `false`. This can be done with `kubectl` as follows: - -``` -kubectl patch felixconfiguration default --patch='{"spec": {"bpfKubeProxyIptablesCleanupEnabled": false}}' -``` - -If both `kube-proxy` and `BPFKubeProxyIptablesCleanupEnabled` is enabled then `kube-proxy` will write its iptables rules and Felix will try to clean them up resulting in iptables flapping between the two. - -### Enable eBPF mode - -**The next step depends on whether you installed $[prodname] using the operator, or a manifest:** - - - - -To enable eBPF mode, change the `spec.calicoNetwork.linuxDataplane` parameter in the operator's `Installation` - resource to `"BPF". - -```bash - kubectl patch installation.operator.tigera.io default --type merge -p '{"spec":{"calicoNetwork":{"linuxDataplane":"BPF"}}}' -``` - -:::note - -The operator rolls out the change with a rolling update (non-disruptive) and then swiftly transitions all nodes to eBPF mode. However, it's inevitable that some nodes will enter eBPF mode before others. This can disrupt the flow of traffic through node ports. - -::: - - - - -If you installed $[prodname] using a manifest, change Felix configuration parameter `BPFEnabled` to `true`. This can be done with `calicoctl`, as follows: - -``` -calicoctl patch felixconfiguration default --patch='{"spec": {"bpfEnabled": true}}' -``` - - - - - -When enabling eBPF mode, preexisting connections continue to use the non-BPF datapath; such connections should -not be disrupted, but they do not benefit from eBPF mode’s advantages. - -### Try out direct server return mode - -Direct server return (DSR) mode skips a hop through the network for traffic to services (such as node ports) from outside the cluster. -This reduces latency and CPU overhead but it requires the underlying network to allow nodes to send traffic with each other's IPs. - -In AWS, this requires all your nodes to be in the same subnet and for the source/dest check to be disabled. -In GCP, the source/dest check should also be disabled, which can be done by enabling IP forwarding. - -DSR mode is disabled by default; to enable it, set the `BPFExternalServiceMode` Felix configuration parameter to `"DSR"`. This can be done with `calicoctl`: - -``` -calicoctl patch felixconfiguration default --patch='{"spec": {"bpfExternalServiceMode": "DSR"}}' -``` - -To switch back to tunneled mode, set the configuration parameter to `"Tunnel"`: - -``` -calicoctl patch felixconfiguration default --patch='{"spec": {"bpfExternalServiceMode": "Tunnel"}}' -``` - -Switching external traffic mode can disrupt in-progress connections. - -### Reversing the process - -To revert to standard Linux networking: - -1. (Depending on whether you installed Calico with the operator or with a manifest) reverse the changes to the operator's `Installation` or the `FelixConfiguration` resource: - - - - - ```bash - kubectl patch installation.operator.tigera.io default --type merge -p '{"spec":{"calicoNetwork":{"linuxDataplane":"Iptables"}}}' - ``` - - - - - ``` - calicoctl patch felixconfiguration default --patch='{"spec": {"bpfEnabled": false}}' - ``` - - - - -1. If you disabled `kube-proxy`, re-enable it (for example, by removing the node selector added above). - - ``` - kubectl patch ds -n kube-system kube-proxy --type merge -p '{"spec":{"template":{"spec":{"nodeSelector":{"non-calico": null}}}}}' - -2. If you are running MKE, follow the step procedure in [Modify an existing MKE configuration](https://docs.mirantis.com/mke/current/ops/administer-cluster/configure-an-mke-cluster/use-an-mke-configuration-file.html#modify-an-existing-mke-configuration) to download, edit, and upload your MKE configuration. During the editing step, add the following configuration: -`kube_proxy_mode` to `iptables`. - -1. Since disabling eBPF mode is disruptive to existing connections, monitor existing workloads to make sure they re-establish any connections that were disrupted by the switch. diff --git a/calico_versioned_docs/version-3.29/operations/ebpf/index.mdx b/calico_versioned_docs/version-3.29/operations/ebpf/index.mdx deleted file mode 100644 index 357f65bedd..0000000000 --- a/calico_versioned_docs/version-3.29/operations/ebpf/index.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: Documentation for eBPF data plane mode, including how to enable eBPF data plane mode. -hide_table_of_contents: true ---- - -# eBPF data plane mode - -import DocCardList from '@theme/DocCardList'; -import { useCurrentSidebarCategory } from '@docusaurus/theme-common'; - - diff --git a/calico_versioned_docs/version-3.29/operations/ebpf/install.mdx b/calico_versioned_docs/version-3.29/operations/ebpf/install.mdx deleted file mode 100644 index 331c33db02..0000000000 --- a/calico_versioned_docs/version-3.29/operations/ebpf/install.mdx +++ /dev/null @@ -1,456 +0,0 @@ ---- -description: Install Calico in eBPF mode. ---- - -# Install in eBPF mode - -import EbpfValue from '@site/calico_versioned_docs/version-3.29/_includes/content/_ebpf-value.mdx'; - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - -## Big picture - -Install the eBPF data plane during the initial installation of $[prodname]. - -## Value - - - -## Concepts - -### eBPF - -eBPF (or "extended Berkeley Packet Filter"), is a technology that allows safe mini programs to be attached to various -low-level hooks in the Linux kernel. eBPF has a wide variety of uses, including networking, security, and tracing. -You’ll see a lot of non-networking projects leveraging eBPF, but for $[prodname] our focus is on networking, -and in particular, pushing the networking capabilities of the latest Linux kernels to the limit. - -## Before you begin - -### Supported - -- x86-64 -- arm64 (little-endian) - -- Kubernetes datastore driver. - -- Distributions: - - - Generic or kubeadm - - kOps - - OpenShift - - EKS - - AKS - - MKE - -- Linux distribution/kernel: - - - Ubuntu 20.04. - - Red Hat v8.2 with Linux kernel v4.18.0-193 or above (Red Hat have backported the required features to that build). - - Another [supported distribution](../../getting-started/kubernetes/requirements.mdx) with Linux kernel v5.3 or above. - -- An underlying network fabric that allows VXLAN traffic between hosts. In eBPF mode, VXLAN is used to forward Kubernetes NodePort traffic. - -- IPv6 - -Limitations: - - - IPIP is not supported ($[prodname] iptables does not support it either). VXLAN is the recommended overlay for eBPF mode. - -To enable IPv6 in eBPF mode, see [Configure dual stack or IPv6 only](../../networking/ipam/ipv6.mdx). You may be able to run with non-Calico IPAM. eks-cni is known to work. - -### Not supported - -- Other processor architectures. - -- etcd datastore driver. The etcd datastore driver doesn't support watching Kubernetes services, which is required for some features in eBPF mode. - -- Distributions: - - - GKE. This is because of an incompatibility with the GKE CNI plugin. - - - RKE: eBPF mode cannot be enabled at install time because RKE doesn't provide - a stable address for the API server. However, by following [these instructions](enabling-ebpf.mdx), - it can be enabled as a post-install step. - -- Clusters with some eBPF nodes and some standard data plane and/or Windows nodes. -- Floating IPs. -- SCTP (either for policy or services). -- Tagged VLAN devices. - -### Performance - -For best pod-to-pod performance, we recommend using an underlying network that doesn't require Calico to use an overlay. For example: - -- A cluster within a single AWS subnet. -- A cluster using a compatible cloud provider's CNI (such as the AWS VPC CNI plugin). -- An on-prem cluster with BGP peering configured. - -If you must use an overlay, we recommend that you use VXLAN, not IPIP. VXLAN has better performance than IPIP in -eBPF mode due to various kernel optimisations. - -## How to - -To install in eBPF mode, we recommend using the Tigera Operator to install $[prodname] so these instructions -use the operator. Installing $[prodname] normally consists of the following stages, which are covered by the -main installation guides: - -- Create a cluster suitable to run $[prodname]. -- Install the Tigera Operator (possibly via a Helm chart), and the associated Custom Resource Definitions. -- Apply a set of Custom Resources to tell the operator what to install. -- Wait for the operator to provision all the associated resources and report back via its status resource. - -To install directly in eBPF is very similar; this guide explains the differences: - -- [Create a cluster](#create-a-suitable-cluster) suitable to run $[prodname] **with the added requirement that the nodes must use a recent - enough kernel**. -- [**Create a config map with the "real" address of the API server.**](#create-kubernetes-service-endpoint-config-map) This allows the operator to install $[prodname] - with a direct connection to the API server so that it can take over from `kube-proxy`. -- [Install the Tigera Operator](#install-the-tigera-operator) (possibly via a Helm chart), and the associated Custom Resource Definitions. -- **[Download and tweak the installation Custom Resource](#tweak-and-apply-installation-custom-resources) to tell the operator to use eBPF mode.** -- [Apply a set of Custom Resources](#tweak-and-apply-installation-custom-resources) to tell the operator what to install. -- [Wait for the operator to provision all the associated resources and report back via its status resource](#monitor-the-progress-of-the-installation). -- [Disable kube-proxy or avoid conflicts.](#disable-kube-proxy-or-avoid-conflicts) - -These steps are explained in more detail below. - -### Create a suitable cluster - -The basic requirement for eBPF mode is to have a recent-enough kernel (see [above](#supported)). - -Select the appropriate tab below for distribution-specific instructions: - - - - -`kubeadm` supports a number of base OSes; as long as the base OS chosen (such as Ubuntu 20.04) meets the kernel -requirements, `kubeadm`-provisioned clusters are supported. - -Since `kube-proxy` is not required in eBPF mode, you must disable `kube-proxy` at install time. With `kubeadm` -you can do that by passing the ` --skip-phases=addon/kube-proxy` flag to `kubeadm init`: - -```bash -kubeadm init --skip-phases=addon/kube-proxy -``` - - - - -`kops` supports a number of base OSes; as long as the base OS chosen (such as Ubuntu 20.04 or RHEL 8.2) meets the kernel -requirements, `kops`-provisioned clusters are supported. - -Since `kube-proxy` is not required in eBPF mode, you must disable `kube-proxy` at install time. With `kops` you -can do that by setting the following in your `kops` configuration: - -```yaml -kubeProxy: - enabled: false -``` - - - - -OpenShift supports a number of base OSes; as long as the base OS chosen has a recent enough kernel, OpenShift clusters are -fully supported. Since Red Hat have backported the eBPF features required by $[prodname] the Red Hat kernel -version required is lower than the mainline: v4.18.0-193 or above. - - - - -Azure Kubernetes Service (AKS) supports a number of base OSes. The most recent Ubuntu 18.04 image has a recent enough -kernel to use with eBPF mode. - -AKS does not support disabling `kube-proxy` so it's necessary to tell $[prodname] not to try to clean up -`kube-proxy`'s iptables rules at a later stage. - - - - -Amazon's Elastic Kubernetes Service (EKS) supports a number of base OSes for nodes. At the time of writing, the -default kernel used by Amazon Linux is recent enough to run eBPF mode, as is the Bottlerocket kernel. The Ubuntu -18.04 image did not have a recent-enough kernel (but that may have changed by the time you read this). - - - - -The eBPF data plane is supported on MKE with any Linux operating system that meets the minimum kernel requirements. - -Since `kube-proxy` is not required in eBPF mode, you must disable `kube-proxy` at install time. With `MKE` you -can do that by setting `--kube-proxy-mode=disabled` and `--kube-default-drop-masq-bits` when installing the cluster. - -More details can be found in [the MKE documentation](https://docs.mirantis.com/mke/current/install/predeployment/configure-networking/cluster-service-networking-options.html) - - - - - -### Create kubernetes-service-endpoint config map - -In eBPF mode, $[prodname] takes over from `kube-proxy`. This means that, like `kube-proxy`, it needs to be able -to reach the API server _directly_ rather than by using the API server's `ClusterIP`. To tell $[prodname] how -to reach the API server we create a `ConfigMap` with the API server's "real" address. In this guide we do that before -installing the Tigera Operator. That means that the operator itself can also use the direct connection and hence -it doesn't require `kube-proxy` to be running. - -The tabs below explain how to find the "real" address of the API server for a range of distributions. -**Note:** In all cases it's important that the address used is stable even if your API server is restarted or -scaled up/down. If you have multiple API servers, with DNS or other load balancing in front it's important to use -the address of the load balancer. This prevents $[prodname] from being disconnected if the API servers IP changes. - - - - -If you created a cluster manually (for example by using `kubeadm`) then the right address to use depends on whether you -opted for a high-availability cluster with multiple API servers or a simple one-node API server. - -- If you opted to set up a high availability cluster then you should use the address of the load balancer that you - used in front of your API servers. As noted in the Kubernetes documentation, a load balancer is required for a - HA set-up but the precise type of load balancer is not specified. -- If you opted for a single control plane node then you can use the address of the control plane node itself. However, - it's important that you use a _stable_ address for that node such as a dedicated DNS record, or a static IP address. - If you use a dynamic IP address (such as an EC2 private IP) then the address may change when the node is restarted - causing $[prodname] to lose connectivity to the API server. - - - - -When using `kops`, `kops` typically sets up a load balancer of some sort in front of the API server. You should use -the FQDN and port of the API load balancer: `api.internal.`. - - - - -OpenShift requires various DNS records to be created for the cluster; one of these is exactly what we need: -`api..` should point to the API server or to the load balancer in front of the -API server. Use that (filling in the `` and `` as appropriate for your cluster) for the -`KUBERNETES_SERVICE_HOST` below. OpenShift uses 6443 for the `KUBERNETES_SERVICE_PORT`. - - - - -For AKS clusters, you should use the FQDN of your API server. This can be found by running the following command: - -```bash -kubectl cluster-info -``` - -which should give output similar to the following: - -``` -Kubernetes master is running at https://mycalicocl-calicodemorg-03a087-36558dbb.hcp.canadaeast.azmk8s.io:443 -``` - -In this example, you would use `mycalicocl-calicodemorg-03a087-36558dbb.hcp.canadaeast.azmk8s.io` for -`KUBERNETES_SERVICE_HOST` and `443` for `KUBERNETES_SERVICE_PORT` when creating the config map. - - - - -For an EKS cluster, it's important to use the domain name of the EKS-provided load balancer that is in front of the API -server. This can be found by running the following command: - -```bash -kubectl cluster-info -``` - -which should give output similar to the following: - -``` -Kubernetes master is running at https://60F939227672BC3D5A1B3EC9744B2B21.gr7.us-west-2.eks.amazonaws.com -... -``` - -In this example, you would use `60F939227672BC3D5A1B3EC9744B2B21.gr7.us-west-2.eks.amazonaws.com` for -`KUBERNETES_SERVICE_HOST` and `443` for `KUBERNETES_SERVICE_PORT` when creating the config map. - - - - -MKE runs a reverse proxy in each node which can be used to reach the api-server. `KUBERNETES_SERVICE_HOST` must be set to -`proxy.local` and `KUBERNETES_SERVICE_PORT` must be set to `6444`. - - - - -### Install the Tigera Operator - -Follow the steps in the main install for your platform that installs the Tigera Operator, without applying the custom-resources.yaml (you will update this file in a later step in this doc). - -For clusters in AWS, such as kOps and EKS, you must also patch the tigera-operator deployment with DNS config so the operator can resolve the apiserver DNS. -AWS DNS server's address is 169.254.169.253. - -```bash -kubectl patch deployment -n tigera-operator tigera-operator -p '{"spec":{"template":{"spec":{"dnsConfig":{"nameservers":["169.254.169.253"]}}}}}' -``` - -### Create the Config Map - -Create the following config map in the `tigera-operator` namespace using the host and port determined above: - -```bash -kubectl apply -f - <" - KUBERNETES_SERVICE_PORT: "" -EOF -``` - -### Tweak and apply installation Custom Resources - -When the main install guide tells you to apply the `custom-resources.yaml`, typically by running `kubectl create` with -the URL of the file directly, you should instead download the file, so that you can edit it: - -```bash - curl -o custom-resources.yaml $[manifestsUrl]/manifests/custom-resources.yaml -``` - -Edit the file in your editor of choice and find the `Installation` resource, which should be at the top of the file. -To enable eBPF mode, we need to add a new `calicoNetwork` section inside the `spec` of the Installation resource, -including the `linuxDataplane` field. For EKS Bottlerocket OS only, you should also add the `flexVolumePath` setting -as shown below. - -For example: - -```yaml -# This section includes base $[prodname] installation configuration. - -apiVersion: operator.tigera.io/v1 -kind: Installation -metadata: - name: default -spec: - # Added calicoNetwork section with linuxDataplane field - calicoNetwork: - linuxDataplane: BPF - - # EKS with Bottlerocket as node image only: - # flexVolumePath: /var/lib/kubelet/plugins - - # Install Calico Open Source - variant: Calico - -# This section configures the Calico API server. - -apiVersion: operator.tigera.io/v1 -kind: APIServer -metadata: - name: default -spec: {} -``` - -Then apply the edited file: - -```bash -kubectl create -f custom-resources.yaml -``` - -:::tip - -If you already created the custom resources, you can switch your cluster over to eBPF mode by updating the -installation resource. The operator will automatically roll out the change. - -```bash -kubectl patch installation.operator.tigera.io default --type merge -p '{"spec":{"calicoNetwork":{"linuxDataplane":"BPF", "hostPorts":null}}}' -``` - -::: - -### Monitor the progress of the installation - -You can monitor progress of the installation with the following command: - -```bash -watch kubectl get tigerastatus -``` - -### Disable `kube-proxy` (or avoid conflicts) - -In eBPF mode, to avoid conflicts with `kube-proxy` it's necessary to either disable `kube-proxy` or to configure -$[prodname] not to clean up `kube-proxy`'s iptables rules. If you didn't disable `kube-proxy` when starting -your cluster then follow the steps below to avoid conflicts: - -:::caution - -If you are running `kube-proxy` in IPVS mode, you must switch it to iptables mode before disabling `kube-proxy` or enabling eBPF mode. This applies to all platforms and is required for a successful migration. After switching to iptables mode, restart your nodes before proceeding. - -::: - - - - -For a cluster that runs `kube-proxy` in a `DaemonSet` (such as a `kubeadm`-created cluster), you can disable -`kube-proxy`, reversibly, by adding a node selector to `kube-proxy`'s `DaemonSet` that matches no nodes, for example: - -``` -kubectl patch ds -n kube-system kube-proxy -p '{"spec":{"template":{"spec":{"nodeSelector":{"non-calico": "true"}}}}}' -``` - -Then, should you want to start `kube-proxy` again, you can simply remove the node selector. - - - - -`kops` allows `kube-proxy` to be disabled by setting - -```yaml -kubeProxy: - enabled: false -``` - -in its configuration. You will need to do `kops update cluster` to roll out the change. - - - - -In OpenShift, you can disable `kube-proxy` as follows: - -```bash -kubectl patch networks.operator.openshift.io cluster --type merge -p '{"spec":{"deployKubeProxy": false}}' -``` - -If you need to re-enable it later: - -```bash -kubectl patch networks.operator.openshift.io cluster --type merge -p '{"spec":{"deployKubeProxy": true}}' -``` - - - - -AKS with Azure CNI does not allow `kube-proxy` to be disabled, `kube-proxy` is deployed by the add-on manager, which will reconcile -away any manual changes made to its configuration. To ensure `kube-proxy` and $[prodname] don't fight, set -the Felix configuration parameter `bpfKubeProxyIptablesCleanupEnabled` to false. This can be done with -`kubectl` as follows: - -```bash -kubectl patch felixconfiguration default --type merge --patch='{"spec": {"bpfKubeProxyIptablesCleanupEnabled": false}}' -``` - - - - -In EKS, you can disable `kube-proxy`, reversibly, by adding a node selector that doesn't match and nodes to -`kube-proxy`'s `DaemonSet`, for example: - -```bash -kubectl patch ds -n kube-system kube-proxy -p '{"spec":{"template":{"spec":{"nodeSelector":{"non-calico": "true"}}}}}' -``` - -Then, should you want to start `kube-proxy` again, you can simply remove the node selector. - - - - - -## Next steps - -**Recommended** - -- [Learn more about eBPF](use-cases-ebpf.mdx) -- [Debug eBPF policies](../../network-policy/policy-rules/log-rules.mdx) diff --git a/calico_versioned_docs/version-3.29/operations/ebpf/troubleshoot-ebpf.mdx b/calico_versioned_docs/version-3.29/operations/ebpf/troubleshoot-ebpf.mdx deleted file mode 100644 index 679fb1a221..0000000000 --- a/calico_versioned_docs/version-3.29/operations/ebpf/troubleshoot-ebpf.mdx +++ /dev/null @@ -1,247 +0,0 @@ ---- -description: How to troubleshoot when running in eBPF mode. ---- - -# Troubleshoot eBPF mode - -This document gives some general troubleshooting guidance for the eBPF data plane. - -To understand basic concepts, we recommend the following video by Tigera Engineers: [Opening the Black Box: Understanding and troubleshooting Calico's eBPF Data Plane](https://www.youtube.com/watch?v=Mh43sNBu208). - -## Troubleshoot access to services - -If pods or hosts within your cluster have trouble accessing services, check the following: - -- Either $[prodname]'s eBPF mode or `kube-proxy` must be active on a host for services to function. If you - disabled `kube-proxy` when enabling eBPF mode, verify that eBPF mode is actually functioning. If $[prodname] - detects that the kernel is not supported, it will fall back to standard data plane mode (which does not support - services). - - To verify that eBPF mode is correctly enabled, examine the log for a `$[noderunning]` container; if - eBPF mode is not supported it will log an `ERROR` log that says - - ```bash - BPF data plane mode enabled but not supported by the kernel. Disabling BPF mode. - ``` - - If BPF mode is correctly enabled, you should see an `INFO` log that says - - ```bash - BPF enabled, starting BPF endpoint manager and map manager. - ``` - -- In eBPF mode, external client access to services (typically NodePorts) is implemented using VXLAN encapsulation. - If NodePorts time out when the backing pod is on another node, check your underlying network fabric allows - VXLAN traffic between the nodes. VXLAN is a UDP protocol; by default it uses port 4789. -- In DSR mode, $[prodname] requires that the underlying network fabric allows one node to respond on behalf of - another. - - - In AWS, to allow this, the Source/Dest check must be disabled on the node's NIC. However, note that DSR only - works within AWS; it is not compatible with external traffic through a load balancer. This is because the load - balancer is expecting the traffic to return from the same host. - - - In GCP, the "Allow forwarding" option must be enabled. As with AWS, traffic through a load balancer does not - work correctly with DSR because the load balancer is not consulted on the return path from the backing node. - -# The `calico-bpf` tool - -Since BPF maps contain binary data, the $[prodname] team wrote a tool to examine $[prodname]'s BPF maps. -The tool is embedded in the $[nodecontainer] container image. To run the tool: - -- Find the name of the $[nodecontainer] Pod on the host of interest using - - ```bash - kubectl get pod -o wide -n calico-system - ``` - - for example, `calico-node-abcdef` - -- Run the tool as follows: - - ```bash - kubectl exec -n calico-system calico-node-abcdef -- calico-node -bpf ... - ``` - - For example, to show the tool's help: - - ```bash - kubectl exec -n calico-system calico-node-abcdef -- calico-node -bpf help - - Usage: - calico-bpf [command] - - Available Commands: - arp Manipulates arp - connect-time Manipulates connect-time load balancing programs - conntrack Manipulates connection tracking - counters Show and reset counters - help Help about any command - ipsets Manipulates ipsets - nat Manipulates network address translation (nat) - routes Manipulates routes - version Prints the version and exits - - Flags: - --config string config file (default is $HOME/.calico-bpf.yaml) - -h, --help help for calico-bpf - --log-level string Set log level (default "warn") - -t, --toggle Help message for toggle - ``` - - (Since the tool is embedded in the main `calico-node` binary the `--help` option is not available, but running - `calico-node -bpf help` does work.) - - To dump the BPF conntrack table: - - ``` - kubectl exec -n calico-system calico-node-abcdef -- calico-node -bpf conntrack dump - ... - ``` - - Also, it is possible to fetch various counters, like packets dropped by a policy or different errors, from BPF data plane using the same tool. - For example, to dump the BPF counters of `eth0` interface: - - ``` - kubectl exec -n calico-system calico-node-abcdef -- calico-node -bpf counters dump --iface=eth0 - +----------+--------------------------------+---------+--------+-----+ - | CATEGORY | TYPE | INGRESS | EGRESS | XDP | - +----------+--------------------------------+---------+--------+-----+ - | Accepted | by another program | 0 | 0 | 0 | - | | by failsafe | 0 | 2 | 23 | - | | by policy | 1 | 0 | 0 | - | Dropped | by policy | 0 | 0 | 0 | - | | failed decapsulation | 0 | 0 | 0 | - | | failed encapsulation | 0 | 0 | 0 | - | | incorrect checksum | 0 | 0 | 0 | - | | malformed IP packets | 0 | 0 | 0 | - | | packets with unknown route | 0 | 0 | 0 | - | | packets with unknown source | 0 | 0 | 0 | - | | packets with unsupported IP | 0 | 0 | 0 | - | | options | | | | - | | too short packets | 0 | 0 | 0 | - | Total | packets | 27 | 124 | 41 | - +----------+--------------------------------+---------+--------+-----+ - dumped eth0 counters. - ``` - -## Check if a program is dropping packets - -To check if an eBPF program is dropping packets, you can use either the `calico-bpf` or `tc` command-line tool. For example, if you -are worried that the eBPF program attached to `eth0` is dropping packets, you can use `calico-bpf` to fetch BPF counters as described -in the previous section and look for one of the `Dropped` counters or you can run the following command: - -``` -tc -s qdisc show dev eth0 -``` - -The output should look like the following; find the `clsact` qdisc, which is the attachment point for eBPF programs. -The `-s` option to `tc` causes `tc` to display the count of dropped packets, which amounts to the count of packets -dropped by the eBPF programs. - -``` -... -qdisc clsact 0: dev eth0 root refcnt 2 - sent 1340 bytes 10 pkt (dropped 10, overlimits 0 requeues 0) - backlog 0b 0p requeues 0 -... -``` - -## Debug high CPU usage - -If you notice `$[noderunning]` using high CPU: - -- Check if `kube-proxy` is still running. If `kube-proxy` is still running, you must either disable `kube-proxy` or - ensure that the Felix configuration setting `bpfKubeProxyIptablesCleanupEnabled` is set to `false`. If the setting - is set to `true` (its default), then Felix will attempt to remove `kube-proxy`'s iptables rules. If `kube-proxy` is - still running, it will fight with `Felix`. -- If your cluster is very large, or your workload involves significant service churn, you can increase the interval - at which Felix updates the services data plane by increasing the `bpfKubeProxyMinSyncPeriod` setting. The default is - 1 second. Increasing the value has the trade-off that service updates will happen more slowly. -- $[prodname] supports endpoint slices, similarly to `kube-proxy`. If your Kubernetes cluster supports endpoint - slices and they are enabled, then you can enable endpoint slice support in $[prodname] with the - `bpfKubeProxyEndpointSlicesEnabled` configuration flag. - -## eBPF program debug logs - -$[prodname]'s eBPF programs contain optional detailed debug logging. Although the logs can be very verbose (because -the programs will log every packet), they can be invaluable to diagnose eBPF program issues. To enable the log, set the -`bpfLogLevel` Felix configuration setting to `Debug`. - -:::caution - -Enabling logs in this way has a significant impact on eBPF program performance. - -::: - -> The logs are emitted to the kernel trace buffer, and they can be examined using the following command: - -``` -tc exec bpf debug -``` - -Logs have the following format: - -``` - <...>-84582 [000] .Ns1 6851.690474: 0: ens192---E: Final result=ALLOW (-1). Program execution time: 7366ns -``` - -The parts of the log are explained below: - -- `<...>-84582` gives an indication about what program (or kernel process) was handling the - packet. For packets that are being sent, this is usually the name and PID of the program that is actually sending - the packet. For packets that are received, it is typically a kernel process, or an unrelated program that happens to - trigger the processing. -- `6851.690474` is the log timestamp. - -- `ens192---E` is the $[prodname] log tag. For programs attached to interfaces, the first part contains the - first few characters of the interface name. The suffix is either `-I` or `-E` indicating "Ingress" or "Egress". - "Ingress" and "Egress" have the same meaning as for policy: - - - A workload ingress program is executed on the path from the host network namespace to the workload. - - A workload egress program is executed on the workload to host path. - - A host endpoint ingress program is executed on the path from external node to the host. - - A host endpoint egress program is executed on the path from host to external host. - -- `Final result=ALLOW (-1). Program execution time: 7366ns` is the message. In this case, logging the final result of - the program. Note that the timestamp is massively distorted by the time spent logging. - -## Poor performance - -A number of problems can reduce the performance of the eBPF data plane. - -- Verify that you are using the best networking mode for your cluster. If possible, avoid using an overlay network; - a routed network with no overlay is considerably faster. If you must use one of $[prodname]'s overlay modes, - use VXLAN, not IPIP. IPIP performs poorly in eBPF mode due to kernel limitations. -- If you are not using an overlay, verify that the [Felix configuration parameters](../../reference/felix/configuration.mdx) - `ipInIpEnabled` and `vxlanEnabled` are set to `false`. Those parameters control whether Felix configured itself to - allow IPIP or VXLAN, even if you have no IP pools that use an overlay. The parameters also disable certain eBPF - mode optimisations for compatibility with IPIP and VXLAN. - - To examine the configuration: - - ```bash - kubectl get felixconfiguration -o yaml - ``` - - ```yaml noValidation - apiVersion: projectcalico.org/v3 - items: - - apiVersion: projectcalico.org/v3 - kind: FelixConfiguration - metadata: - creationTimestamp: "2020-10-05T13:41:20Z" - name: default - resourceVersion: "767873" - uid: 8df8d751-7449-4b19-a4f9-e33a3d6ccbc0 - spec: - ... - ipipEnabled: false - ... - vxlanEnabled: false - kind: FelixConfigurationList - metadata: - resourceVersion: "803999" - ``` - -- If you are running your cluster in a cloud such as AWS, then your cloud provider may limit the bandwidth between - nodes in your cluster. For example, most AWS nodes are limited to 5GBit per connection. diff --git a/calico_versioned_docs/version-3.29/operations/ebpf/use-cases-ebpf.mdx b/calico_versioned_docs/version-3.29/operations/ebpf/use-cases-ebpf.mdx deleted file mode 100644 index 35d5f33d66..0000000000 --- a/calico_versioned_docs/version-3.29/operations/ebpf/use-cases-ebpf.mdx +++ /dev/null @@ -1,95 +0,0 @@ ---- -description: Learn when to use eBPF, and when not to. ---- - -# eBPF use cases - -## Big picture - -Learn when to use eBPF (and when not to). - -## What is eBPF? - -eBPF is a feature available in Linux kernels that allows you to run a virtual machine inside the kernel. This virtual machine allows you to safely load programs into the kernel, to customize its operation. Why is this important? - -In the past, making changes to the kernel was difficult: there were APIs you could call to get data, but you couldn’t influence what was inside the kernel or execute code. Instead, you had to submit a patch to the Linux community and wait for it to be approved. With eBPF, you can load a program into the kernel and instruct the kernel to execute your program if, for example, a certain packet is seen or another event occurs. - -With eBPF, the kernel and its behavior become highly customizable, instead of being fixed. This can be extremely beneficial, when used under the right circumstances. - -## $[prodname] and eBPF - -$[prodname] offers an eBPF data plane as an alternative to our standard Linux data plane (which is iptables based). While the standard data plane focuses on compatibility by working together with kube-proxy and your own iptables rules, the eBPF data plane focuses on performance, latency, and improving user experience with features that aren’t possible with the standard data plane. - -But $[prodname] doesn’t only support standard Linux and eBPF; it currently supports a total of three data planes, including Windows HNS, and has plans to add support for even more data planes in the near future. $[prodname] enables you, the user, to decide what works best for what you want to do. - -If you enable eBPF within $[prodname] but have existing iptables flows, we won’t touch them. Because maybe you want to use connect-time load balancing, but leave iptables as is. With $[prodname], it’s not an all-or-nothing deal—we allow you to easily load and unload our eBPF data plane to suit your needs, which means you can quickly try it out before making a decision. $[prodname] offers you the ability to leverage eBPF as needed, as an additional control to build your Kubernetes cluster security. - -## Use cases - -There are several use cases for eBPF, including traffic control, creating network policy, and connect-time load balancing. - -### Traffic control - -Without eBPF, packets use the standard Linux networking path on their way to a final destination. If a packet shows up at point A, and you know that the packet needs to go to point B, you can optimize the network path in the Linux kernel by sending it straight to point B. With eBPF, you can leverage additional context to make these changes in the kernel so that packets bypass complex routing and simply arrive at their final destination. - -This is especially relevant in a Kubernetes container environment, where you have numerous networks. (In addition to the host network stack, each container has its own mini network stack.) When traffic comes in, it is usually routed to a container stack and must travel a complex path as it makes its way there from the host stack. This routing can be bypassed using eBPF. - -### Creating network policy - -When creating network policy, there are two instances where eBPF can be used: - -- **eXpress Data Path (XDP)** – As a raw packet buffer enters the system, eBPF gives you an efficient way to examine that buffer and make quick decisions about what to do with it. - -- **Network policy** – eBPF allows you to efficiently examine a packet and apply network policy, both for pods and hosts. - -### Connect-time load balancing - -When load balancing service connections in Kubernetes, a port needs to talk to a service and therefore network address translation (NAT) must occur. A packet is sent to a virtual IP, and that virtual IP translates it to the destination IP of the pod backing the service; the pod then responds to the virtual IP and the return packet is translated back to the source. - -With eBPF, you can avoid this packet translation by using an eBPF program that you’ve loaded into the kernel and load balancing at the source of the connection. All NAT overhead from service connections is removed because destination network address translation (DNAT) does not need to take place on the packet processing path. - -## The price of performance - -So is eBPF more efficient than standard Linux iptables? The short answer: it depends. - -If you were to micro-benchmark how iptables works when applying network policies with a large number of IP addresses (i.e. ipsets), iptables in many cases is better than eBPF. But if you want to do something in the Linux kernel where you need to alter the packet flow in the kernel, eBPF would be the better choice. Standard Linux iptables is a complex system and certainly has its limitations, but at the same time it provides options to manipulate traffic; if you know how to program iptables rules, you can achieve a lot. eBPF allows you to load your own programs into the kernel to influence behavior that can be customized to your needs, so it is more flexible than iptables as it is not limited to one set of rules. - -Something else to consider is that, while eBPF allows you to run a program, add logic, redirect flows, and bypass processing—which is a definite win—it’s a virtual machine and as such must be translated to bytecode. By comparison, the Linux kernel’s iptables is already compiled to code. - -As you can see, comparing eBPF to iptables is not a straight apples-to-apples comparison. What we need to assess is performance, and the two key factors to look at here are latency (speed) and expense. If eBPF is very fast but takes up 80% of your resources, then it’s like a Lamborghini—an expensive, fast car. And if that works for you, great (maybe you really like expensive, fast cars). Just keep in mind that more CPU usage means more money spent with your cloud providers. So while a Lamborghini might be faster than a lot of other cars, it might not be the best use of money if you need to comply with speed limits on your daily commute. - -## When to use eBPF (and when not to) - -With eBPF, you get performance—but it comes at a cost. You need to find a balance between the two by figuring out the price of performance, and deciding if it’s acceptable to you from an eBPF perspective. - -Let’s look at some specific cases where it would make sense to use eBPF, and some where it would not. - -### When not to use eBPF - -### ✘ Packet-by-packet processing - -Using eBPF to perform CPU intensive or packet-by-packet processing, such as decryption and re-encryption for encrypted flows, would not be efficient because you would need to build a structure and do a lookup for every packet, which is expensive. - -### When to use eBPF - -### ✔ XDP - -eBPF provides an efficient way to examine raw packet buffers as they enter the system, allowing you to make quick decisions about what to do with them. - -### ✔ Connect-time load balancing - -With eBPF, you can load balance at the source using a program you’ve loaded into the kernel, instead of using a virtual IP. Since DNAT does not need to take place on the packet processing path, all NAT overhead from service connections is removed. - -### ✔ Building a service mesh control plane - -Service mesh relies on proxies like Envoy. A lot of thought has gone into designing this process over the years. The main reason for doing it this way is that, in many cases, it is not viable to do inline processing for application protocols like HTTP at the high speeds seen inside a cluster. Therefore, you should think of using eBPF to route traffic to a proxy like Envoy in an efficient way, rather than using it to replace the proxy itself. However, you do need to turn off connect-time load balancing (CTLB) so sidecars can see the service addresses. Given you are already taking a performance hit by the extra hop to the sidecar, not using CTLB performance optimization to avoid NAT overhead is likely not a big deal. - -## Summary - -Is eBPF a replacement for iptables? Not exactly. It’s hard to imagine everything working as efficiently with eBPF as it does with iptables. For now, the two co-exist and it’s up to the user to weigh the price-performance tradeoff and decide which feature to use when, given their specific needs. - -We believe the right solution is to leverage eBPF, along with existing mechanisms in the Linux kernel, to achieve your desired outcome. That’s why $[prodname] offers support for multiple data planes, including standard Linux, Windows HNS, and Linux eBPF. Since we have established that both eBPF and iptables are useful, the only logical thing to do in our opinion is to support both. $[prodname] gives you the choice so you can choose the best tool for the job. - -## Additional resources - -To learn more and see performance metrics from our test environment, see the blog, [Introducing the eBPF data plane](https://www.projectcalico.org/introducing-the-calico-ebpf-dataplane/). diff --git a/calico_versioned_docs/version-3.29/operations/fips.mdx b/calico_versioned_docs/version-3.29/operations/fips.mdx deleted file mode 100644 index 67736d30da..0000000000 --- a/calico_versioned_docs/version-3.29/operations/fips.mdx +++ /dev/null @@ -1,60 +0,0 @@ ---- -description: Run Calico using FIPS validated cryptography. ---- - -# FIPS mode - -## Big picture - -Run $[prodname] in [FIPS 140-2](https://csrc.nist.gov/publications/detail/fips/140/2/final) compliant mode. - -## Value - -When running in FIPS compliant mode, $[prodname] uses FIPS-approved cryptographic algorithms and NIST-validated cryptographic modules. - -## Concepts - -The Federal Information Processing Standards (FIPS) are publicly announced standards developed by the National Institute of Standards and Technology for use in computer systems by government agencies and government contractors. $[prodname] FIPS mode is enabled during installation by: - -- Switching the cryptographic modules for the golang-based applications to use the FIPS-140-2 validated [Tigera Cryptographic Module](https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4095) -- Configuring TLS servers and other cryptographic functions to use FIPS 140-2 approved cryptographic algorithms - -## Before you begin - -**Required** - -- A Kubernetes distribution and cluster that run in FIPS mode -- The hosts must run Linux x86_64 distributions -- $[prodname] contains programs that run directly on the host that use dynamic linking of c libraries. For this reason, it is a requirement for host systems to contain the following libraries: - - ld-linux-x86-64.so.2 - - libpthread.so.0 - - libc.so.6 - -**Unsupported** - -- The following features are disabled and are not allowed to be used: - - Application Layer API - - BGP password - - WireGuard -- Switching FIPS mode off and then on again is not supported because this can break hashes and other cryptographic settings. - -## How to - -To install $[prodname] in FIPS mode follow these steps. - -Follow [the installation steps](../getting-started/index.mdx) for your platform. - - - In the step for installing custom resources, edit `custom-resources.yaml` and enable FIPS mode in the installation spec. - - ```yaml - apiVersion: operator.tigera.io/v1 - kind: Installation - metadata: - name: default - spec: - fipsMode: Enabled - ``` - - - For more information on configuration options available in this manifest, see [the installation reference](../reference/installation/api.mdx). - -After you apply the YAML, FIPS mode is fully operational. diff --git a/calico_versioned_docs/version-3.29/operations/image-options/alternate-registry.mdx b/calico_versioned_docs/version-3.29/operations/image-options/alternate-registry.mdx deleted file mode 100644 index 5b603fd026..0000000000 --- a/calico_versioned_docs/version-3.29/operations/image-options/alternate-registry.mdx +++ /dev/null @@ -1,87 +0,0 @@ ---- -description: Configure Calico to pull images from a public or private registry. ---- - -# Configure use of your image registry - -import MaintenanceImageOptionsAlternateRegistry from '../../_includes/components/MaintenanceImageOptionsAlternateRegistry'; - -## Big picture - -Configure $[prodname] to pull images from a registry (public or private). - -## Value - -In many deployments, installing $[prodname] in clusters from third-party private repos is not an option. $[prodname] offers these public and private registry options, which can be used in any combination: - -- **Install from a registry** for use cases like air-gapped clusters, or clusters with bandwidth or security constraints -- **Install from an image path in a registry** if you have pulled $[prodname] images to a sub path in your registry -- [Install images by registry digest](imageset.mdx) - -## Concepts - -A **container image registry** (often known as a **registry**), is a service where you can push, pull, and store container images. In Kubernetes, a registry is considered _private_ if it is not publicly available. - -A **private registry** requires an **image pull secret**. An **image pull secret** provides authentication for an image registry; this allows you to control access to certain images or give access to higher pull rate limits (like with DockerHub). - -An **image path** is a directory in a registry that contains images required to install $[prodname]. - -## Before you begin - -**Required** - -- $[prodname] is managed by the operator -- Configure pull access to your registry -- If you are using a private registry that requires user authentication, ensure that an image pull secret is configured for your registry in the tigera-operator namespace. Set the environment variable, `REGISTRY_PULL_SECRET` to the secret name. For help, see `imagePullSecrets` and `registry` fields, in [Installation resource reference](../../reference/installation/api.mdx). -- Use the [Crane command](https://github.com/google/go-containerregistry/blob/main/cmd/crane/README.md) to manage the $[prodnameWindows] images, as using `docker pull` commands for these images may not work depending on the operating system and version in which the commands are run. - -## How to - -The following examples show the path format for public and private registry, `$REGISTRY/`. If you are using an image path, substitute the format: `$REGISTRY/$IMAGE_PATH/`. - -### Push $[prodname] images to your registry - -To install images from your registry, you must first pull the images from Tigera's registry, retag them with your own registry, and then push the newly-tagged images to your own registry. Use the `crane cp` command instead of pulling+retagging+pushing on the $[prodnameWindows] images (`node-windows` and `cni-windows`). - - - -### Run the operator using images from your registry - -Before applying `tigera-operator.yaml`, modify registry references to use your custom registry: - -**For OpenShift** - -Download all manifests first, then modify the following: - -```bash -sed -ie "s?quay.io?$REGISTRY?g" manifests/02-tigera-operator.yaml -``` - -**For all other platforms** - -```bash -sed -ie "s?quay.io?$REGISTRY?g" tigera-operator.yaml -``` - -Next, if you are implementing user authentication to access a private registry, add the image pull secret for your `registry` to the secret `tigera-pull-secret`. - -```bash -sed -ie "/serviceAccountName: tigera-operator/a \ imagePullSecrets:\n\ - name: $REGISTRY_PULL_SECRET" tigera-operator.yaml -``` - -### Configure the operator to use images - -Set the `spec.registry` field of your Installation resource to the name of your custom registry. For example: - -```yaml -apiVersion: operator.tigera.io/v1 -kind: Installation -metadata: - name: default -spec: - variant: Calico - imagePullSecrets: - - name: tigera-pull-secret - // highlight-next-line - registry: myregistry.com -``` diff --git a/calico_versioned_docs/version-3.29/operations/image-options/imageset.mdx b/calico_versioned_docs/version-3.29/operations/image-options/imageset.mdx deleted file mode 100644 index 3cb13dd580..0000000000 --- a/calico_versioned_docs/version-3.29/operations/image-options/imageset.mdx +++ /dev/null @@ -1,247 +0,0 @@ ---- -description: Specify the digests for operator to use to deploy images. ---- - -# Install images by registry digest - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - -## Big picture - -Deploy images by container registry digest for operator installations. - -## Value - -Some deployments have strict security requirements that require deploying images by immutable digest instead of tags. -Once released, official $[prodname] images and tags will not be modified. However using an immutable digest allows specific images to be reviewed -and verified by security teams. - -## Concepts - -### Container registry - -A container registry provides access to container images referenced by tags or digest. - -### Image tag - -Versioned container images are typically referenced by a tag which is appended to an image reference. Example: `/:`. Container image tags are typically not expected be changed or updated, but this is not required or enforced by most image registries, meaning it is possible to push new code to the same image tag. - -### Image digest - -Container images, when added to a container registry, have a unique hash created that can be used to pull a specific version of an image that cannot be changed or updated. - -## Before you begin - -**Required** - -- $[prodname] managed by the operator -- Docker client is configured to pull images from the container registries where images are stored -- Kubernetes permissions to apply an ImageSet manifest to your cluster - -## How to - -1. [Update the operator deployment with a digest](#update-the-operator-deployment-with-a-digest) -2. [Create an ImageSet](#create-an-imageset) -3. [Verify the correct ImageSet is being used](#verify-the-correct-imageset-is-being-used) - -**Other tasks** - -- [Create new ImageSet when upgrading or downgrading](#create-new-imageset-when-upgrading-or-downgrading) - -**Troubleshooting** - -- [Why does the Installation resource status not include my ImageSet?](#why-does-the-installation-resource-status-not-include-my-imageset) -- [How can I tell if there is a problem with my ImageSet?](#how-can-i-tell-if-there-is-a-problem-with-my-imageset) - -### Update the operator deployment with a digest - -Before applying `tigera-operator.yaml`, modify the operator deployment to use the operator image digest. - -Use commands like the following to get the image digest (adjust the image in the commands if you are using a different operator image): - -```bash -docker pull $[tigeraOperator.registry]/$[tigeraOperator.image]:$[tigeraOperator.version] -docker inspect $[tigeraOperator.registry]/$[tigeraOperator.image]:$[tigeraOperator.version] -f '{{range .RepoDigests}}{{printf "%s\n" .}}{{end}}' -``` - -If multiple digests are returned, select the one matching the registry you are using. - -Update the tigera-operator deployment: - -```bash -sed -ie "s|\(image: .*/operator\):.*|?\1@|" tigera-operator.yaml -``` - -### Create an ImageSet - -Create an [ImageSet](../../reference/installation/api.mdx#imageset) manifest file named `imageset.yaml` like the following: - -```yaml -apiVersion: operator.tigera.io/v1 -kind: ImageSet -metadata: - name: calico-$[releaseTitle] -spec: - images: - - image: 'calico/apiserver' - digest: 'sha256:0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef' - - image: 'calico/cni' - digest: 'sha256:0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef' - - image: 'calico/kube-controllers' - digest: 'sha256:0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef' - - image: 'calico/node' - digest: 'sha256:0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef' - - image: 'calico/typha' - digest: 'sha256:0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef' - - image: 'calico/pod2daemon-flexvol' - digest: 'sha256:0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef' - - image: 'calico/node-windows' - digest: 'sha256:0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef' - - image: 'tigera/operator' - digest: 'sha256:0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef' - - image: 'tigera/key-cert-provisioner' - digest: 'sha256:0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef' -``` - -You can create an ImageSet manifest manually or by script. - - - - -1. Copy the above example into a file called `imageset.yaml` and edit that file in the steps below. -1. Set the name for your ImageSet to `calico-` (Example: `calico-$[releaseTitle]`). - The version can be obtained by running: - ``` - docker run $[tigeraOperator.registry]/$[tigeraOperator.image]:$[tigeraOperator.version] --version - ``` -1. Add the correct digest for each image. If you are using a private registry, ensure you pull the image from the private registry and use the digest associated with the private registry. - - 1. If using the default images, get a list of them by running: - - ``` - docker run $[tigeraOperator.registry]/$[tigeraOperator.image]:$[tigeraOperator.version] --print-images=list - ``` - - :::note - - If you are not using the default image registries or paths, you must create your own list of images (and the above command will not apply). - - ::: - :::note - - The list will contain images for an Enterprise deployment but they do not need to be added to the ImageSet. - - ::: - - 1. Get the needed digests by using the images returned from the above step in the following command: - ``` - docker pull && docker inspect -f '{{range .RepoDigests}}{{printf "%s\n" .}}{{end}}' - ``` - 1. Use the digest from the image that matches the repo/image you will use. - If you are using a private registry or have specified an [imagePath](../../reference/installation/api.mdx#installation) - you will still use the "default" `/` in the `image` field, for example if you your node image is coming from - `example.com/registry/imagepath/node` you will still use `calico/node` in the image field of the ImageSet. - :::note - - For image `quay.io/tigera/operator@sha256:d111db2f94546415a30eff868cb946d47e183faa804bd2e9a758fd9a8a4eaff1` copy everything after `@` and add it as the digest for the `tigera/operator` image. - - ::: - - - - -Copy the following script into a file, make it executable, and run the script. The script creates an `imageset.yaml` file in the directory it was run. -:::note - -This script will only work if using the default registries and image paths. - -::: - -``` -#!/bin/bash -e - -images=(calico/apiserver calico/cni calico/kube-controllers calico/node calico/typha calico/pod2daemon-flexvol calico/node-windows tigera/key-cert-provisioner tigera/operator) - -OPERATOR_IMAGE=$[tigeraOperator.registry]/$[tigeraOperator.image]:$[tigeraOperator.version] -echo "Pulling $OPERATOR_IMAGE" -echo -docker pull $OPERATOR_IMAGE -q >/dev/null -versions=$(docker run $OPERATOR_IMAGE --version) -ver=$(echo -e "$versions" | grep 'Calico:') - -imagelist=($(docker run $OPERATOR_IMAGE --print-images=list)) - -cat > ./imageset.yaml <> ./imageset.yaml - echo " digest: \"$digest\"" >> ./imageset.yaml - fi - done -done -``` - - - - -Apply the created `imageset.yaml` to your cluster. - -### Verify the correct ImageSet is being used - -1. Check tigerastatus for components that are Degraded with `kubectl get tigerastatus`. - - If any components show Degraded, [investigate further](#how-can-i-tell-if-there-is-a-problem-with-my-imageset). -2. When tigerastatus for all components show Available True, the ImageSet has been applied. - ``` - NAME AVAILABLE PROGRESSING DEGRADED SINCE - calico True False False 54s - ``` -3. Verify that the correct ImageSet is being used. In Installation status, check that the `imageset` field is set to the ImageSet you created. - Check the field by running the following command: - - ```bash - kubectl get installation default -o yaml | grep imageSet - ``` - - You should see output similar to: - - ```yaml - imageSet: calico-$[releaseTitle] - ``` - -## Other tasks - -### Create new ImageSet when upgrading or downgrading - -Before upgrading to a new release or downgrading, you must create a new [ImageSet](../../reference/installation/api.mdx#imageset) -with updated image references and names for the new release. This must be done prior -to upgrading the cluster so when the new manifests are applied, the appropriate ImageSet is available. - -## Troubleshooting - -### Why does the Installation Resource status not include my ImageSet? - -The [status.imageset](../../reference/installation/api.mdx#installationstatus) field of -the Installation Resource will not be updated until the `calico` component has fully been deployed. `calico` is -fully deployed when `kubectl get tigerastatus calico` reports Available True with Progressing and Degraded as False. - -### How can I tell if there is a problem with my ImageSet? - -If you suspect an issue with your ImageSet, check tigerastatus with `kubectl get tigerastatus`. If any components are -degraded, you can get additional information with `kubectl get tigerastatus -o yaml`. If the digest -provided for an image is incorrect or unable to be pulled, the tigerastatus will not directly report that information, -but you should see information that there is an issue rolling out a Deployment, Daemonset, or Job. If you suspect -an issue with a resource rollout due to an issue with an image, you will need to `get` or `describe` a specific pod -to see details about the problem. diff --git a/calico_versioned_docs/version-3.29/operations/image-options/index.mdx b/calico_versioned_docs/version-3.29/operations/image-options/index.mdx deleted file mode 100644 index b65e8c2905..0000000000 --- a/calico_versioned_docs/version-3.29/operations/image-options/index.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: Install Calico using from a public or private registry, or by digest. -hide_table_of_contents: true ---- - -# Install using an alternate registry - -import DocCardList from '@theme/DocCardList'; -import { useCurrentSidebarCategory } from '@docusaurus/theme-common'; - - diff --git a/calico_versioned_docs/version-3.29/operations/index.mdx b/calico_versioned_docs/version-3.29/operations/index.mdx deleted file mode 100644 index 137a7526f6..0000000000 --- a/calico_versioned_docs/version-3.29/operations/index.mdx +++ /dev/null @@ -1,70 +0,0 @@ ---- -description: Post-installation tasks for managing Calico including upgrading and troubleshooting. ---- - -import { DocCardLink, DocCardLinkLayout } from '/src/___new___/components'; - -# Operations - -Post-installation tasks for managing Calico. - -## Upgrading Calico - - - - - - - - -## calicoctl - - - - - - - - -## Deploy image options - - - - - - -## eBPF - - - - - - - - -## Monitoring - - - - - - -## Troubleshooting - - - - - - - - -## Other operations tasks - - - - - - - - - diff --git a/calico_versioned_docs/version-3.29/operations/install-apiserver.mdx b/calico_versioned_docs/version-3.29/operations/install-apiserver.mdx deleted file mode 100644 index 08a1c4a359..0000000000 --- a/calico_versioned_docs/version-3.29/operations/install-apiserver.mdx +++ /dev/null @@ -1,194 +0,0 @@ ---- -description: Install the Calico API server on an existing Calico cluster ---- - -# Enable kubectl to manage Calico APIs - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - -## Big picture - -[ **Feature status**: GA in Calico v3.20+ ] - -Install the Calico API server on an existing cluster to enable management of Calico APIs using kubectl. - -## Value - -The API server provides a REST API for Calico, and allows management of `projectcalico.org/v3` APIs using kubectl without the need for calicoctl. - -:::note - -Starting in Calico v3.20.0, new operator-based installations of Calico include the API server component by default, so the instructions -in this document are not required. - -::: - -## Before you begin - -- Make sure you have a cluster with Calico installed using the Kubernetes API data store. If not, you can [migrate from etcd](datastore-migration.mdx). - -- Upgrade to Calico v3.20+ using the appropriate [upgrade instructions](upgrading/index.mdx). - -- For non-operator installations, you will need a machine with `openssl` installed. - -## Concepts - -### calicoctl vs kubectl - -In previous releases, calicoctl has been required to manage Calico API resources in the `projectcalico.org/v3` API group. The calicoctl CLI tool provides important validation and defaulting on these APIs. The Calico API server performs -that defaulting and validation server-side, exposing the same API semantics without a dependency on calicoctl. - -calicoctl is still required for the following subcommands: - -- [calicoctl node](../reference/calicoctl/node/index.mdx) -- [calicoctl ipam](../reference/calicoctl/ipam/index.mdx) -- [calicoctl convert](../reference/calicoctl/convert.mdx) -- [calicoctl version](../reference/calicoctl/version.mdx) - -## How to - -### Install the API server - -Select the method below based on your installation method. - - - - -1. Create an instance of an `operator.tigera.io/APIServer` with the following contents. - - ```yaml - apiVersion: operator.tigera.io/v1 - kind: APIServer - metadata: - name: default - spec: {} - ``` - -1. Confirm it appears as `Available` with the following command. - - ```bash - kubectl get tigerastatus apiserver - ``` - - You should see the following output: - - ``` - NAME AVAILABLE PROGRESSING DEGRADED SINCE - apiserver True False False 1m10s - ``` - - - - -1. Create the following manifest, which will install the API server as a deployment in the `calico-apiserver` namespace. - - ```bash - kubectl create -f $[manifestsUrl]/manifests/apiserver.yaml - ``` - - You will notice that the API server remains in a `ContainerCreating` state, as it is waiting for credentials to be provided for authenticating the main Kubernetes API server. - -1. Generate a private key and CA bundle using the following openssl command. This certificate will be used by the main API server to authenticate with the Calico API server. - - :::note - - Please note in the following command `-addext` argument requires openssl 1.1.1 or above. You can check your version of openssl using `openssl version`. - - ::: - - ``` - openssl req -x509 -nodes -newkey rsa:4096 -keyout apiserver.key -out apiserver.crt -days 365 -subj "/" -addext "subjectAltName = DNS:calico-api.calico-apiserver.svc" - ``` - -1. Provide the key and certificate to the Calico API server as a Kubernetes secret. - - ```bash - kubectl create secret -n calico-apiserver generic calico-apiserver-certs --from-file=apiserver.key --from-file=apiserver.crt - ``` - -1. Configure the main API server with the CA bundle. - - ```bash - kubectl patch apiservice v3.projectcalico.org -p \ - "{\"spec\": {\"caBundle\": \"$(kubectl get secret -n calico-apiserver calico-apiserver-certs -o go-template='{{ index .data "apiserver.crt" }}')\"}}" - ``` - - - - -After following the above steps, you should see the API server pod become ready, and Calico API resources become available. You can check whether the APIs are available with the following command: - -```bash -kubectl api-resources | grep '\sprojectcalico.org' -``` - -You should see the following output: - -``` -bgpconfigurations bgpconfig,bgpconfigs projectcalico.org false BGPConfiguration -bgppeers projectcalico.org false BGPPeer -clusterinformations clusterinfo projectcalico.org false ClusterInformation -felixconfigurations felixconfig,felixconfigs projectcalico.org false FelixConfiguration -globalnetworkpolicies gnp,cgnp,calicoglobalnetworkpolicies projectcalico.org false GlobalNetworkPolicy -globalnetworksets projectcalico.org false GlobalNetworkSet -hostendpoints hep,heps projectcalico.org false HostEndpoint -ippools projectcalico.org false IPPool -kubecontrollersconfigurations projectcalico.org false KubeControllersConfiguration -networkpolicies cnp,caliconetworkpolicy,caliconetworkpolicies projectcalico.org true NetworkPolicy -networksets netsets projectcalico.org true NetworkSet -profiles projectcalico.org false Profile -``` - -:::note - -kubectl may continue to prefer the crd.projectcalico.org API group due to the way it caches APIs locally. You can force kubectl to update -by removing its cache directory for your cluster. By default, the cache is located in `$(HOME)/.kube/cache`. - -::: - -### Use kubectl for projectcalico.org APIs - -Once the API server has been installed, you can use kubectl to interact with the Calico APIs. For example, you can view and edit IP pools. - -```bash -kubectl get ippools -``` - -You should see output that looks like this: - -``` -NAME CREATED AT -default-ipv4-ippool 2021-03-19T16:47:12Z -``` - -### Uninstall the Calico API server - -To uninstall the API server, use the following instructions depending on your install method. - - - - -```bash - kubectl delete apiserver default -``` - - - - -```bash - kubectl delete -f $[manifestsUrl]/manifests/apiserver.yaml -``` - - - - -Once removed, you will need to use calicoctl to manage projectcalico.org/v3 APIs. - -## Next steps - -**Recommended tutorials** - -- [Secure a simple application using the Kubernetes NetworkPolicy API](../network-policy/get-started/kubernetes-policy/kubernetes-policy-basic.mdx) -- [Control ingress and egress traffic using the Kubernetes NetworkPolicy API](../network-policy/get-started/kubernetes-policy/kubernetes-policy-advanced.mdx) -- [Run a tutorial that shows blocked and allowed connections in real time](../network-policy/get-started/kubernetes-policy/kubernetes-demo.mdx) diff --git a/calico_versioned_docs/version-3.29/operations/monitor/index.mdx b/calico_versioned_docs/version-3.29/operations/monitor/index.mdx deleted file mode 100644 index 486c353c54..0000000000 --- a/calico_versioned_docs/version-3.29/operations/monitor/index.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: Tools for scraping useful metrics -hide_table_of_contents: true ---- - -# Monitor - -import DocCardList from '@theme/DocCardList'; -import { useCurrentSidebarCategory } from '@docusaurus/theme-common'; - - diff --git a/calico_versioned_docs/version-3.29/operations/monitor/monitor-component-metrics.mdx b/calico_versioned_docs/version-3.29/operations/monitor/monitor-component-metrics.mdx deleted file mode 100644 index 0a3984ed76..0000000000 --- a/calico_versioned_docs/version-3.29/operations/monitor/monitor-component-metrics.mdx +++ /dev/null @@ -1,709 +0,0 @@ ---- -description: Use open source Prometheus for monitoring and alerting on Calico components. ---- - -# Monitor Calico component metrics - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - -## Big picture - -Use Prometheus configured for $[prodname] components to get valuable metrics about the health of $[prodname]. - -## Value - -Using the open-source Prometheus monitoring and alerting toolkit, you can view time-series metrics from $[prodname] components in the Prometheus or Grafana interfaces. - -## Concepts - -### About Prometheus - -The Prometheus monitoring tool 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 are the Felix and Typha components. - -### About $[prodname] Felix, Typha, and kube-controllers components - -**Felix** is a daemon that runs on every machine that implements network policy. Felix is the brains of $[prodname]. Typha is an optional set of pods that extends Felix to scale traffic between $[prodname] nodes and the datastore. The kube-controllers pod runs a set of controllers which are responsible for a variety of control plane functions, such as resource garbage collection and synchronization with the Kubernetes API. - -You can configure Felix, Typha, and/or kube-controllers to provide metrics to Prometheus. - -## Before you begin... - -In this tutorial we assume that you have completed all other introductory tutorials and possess a running Kubernetes cluster with $[prodname]. You can either use `kubectl` or `calicoctl` to perform the following steps. Depending on which tool you would like to use, make sure you have the necessary prerequisites as shown below. - - - - -If you wish to modify $[prodname] configurations with `kubectl` binary you need to make sure you have the $[prodname] API server in your cluster. The API server allows you to manage resources within the `projectcalico.org/v3` api group. - -:::note - -Operator based installs include the API server by default. - -::: - -For more information about the API server please use [this link](../install-apiserver.mdx). - - - - -You can run `calicoctl` on any host with network access to the Calico datastore as either a binary or a container to manage Calico APIs in the `projectcalico.org/v3` API group. - -For more information about calicoctl please use [this link](../calicoctl/install.mdx). - - - - -## How to - -This tutorial will go through the necessary steps to implement basic monitoring of $[prodname] with Prometheus. - -1. Configure $[prodname] to enable the metrics reporting. -2. Create the namespace and service account that Prometheus will need. -3. Deploy and configure Prometheus. -4. View the metrics in the Prometheus dashboard and create a simple graph. - -### 1. Configure $[prodname] to enable metrics reporting - -#### **Felix configuration** - -Felix prometheus metrics are **disabled** by default. -:::note - -A comprehensive list of configuration values can be [found at this link](../../reference/felix/configuration.mdx). - -::: - -Use the following command to enable Felix metrics. - - - - -```bash -kubectl patch felixconfiguration default --type merge --patch '{"spec":{"prometheusMetricsEnabled": true}}' -``` - -You should see an output like below: - -``` -felixconfiguration.projectcalico.org/default patched -``` - - - - -```bash -calicoctl patch felixconfiguration default --patch '{"spec":{"prometheusMetricsEnabled": true}}' -``` - -You should see an output like below: - -``` -Successfully patched 1 'FelixConfiguration' resource -``` - - - - -#### **Creating a service to expose Felix metrics** - -Prometheus uses Kubernetes services to dynamically discover endpoints. Here you will create a service named `felix-metrics-svc` which Prometheus will use to discover all the Felix metrics endpoints. - -:::note - -Felix by default uses port 9091 TCP to publish its metrics. - -::: - - - - -```bash -kubectl apply -f - < - - -```bash -kubectl apply -f - < - - -#### **Typha Configuration** - - - - -An Operator installation of $[prodname] automatically deploys one or more Typha instances depending on the scale of your cluster. By default metrics for these instances are disabled. - -Use the following command to instruct `tigera-operator` to enable Typha metrics. - -```bash -kubectl patch installation default --type=merge -p '{"spec": {"typhaMetricsPort":9093}}' -``` - -You should see a result similar to: - -```bash -installation.operator.tigera.io/default patched -``` - - - - -:::note - -Typha implementation is optional, if you don't have Typha in your cluster you can skip [Typha configuration](#typha-configuration) section. - -::: - -If you are uncertain whether you have `Typha` in your cluster execute the following code: - -```bash -kubectl get pods -A | grep typha -``` - -If your result is similar to what is shown below you are using Typha in your cluster. - -:::note - -The name suffix of pods shown below was dynamically generated. Your typha instance might have a different suffix. - -::: - -``` -kube-system calico-typha-56fccfcdc4-z27xj 1/1 Running 0 28h -kube-system calico-typha-horizontal-autoscaler-74f77cd87c-6hx27 1/1 Running 0 28h -``` - -You can enable Typha metrics to be consumed by Prometheus via [two ways](../../reference/typha/configuration.mdx). - - - - -#### **Creating a service to expose Typha metrics** - -:::note - -Typha uses **port 9091** TCP by default to publish its metrics. However, if $[prodname] is installed using [Amazon yaml file](https://github.com/aws/amazon-vpc-cni-k8s/blob/b001dc6a8fff52926ed9a93ee6c4104f02d365ab/config/v1.5/calico.yaml#L535-L536) this port will be 9093 as its set manually via **TYPHA_PROMETHEUSMETRICSPORT** environment variable. - -::: - - - - -When you set `typhaMetricsPort`, the operator automatically creates a service that exposes these metrics. You do not need to create one yourself. - -You can use the following command to verify it. - -```bash -kubectl get svc -n calico-system calico-typha-metrics -``` - -You should see a result similar to: - -```bash -NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE -calico-typha-metrics ClusterIP 10.43.164.10 9093/TCP 39d -``` - - - - -```bash -kubectl apply -f - < - - -#### **kube-controllers configuration** - -Prometheus metrics are **enabled** by default on [TCP port 9094](../../reference/resources/kubecontrollersconfig.mdx) for `calico-kube-controllers`. - - - - -The operator automatically creates a service that exposes these metrics. - -You can use the following command to verify it. - -```bash -kubectl get svc -n calico-system -``` - -You should see a result similar to: - -```bash -calico-kube-controllers-metrics ClusterIP 10.43.77.57 9094/TCP 39d -``` - - - - -#### **Creating a service to expose kube-controllers metrics** - -Create a service to expose `calico-kube-controllers` metrics to Prometheus. - -```bash -kubectl apply -f - < - - -**Optionally**, you can use the following command to modify the port by changing the `KubeControllersConfiguration` resource if desired. - -:::note - -Setting this value to zero will disable metrics in the kube-controllers pod. - -::: - - - - -```bash -kubectl patch kubecontrollersconfiguration default --type=merge --patch '{"spec":{"prometheusMetricsPort": 9095}}' -``` - - - - -```bash -calicoctl patch kubecontrollersconfiguration default --patch '{"spec":{"prometheusMetricsPort": 9095}}' -``` - - - - -### 2. Cluster preparation - -#### **Namespace creation** - -`Namespace` isolates resources in your cluster. Here you will create a Namespace called `calico-monitoring` to hold your monitoring resources. -:::note - -Kubernetes namespaces guide can be [found at this link](https://kubernetes.io/docs/tasks/administer-cluster/namespaces/). - -::: - -```bash -kubectl create -f -< - - -```bash -kubectl apply -f - < - - -```bash -kubectl apply -f - < - - -#### **Create Prometheus pod** - -Now that you have a `serviceaccount` with permissions to gather metrics and have a valid config file for your Prometheus, it's time to create the Prometheus pod. - -```bash -kubectl apply -f - < - - -```bash -kubectl delete service felix-metrics-svc -n calico-system -``` - -If running $[prodnameWindows], also clean up the Windows nodes service: -```bash -kubectl delete service felix-windows-metrics-svc -n calico-system -``` - - - - -``` -kubectl delete service felix-metrics-svc -n kube-system -kubectl delete service typha-metrics-svc -n kube-system -kubectl delete service kube-controllers-metrics-svc -n kube-system -``` - - - - -Return $[prodname] configurations to their default state. - - - - -```bash -kubectl patch felixConfiguration default --type merge --patch '{"spec":{"prometheusMetricsEnabled": false}}' -kubectl patch installation default --type=json -p '[{"op": "remove", "path":"/spec/typhaMetricsPort"}]' -``` - - - - -```bash -calicoctl patch felixConfiguration default --patch '{"spec":{"prometheusMetricsEnabled": false}}' -``` - - - - -Finally, remove the namespace and RBAC permissions. - -```bash -kubectl delete namespace calico-monitoring -kubectl delete ClusterRole calico-prometheus-user -kubectl delete clusterrolebinding calico-prometheus-user -``` - -## Best practices - -If you enable $[prodname] metrics to Prometheus, a best practice is to use network policy to limit access to the $[prodname] metrics endpoints. For details, see [Secure $[prodname] Prometheus endpoints](../../network-policy/comms/secure-metrics.mdx). - -If you are not using Prometheus metrics, we recommend disabling the Prometheus ports entirely for more security. - -## Next Steps - -[Visualizing metrics via Grafana.](monitor-component-visual.mdx) diff --git a/calico_versioned_docs/version-3.29/operations/monitor/monitor-component-visual.mdx b/calico_versioned_docs/version-3.29/operations/monitor/monitor-component-visual.mdx deleted file mode 100644 index ac182a24b5..0000000000 --- a/calico_versioned_docs/version-3.29/operations/monitor/monitor-component-visual.mdx +++ /dev/null @@ -1,201 +0,0 @@ ---- -description: Use open source Grafana for visualizing Calico components. ---- - -# Visualizing metrics via Grafana - -## Big picture - -Use Grafana dashboard to view $[prodname] component metrics. - -## Value - -Using Grafana can be beneficial by providing a means to visualize metrics through graphs that can help you quickly identify unusual activity. The following image shows some of the graphs and metrics that are available for you to leverage to achieve this goal. - -![Screenshot of a Grafana dashboard displaying Calico component metrics including CPU usage, memory usage, client connections, and other performance graphs](/img/calico/grafana-dashboard_3.28.png) - -## Concepts - -### About Grafana - -Grafana is an open source visualization and analytics tool that allows you to query, visualize, alert on, and explore metrics from a variety of data source, including Calico component metrics stored in Prometheus. - -### About Prometheus - -Prometheus is an open source monitoring tool that scrapes metrics from instrumented components and stores them as time series data which can then be visualized using tools such as Grafana. - -## Before you begin... - -In this tutorial we assume you have - -- a running Kubernetes cluster with $[prodname], calicoctl and kubectl installed -- completed all steps in the [monitor component metrics](monitor-component-metrics.mdx) guide to set up Prometheus to gather $[prodname] component metrics. - -## How to - -This tutorial will go through the necessary steps to create $[prodname] metrics dashboards with Grafana. - -### Preparing Prometheus - -Here you will create a service to make your prometheus visible to Grafana. - -```bash -kubectl apply -f - < 27h v1.18.0 -ip-10-0-0-12 Ready 27h v1.18.0 - -``` - -### Verify calico-node pods are running on every node, and are in a healthy state - -```bash -kubectl get pods -n calico-system -o wide -``` - -``` -NAME READY STATUS RESTARTS AGE IP NODE -calico-node-77zgj 1/1 Running 0 27h 10.0.0.10 ip-10-0-0-10 -calico-node-nz8k2 1/1 Running 0 27h 10.0.0.11 ip-10-0-0-11 -calico-node-7trv7 1/1 Running 0 27h 10.0.0.12 ip-10-0-0-12 -``` - -### Exec into pod for further troubleshooting - -```bash -kubectl run multitool --image=praqma/network-multitool - -kubectl exec -it multitool -- bash -``` - -``` -bash-5.0 ping 8.8.8.8 -PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. -64 bytes from 8.8.8.8: icmp_seq=1 ttl=97 time=6.61 ms -64 bytes from 8.8.8.8: icmp_seq=2 ttl=97 time=6.64 ms -``` - -### Collect $[prodname] diagnostic logs - -```bash -sudo calicoctl node diags -``` - -``` -Collecting diagnostics -Using temp dir: /tmp/calico194224816 -Dumping netstat -Dumping routes (IPv4) -Dumping routes (IPv6) -Dumping interface info (IPv4) -Dumping interface info (IPv6) -Dumping iptables (IPv4) -Dumping iptables (IPv6) - -Diags saved to /tmp/calico194224816/diags-20201127_010117.tar.gz -``` - -## Kubernetes - -### Verify all pods are running - -```bash -kubectl get pods -A -``` - -``` -kube-system coredns-66bff467f8-dxbtl 1/1 Running 0 27h -kube-system coredns-66bff467f8-n95vq 1/1 Running 0 27h -kube-system etcd-ip-10-0-0-10 1/1 Running 0 27h -kube-system kube-apiserver-ip-10-0-0-10 1/1 Running 0 27h -``` - -### Verify Kubernetes API server is running - -```bash -kubectl cluster-info -``` - -``` -Kubernetes master is running at https://10.0.0.10:6443 -KubeDNS is running at https://10.0.0.10:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy -ubuntu@master:~$ kubectl get svc -NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE -kubernetes ClusterIP 10.49.0.1 443/TCP 2d2h -``` - -### Verify Kubernetes kube-dns is working - -```bash -kubectl get svc -``` - -``` -NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE -kubernetes ClusterIP 10.49.0.1 443/TCP 2d2h -``` - -```bash -kubectl exec -it multitool bash -``` - -``` -bash-5.0 curl -I -k https://kubernetes -HTTP/2 403 -cache-control: no-cache, private -content-type: application/json -x-content-type-options: nosniff -content-length: 234 -``` - -```bash -bash-5.0 nslookup google.com -``` - -``` -Server: 10.49.0.10 -Address: 10.49.0.10#53 -Non-authoritative answer: -Name: google.com -Address: 172.217.14.238 -Name: google.com -Address: 2607:f8b0:400a:804::200e -``` - -### Verify that kubelet is running on the node with the correct flags - -```bash -systemctl status kubelet -``` - -If there is a problem, check the journal - -```bash -journalctl -u kubelet | head -``` - -### Check the status of other system pods - -Look especially at coredns; if they are not getting an IP, something is wrong with the CNI - -```bash -kubectl get pod -n kube-system -o wide -``` - -But if other pods fail, it is likely a different issue. Perform normal Kubernetes troubleshooting. For example: - -```bash -kubectl describe pod kube-scheduler-ip-10-0-1-20.eu-west-1.compute.internal -n kube-system | tail -15 -``` - -## Calico components - -### View Calico CNI configuration on a node - -```bash -cat /etc/cni/net.d/10-calico.conflist -``` - -### Verify calicoctl matches cluster - -The cluster version and type must match the calicoctl version. - -```bash -calicoctl version -``` - -For syntax: - -```bash -calicoctl version -help -``` - -### Check Tigera Operator status - -```bash -kubectl get tigerastatus -``` - -``` -NAME AVAILABLE PROGRESSING DEGRADED SINCE -calico True False False 27h -``` - -### Check if operator pod is running - -```bash -kubectl get pod -n tigera-operator -``` - -### View calico nodes - -```bash -kubectl get pod -n calico-system -o wide -``` - -### View $[prodname] installation parameters - -```bash -kubectl get installation -o yaml -``` - -```yaml -apiVersion: v1 -items: -- apiVersion: operator.tigera.io/v1 - kind: Installation - metadata: - - apiVersion: operator.tigera.io/v1 - spec: - calicoNetwork: - bgp: Enabled - hostPorts: Enabled - ipPools: - - blockSize: 26 - cidr: 10.48.0.0/16 - encapsulation: VXLANCrossSubnet - natOutgoing: Enabled - nodeSelector: all() - multiInterfaceMode: None - nodeAddressAutodetectionV4: - firstFound: true - cni: - ipam: - type: Calico - type: Calico -``` - -### Run commands across multiple nodes - -```bash -export THE_COMMAND_TO_RUN=date && for calinode in `kubectl get pod -o wide -n calico-system | grep calico-node | awk '{print $1}'`; do echo $calinode; echo "-----"; kubectl exec -n calico-system $calinode -- $THE_COMMAND_TO_RUN; printf "\n"; done -``` - -```bash -calico-node-87lpx ------ -Defaulted container "calico-node" out of: calico-node, flexvol-driver (init), install-cni (init) -Thu Apr 28 13:48:06 UTC 2022 - -calico-node-x5fmm ------ -Defaulted container "calico-node" out of: calico-node, flexvol-driver (init), install-cni (init) -Thu Apr 28 13:48:07 UTC 2022 - -``` - -### View pod info - -```bash -kubectl describe pods `` -n ` ` -``` - -```bash -kubectl describe pods busybox -n default -``` - -``` -Events: - Type Reason Age From Message - ---- ------ ---- ---- ------- - Normal Scheduled 21s default-scheduler Successfully assigned default/busybox to ip-10-0-0-11 - Normal Pulling 20s kubelet, ip-10-0-0-11 Pulling image "busybox" - Normal Pulled 19s kubelet, ip-10-0-0-11 Successfully pulled image "busybox" - Normal Created 19s kubelet, ip-10-0-0-11 Created container busybox - Normal Started 18s kubelet, ip-10-0-0-11 Started container busybox -``` - -### View logs of a pod - -```bash -kubectl logs `` -n `` -``` - -```bash -kubectl logs busybox -n default -``` - -### View kubelet logs - -```bash -journalctl -u kubelet -``` - -## Routing - -### Verify routing table on the node - -```bash -ip route -``` - -``` -default via 10.0.0.1 dev eth0 proto dhcp src 10.0.0.10 metric 100 -10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.10 -10.0.0.1 dev eth0 proto dhcp scope link src 10.0.0.10 metric 100 -10.48.66.128/26 via 10.0.0.12 dev eth0 proto 80 onlink -10.48.231.0/26 via 10.0.0.11 dev eth0 proto 80 onlink -172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown -``` - -### Verify BGP peer status - -```bash -sudo calicoctl node status -``` - -``` -Calico process is running. - -IPv4 BGP status -+--------------+-------------------+-------+------------+-------------+ -| PEER ADDRESS | PEER TYPE | STATE | SINCE | INFO | -+--------------+-------------------+-------+------------+-------------+ -| 10.0.0.12 | node-to-node mesh | up | 2020-11-25 | Established | -| 10.0.0.11 | node-to-node mesh | up | 2020-11-25 | Established | -+--------------+-------------------+-------+------------+-------------+ -``` - -### Verify overlay configuration - -```bash -kubectl get ippools default-ipv4-ippool -o yaml -``` - -```yaml - ---- -spec: - ipipMode: Always - vxlanMode: Never -``` - -### Verify bgp learned routes - -```bash -ip r | grep bird -``` - -``` -192.168.66.128/26 via 10.0.0.12 dev tunl0 proto bird onlink -192.168.180.192/26 via 10.0.0.10 dev tunl0 proto bird onlink -blackhole 192.168.231.0/26 proto bird -``` - -### Verify BIRD routing table - -**Note**: The BIRD routing table gets pushed to node routing tables. - -```bash -kubectl exec -it -n calico-system calico-node-8cfc8 -- /bin/bash -``` - -``` -[root@ip-10-0-0-11 /] birdcl -BIRD v0.3.3+birdv1.6.8 ready. -bird> show route -0.0.0.0/0 via 10.0.0.1 on eth0 [kernel1 18:13:33] * (10) -10.0.0.0/24 dev eth0 [direct1 18:13:32] * (240) -10.0.0.1/32 dev eth0 [kernel1 18:13:33] * (10) -10.48.231.2/32 dev calieb874a8ef0b [kernel1 18:13:41] * (10) -10.48.231.1/32 dev caliaeaa173109d [kernel1 18:13:35] * (10) -10.48.231.0/26 blackhole [static1 18:13:32] * (200) -10.48.231.0/32 dev vxlan.calico [direct1 18:13:32] * (240) -10.48.180.192/26 via 10.0.0.10 on eth0 [Mesh_10_0_0_10 18:13:34] * (100/0) [i] - via 10.0.0.10 on eth0 [Mesh_10_0_0_12 18:13:41 from 10.0.0.12] (100/0) [i] - via 10.0.0.10 on eth0 [kernel1 18:13:33] (10) -10.48.66.128/26 via 10.0.0.12 on eth0 [Mesh_10_0_0_10 18:13:36 from 10.0.0.10] * (100/0) [i] - via 10.0.0.12 on eth0 [Mesh_10_0_0_12 18:13:41] (100/0) [i] - via 10.0.0.12 on eth0 [kernel1 18:13:36] (10) -``` - -### Capture traffic - -For example, - -```bash -sudo tcpdump -i calicofac0017c3 icmp -``` - -## Network policy - -### Verify existing Kubernetes network policies - -```bash -kubectl get networkpolicy --all-namespaces -``` - -``` -NAMESPACE NAME POD-SELECTOR AGE -client allow-ui 20m -client default-deny 4h51m -stars allow-ui 20m -stars backend-policy role=backend 20m -stars default-deny 4h51m -``` - -### Verify existing $[prodname] network policies - -```bash -calicoctl get networkpolicy --all-namespaces -o wide -``` - -``` -NAMESPACE NAME ORDER SELECTOR -calico-demo allow-busybox 50 app == 'porter' -client knp.default.allow-ui 1000 projectcalico.org/orchestrator == 'k8s' -client knp.default.default-deny 1000 projectcalico.org/orchestrator == 'k8s' -stars knp.default.allow-ui 1000 projectcalico.org/orchestrator == 'k8s' -stars knp.default.backend-policy 1000 projectcalico.org/orchestrator == 'k8s' -stars knp.default.default-deny 1000 projectcalico.org/orchestrator == 'k8s' -``` - -### Verify existing $[prodname] global network policies - -```bash -calicoctl get globalnetworkpolicy -o wide -``` - -``` -NAME ORDER SELECTOR -default-app-policy 100 -egress-lockdown 600 -default-node-policy 100 has(kubernetes.io/hostname) -nodeport-policy 100 has(kubernetes.io/hostname) -``` - -### Check policy selectors and order - -For example, - -```bash -calicoctl get np -n yaobank -o wide -``` - -If the selectors should match, check the endpoint IP and the node where it is running. For example, - -```bash -kubectl get pod -l app=customer -n yaobank -``` diff --git a/calico_versioned_docs/version-3.29/operations/troubleshoot/component-logs.mdx b/calico_versioned_docs/version-3.29/operations/troubleshoot/component-logs.mdx deleted file mode 100644 index fa97ffed64..0000000000 --- a/calico_versioned_docs/version-3.29/operations/troubleshoot/component-logs.mdx +++ /dev/null @@ -1,121 +0,0 @@ ---- -description: Where to find component logs. ---- - -# Component logs - -## Big picture - -View and collect $[prodname] logs. - -## Value - -It is useful to view logs to monitor component health and diagnose potential issues. - -## Concepts - -### $[nodecontainer] logs - -The $[nodecontainer] logs contain log output from the following subcomponents: - -- Per-node startup logic -- BGP agent -- Felix policy agent - -Components log either to disk within `/var/log/calico`, to stdout, or both. - -For components that log to disk, files are automatically rotated, and by default 10 files of 1MB each are kept. The current log file is called `current` and rotated files have @ followed by a timestamp detailing when the files was rotated in [tai64n](http://cr.yp.to/libtai/tai64.html#tai64n) format. - -## How to - -## View logs for a $[nodecontainer] instance - -You can view logs for a node using the `kubectl logs` command. This will show logs for all subcomponents of the given node. - -For example: - -``` -kubectl logs -n calico-system calico-node-xxxx -``` - -## View logs from the CNI plugin - -CNI plugin logs are not available through kubectl and are instead logged both to the host machine's disk as well as stderr. - -By default, these logs can be found at `/var/log/calico/cni/` on the host machine. - -The container runtime may also display the CNI plugin logs within its own log output. - -## Configure BGP agent log level - -BGP log level is configured via the [BGPConfiguration](../../reference/resources/bgpconfig.mdx) API, and can be one of the following values: - -- `Debug`: enables "debug all" logging for BIRD. The most verbose logging level. -- `Info`: enables logging for protocol state changes. This is the default log level. -- `Warning`: disables BIRD logging, emits warning level configuration logs only. -- `Error`: disables BIRD logging, emits error level configuration logs only. -- `Fatal`: disables BIRD logging, emits fatal level configuration logs only. - -To modify the BGP log level: - -1. Get the current bgpconfig settings. - - ```bash - kubectl get bgpconfig -o yaml > bgp.yaml - ``` - -1. Modify logSeverityScreen to the desired value. - - ```bash - vim bgp.yaml - ``` - - :::tip - - For a global change set the name to "default". - For a node-specific change set the name to the node name prefixed with "node.", e.g., "node.node-1". - - ::: - -1. Replace the current bgpconfig settings. - - ```bash - kubectl replace -f bgp.yaml - ``` - -## Configure Felix log level - -Felix log level is configured via the [FelixConfiguration](../../reference/resources/felixconfig.mdx) API, and can be one of the following values: - -- `Debug`: The most verbose logging level - for development and debugging. -- `Info`: The default log level. Shows important state changes. -- `Warning`: Shows warnings only. -- `Error`: Shows errors only. -- `Fatal`: Shows fatal errors only. - -To modify Felix's log level: - -1. Get the current felixconfig settings. - - ```bash - kubectl get felixconfig -o yaml > felixconfig.yaml - ``` - -1. Modify logSeverityScreen to desired value. - - ```bash - vim felixconfig.yaml - ``` - - :::tip - - For a global change set the name to "default". - For a node-specific change set the name to the node name prefixed with "node.", e.g., "node.node-1". - - ::: - -1. Replace the current felixconfig settings. - - ```bash - kubectl replace -f felixconfig.yaml - ``` diff --git a/calico_versioned_docs/version-3.29/operations/troubleshoot/index.mdx b/calico_versioned_docs/version-3.29/operations/troubleshoot/index.mdx deleted file mode 100644 index fb1ae8c95e..0000000000 --- a/calico_versioned_docs/version-3.29/operations/troubleshoot/index.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: Troubleshooting, logs, and diagnostics. -hide_table_of_contents: true ---- - -# Troubleshoot - -import DocCardList from '@theme/DocCardList'; -import { useCurrentSidebarCategory } from '@docusaurus/theme-common'; - - diff --git a/calico_versioned_docs/version-3.29/operations/troubleshoot/troubleshooting.mdx b/calico_versioned_docs/version-3.29/operations/troubleshoot/troubleshooting.mdx deleted file mode 100644 index 107b05e5a1..0000000000 --- a/calico_versioned_docs/version-3.29/operations/troubleshoot/troubleshooting.mdx +++ /dev/null @@ -1,101 +0,0 @@ ---- -description: View logs and diagnostics, common issues, and where to report issues in github. ---- - -# Troubleshooting and diagnostics - -## Logs and diagnostics - -To collect diagnostics use the `calicoctl` command line tool using superuser privileges. For example: - -```bash -sudo calicoctl node diags -``` - -To view logs, use the following command: - -`kubectl logs -n calico-system ` - -To view debug logs on some Calico components, set the `LogSeverityScreen` through the associated environment variable. - -To report a problem, please [open an issue in GitHub](https://github.com/projectcalico/calico/issues). - -### Check BGP peer status - -If you have connectivity between containers on the same host, and between -containers and the Internet, but not between containers on different hosts, it -probably indicates a problem in your BGP configuration. - -Look at `calicoctl node status` on each host. It should include output like this: - -``` -Calico process is running. - -IPv4 BGP status -+--------------+-------------------+-------+----------+-------------+ -| PEER ADDRESS | PEER TYPE | STATE | SINCE | INFO | -+--------------+-------------------+-------+----------+-------------+ -| 172.17.8.102 | node-to-node mesh | up | 23:30:04 | Established | -+--------------+-------------------+-------+----------+-------------+ - -IPv6 BGP status -No IPv6 peers found. -``` - -Alternatively, you can create a [`CalicoNodeStatus` resource](../../reference/resources/caliconodestatus.mdx) to get BGP session status for the node. - -If you do not see this, please check the following. - -- Make sure there is IP connectivity between your hosts. - -- Make sure your network allows the requisite BGP traffic on TCP port 179. - -### Configure NetworkManager - -Configure [NetworkManager](https://help.ubuntu.com/community/NetworkManager) before -attempting to use $[prodname] networking. - -NetworkManager manipulates the routing table for interfaces in the default network -namespace where $[prodname] veth pairs are anchored for connections to containers. -This can interfere with the $[prodname] agent's ability to route correctly. - -Create the following configuration file at `/etc/NetworkManager/conf.d/calico.conf` to prevent -NetworkManager from interfering with the interfaces: - -```conf -[keyfile] -unmanaged-devices=interface-name:cali*;interface-name:tunl*;interface-name:vxlan.calico;interface-name:vxlan-v6.calico;interface-name:wireguard.cali;interface-name:wg-v6.cali -``` - -## Errors when running sudo calicoctl - -If you use `sudo` for commands, remember that your environment variables are not transferred to the `sudo` environment. You must run `sudo` with the `-E` flag to include your environment variables: - -```bash -sudo -E calicoctl node diags -``` - -or you can set environment variables for `sudo` commands like this: - -```bash -sudo ETCD_ENDPOINTS=http://172.25.0.1:2379 calicoctl node run -``` - -Also be aware that connection information can be specified as a config file rather than using environment variables. See [Installing calicoctl](../calicoctl/install.mdx) -for details. - -## Error: $[nodecontainer] is not ready: BIRD is not ready: BGP not established with 10.0.0.1 - -In most cases, this "unready" status error in Kubernetes means that a particular peer is unreachable in the cluster. Check that BGP connectivity between the two peers is allowed in the environment. - -This error can also occur if inactive Node resources are configured for node-to-node mesh. To fix this, [decommission the stale nodes](../decommissioning-a-node.mdx). - -## Linux conntrack table is out of space - -A common problem on Linux systems is running out of space in the conntrack table, which can cause poor iptables performance. This can -happen if you run a lot of workloads on a given host, or if your workloads create a lot of TCP connections or bidirectional UDP streams. To avoid this problem, we recommend increasing the conntrack table size using the following commands: - -```bash -sysctl -w net.netfilter.nf_conntrack_max=1000000 -echo "net.netfilter.nf_conntrack_max=1000000" >> /etc/sysctl.conf -``` diff --git a/calico_versioned_docs/version-3.29/operations/troubleshoot/vpp.mdx b/calico_versioned_docs/version-3.29/operations/troubleshoot/vpp.mdx deleted file mode 100644 index 9af6dc5ca6..0000000000 --- a/calico_versioned_docs/version-3.29/operations/troubleshoot/vpp.mdx +++ /dev/null @@ -1,405 +0,0 @@ ---- -description: Specific troubleshooting steps for the VPP data plane. ---- - -# VPP data plane troubleshooting - -## Big picture - -This page describes the troubleshooting steps for the [VPP data plane](../../getting-started/kubernetes/vpp/getting-started.mdx). If you did not configure the VPP data plane, this page is not for you! - -If you're encountering issues with the VPP data plane, feel free to reach out to us either on the [#vpp channel](https://calicousers.slack.com/archives/C017220EXU1) on the $[prodname] slack, or by opening a new issue in [GitHub](https://github.com/projectcalico/vpp-dataplane/issues)). - -## Installing calivppctl - -`calivppctl` is a helper bash script shipped alongside vpp container images. It can be installed to your host with the following methods, and helps collecting logs and debugging a running cluster with the VPP data plane installed. - -- With curl - - ```bash - curl https://raw.githubusercontent.com/projectcalico/vpp-dataplane/$[vppbranch]/test/scripts/vppdev.sh | tee /usr/bin/calivppctl - chmod +x /usr/bin/calivppctl - ``` - -- With docker (and a cluster with $[prodname] VPP running) - - ```bash - vppcontainer=$(docker ps | grep vpp_calico-vpp | awk '{ print $1 }') - docker cp ${vppcontainer}:/usr/bin/calivppctl /usr/bin/calivppctl - ``` - -- With kubectl (and a cluster with $[prodname] VPP running) - - ```bash - vpppod=$(kubectl -n calico-vpp-dataplane get pods -o wide | grep calico-vpp-node- | awk '{ print $1 }' | head -1) - kubectl -n calico-vpp-dataplane exec -it ${vpppod} -c vpp -- cat /usr/bin/calivppctl | tee /usr/bin/calivppctl > /dev/null - chmod +x /usr/bin/calivppctl - ``` - -## Troubleshooting - -### Kubernetes Cluster - -First you need to make sure Kubernetes is up and running. - -- `service kubelet status` should give you a first hint. -- Issues should be reported in the kubelet logs, which you can check with this command if you are using systemd: `journalctl -u kubelet -r -n200` - -:::note - -Kubernetes does not run with swap enabled. - -::: - -### Starting calico-vpp-node Daemon set - -Once the cluster is correctly started, the next issue can come from the Daemonset configuration. -Best is to start by inspecting the pods : are they running correctly ? -Usually configuration issues (available hugepages, memory, ...) will be reported here: - -```bash -kubectl -n calico-vpp-dataplane describe pod/calico-vpp-node-XXXXX -``` - -:::note - -If at this point you don't have enough hugepages, you'll have to restart kubelet -after allocating them for taking it into account (using for instance `service kubelet restart`) - -::: - -### Having VPP up and running - -Once the pods don't report any issue, the pods should have started. There are two -containers for each node : `vpp-manager` that starts the VPP process and sets up connectivity, -and the agent handling pod connectivity, service load balancing, BGP, policies, etc. - -First check that VPP is running correctly. If the connectivity configuration, interface naming -is not correct, this will be reported here. Once this is running, you should be able to ping your other nodes through VPP. - -```bash -# Print VPP's log : basic connectivity and NIC configuration -calivppctl log -vpp myk8node1 -``` - -Then you can check for any issues reported by the agent (e.g. BGP listen issue -if the port is already taken, or missing configuration pieces). If this doesn't -show any errors, you should be able to `nslookup kubernetes.default` from pods. - -```bash -# Print the logs for the $[prodname] VPP data plane agent, programming serviceIPs, BGP, ... -calivppctl log -agent myk8node1 -``` - -If all this doesn't play well you can always use the export to generate an `export.tar.gz` -bundle and ask for help on the [#vpp channel](https://calicousers.slack.com/archives/C017220EXU1) - -```bash -calivppctl export -``` - -## Accessing the VPP cli - -For further debugging, tracing packets and inspecting VPP's internals, you can -get a vpp shell using the following: - -```bash -calivppctl vppctl myk8node1 -``` - -### Listing interfaces and basics - -To list existing interfaces and basic counters use - -``` -vpp# show int -vpp# show int addr -``` - -To get more insights on the main interface (e.g. if you're using dpdk) you can check -for errors & drops in - -``` -vpp# show hardware-interfaces -``` - -Other places to look for errors - -``` -vpp# show log # VPP startup log -vpp# show err # Prints out packet counters (not always actual errors, but includes drops) -vpp# show buffers # You should have non zero free buffers, otherwise traffic won't flow -``` - -## Tracing packets - -### Internal network layout - -For starters, here is a small schematic of how the network looks like: -![k8-calico-vpp](/img/calico/vpp-tracing-net.svg) - -Container interfaces are named `tun[0-9]+`. You can find which one belong to which container as follows: - -- Connect to VPP - ``` - calivppctl vppctl NODENAME - ``` -- List interfaces - ``` - vpp# show interface - Name Idx State MTU (L3/IP4/IP6/MPLS) Counter Count - avf-0/d8/a/0 1 up 9000/0/0/0 tx packets 2 - tx bytes 216 - local0 0 down 0/0/0/0 - tap0 2 up 0/0/0/0 rx packets 9 - [...] - tun3 5 up 0/0/0/0 rx packets 5 - rx bytes 431 - tx packets 5 - tx bytes 387 - ip4 5 - ``` - -- Show the route for address 11.0.166.132 - ``` - vpp# show ip fib 11.0.166.132 - ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport symmetric ] epoch:0 flags:none locks:[adjacency:1, default-route:1, ] - 11.0.166.132/32 fib:0 index:19 locks:5 - cnat refs:1 entry-flags:uRPF-exempt,interpose, src-flags:added,contributing,active, cover:-1 interpose: - [@0]: [4] cnat-client:[11.0.166.132] tr:0 sess:1 - path-list:[26] locks:3 flags:shared, uPRF-list:24 len:1 itfs:[5, ] - path:[32] pl-index:26 ip4 weight=1 pref=0 attached-nexthop: oper-flags:resolved, cfg-flags:attached, - 11.0.166.132 tun3 (p2p) - [@0]: ipv4 via 0.0.0.0 tun3: mtu:9000 next:7 - [...] - ``` - -- This one is behind `tun3`. If you want more info about this interface (name in Linux, queues, descriptors, ...) - ``` - vpp# show tun tun3 - Interface: tun3 (ifindex 5) - name "eth0" - host-ns "/proc/17675/ns/net" - [...] - ``` - - `tap0` is the interface providing connectivity to the host, using the original interface name on the Linux side (use `show tap tap0` and `show ip punt redirect`). - -### Capturing traffic inside the cluster - -Let's take the case of two pods talking to each other in your cluster (see the schema above). -You might want to inspect the traffic at 3 different locations: - -- as it exits the pod (in Linux inside the first pod) -- as it goes through VPP -- as it is received in the second pod (in Linux again) - -We cover the three cases, first inside VPP (depending on where your traffic is coming from : a pod or outside your host) -then inside your pods (usually with `tcpdump`) - -### Traffic capture inside VPP - -#### Traffic from a pod - -The following snippet will allow you to capture all traffic coming from containers on a particular node, grep from a specific packet, -and see what happened to it. - -```bash -# Make sure that the trace buffer is clean in VPP -calivppctl vppctl NODENAME clear trace -# Add a trace from the virtio-input input-node -calivppctl vppctl NODENAME trace add virtio-input 500 -# generate some traffic -calivppctl vppctl NODENAME show trace max 500 > somefile -# Grep for your IPs -cat somefile | grep '1.2.3.4 -> 5.6.7.8' -A40 -B40 -``` - -Output looks quite cumbersome at first as it contains the whole path of a packet through VPP, from reception to tx. - -``` -vpp# show trace -Packet 1 - -00:09:46:518858: virtio-input - This packet has been received on the interface number #2 (column Idx in `show int`) - and is 688 Bytes long - virtio: hw_if_index 2 next-index 1 vring 0 len 688 - hdr: flags 0x00 gso_type 0x00 hdr_len 0 gso_size 0 csum_start 0 csum_offset 0 num_buffers 1 -00:09:46:518866: ip4-input - we read TCP header, addresses and ports - TCP: 20.0.0.1 -> 11.0.166.133 - tos 0x00, ttl 64, length 688, checksum 0x1bc5 dscp CS0 ecn NON_ECN - fragment id 0x56fd, flags DONT_FRAGMENT - TCP: 6443 -> 34112 - seq. 0xa1f93599 ack 0x818eb1c1 - flags 0x18 PSH ACK, tcp header: 32 bytes - window 502, checksum 0x00b7 -00:09:46:518870: ip4-lookup - fib 0 dpo-idx 5 flow hash: 0x00000000 - TCP: 20.0.0.1 -> 11.0.166.133 - tos 0x00, ttl 64, length 688, checksum 0x1bc5 dscp CS0 ecn NON_ECN - fragment id 0x56fd, flags DONT_FRAGMENT - TCP: 6443 -> 34112 - seq. 0xa1f93599 ack 0x818eb1c1 - flags 0x18 PSH ACK, tcp header: 32 bytes - window 502, checksum 0x00b7 -00:09:46:518873: ip4-cnat-tx - We need to do some NATing as it's Kubernetes - found: session:[20.0.0.1;6443 -> 11.0.166.133;34112, TCP] => 11.96.0.1;443 -> 11.0.166.133;34112 lb:-1 age:4190 -00:09:46:518879: ip4-rewrite - We rewrite the ip packet - mac addresses only when coming / going to a PHY, as tun interfaces are L3-only - tx_sw_if_index 6 dpo-idx 7 : ipv4 via 0.0.0.0 tun4: mtu:9000 next:8 flow hash: 0x00000000 - 00000000: 450002b056fd40003f0625650b6000010b00a68501bb8540a1f93599818eb1c1 - 00000020: 801801f620c700000101080a3f906c98fbaaba031703030277413d39 - Output happens on the interface `tun4` -00:09:46:518880: tun4-output - tun4 - 00000000: 450002b056fd40003f0625650b6000010b00a68501bb8540a1f93599818eb1c1 - 00000020: 801801f620c700000101080a3f906c98fbaaba031703030277413d39b97817c1 - 00000040: 41392fdbe0e9d4886849851476cdb8986362ee2f789bfefd8a5c106c898d1309 - 00000060: 4f8f8cb89159d99e986813a48d91334930eb5eb10ca4248c -00:09:46:518881: tun4-tx - buffer 0x24cf615: current data 0, length 688, buffer-pool 1, ref-count 1, totlen-nifb 0, trace handle 0x1000000 - ipv4 tcp hdr-sz 52 l2-hdr-offset 0 l3-hdr-offset 0 l4-hdr-offset 20 l4-hdr-sz 32 - 0x0b60: 40:00:3f:06:25:65 -> 45:00:02:b0:56:fd - -Packet 2 -[...] -``` - -#### Traffic from the phy - -If you want to capture traffic coming from the physical NIC, you should use `trace add` but with a different source node a.k.a `dpdk-input` or `af-packet-input` or `af_xdp-input` or `avf-input` instead of `virtio-input`. - -`show run` should give you a hint of the `X-input` node you want to trace from. - -For example, going by the output of `show run` below we seem to want to use `avf-input` as the node to trace from: - -``` -vpp# show run -Thread 1 vpp_wk_0 (lcore 25) -Time 1.9, 10 sec internal node vector rate 1.05 loops/sec 1074819.68 - vector rates in 7.5356e0, out 7.5356e0, drop 0.0000e0, punt 0.0000e0 - Name State Calls Vectors Suspends Clocks Vectors/Call -avf-input polling 2233530 0 0 8.24e1 0.00 -ip4-cnat-snat active 1 1 0 5.35e3 1.00 -ip4-cnat-tx active 14 15 0 1.18e3 1.07 -[...] -``` - -So, same as with traffic from a container, you can use - -```bash -# Make sure that the trace buffer is clean in VPP -calivppctl vppctl NODENAME clear trace -# Add a trace from the virtio-input input-node -calivppctl vppctl NODENAME trace add avf-input 500 -# generate some traffic -calivppctl vppctl NODENAME show trace max 500 > somefile -# Grep for your IPs -cat somefile | grep '1.2.3.4 -> 5.6.7.8' -A40 -B40 -``` - -#### With Wireshark - -Alternatively to the trace, you can do a capture and analyze it inside Wireshark. You can do this with: - -``` -vpp# pcap dispatch trace on max 1000 file vppcapture buffer-trace dpdk-input 1000 -vpp# pcap dispatch trace off -``` - -This will generate a file named `/tmp/vppcapture`. - -Then on your host run: - -```bash -calivppctl sh vpp NODENAME -root@server:~ mv /tmp/vppcapture /var/lib/vpp/ -root@server:~ exit -``` - -The file should now be at `/var/lib/vpp/vppcapture` on your host 'NODENAME'. You can then `scp NODENAME:/var/lib/vpp/vppcapture .` on your machine and open it with Wireshark. More info about this [here](https://haryachyy.wordpress.com/2019/09/29/learning-vpp-trace-with-wireshark/). - -### Traffic received in the pods - -To inspect traffic actually received by the pods (if `tcpdump` is installed in the pod), simply run `tcpdump -ni eth0` inside the pod. If tcpdump is not available in the pod, here are two options to still be able to capture pod traffic: - -#### Tcpdump is available on the host - -Provided that you have `tcpdump` installed on the host, you can use `nsenter` to attach to the pod's network namespace and use the host's `tcpdump` on the container's interface. - -This works on docker as follows: - -- Find the container ID you want to inspect - ```bash - docker ps - CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES - 4c01db0b339c ubuntu:12.04 bash 17 seconds ago Up 16 seconds 3300-3310/tcp webapp - ``` - -- Get the container PID out of it - ``` - docker inspect --format '{{ .State.Pid }}' 4c01db0b339c - 12345 - ``` - -- Attach - ``` - nsenter -t 12345 -n bash - ``` - -#### No tcpdump, but we have python ! - -Open an AF_PACKET socket in python with the following code and run it attached to the running namespace as previously. - -```python -#!/usr/bin/env python -from socket import * -from struct import unpack - -IFNAME = "eth0" -N_PKT = 50 -MTU=1500 - -sock = socket(AF_PACKET, SOCK_DGRAM, 0x0800) -sock.bind((IFNAME, 0x0800)) -for _ in range(N_PKT): - data = sock.recvfrom(MTU, 0)[0] - src_addr = inet_ntop(AF_INET, data[12:16]) - dst_addr = inet_ntop(AF_INET, data[16:20]) - src_port, = unpack("!H", data[20:22]) - dst_port, = unpack("!H", data[22:24]) - data_len, = unpack("!H", data[24:26]) - cksum, = unpack("!H", data[26:28]) - - print("%s:%d -> %s:%d len %d cs %d" % (src_addr, src_port, dst_addr, dst_port, data_len, cksum)) -``` - -This requires privileges and thus is usually easier to run from the host. From the host, you can use `echo "the python blob above" | nsenter -t -n python` to execute this code. - -### Traffic to the kubelet agent - -As the kubelet agent runs directly on the host without a network namespace, pods talking to it (e.g. coredns resolvers) would go through a specific path. Packets destined to it will be caught by VPP's punt mechanism, and will be forwarded to the host through a tap interface which will have the same name as the original interface in Linux. - -To debug traffic within VPP, use the trace & check that traffic is correctly punted to the tap0 interface. - -On the host, you can use `tcpdump` normally to check the traffic. - -## Crashes & coredumps - -If VPP aborts unexpectedly, it will generate a coredump file, `vppcore.vpp_main.`, in the `/var/lib/vpp/` dir. If you encounter this situation, please note the exact version of the vpp image that generated the corefile (using the image hash) to facilitate further troubleshooting. - -To explore the corefile run: - -```bash -docker run -it --entrypoint=bash -v /var/lib/vpp/vppcore.vpp_main.12345:/root/vppcore calicovpp/vpp:VERSION -``` -You should now have a shell inside the vpp container. - -```bash -apt update && apt install -y gdb -gdb vpp ./vppcore -``` diff --git a/calico_versioned_docs/version-3.29/operations/upgrading/index.mdx b/calico_versioned_docs/version-3.29/operations/upgrading/index.mdx deleted file mode 100644 index 20bc2723b1..0000000000 --- a/calico_versioned_docs/version-3.29/operations/upgrading/index.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: Upgrade to a newer version of Calico. -hide_table_of_contents: true ---- - -# Upgrade - -import DocCardList from '@theme/DocCardList'; -import { useCurrentSidebarCategory } from '@docusaurus/theme-common'; - - diff --git a/calico_versioned_docs/version-3.29/operations/upgrading/kubernetes-upgrade.mdx b/calico_versioned_docs/version-3.29/operations/upgrading/kubernetes-upgrade.mdx deleted file mode 100644 index 937db33197..0000000000 --- a/calico_versioned_docs/version-3.29/operations/upgrading/kubernetes-upgrade.mdx +++ /dev/null @@ -1,230 +0,0 @@ ---- -description: Upgrade to a newer version of Calico for Kubernetes. ---- - -import AutoHostendpointsMigrate from '@site/calico_versioned_docs/version-3.29/_includes/components/AutoHostendpointsMigrate'; - -# Upgrade Calico on Kubernetes - -## About upgrading $[prodname] - -This page describes how to upgrade to $[version] from $[prodname] v3.15 or later. The -procedure varies by datastore type and install method. - -If you are using $[prodname] in etcd mode on a Kubernetes cluster, we recommend upgrading to the Kubernetes API datastore [as discussed here](../datastore-migration.mdx). - -If you have installed $[prodname] using the `calico.yaml` manifest, we recommend upgrading to the $[prodname] operator, [as discussed here](../operator-migration.mdx). - -- [Upgrading an installation that was installed using Helm](#upgrading-an-installation-that-was-installed-using-helm) - -- [Upgrading an installation that uses the operator](#upgrading-an-installation-that-uses-the-operator) - -- [Upgrading an installation that uses manifests and the Kubernetes API datastore](#upgrading-an-installation-that-uses-manifests-and-the-kubernetes-api-datastore) - -- [Upgrading an installation that connects directly to an etcd datastore](#upgrading-an-installation-that-uses-an-etcd-datastore) - -:::note - -Do not use older versions of `calicoctl` after the upgrade. -This may result in unexpected behavior and data. - -::: - -## Upgrade OwnerReferences - -If you do not use OwnerReferences on resources in the projectcalico.org/v3 API group, you can skip this section. - -Starting in $[prodname] v3.28, a change in the way UIDs are generated for projectcalico.org/v3 resources requires that you update any OwnerReferences -that refer to projectcalico.org/v3 resources as an owner. After upgrade, the UID for all projectcalico.org/v3 resources will be changed, resulting in any -owned resources being garbage collected by Kubernetes. - -1. Remove any OwnerReferences from resources in your cluster that have `apiGroup: projectcalico.org/v3`. -1. Perform the upgrade normally. -1. Add new OwnerReferences to your resources referencing the new UID. - -## Upgrading an installation that was installed using helm - -1. Apply the $[version] CRDs: - - ```bash - kubectl apply --server-side --force-conflicts -f $[manifestsUrl]/manifests/operator-crds.yaml - ``` - -1. Run the Helm upgrade: - - ```bash - helm upgrade $[prodnamedash] projectcalico/tigera-operator - ``` - -## Upgrading an installation that uses the operator - -1. Download the $[version] operator manifest. - - ```bash - curl $[manifestsUrl]/manifests/tigera-operator.yaml -O - ``` - -1. Use the following command to initiate an upgrade. - - ```bash - kubectl apply --server-side --force-conflicts -f tigera-operator.yaml - ``` - -## Upgrading an installation that uses manifests and the Kubernetes API datastore - -1. Download the $[version] manifest that corresponds to your original installation method. - - **$[prodname] for policy and networking** - - ```bash - curl $[manifestsUrl]/manifests/calico.yaml -o upgrade.yaml - ``` - - **$[prodname] for policy and flannel for networking** - - ```bash - curl $[manifestsUrl]/manifests/canal.yaml -o upgrade.yaml - ``` - - **$[prodname] for policy (advanced)** - - ```bash - curl $[manifestsUrl]/manifests/calico-policy-only.yaml -o upgrade.yaml - ``` - - :::note - - If you manually modified the manifest, you must manually apply the - same changes to the downloaded manifest. - - ::: - -1. Use the following command to initiate a rolling update. - - ```bash - kubectl apply --server-side --force-conflicts -f upgrade.yaml - ``` - -1. Watch the status of the upgrade as follows. - - ```bash - watch kubectl get pods -n kube-system - ``` - - Verify that the status of all $[prodname] pods indicate `Running`. - - ``` - $[noderunning]-hvvg8 2/2 Running 0 3m - $[noderunning]-vm8kh 2/2 Running 0 3m - $[noderunning]-w92wk 2/2 Running 0 3m - ``` - -1. Remove any existing `calicoctl` instances, [install the new `calicoctl`](../calicoctl/install.mdx) - and [configure it to connect to your datastore](../calicoctl/configure/overview.mdx). - -1. Use the following command to check the $[prodname] version number. - - ```bash - calicoctl version - ``` - - It should return a `Cluster Version` of `$[version].x`. - -1. If you have [enable application layer policy](../../network-policy/istio/app-layer-policy.mdx), - follow [the instructions below](#upgrading-if-you-have-application-layer-policy-enabled) to complete your upgrade. Skip this if you are not using Istio with $[prodname]. - -1. If you were upgrading from a version of Calico prior to v3.14 and followed the pre-upgrade steps for host endpoints above, review traffic logs from the temporary policy, - add any global network policies needed to allow traffic, and delete the temporary network policy **allow-all-upgrade**. - -1. Congratulations! You have upgraded to $[prodname] $[version]. - -## Upgrading an installation that uses an etcd datastore - -1. Download the $[version] manifest that corresponds to your original installation method. - - **$[prodname] for policy and networking** - - ```bash - curl $[manifestsUrl]/manifests/calico-etcd.yaml -o upgrade.yaml - ``` - - **$[prodname] for policy and flannel for networking** - - ```bash - curl $[manifestsUrl]/manifests/canal-etcd.yaml -o upgrade.yaml - ``` - - :::note - - You must manually apply the changes you made to the manifest - during installation to the downloaded $[version] manifest. At a minimum, - you must set the `etcd_endpoints` value. - - ::: - -1. Use the following command to initiate a rolling update. - - ```bash - kubectl apply --server-side --force-conflicts -f upgrade.yaml - ``` - -1. Watch the status of the upgrade as follows. - - ```bash - watch kubectl get pods -n kube-system - ``` - - Verify that the status of all $[prodname] pods indicate `Running`. - - ``` - calico-kube-controllers-6d4b9d6b5b-wlkfj 1/1 Running 0 3m - $[noderunning]-hvvg8 1/2 Running 0 3m - $[noderunning]-vm8kh 1/2 Running 0 3m - $[noderunning]-w92wk 1/2 Running 0 3m - ``` - - :::tip - - The $[noderunning] pods will report `1/2` in the `READY` column, as shown. - - ::: - -1. Remove any existing `calicoctl` instances, [install the new `calicoctl`](../calicoctl/install.mdx) - and [configure it to connect to your datastore](../calicoctl/configure/overview.mdx). - -1. Use the following command to check the $[prodname] version number. - - ```bash - calicoctl version - ``` - - It should return a `Cluster Version` of `$[version]`. - -1. If you have [enabled application layer policy](../../network-policy/istio/app-layer-policy.mdx), - follow [the instructions below](#upgrading-if-you-have-application-layer-policy-enabled) to complete your upgrade. Skip this if you are not using Istio with $[prodname]. - -1. If you were upgrading from a version of Calico prior to v3.14 and followed the pre-upgrade steps for host endpoints above, review traffic logs from the temporary policy, - add any global network policies needed to allow traffic, and delete the temporary network policy **allow-all-upgrade**. - -1. Congratulations! You have upgraded to $[prodname] $[version]. - -## Upgrading if you have Application Layer Policy enabled - -Dikastes is versioned the same as the rest of $[prodname], but an upgraded `calico-node` will still be able to work with a downlevel Dikastes -so that you will not lose data plane connectivity during the upgrade. Once `calico-node` is upgraded, you can begin redeploying your service pods -with the updated version of Dikastes. - -If you have [enabled application layer policy](../../network-policy/istio/app-layer-policy.mdx), -take the following steps to upgrade the Dikastes sidecars running in your application pods. Skip these steps if you are not using Istio with $[prodname]. - -1. Update the Istio sidecar injector template to use the new version of Dikastes. Replace `` below with - the full version string of your Istio install, for example `1.4.2`. - - ```bash - kubectl apply -f $[manifestsUrl]/manifests/alp/istio-inject-configmap-.yaml - ``` - -1. Once the new template is in place, newly created pods use the upgraded version of Dikastes. Perform a rolling update of each of your service deployments - to get them on the new version of Dikastes. - - diff --git a/calico_versioned_docs/version-3.29/operations/upgrading/openshift-upgrade.mdx b/calico_versioned_docs/version-3.29/operations/upgrading/openshift-upgrade.mdx deleted file mode 100644 index e377dc04f2..0000000000 --- a/calico_versioned_docs/version-3.29/operations/upgrading/openshift-upgrade.mdx +++ /dev/null @@ -1,51 +0,0 @@ ---- -description: Upgrade to a newer version of Calico for OpenShift. ---- - -import AutoHostendpointsMigrate from '@site/calico_versioned_docs/version-3.29/_includes/components/AutoHostendpointsMigrate'; -import InstallOpenShiftManifests from '@site/calico_versioned_docs/version-3.29/_includes/components/InstallOpenShiftManifests'; - -# Upgrade Calico on OpenShift 4 - -## About upgrading $[prodname] - -This page describes how to upgrade to $[version] for OpenShift 4 from an existing $[prodname] cluster. - -## Upgrade OwnerReferences - -If you do not use OwnerReferences on resources in the projectcalico.org/v3 API group, you can skip this section. - -Starting in Calico v3.28, a change in the way UIDs are generated for projectcalico.org/v3 resources requires that you update any OwnerReferences -that refer to projectcalico.org/v3 resources as an owner. After upgrade, the UID for all projectcalico.org/v3 resources will be changed, resulting in any -owned resources being garbage collected by Kubernetes. - -1. Remove any OwnerReferences from resources in your cluster that have `apiGroup: projectcalico.org/v3`. -1. Perform the upgrade normally. -1. Add new OwnerReferences to your resources referencing the new UID. - -## Upgrading Calico on OpenShift 4 - -Make a manifests directory. - -```bash -mkdir manifests -``` - - - -Apply the updated manifests. - -```bash -oc apply -f manifests/ -``` - -You can now monitor the upgrade progress with the following command: - -```bash -watch oc get tigerastatus -``` - -If you were upgrading from a version of Calico prior to v3.14 and followed the pre-upgrade steps for host endpoints above, review traffic logs from the temporary policy, -add any global network policies needed to allow traffic, and delete the temporary network policy **allow-all-upgrade**. - - diff --git a/calico_versioned_docs/version-3.29/operations/upgrading/openstack-upgrade.mdx b/calico_versioned_docs/version-3.29/operations/upgrading/openstack-upgrade.mdx deleted file mode 100644 index 0c0d8e64d1..0000000000 --- a/calico_versioned_docs/version-3.29/operations/upgrading/openstack-upgrade.mdx +++ /dev/null @@ -1,166 +0,0 @@ ---- -description: Upgrade to a newer version of Calico for OpenStack. ---- - -# Upgrade Calico on OpenStack - -## $[prodname] package update - -This page describes how to upgrade to $[version] from $[prodname] v3.0 or later. The procedure -varies by Linux distribution. - -- [Upgrading an OpenStack cluster based on CentOS](#upgrading-an-openstack-cluster-based-on-centos) - -- [Upgrading an OpenStack cluster based on Ubuntu](#upgrading-an-openstack-cluster-based-on-ubuntu) - -:::note - -Do not use older versions of `calicoctl` after the upgrade. -This may result in unexpected behavior and data. - -::: - -## Upgrading an OpenStack cluster based on CentOS - -1. On all nodes, change the location of the $[prodname] packages to point to the $[version] repo: - - ``` - sudo sed -i 's/calico-X.X/calico-Y.Y/g' /etc/yum.repos.d/calico.repo - ``` - - Replace `X.X` in the above command with the version you're upgrading from (must be v3.0 or later). - Replace `Y.Y` with the version of the release you're upgrading to. Example: if you are upgrading from v3.1 - to v3.5, replace `X.X` with `3.1` and replace `Y.Y` with `3.5`. - -1. On all compute nodes, update packages: - - ``` - sudo yum update - ``` - - We recommend upgrading the whole distribution as shown here. In case you prefer to upgrade particular packages only, those needed for a $[prodname] compute node are the following. - - - `calico-common` - - `calico-compute` - - `calico-dhcp-agent` - - `calico-felix` - - `dnsmasq` - - `networking-calico` - - `openstack-neutron` - - `openstack-nova-api` - - `openstack-nova-compute` -
    -
    - -1. Use the following command on the compute nodes to confirm that Felix has upgraded to $[version]. - - ``` - calico-felix --version - ``` - - It should return `$[version]`. - -1. On all compute nodes, add the following line to the end of `/etc/calico/felix.cfg`: - - ``` - DatastoreType = etcdv3 - ``` - - If you need to change the EtcdEndpoints address (e.g. because you've installed a new etcdv3 cluster - rather than upgrading your existing etcdv2 cluster), you should update the EtcdEndpoints addresses - in `/etcd/calico/felix.cfg` at this point. - -1. On all control nodes, update packages: - - ``` - sudo yum update - ``` - - We recommend upgrading the whole distribution as shown here. In case you prefer to upgrade particular packages only, those needed for a $[prodname] control node are the following. - - - `calico-common` - - `calico-control` - - `networking-calico` - - `openstack-neutron` -
    -
    - -1. On all control nodes, restart `neutron-server`: - - ``` - sudo systemctl restart neutron-server - ``` - -1. If you ran `calico-upgrade` earlier to migrate non-openstack data, on the control node run: - - ``` - calico-upgrade complete - ``` - -1. Remove any existing `calicoctl` instances and [install the new `calicoctl`](../calicoctl/install.mdx). - -1. Congratulations! You have upgraded to $[prodname] $[version]. - -## Upgrading an OpenStack cluster based on Ubuntu - -1. On all nodes, change the location of the $[prodname] packages to point to the $[version] repo: - - ``` - sudo bash -c 'cat > /etc/apt/sources.list.d/project-calico-calico-X_X-trusty.list' << EOF - deb http://ppa.launchpad.net/project-calico/calico-X.X/ubuntu trusty main - # deb-src http://ppa.launchpad.net/project-calico/calico-X.X/ubuntu trusty main - EOF - ``` - - Replace `X_X` and `X.X` with the version you're upgrading to. Example: if you're upgrading to v3.5, replace `X_X` with - `3_5` and replace `X.X` with `3.5`. Also replace `trusty` with the code name of your Ubuntu version. - -1. On all compute nodes, update packages: - - ``` - sudo apt-get update - sudo apt-get install calico-compute calico-felix calico-common \ - python-etcd networking-calico calico-dhcp-agent - - ``` - -1. Use the following command on the compute nodes to confirm that Felix has upgraded to $[version]. - - ``` - calico-felix --version - ``` - - It should return `$[version]`. - -1. On all compute nodes, add the following line to the end of `/etc/calico/felix.cfg`: - - ``` - DatastoreType = etcdv3 - ``` - - If you need to change the EtcdEndpoints address (e.g. because you've installed a new etcdv3 cluster - rather than upgrading your existing etcdv2 cluster), you should update the EtcdEndpoints addresses - in `/etcd/calico/felix.cfg` at this point. - -1. On all control nodes, update packages: - - ``` - sudo apt-get update - sudo apt-get install calico-control calico-common python-etcd networking-calico - ``` - -1. On all control nodes, restart `neutron-server`: - - ``` - sudo service neutron-server restart - ``` - -1. If you ran `calico-upgrade` earlier to migrate non-openstack data, on the control node run: - - ``` - calico-upgrade complete - ``` - -1. Remove any existing `calicoctl` instances and [install the new `calicoctl`](../calicoctl/install.mdx). - -1. Congratulations! You have upgraded to $[prodname] $[version]. diff --git a/calico_versioned_docs/version-3.29/reference/api.mdx b/calico_versioned_docs/version-3.29/reference/api.mdx deleted file mode 100644 index a9c53099da..0000000000 --- a/calico_versioned_docs/version-3.29/reference/api.mdx +++ /dev/null @@ -1,12 +0,0 @@ ---- -description: Learn about the Calico client library and how to use it. ---- - -# Calico Client library - -$[prodname] provides and consumes a client library in Go that allows developers to work with $[prodname] resources. The -client library can be used to get, list, watch, create, delete and update custom resources, such as network policies much -like the [client-go project](https://github.com/kubernetes/client-go) does for native Kubernetes resources. - -To learn more about the Calico client library and how to use it, see the Calico API project [README](https://github.com/projectcalico/api/blob/master/README.md) or -the [github.com/projectcalico/api Go module page](https://pkg.go.dev/github.com/projectcalico/api). diff --git a/calico_versioned_docs/version-3.29/reference/architecture/data-path.mdx b/calico_versioned_docs/version-3.29/reference/architecture/data-path.mdx deleted file mode 100644 index 0aef26a0ab..0000000000 --- a/calico_versioned_docs/version-3.29/reference/architecture/data-path.mdx +++ /dev/null @@ -1,63 +0,0 @@ ---- -description: Learn how packets flow between workloads in a datacenter, or between a workload and the internet. ---- - -# 'The Calico data path: IP routing and iptables' - -One of $[prodname]’s key features is how packets flow between workloads in a -data center, or between a workload and the Internet, without additional -encapsulation. - -In the $[prodname] approach, IP packets to or from a workload are routed and -firewalled by the Linux routing table and iptables or eBPF infrastructure on the -workload’s host. For a workload that is sending packets, $[prodname] ensures -that the host is always returned as the next hop MAC address regardless -of whatever routing the workload itself might configure. For packets -addressed to a workload, the last IP hop is that from the destination -workload’s host to the workload itself. - -![Calico datapath](/img/calico/calico-datapath.png) - -Suppose that IPv4 addresses for the workloads are allocated from a -datacenter-private subnet of 10.65/16, and that the hosts have IP -addresses from 172.18.203/24. If you look at the routing table on a host: - -```bash -route -n -``` - -You will see something like this: - -``` -Kernel IP routing table -Destination Gateway Genmask Flags Metric Ref Use Iface -0.0.0.0 172.18.203.1 0.0.0.0 UG 0 0 0 eth0 -10.65.0.0 0.0.0.0 255.255.0.0 U 0 0 0 ns-db03ab89-b4 -10.65.0.21 172.18.203.126 255.255.255.255 UGH 0 0 0 eth0 -10.65.0.22 172.18.203.129 255.255.255.255 UGH 0 0 0 eth0 -10.65.0.23 172.18.203.129 255.255.255.255 UGH 0 0 0 eth0 -10.65.0.24 0.0.0.0 255.255.255.255 UH 0 0 0 tapa429fb36-04 -172.18.203.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 -``` - -There is one workload on this host with IP address 10.65.0.24, and -accessible from the host via a TAP (or veth, etc.) interface named -tapa429fb36-04. Hence there is a direct route for 10.65.0.24, through -tapa429fb36-04. Other workloads, with the .21, .22 and .23 addresses, -are hosted on two other hosts (172.18.203.126 and .129), so the routes -for those workload addresses are via those hosts. - -The direct routes are set up by a $[prodname] agent named Felix when it is -asked to provision connectivity for a particular workload. A BGP client -(such as BIRD) then notices those and distributes them – perhaps via a -route reflector – to BGP clients running on other hosts, and hence the -indirect routes appear also. - -## Is that all? - -As far as the static data path is concerned, yes. It’s just a -combination of responding to workload ARP requests with the host MAC, IP -routing and iptables or eBPF. There’s a great deal more to $[prodname] in terms of -how the required routing and security information is managed, and for -handling dynamic things such as workload migration – but the basic data -path really is that simple. diff --git a/calico_versioned_docs/version-3.29/reference/architecture/design/index.mdx b/calico_versioned_docs/version-3.29/reference/architecture/design/index.mdx deleted file mode 100644 index 717ac9f295..0000000000 --- a/calico_versioned_docs/version-3.29/reference/architecture/design/index.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: Deep dive into using Calico over Ethernet and IP fabrics. -hide_table_of_contents: true ---- - -# Network design - -import DocCardList from '@theme/DocCardList'; -import { useCurrentSidebarCategory } from '@docusaurus/theme-common'; - - diff --git a/calico_versioned_docs/version-3.29/reference/architecture/design/l2-interconnect-fabric.mdx b/calico_versioned_docs/version-3.29/reference/architecture/design/l2-interconnect-fabric.mdx deleted file mode 100644 index 983da06ff8..0000000000 --- a/calico_versioned_docs/version-3.29/reference/architecture/design/l2-interconnect-fabric.mdx +++ /dev/null @@ -1,117 +0,0 @@ ---- -description: Understand the interconnect fabric options in a Calico network. ---- - -# Calico over Ethernet fabrics - -Any technology that is capable of transporting IP packets can be used as the interconnect fabric in a $[prodname] network. This means that the standard tools used to transport IP, such as MPLS and Ethernet can be used in a $[prodname] network. - -The focus of this article is on Ethernet as the interconnect network. Most at-scale cloud operators have converted to IP fabrics, and that infrastructure will work for $[prodname] as well. However, the concerns that drove most of those operators to IP as the interconnection network in their pods are largely ameliorated by $[prodname], allowing Ethernet to be viably considered as a $[prodname] interconnect, even in large-scale deployments. - -## Concerns over Ethernet at scale - -It has been acknowledged by the industry for years that, beyond a certain size, classical Ethernet networks are unsuitable for production deployment. Although there have been [multiple](https://en.wikipedia.org/wiki/Provider_Backbone_Bridge_Traffic_Engineering) [attempts](https://web.archive.org/web/20150923231827/https://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_14-3/143_trill.html) [to address](https://en.wikipedia.org/wiki/Virtual_Private_LAN_Service) these issues, the scale-out networking community has largely abandoned Ethernet for anything other than providing physical point-to-point links in the networking fabric. The principle reasons for Ethernet failures at large scale are: - -- Large numbers of _endpoints_ ([note 1](#note-1)) - - Each switch in an Ethernet network must learn the path to all Ethernet endpoints that are connected to the Ethernet network. Learning this amount of state can become a substantial task when we are talking about hundreds of thousands of _endpoints_. - -- High rate of _churn_ or change in the network - - With that many endpoints, most of them being ephemeral (such as virtual machines or containers), there is a large amount of _churn_ in the network. That load of re-learning paths can be a substantial burden on the control plane processor of most Ethernet switches. - -- High volumes of broadcast traffic - - As each node on the Ethernet network must use Broadcast packets to locate peers, and many use broadcast for other purposes, the resultant packet replication to each and every endpoint can lead to _broadcast storms_ in large Ethernet networks, effectively consuming most, if not all resources in the network and the attached endpoints. - -- Spanning tree - - Spanning tree is the protocol used to keep an Ethernet network from forming loops. The protocol was designed in the era of smaller, simpler networks, and it has not aged well. As the number of links and interconnects in an Ethernet network goes up, many implementations of spanning tree become more _fragile_. Unfortunately, when spanning tree fails in an Ethernet network, the effect is a catastrophic loop or partition (or both) in the network, and, in most cases, difficult to troubleshoot or resolve. - -Although many of these issues are crippling at _VM scale_ (tens of thousands of endpoints that live for hours, days, weeks), they will be absolutely lethal at _container scale_ (hundreds of thousands of endpoints that live for seconds, minutes, days). - -If you weren't ready to turn off your Ethernet data center network before this, I bet you are now. Before you do, however, let's look at how $[prodname] can mitigate these issues, even in very large deployments. - -## How does $[prodname] tame the Ethernet daemons? - -First, let's look at how $[prodname] uses an Ethernet interconnect fabric. It's important to remember that an Ethernet network _sees_ nothing on the other side of an attached IP router, the Ethernet network just _sees_ the router itself. This is why Ethernet switches can be used at Internet peering points, where large fractions of Internet traffic is exchanged. The switches only see the routers from the various ISPs, not those ISPs' customers' nodes. We leverage the same effect in $[prodname]. - -To take the issues outlined above, let's revisit them in a $[prodname] -context. - -- Large numbers of endpoints - - In a $[prodname] network, the Ethernet interconnect fabric only sees the routers/compute servers, not the - endpoint. In a standard cloud model, where there is tens of VMs per server (or hundreds of containers), this reduces the number of nodes that the Ethernet sees (and has to learn) by one to two orders - of magnitude. Even in very large pods (say twenty thousand servers), the Ethernet network would still only see a few tens of thousands of endpoints. Well within the scale of any competent data center - Ethernet top of rack (ToR) switch. - -- High rate of churn - - In a classical Ethernet data center fabric, there is a _churn_ event each time an endpoint is created, - destroyed, or moved. In a large data center, with hundreds of thousands of endpoints, this _churn_ could run into tens of events per second, every second of the day, with peaks easily in the hundreds or thousands of events per second. In a $[prodname] network, however, the _churn_ is very low. The only event that would lead to _churn_ - orders of magnitude more than what is normally experienced), there would only be two thousand events per **day**. Any switch that cannot handle that volume of change in the network should not be used - for any application. - -- High volume of broadcast traffic - - Because the first (and last) hop for any traffic in a $[prodname] network is an IP hop, and IP hops terminate - broadcast traffic, there is no endpoint broadcast network in the Ethernet fabric, period. In fact, the only broadcast traffic that should be seen in the Ethernet fabric is the ARPs of the compute servers locating each other. If the traffic pattern is fairly consistent, the steady-state ARP rate should be almost zero. Even in a pathological case, the ARP rate should be well within normal accepted boundaries. - -- Spanning tree - - Depending on the architecture chosen for the Ethernet fabric, it may even be possible to turn off spanning tree. However, even if it is left on, due to the reduction in node count, and reduction in churn, most competent spanning tree implementations should be able to handle the load without stress. - -With these considerations in mind, it should be evident that an Ethernet connection fabric in $[prodname] is not only possible, it is practical and should be seriously considered as the interconnect fabric for a $[prodname] -network. - -As mentioned in the IP fabric post, an IP fabric is also quite feasible for $[prodname], but there are more considerations that must be taken into account. The Ethernet fabric option has fewer architectural considerations in its design. - -## A brief note about Ethernet topology - -As mentioned elsewhere in the $[prodname] documentation, because $[prodname] can use most of the standard IP tooling, some interesting options regarding fabric topology become possible. - -We assume that an Ethernet fabric for $[prodname] would most likely be constructed as a _leaf/spine_ architecture. Other options are possible, but the _leaf/spine_ is the predominant architectural model in use in -scale-out infrastructure today. - -Because $[prodname] is an IP routed fabric, a $[prodname] network can use [ECMP](https://en.wikipedia.org/wiki/Equal-cost_multi-path_routing) to distribute traffic across multiple links (instead of using Ethernet techniques such as MLAG). By leveraging ECMP load balancing on the $[prodname] compute servers, it is possible to build the fabric out of multiple _independent_ leaf/spine planes using no technologies other than IP routing in the $[prodname] nodes, and basic Ethernet switching in the interconnect fabric. These planes would operate completely independently and could be designed such that they would not share a fault domain. This would allow for the catastrophic failure of one (or more) plane(s) of Ethernet interconnect fabric without the loss of the pod (the failure would just decrease the amount of interconnect bandwidth in the pod). This is a gentler failure mode than the pod-wide IP or Ethernet failure that is possible with today's designs. - -You might find this [Facebook blog post](https://engineering.fb.com/2014/11/14/production-engineering/introducing-data-center-fabric-the-next-generation-facebook-data-center-network/) - on their fabric approach interesting. A graphic to visualize the idea is shown below. - -![Ethernet spine planes](/img/calico/l2-spine-planes.png) - -The diagram does not show the endpoints in this diagram, and the endpoints would be unaware of anything in the fabric (as noted above). - -In this diagram, each ToR is segmented into four logical switches (possibly by using 'port VLANs'), ([note 2](#note-2)) and each compute server has a connection to each of those logical switches. We will identify those logical switches by their color. Each ToR would then have a blue, green, orange, and red logical switch. Those 'colors' would be members of a given _plane_, so there would be a blue plane, a green plane, an orange plane, and a red plane. Each plane would have a dedicated spine switch. and each ToR in a given spine would be connected to its spine, and only its spine. - -Each plane would constitute an IP network, so the blue plane would be 2001:db8:1000::/36, the green would be 2001:db8:2000::/36, and the orange and red planes would be 2001:db8:3000::/36 and 2001:db8:4000::/36 respectively ([note 3](#note-3)). - -Each IP network (plane) requires its own BGP route reflectors. Those route reflectors need to be peered with each other within the plane, but the route reflectors in each plane do not need to be peered with one another. Therefore, a fabric of four planes would have four route reflector meshes. Each compute server, border router, _etc._ would need -to be a route reflector client of at least one route reflector in each plane, and very preferably two or more in each plane. - -The following diagram visualizes the route reflector environment. - -![route-reflector](/img/calico/l2-rr-spine-planes.png) - -These route reflectors could be dedicated hardware connected to the spine switches (or the spine switches themselves), or physical or virtual route reflectors connected to the necessary logical leaf switches (blue, green, orange, and red). That may be a route reflector running on a compute server and connected directly to the correct plane link, and not routed through the vRouter, to avoid the chicken and egg problem that would occur if the route reflector were "behind" the $[prodname] network. - -Other physical and logical configurations and counts are, of course, possible, this is just an example. - -The logical configuration would then have each compute server would have an address on each plane's subnet, and announce its endpoints on each subnet. If ECMP is then turned on, the compute servers would distribute the load across all planes. - -If a plane were to fail (say due to a spanning tree failure), then only that one plane would fail. The remaining planes would stay running. - -### Footnotes - -### Note 1 - -In this document (and in all $[prodname] documents) we tend to use the term _endpoint_ to refer to a virtual machine, container, appliance, bare metal server, or any other entity that is connected to a $[prodname] network. If we are referring to a specific type of endpoint, we will call that out (such as referring to the behavior of VMs as distinct from containers). - -### Note 2 - -We are using logical switches in this example. Physical ToRs could also be used, or a mix of the two (say 2 logical switches hosted on each physical switch). - -### Note 3 - -We use IPv6 here purely as an example. IPv4 would be configured similarly. diff --git a/calico_versioned_docs/version-3.29/reference/architecture/design/l3-interconnect-fabric.mdx b/calico_versioned_docs/version-3.29/reference/architecture/design/l3-interconnect-fabric.mdx deleted file mode 100644 index 2707e1f031..0000000000 --- a/calico_versioned_docs/version-3.29/reference/architecture/design/l3-interconnect-fabric.mdx +++ /dev/null @@ -1,282 +0,0 @@ ---- -description: Understand considerations for implementing interconnect fabrics with Calico. ---- - -# Calico over IP fabrics - -$[prodname] provides an end-to-end IP network that interconnects the endpoints ([note 1](#note-1)) in a scale-out or cloud environment. To do that, it needs an _interconnect fabric_ to provide the physical networking layer on which $[prodname] operates ([note 2](#note-2)). - -Although $[prodname] is designed to work with any underlying interconnect fabric that can support IP traffic, the fabric that has the least considerations attached to its implementation is an Ethernet fabric as -discussed in [Calico over Ethernet fabrics](l2-interconnect-fabric.mdx). - -In most cases, the Ethernet fabric is the appropriate choice, but there are infrastructures where L3 (an IP fabric) has already been deployed, or will be deployed, and it makes sense for $[prodname] to operate in those -environments. - -However, because $[prodname] is, itself, a routed infrastructure, there are more engineering, architecture, and operations considerations that have to be weighed when running $[prodname] with an IP routed interconnection -fabric. We will briefly outline those in the rest of this post. That said, $[prodname] operates equally well with Ethernet or IP interconnect fabrics. - -## Background - -### Basic $[prodname] architecture overview - -A description of the $[prodname] architecture can be found in our [architectural overview](../overview.mdx). However, a brief discussion of the routing and data paths is useful for -the discussion. - -In a $[prodname] network, each compute server acts as a router for all of the endpoints that are hosted on that compute server. We call that function a vRouter. The data path is provided by the Linux kernel, the control -plane by a BGP protocol server, and management plane by $[prodname]'s on-server agent, _Felix_. - -Each endpoint can only communicate through its local vRouter, and the first and last _hop_ in any $[prodname] packet flow is an IP router hop through a vRouter. Each vRouter announces all of the endpoints it is attached to all the other vRouters and other routers on the infrastructure fabric, using BGP, usually with BGP route reflectors to -increase scale. A discussion of why we use BGP can be found in [Why BGP?](https://www.tigera.io/blog/why-bgp/). - -Access control lists (ACLs) enforce security (and other) policy as directed by whatever cloud orchestrator is in use. There are other components in the $[prodname] architecture, but they are irrelevant to the interconnect network fabric discussion. - -### Overview of current common IP scale-out fabric architectures - -There are two approaches to building an IP fabric for a scale-out infrastructure. However, all of them, to date, have assumed that the edge router in the infrastructure is the top of rack (TOR) switch. In the $[prodname] model, that function is pushed to the compute server itself. - -The two approaches are: - -**Routing infrastructure is based on some form of IGP** - -Due to the limitations in scale of IGP networks, the $[prodname] team does not believe that using an IGP to distribute endpoint reachability information will adequately scale in a $[prodname] environment. However, it is possible to use a combination of IGP and BGP in the interconnect fabric, where an IGP communicates the path to the _next-hop_ router (in $[prodname], this is often the destination compute server) and BGP is used to distribute the actual next-hop for a given endpoint. This is a valid model, and, in fact is the most common approach in a widely distributed IP network (say a carrier's backbone network). The design of these networks is somewhat complex though, and will not be addressed further in this article. ([note 3](#note-3)). - -**Routing infrastructure is based entirely on BGP** - -In this model, the IP network is "tight enough" or has a small enough diameter that BGP can be used to distribute endpoint routes, and the paths to the next-hops for those routes is known to all of the routers in the network (in a $[prodname] network this includes the compute servers). This is the network model that this note will address. - -In this article, we will cover the second option because it is more common in the scale-out world. - -### BGP-only interconnect fabrics - -There are multiple methods to build a BGP-only interconnect fabric. We will focus on three models, each with two widely viable variations. There are other options, and we will briefly touch on why we didn't include some of them in [Other Options](#other-options). - -The two methods are: - -- A BGP fabric where each of the TOR switches (and their subsidiary compute servers) are a unique [Autonomous System (AS)]() - and they are interconnected via either an Ethernet switching plane provided by the spine switches in a [leaf/spine](http://bradhedlund.com/2012/10/24/video-a-basic-introduction-to-the-leafspine-data-center-networking-fabric-design/) architecture, or via a set of spine switches, each of which is also a unique AS. We'll refer to this as the _AS per rack_ model. This model is detailed in [IETF RFC 7938](https://datatracker.ietf.org/doc/html/rfc7938). - -- A BGP fabric where each of the compute servers is a unique AS, and the TOR switches make up a transit AS. We'll refer to this as the _AS per server_ model. - -Each of these models can either have an Ethernet or IP spine. In the case of an Ethernet spine, each spine switch provides an isolated Ethernet connection _plane_ as in the $[prodname] Ethernet interconnect fabric model and each TOR switch is connected to each spine switch. - -Another model is where each spine switch is a unique AS, and each TOR switch BGP peers with each spine switch. In both cases, the TOR switches use ECMP to load-balance traffic between all available spine switches. - -### BGP network design considerations - -Contrary to popular opinion, BGP is actually a fairly simple protocol. For example, the BGP configuration on a $[prodname] compute server is approximately sixty lines long, not counting comments. The perceived complexity is due to the things that you can _do_ with BGP. Many uses of BGP involve complex policy rules, where the behavior of BGP can be modified to meet technical (or business, financial, political, etc.) requirements. A default $[prodname] network does not venture into those areas, ([note 4](#note-4)) and therefore is fairly straight forward. - -That said, there are a few design rules for BGP that need to be kept in mind when designing an IP fabric that will interconnect nodes in a $[prodname] network. These BGP design requirements _can_ be worked around, if necessary, but doing so takes the designer out of the standard BGP _envelope_ and should only be done by an implementer who is _very_ comfortable with advanced BGP design. - -These considerations are: - -- AS continuity or _AS puddling_ - - Any router in an AS _must_ be able to communicate with any other router in that same AS without transiting another AS. - -- Next hop behavior - - By default BGP routers do not change the _next hop_ of a route if it is peering with another router in its same AS. The inverse is also true, a BGP router will set itself as the _next hop_ of a route if it is peering with a router in another AS. - -- Route reflection - - All BGP routers in a given AS must _peer_ with all the other routers in that AS. This is referred to a _complete BGP mesh_. This can become problematic as the number of routers in the AS scales up. The use of _route reflectors_ reduce the need for the complete BGP mesh. However, route reflectors also have scaling considerations. - -- Endpoints - - In a $[prodname] network, each endpoint is a route. Hardware networking platforms are constrained by the number of routes they can learn. This is usually in range of 10,000's or 100,000's of routes. Route aggregation can help, but that is usually dependent on the capabilities of the scheduler used by the orchestration software (_e.g._ OpenStack). - -A deeper discussion of these considerations can be found in the [IP Fabric Design Considerations](#ip-fabric-design-considerations). - -The designs discussed below address these considerations. - -### The AS Per Rack model - -This model is the closest to the model suggested by [IETF RFC 7938](https://datatracker.ietf.org/doc/html/rfc7938). - -As mentioned earlier, there are two versions of this model, one with an set of Ethernet planes interconnecting the ToR switches, and the other where the core planes are also routers. The following diagrams may be useful for the discussion. - -![Diagram showing the AS per rack model with ToR switches meshed via Ethernet switching planes at the spine layer](/img/calico/l3-fabric-diagrams-as-rack-l2-spine.png) - -The diagram above shows the **AS per rack model** where the ToR switches are physically meshed via a set of Ethernet switching planes. - -![Diagram showing the AS per rack model with ToR switches meshed via discrete BGP spine routers, each in their own AS](/img/calico/l3-fabric-diagrams-as-rack-l3-spine.png) - -The diagram above shows the **AS per rack model** where the ToR switches are physically meshed via a set of discrete BGP spine routers, each in their own AS. - -In this approach, every ToR-ToR or ToR-Spine (in the case of an AS per spine) link is an eBGP peering which means that there is no route-reflection possible (using standard BGP route reflectors) _north_ of the ToR switches. - -If the L2 spine option is used, the result of this is that each ToR must either peer with every other ToR switch in the cluster (which could be hundreds of peers). - -If the AS per spine option is used, then each ToR only has to peer with each spine (there are usually somewhere between two and sixteen spine switches in a pod). However, the spine switches must peer with all ToR -switches (again, that would be hundreds, but most spine switches have more control plane capacity than the average ToR, so this might be more scalable in many circumstances). - -Within the rack, the configuration is the same for both variants, and is somewhat different than the configuration north of the ToR. - -Every router within the rack, which, in the case of $[prodname] is every compute server, shares the same AS as the ToR that they are connected to. That connection is in the form of an Ethernet switching layer. Each router in the rack must be directly connected to enable the AS to remain contiguous. The ToR's _router_ function is then connected to that Ethernet switching layer as well. The actual configuration of this is dependent on the ToR in use, but usually it means that the ports that are connected to the compute servers are treated as _subnet_ or _segment_ ports, and then the ToR's _router_ function has a single interface into that subnet. - -This configuration allows each compute server to connect to each other compute server in the rack without going through the ToR router, but it will, of course, go through the ToR switching function. The compute servers and the ToR router could all be directly meshed, or a route reflector could be used within the rack, either hosted on the ToR -itself, or as a virtual function hosted on one or more compute servers within the rack. - -The ToR, as the eBGP router redistributes all of the routes from other ToRs as well as routes external to the data center to the compute servers that are in its AS, and announces all of the routes from within -the AS (rack) to the other ToRs and the larger world. This means that each compute server will see the ToR as the next hop for all external routes, and the individual compute servers are the next hop for all routes internal to the rack. - -### The AS per Compute Server model - -This model takes the concept of an AS per rack to its logical conclusion. In the earlier referenced [IETF RFC 7938](https://datatracker.ietf.org/doc/html/rfc7938) the assumption in the overall model is that the ToR is first tier aggregating and routing element. In $[prodname], the ToR, if it is an L3 router, is actually the second tier. Remember, in $[prodname], the compute server is always the first/last router for an endpoint, and is also the first/last point of aggregation. - -Therefore, if we follow the architecture of the draft, the compute server, not the ToR should be the AS boundary. The differences can be seen in the following two diagrams. - -![Diagram showing the AS per compute server model with ToR switches meshed via Ethernet switching planes at the spine layer](/img/calico/l3-fabric-diagrams-as-server-l2-spine.png) - -The diagram above shows the _AS per compute server model_ where the ToR -switches are physically meshed via a set of Ethernet switching planes. - -![Diagram showing the AS per compute server model with ToR switches connected to independent routing planes at the spine layer](/img/calico/l3-fabric-diagrams-as-server-l3-spine.png) - -The diagram above shows the _AS per compute server model_ where the ToR switches are physically connected to a set of independent routing planes. - -As can be seen in these diagrams, there are still the same two variants as in the _AS per rack_ model, one where the spine switches provide a set of independent Ethernet planes to interconnect the ToR switches, and the other where that is done by a set of independent routers. - -The real difference in this model, is that the compute servers as well as the ToR switches are all independent autonomous systems. To make this work at scale, the use of four byte AS numbers as discussed in [RFC 4893](http://www.faqs.org/rfcs/rfc4893.html). Without -using four byte AS numbering, the total number of ToRs and compute servers in a $[prodname] fabric would be limited to the approximately five thousand available private AS ([note 5](#note-5)) numbers. If four byte AS numbers are used, there are approximately ninety-two million private AS numbers available. This should be sufficient for any given $[prodname] fabric. - -The other difference in this model _vs._ the AS per rack model, is that there are no route reflectors used, as all BGP peerings are eBGP. In this case, each compute server in a given rack peers with its ToR switch which is also acting as an eBGP router. For two servers within the same rack to communicate, they will be routed through the ToR. Therefore, each server will have one peering to each ToR it is connected to, and each ToR will have a peering with each compute server that it is connected to (normally, all the compute servers in the rack). - -The inter-ToR connectivity considerations are the same in scale and scope as in the AS per rack model. - -### The Downward Default model - -The final model is a bit different. Whereas, in the previous models, all of the routers in the infrastructure carry full routing tables, and leave their AS paths intact, this model ([note 6](#note-6)) removes the AS numbers at -each stage of the routing path. This is to prevent routes from other nodes in the network from not being installed due to it coming from the _local_ AS (since they share the source and dest of the route share the same AS). - -The following diagram will show the AS relationships in this model. - -![Diagram showing the downward default model where all Calico nodes share one AS and all ToR switches share another, with spine routers announcing default routes downward](/img/calico/l3-fabric-downward-default.png) - -In the diagram above, we are showing that all $[prodname] nodes share the same AS number, as do all ToR switches. However, those ASs are different (_A1_ is not the same network as _A2_, even though the both share the -same AS number _A_ ). - -Although the use of a single AS for all ToR switches, and another for all compute servers simplifies deployment (standardized configuration), the real benefit comes in the offloading of the routing tables in the ToR -switches. - -In this model, each router announces all of its routes to its upstream peer (the $[prodname] routers to their ToR, the ToRs to the spine switches). However, in return, the upstream router only announces a default route. -In this case, a given $[prodname] router only has routes for the endpoints that are locally hosted on it, as well as the default from the ToR. Because the ToR is the only route for the $[prodname] network the rest of the -network, this matches reality. The same happens between the ToR switches and the spine. This means that the ToR only has to install the routes that are for endpoints that are hosted on its downstream $[prodname] nodes. -Even if we were to host 200 endpoints per $[prodname] node, and stuff 80 $[prodname] nodes in each rack, that would still limit the routing table on the ToR to a maximum of 16,000 entries (well within the capabilities of -even the most modest of switches). - -Because the default is originated by the Spine (originally) there is no chance for a downward announced route to originate from the recipient's AS, preventing the **AS puddling** problem. - -There is one (minor) drawback to this model, in that all traffic that is destined for an invalid destination (the destination IP does not exist) will be forwarded to the spine switches before they are dropped. - -It should also be noted that the spine switches do need to carry all of the $[prodname] network routes, just as they do in the routed spines in the previous examples. In short, this model imposes no more load on the -spines than they already would have, and substantially reduces the amount of routing table space used on the ToR switches. It also reduces the number of routes in the $[prodname] nodes, but, as we have discussed -before, that is not a concern in most deployments as the amount of memory consumed by a full routing table in $[prodname] is a fraction of the total memory available on a modern compute server. - -## Recommendation - -The $[prodname] team recommends the use of the [AS per rack](#the-as-per-rack-model) model if the resultant routing table size can be accommodated by the ToR and spine switches, remembering to account for projected growth. - -If there is concern about the route table size in the ToR switches, the $[prodname] recommends the [Downward Default](#the-downward-default-model) model. - -If there are concerns about both the spine and ToR switch route table capacity, or there is a desire to run a very simple L2 fabric to connect the $[prodname] nodes, then the user should consider the Ethernet fabric as -detailed in [Calico over Ethernet fabrics](l2-interconnect-fabric.mdx). - -If you are interested in the AS per compute server, the $[prodname] team would be very interested in discussing the deployment of that model. - -## Other options - -The way the physical and logical connectivity is laid out in this article, and the [Ethernet fabric](l2-interconnect-fabric.mdx), the next hop router for a given route is always directly connected to the router receiving that route. This makes the need for another protocol to distribute the next hop routes unnecessary. - -However, in many (or most) WAN BGP networks, the routers within a given AS may not be directly adjacent. Therefore, a router may receive a route with a next hop address that it is not directly adjacent to. In those cases, an IGP, such as OSPF or IS-IS, is used by the routers within a given AS to determine the path to the BGP next hop route. - -There may be $[prodname] architectures where there are similar models where the routers within a given AS are not directly adjacent. In those models, the use of an IGP in $[prodname] may be warranted. The configuration -of those protocols are, however, beyond the scope of this technical -note. - -### IP fabric design considerations - -**AS puddling** - -The first consideration is that an AS must be kept contiguous. This means that any two nodes in a given AS must be able to communicate without traversing any other AS. If this rule is not observed, the effect is often referred to as _AS puddling_ and the network will _not_ function correctly. - -A corollary of that rule is that any two administrative regions that share the same AS number, are in the same AS, even if that was not the desire of the designer. BGP has no way of identifying if an AS is local or foreign other than the AS number. Therefore re-use of an AS number for two _networks_ that are not directly connected, but only connected -through another _network_ or AS number will not work without a lot of policy changes to the BGP routers. - -Another corollary of that rule is that a BGP router will not propagate a route to a peer if the route has an AS in its path that is the same AS as the peer. This prevents loops from forming in the network. The effect of this prevents two routers in the same AS from transiting another router (either in that AS or not). - -**Next hop behavior** - -Another consideration is based on the differences between iBGP and eBGP. BGP operates in two modes, if two routers are BGP peers, but share the same AS number, then they are considered to be in an _internal_ BGP (or iBGP) peering relationship. If they are members of different AS's, then they are in an _external_ or eBGP relationship. - -BGP's original design model was that all BGP routers within a given AS would know how to get to one another (via static routes, IGP ([note 7](#note-7)) routing protocols, or the like), and that routers in different ASs would -not know how to reach one another unless they were directly connected. - -Based on that design point, routers in an iBGP peering relationship assume that they do not transit traffic for other iBGP routers in a given AS (i.e. A can communicate with C, and therefore will not need to route through B), and therefore, do not change the _next hop_ attribute in BGP ([note 8](#note-8)). - -A router with an eBGP peering, on the other hand, assumes that its eBGP peer will not know how to reach the next hop route, and then will substitute its own address in the next hop field. This is often referred -to as _next hop self_. - -In the $[prodname] [Ethernet fabric](l2-interconnect-fabric.mdx) -model, all of the compute servers (the routers in a $[prodname] network) are directly connected over one or more Ethernet network(s) and therefore are directly reachable. In this case, a router in the $[prodname] network -does not need to set _next hop self_ within the $[prodname] fabric. - -The models we present in this article ensure that all routes that may traverse a non-$[prodname] router are eBGP routes, and therefore _next hop self_ is automatically set correctly. If a deployment of $[prodname] in -an IP interconnect fabric does not satisfy that constraint, then _next hop self_ must be appropriately configured. - -**Route reflection** - -As mentioned above, BGP expects that all of the iBGP routers in a network can see (and speak) directly to one another, this is referred to as a _BGP full mesh_. In small networks this is not a problem, but it does become interesting as the number of routers increases. For example, if you have 99 BGP routers in an AS and wish to add one more, you would -have to configure the peering to that new router on each of the 99 existing routers. Not only is this a problem at configuration time, it means that each router is maintaining 100 protocol adjacencies, which can start being a drain on constrained resources in a router. While this might be _interesting_ at 100 routers, it becomes an impossible task -with 1000's or 10,000's of routers (the potential size of a $[prodname] network). - -Conveniently, large scale/Internet scale networks solved this problem almost 20 years ago by deploying BGP route reflection as described in [RFC 1966](http://www.faqs.org/rfcs/rfc1966.html). This is a technique supported by almost all BGP routers today. In a large network, a number of route reflectors ([note 9](#note-9)) are evenly distributed and each iBGProuter is _peered_ with one or more route reflectors (usually 2 or 3). Each route reflector can handle 10's or 100's of route reflector clients (in $[prodname]'s case, the compute server), depending on the route reflector being used. Those route reflectors are, in turn, peered with each other. This means that there are an order of magnitude less route reflectors that need to be completely meshed, and each route reflector client is only configured to peer to 2 or 3 route reflectors. This is much easier to manage. - -Other route reflector architectures are possible, but those are beyond the scope of this document. - -**Endpoints** - -The final consideration is the number of endpoints in a $[prodname] network. In the [Ethernet fabric](l2-interconnect-fabric.mdx) case the number of endpoints is not constrained by the interconnect fabric, as the interconnect fabric does not _see_ the actual endpoints, it only _sees_ the actual vRouters, or compute servers. This is not the case in an IP fabric, however. IP networks forward by using the -destination IP address in the packet, which, in $[prodname]'s case, is the destination endpoint. That means that the IP fabric nodes (ToR switches and/or spine switches, for example) must know the routes to each endpoint in the network. They learn this by participating as route reflector clients in the BGP mesh, just as the $[prodname] vRouter/compute server does. - -However, unlike a compute server which has a relatively unconstrained amount of memory, a physical switch is either memory constrained, or quite expensive. This means that the physical switch has a limit on how many _routes_ it can handle. The current industry standard for modern commodity switches is in the range of 128,000 routes. This means that, -without other routing _tricks_, such as aggregation, a $[prodname] installation that uses an IP fabric will be limited to the routing table size of its constituent network hardware, with a reasonable upper limit -today of 128,000 endpoints. - -### Footnotes - -### Note 1 - -In $[prodname]'s terminology, an endpoint is an IP address and interface. It could refer to a VM, a container, or even a process bound to an IP address running on a bare metal server. - -### Note 2 - -This interconnect fabric provides the connectivity between the $[prodname] (v)Router (in almost all cases, the compute servers) nodes, as well as any other elements in the fabric (_e.g._ bare metal servers, border routers, and appliances). - -### Note 3 - -If there is interest in a discussion of this approach, please let us know. The $[prodname] team could either arrange a discussion, or if there was enough interest, publish a follow-up tech note. - -### Note 4 - -However those tools are available if a given $[prodname] instance needs to utilize those policy constructs. - -### Note 5 - -The two byte AS space reserves approximately the last five thousand AS numbers for private use. There is no technical reason why other AS numbers could not be used. However the re-use of global scope AS numbers within a private infrastructure is strongly discouraged. The chance for routing system failure or incorrect routing is substantial, and not restricted to the entity that is doing the reuse. - -### Note 6 - -We first saw this design in a customer's lab, and thought it innovative enough to share (we asked them first, of course). Similar **AS Path Stripping** approaches are used in ISP networks, however. - -### Note 7 - -An Interior Gateway Protocol is a local routing protocol that does not cross an AS boundary. The primary IGPs in use today are OSPF and IS-IS. While complex iBGP networks still use IGP routing protocols, a data center is normally a fairly simple network, even if it has many routers in it. Therefore, in the data center case, the use of an IGP can often be disposed of. - -### Note 8 - -A Next hop is an attribute of a route announced by a routing protocol. In simple terms a route is defined by a _target_, or the destination that is to be reached, and a _next hop_, which is the next router in the path to reach that target. There are many other characteristics in a route, but those are well beyond the scope of this post. - -### Note 9 - -A route reflector may be a physical router, a software appliance, or simply a BGP daemon. It only processes routing messages, and does not pass actual data plane traffic. However, some route reflectors are co-resident on regular routers that do pass data plane traffic. Although they may sit on one platform, the functions are distinct. diff --git a/calico_versioned_docs/version-3.29/reference/architecture/index.mdx b/calico_versioned_docs/version-3.29/reference/architecture/index.mdx deleted file mode 100644 index 7d3a0a9862..0000000000 --- a/calico_versioned_docs/version-3.29/reference/architecture/index.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: Understand Calico components, network design, and the data path between workloads. -hide_table_of_contents: true ---- - -# Architecture - -import DocCardList from '@theme/DocCardList'; -import { useCurrentSidebarCategory } from '@docusaurus/theme-common'; - - diff --git a/calico_versioned_docs/version-3.29/reference/architecture/overview.mdx b/calico_versioned_docs/version-3.29/reference/architecture/overview.mdx deleted file mode 100644 index 7d9a8c7463..0000000000 --- a/calico_versioned_docs/version-3.29/reference/architecture/overview.mdx +++ /dev/null @@ -1,155 +0,0 @@ ---- -description: Learn the basic Calico components. ---- - -# Component architecture - -## $[prodname] components - -The following diagram shows the required and optional $[prodname] components for a Kubernetes, on-premises deployment with networking and network policy. - -![calico-components](/img/calico/architecture-calico.svg) - -**$[prodname] components** - -- [Calico API server](#calico-api-server) -- [Felix](#felix) -- [BIRD](#bird) -- [confd](#confd) -- [Dikastes](#dikastes) -- [CNI plugin](#cni-plugin) -- [Datastore plugin](#datastore-plugin) -- [IPAM plugin](#ipam-plugin) -- [kube-controllers](#kube-controllers) -- [Typha](#typha) -- [calicoctl](#calicoctl) - -**Cloud orchestrator plugins** - -- [Plugins for cloud orchestrators](#plugins-for-cloud-orchestrators) - -## Calico API server - -**Main task**: Lets you manage $[prodname] resources directly with `kubectl`. - -## Felix - -**Main task**: Programs routes and ACLs, and anything else required on the host to provide desired connectivity for the endpoints on that host. Runs on each machine that hosts endpoints. Runs as an agent daemon. [Felix resource](../resources/felixconfig.mdx). - -Depending on the specific orchestrator environment, Felix is responsible for: - -- **Interface management** - - Programs information about interfaces into the kernel so the kernel can correctly handle the traffic from that endpoint. In particular, it ensures that the host responds to ARP requests from each workload with the MAC of the host, and enables IP forwarding for interfaces that it manages. It also monitors interfaces to ensure that the programming is applied at the appropriate time. - -- **Route programming** - - Programs routes to the endpoints on its host into the Linux kernel FIB (Forwarding Information Base). This ensures that packets destined for those endpoints that arrive on at the host are forwarded accordingly. - -- **ACL programming** - - Programs ACLs into the Linux kernel to ensure that only valid traffic can be sent between endpoints, and that endpoints cannot circumvent $[prodname] security measures. - -- **State reporting** - - Provides network health data. In particular, it reports errors and problems when configuring its host. This data is written to the datastore so it visible to other components and operators of the network. - -:::note - -`$[nodecontainer]` can be run in _policy only mode_ where Felix runs without BIRD and confd. This provides policy management without route distribution between hosts, and is used for deployments like managed cloud providers. You enable this mode by setting the environment variable, `CALICO_NETWORKING_BACKEND=none` before starting the node. - -::: - -## BIRD - -**Main task**: Gets routes from Felix and distributes to BGP peers on the network for inter-host routing. Runs on each node that hosts a Felix agent. Open source, internet routing daemon. [BIRD](../configure-calico-node.mdx). - -The BGP client is responsible for: - -- **Route distribution** - - When Felix inserts routes into the Linux kernel FIB, the BGP client distributes them to other nodes in the deployment. This ensures efficient traffic routing for the deployment. - -- **BGP route reflector configuration** - - BGP route reflectors are often configured for large deployments rather than a standard BGP client. BGP route reflectors acts as a central point for connecting BGP clients. (Standard BGP requires that every BGP client be connected to every other BGP client in a mesh topology, which is difficult to maintain.) - - For redundancy, you can seamlessly deploy multiple BGP route reflectors. BGP route reflectors are involved only in control of the network: no endpoint data passes through them. When the $[prodname] BGP client advertises routes from its FIB to the route reflector, the route reflector advertises those routes out to the other nodes in the deployment. - -## confd - -**Main task**: Monitors $[prodname] datastore for changes to BGP configuration and global defaults such as AS number, logging levels, and IPAM information. Open source, lightweight configuration management tool. - -Confd dynamically generates BIRD configuration files based on the updates to data in the datastore. When the configuration file changes, confd triggers BIRD to load the new files. [Configure confd](../configure-calico-node.mdx), and [confd project](https://github.com/kelseyhightower/confd). - -## Dikastes - -**Main task**: Enforces network policy for Istio service mesh. Runs on a cluster as a sidecar proxy to Istio Envoy. - -(Optional) $[prodname] enforces network policy for workloads at both the Linux kernel (using iptables, L3-L4), and at L3-L7 using a Envoy sidecar proxy called Dikastes, with cryptographic authentication of requests. Using multiple enforcement points establishes the identity of the remote endpoint based on multiple criteria. The host Linux kernel enforcement protects your workloads even if the workload pod is compromised, and the Envoy proxy is bypassed. - -:::note - -Dikastes can be terminated by issuing an HTTP POST request to /terminate on the socket address specified using environment variables `DIKASTES_HTTP_BIND_ADDR` and `DIKASTES_HTTP_BIND_PORT`. This is to allow for graceful termination so that Kubernetes Jobs can complete successfully and is analogous to Envoy's /quitquitquit. eg. `curl -XPOST http://127.0.0.1:7777/terminate` - -::: - -## CNI plugin - -**Main task**: Provides $[prodname] networking for Kubernetes clusters. - -The $[prodname] binary that presents this API to Kubernetes is called the CNI plugin, and must be installed on every node in the Kubernetes cluster. The $[prodname] CNI plugin allows you to use $[prodname] networking for any orchestrator that makes use of the CNI networking specification. Configured through the standard [CNI configuration mechanism](https://github.com/containernetworking/cni/blob/master/SPEC.md#network-configuration), and [$[prodname] CNI plugin](../configure-cni-plugins.mdx). - -## Datastore plugin - -**Main task**: Increases scale by reducing each node’s impact on the datastore. It is one of the $[prodname] [CNI plugins](../configure-cni-plugins.mdx). - -- **Kubernetes API datastore (kdd)** - - The advantages of using the Kubernetes API datastore (kdd) with $[prodname] are: - - - Simpler to manage because it does not require an extra datastore - - Use Kubernetes RBAC to control access to $[prodname] resources - - Use Kubernetes audit logging to generate audit logs of changes to $[prodname] resources - -- **etcd** - - `etcd` is a consistent, highly-available distributed key-value store that provides data storage for the $[prodname] network, and for communications between components. `etcd` is supported for protecting only non-cluster hosts (as of $[prodname] v3.1). For completeness, `etcd ` advantages are: - - - Lets you run $[prodname] on non-Kubernetes platforms - - Separation of concerns between Kubernetes and $[prodname] resources, for example allowing you to scale the datastores independently - - Lets you run a $[prodname] cluster that contains more than just a single Kubernetes cluster, for example, bare metal servers with $[prodname] host protection interworking with a Kubernetes cluster; or multiple Kubernetes clusters. - - [etcd admin guide](https://coreos.com/etcd/docs/latest/admin_guide.html#optimal-cluster-size) - -## IPAM plugin - -**Main task**: Uses $[prodname]’s IP pool resource to control how IP addresses are allocated to pods within the cluster. It is the default plugin used by most $[prodname] installations. It is one of the $[prodname] [CNI plugins](../configure-cni-plugins.mdx). - -## kube-controllers - -**Main task**: Monitors the Kubernetes API and performs actions based on cluster state. [kube-controllers](../kube-controllers/configuration.mdx). - -The `tigera/kube-controllers` container includes the following controllers: - -- Policy controller -- Namespace controller -- Serviceaccount controller -- Workloadendpoint controller -- Node controller - -## Typha - -**Main task**: Increases scale by reducing each node’s impact on the datastore. Runs as a daemon between the datastore and instances of Felix. Installed by default, but not configured. [Typha description](https://github.com/projectcalico/calico/tree/master/typha), and [Typha component](../typha/index.mdx). - -Typha maintains a single datastore connection on behalf of all of its clients like Felix and confd. It caches the datastore state and deduplicates events so that they can be fanned out to many listeners. Because one Typha instance can support hundreds of Felix instances, it reduces the load on the datastore by a large factor. And because Typha can filter out updates that are not relevant to Felix, it also reduces Felix’s CPU usage. In a high-scale Kubernetes cluster, this is essential because the number of updates generated by the API server scales with the number of nodes. - -## calicoctl - -**Main task**: Command line interface to create, read, update, and delete $[prodname] objects. `calicoctl` command line is available on any host with network access to the $[prodname] datastore as either a binary or a container. Requires separate installation. [calicoctl](../calicoctl/index.mdx). - -## Plugins for cloud orchestrators - -**Main task**: Translates the orchestrator APIs for managing networks to the $[prodname] data-model and datastore. - -For cloud providers, $[prodname] has a separate plugin for each major cloud orchestration platform. This allows $[prodname] to tightly bind to the orchestrator, so users can manage the $[prodname] network using their orchestrator tools. When required, the orchestrator plugin provides feedback from the $[prodname] network to the orchestrator. For example, providing information about Felix liveness, and marking specific endpoints as failed if network setup fails. diff --git a/calico_versioned_docs/version-3.29/reference/calicoctl/apply.mdx b/calico_versioned_docs/version-3.29/reference/calicoctl/apply.mdx deleted file mode 100644 index 3748833094..0000000000 --- a/calico_versioned_docs/version-3.29/reference/calicoctl/apply.mdx +++ /dev/null @@ -1,147 +0,0 @@ ---- -description: Command to apply a policy. ---- - -# calicoctl apply - -This sections describes the `calicoctl apply` command. - -Read the [calicoctl command line interface user reference](overview.mdx) -for a full list of calicoctl commands. - -:::note - -The available actions for a specific resource type may be -limited based on the datastore used for $[prodname] (etcdv3 / Kubernetes API). -Please refer to the -[Resources section](../resources/overview.mdx) -for details about each resource type. - -::: - -## Displaying the help text for 'calicoctl apply' command - -Run `calicoctl apply --help` to display the following help menu for the -command. - -``` -Usage: - calicoctl apply --filename= [--recursive] [--skip-empty] [--config=] [--namespace=] - -Examples: - # Apply a policy using the data in policy.yaml. - calicoctl apply -f ./policy.yaml - - # Apply a policy based on the JSON passed into stdin. - cat policy.json | calicoctl apply -f - - -Options: - -h --help Show this screen. - -f --filename= Filename to use to apply the resource. If set to - "-" loads from stdin. If filename is a directory, this command is - invoked for each .json .yaml and .yml file within that directory, - terminating after the first failure. - -R --recursive Process the filename specified in -f or --filename recursively. - --skip-empty Do not error if any files or directory specified using -f or --filename contain no - data. - -c --config= Path to the file containing connection - configuration in YAML or JSON format. - [default: /etc/calico/calicoctl.cfg] - -n --namespace= Namespace of the resource. - Only applicable to NetworkPolicy and WorkloadEndpoint. - Only applicable to NetworkPolicy, NetworkSet, and WorkloadEndpoint. - Uses the default namespace if not specified. - --context= The name of the kubeconfig context to use. - -Description: - The apply command is used to create or replace a set of resources by filename - or stdin. JSON and YAML formats are accepted. - - Valid resource types are: - - - bgpconfiguration - - bgpfilter - - bgppeer - - clusterinformation - - felixconfiguration - - globalnetworkpolicy - - globalnetworkset - - hostendpoint - - ippool - - ipreservation - - kubecontrollersconfiguration - - networkpolicy - - networkset - - node - - profile - - tier - - workloadendpoint - - When applying a resource: - - if the resource does not already exist (as determined by it's primary - identifiers) then it is created - - if the resource already exists then the specification for that resource is - replaced in it's entirety by the new resource specification. - - The output of the command indicates how many resources were successfully - applied, and the error reason if an error occurred. - - The resources are applied in the order they are specified. In the event of a - failure applying a specific resource it is possible to work out which - resource failed based on the number of resources successfully applied - - When applying a resource to perform an update, the complete resource spec - must be provided, it is not sufficient to supply only the fields that are - being updated. -``` - -### Examples - -1. Apply a set of resources (of mixed type) using the data in resources.yaml. - - ```bash - calicoctl apply -f ./resources.yaml - ``` - - Results indicate that 8 resources were successfully applied - - ``` - Successfully applied 8 resource(s) - ``` - -1. Apply two policy resources based on the JSON passed into stdin. - - ```bash - cat policy.json | calicoctl apply -f - - ``` - - Results indicate success. - - ``` - Successfully applied 2 'policy' resource(s) - ``` - -### Options - -``` --f --filename= Filename to use to apply the resource. If set to - "-" loads from stdin. --n --namespace= Namespace of the resource. - Only applicable to NetworkPolicy and WorkloadEndpoint. - Uses the default namespace if not specified. -``` - -### General options - -``` --c --config= Path to the file containing connection - configuration in YAML or JSON format. - [default: /etc/calico/calicoctl.cfg] -``` - -## See also - -- [Installing calicoctl](../../operations/calicoctl/install.mdx) -- [Resources](../resources/overview.mdx) for details on all valid resources, including file format - and schema -- [NetworkPolicy](../resources/networkpolicy.mdx) for details on the $[prodname] selector-based policy model diff --git a/calico_versioned_docs/version-3.29/reference/calicoctl/convert.mdx b/calico_versioned_docs/version-3.29/reference/calicoctl/convert.mdx deleted file mode 100644 index 4379db62c2..0000000000 --- a/calico_versioned_docs/version-3.29/reference/calicoctl/convert.mdx +++ /dev/null @@ -1,96 +0,0 @@ ---- -description: Command to convert contents of policy.yaml to v3 policy. ---- - -# calicoctl convert - -This sections describes the `calicoctl convert` command. - -Read the [calicoctl command line interface user reference](overview.mdx) -for a full list of calicoctl commands. - -:::note - -The available actions for a specific resource type may be -limited based on the datastore used for $[prodname] (etcdv3 / Kubernetes API). -Please refer to the -[Resources section](../resources/overview.mdx) -for details about each resource type. - -::: - -## Displaying the help text for 'calicoctl convert' command - -Run `calicoctl convert --help` to display the following help menu for the -command. - -``` -Usage: - calicoctl convert --filename= - [--output=] [--ignore-validation] - -Examples: - # Convert the contents of policy.yaml to a Calico v3 policy. - calicoctl convert -f ./policy.yaml -o yaml - - # Convert a policy based on the JSON passed into stdin. - cat policy.json | calicoctl convert -f - - -Options: - -h --help Show this screen. - -f --filename= Filename to use to create the resource. If set to - "-" loads from stdin. - -o --output= Output format. One of: yaml or json. - [Default: yaml] - --ignore-validation Skip validation on the converted manifest. - -Description: - Convert config files from Calico v1 or Kubernetes to Calico v3 API versions. Both YAML and JSON formats are accepted. - - The default output will be printed to stdout in YAML format. -``` - -:::note - -Currently the only Kubernetes API resource supported for conversion is NetworkPolicy. - -::: - -### Examples - -1. Convert a set of resources (of mixed type) from Calico v1 or Kubernetes to Calico v3 APIs using the data in resources.yaml. - - ```bash - calicoctl convert -f multi-resource-v1.yaml -o yaml > multi-resource-v3.yaml - ``` - - :::tip - - By default convert command outputs the converted resources to stdout, but it can be redirected to a file. - - ::: - -1. Convert a policy based on the JSON passed into stdin. - - ```bash - cat policy.json | calicoctl convert -f - - ``` - - Result will be printed to stdout. - -### Options - -``` --f --filename= Filename to use to convert the resource. If set to - "-" loads from stdin. --o --output= Output format. One of: yaml or json. - [Default: yaml] ---ignore-validation Skip validation on the converted manifest. -``` - -## See also - -- [Installing calicoctl](../../operations/calicoctl/install.mdx) -- [Resources](../resources/overview.mdx) for details on all valid resources, including file format - and schema -- [calicoctl get](get.mdx) for details on `calicoctl get` command to get the resources. diff --git a/calico_versioned_docs/version-3.29/reference/calicoctl/create.mdx b/calico_versioned_docs/version-3.29/reference/calicoctl/create.mdx deleted file mode 100644 index faa3761270..0000000000 --- a/calico_versioned_docs/version-3.29/reference/calicoctl/create.mdx +++ /dev/null @@ -1,146 +0,0 @@ ---- -description: Command to create a policy. ---- - -# calicoctl create - -This sections describes the `calicoctl create` command. - -Read the [calicoctl command line interface user reference](overview.mdx) -for a full list of calicoctl commands. - -:::note - -The available actions for a specific resource type may be -limited based on the datastore used for $[prodname] (etcdv3 / Kubernetes API). -Please refer to the -[Resources section](../resources/overview.mdx) -for details about each resource type. - -::: - -## Displaying the help text for 'calicoctl create' command - -Run `calicoctl create --help` to display the following help menu for the -command. - -``` -Usage: - calicoctl create --filename= [--recursive] [--skip-empty] [--skip-exists] [--config=] [--namespace=] - -Examples: - # Create a policy using the data in policy.yaml. - calicoctl create -f ./policy.yaml - - # Create a policy based on the JSON passed into stdin. - cat policy.json | calicoctl create -f - - -Options: - -h --help Show this screen. - -f --filename= Filename to use to create the resource. If set to - "-" loads from stdin. If filename is a directory, this command is - invoked for each .json .yaml and .yml file within that directory, - terminating after the first failure. - -R --recursive Process the filename specified in -f or --filename recursively. - --skip-empty Do not error if any files or directory specified using -f or --filename contain no - data. - --skip-exists Skip over and treat as successful any attempts to - create an entry that already exists. - -c --config= Path to the file containing connection - configuration in YAML or JSON format. - [default: /etc/calico/calicoctl.cfg] - -n --namespace= Namespace of the resource. - Only applicable to NetworkPolicy, NetworkSet, and WorkloadEndpoint. - Uses the default namespace if not specified. - --context= The name of the kubeconfig context to use. - -Description: - The create command is used to create a set of resources by filename or stdin. - JSON and YAML formats are accepted. - - Valid resource types are: - - - bgpconfiguration - - bgpfilter - - bgppeer - - clusterinformation - - felixconfiguration - - globalnetworkpolicy - - globalnetworkset - - hostendpoint - - ippool - - ipreservation - - kubecontrollersconfiguration - - networkpolicy - - networkset - - node - - profile - - tier - - workloadendpoint - - Attempting to create a resource that already exists is treated as a - terminating error unless the --skip-exists flag is set. If this flag is set, - resources that already exist are skipped. - - The output of the command indicates how many resources were successfully - created, and the error reason if an error occurred. If the --skip-exists - flag is set then skipped resources are included in the success count. - - The resources are created in the order they are specified. In the event of a - failure creating a specific resource it is possible to work out which - resource failed based on the number of resources successfully created. -``` - -### Examples - -1. Create a set of resources (of mixed type) using the data in resources.yaml. - - ```bash - calicoctl create -f ./resources.yaml - ``` - - Results indicate that 8 resources were successfully created. - - ``` - Successfully created 8 resource(s) - ``` - -1. Create the same set of resources reading from stdin. - - ```bash - cat resources.yaml | calicoctl create -f - - ``` - - Results indicate failure because the first resource (in this case a Profile) - already exists. - - ``` - Failed to create any resources: resource already exists: Profile(name=profile1) - ``` - -### Options - -``` --f --filename= Filename to use to create the resource. If set to - "-" loads from stdin. - --skip-exists Skip over and treat as successful any attempts to - create an entry that already exists. --n --namespace= Namespace of the resource. - Only applicable to NetworkPolicy and WorkloadEndpoint. - Uses the default namespace if not specified. -``` - -### General options - -``` --c --config= Path to the file containing connection - configuration in YAML or JSON format. - [default: /etc/calico/calicoctl.cfg] -``` - -## See also - -- [Installing calicoctl](../../operations/calicoctl/install.mdx) -- [Resources](../resources/overview.mdx) for details on all valid resources, including file format - and schema -- [NetworkPolicy](../resources/networkpolicy.mdx) for details on the $[prodname] selector-based policy model diff --git a/calico_versioned_docs/version-3.29/reference/calicoctl/datastore/index.mdx b/calico_versioned_docs/version-3.29/reference/calicoctl/datastore/index.mdx deleted file mode 100644 index b8957eb3c9..0000000000 --- a/calico_versioned_docs/version-3.29/reference/calicoctl/datastore/index.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: calicoctl datastore commands. -hide_table_of_contents: true ---- - -# datastore - -import DocCardList from '@theme/DocCardList'; -import { useCurrentSidebarCategory } from '@docusaurus/theme-common'; - - diff --git a/calico_versioned_docs/version-3.29/reference/calicoctl/datastore/migrate/export.mdx b/calico_versioned_docs/version-3.29/reference/calicoctl/datastore/migrate/export.mdx deleted file mode 100644 index 8970f095cb..0000000000 --- a/calico_versioned_docs/version-3.29/reference/calicoctl/datastore/migrate/export.mdx +++ /dev/null @@ -1,101 +0,0 @@ ---- -description: Command and options for exporting an etcdv3 datastore. ---- - -# calicoctl datastore migrate export - -This sections describes the `calicoctl datastore migrate export` command. - -Read the [calicoctl Overview](../../overview.mdx) -for a full list of calicoctl commands. - -## Display the help text for 'calicoctl datastore migrate export' command - -Run `calicoctl datastore migrate export --help` to display the following help menu for the -command. - -``` -Usage: - calicoctl datastore migrate export [--config=] - -Options: - -h --help Show this screen. - -c --config= Path to the file containing connection - configuration in YAML or JSON format. - [default: /etc/calico/calicoctl.cfg] - -Description: - Export the contents of the etcdv3 datastore. Resources will be exported - in yaml and json format. Save the results of this command to a file for - later use with the import command. - - The resources exported include the following: - - IPAMBlocks - - BlockAffinities - - IPAMHandles - - IPAMConfigurations - - IPPools - - BGPConfigurations - - BGPPeers - - ClusterInformations - - FelixConfigurations - - GlobalNetworkPolicies - - GlobalNetworkSets - - HostEndpoints - - KubeControllersConfigurations - - NetworkPolicies - - Networksets - - Nodes - - The following resources are not exported: - - WorkloadEndpoints - - Profiles -``` - -### Exported resources - -The `export` subcommand exports the following Calico resources: - -- IPAMBlocks -- BlockAffinities -- IPAMHandles -- IPAMConfigurations -- IPPools -- BGPConfigurations -- BGPPeers -- ClusterInformations -- FelixConfigurations -- GlobalNetworkPolicies -- GlobalNetworkSets -- HostEndpoints -- NetworkPolicies -- Networksets -- Nodes - -The `export` subcommand does not export the following resources -since they should be generated: - -- WorkloadEndpoints -- Profiles - -### Examples - -Export the contents of an etcdv3 datastore to a file named `etcd-migration`. - -```bash -calicoctl datastore migrate export > etcd-migration -``` - -### General options - -``` --c --config= Path to the file containing connection - configuration in YAML or JSON format. - [default: /etc/calico/calicoctl.cfg] -``` - -## See also - -- [Install calicoctl](../../../../operations/calicoctl/install.mdx) -- [Resources](../../../resources/overview.mdx) for details on all valid resources, including file format - and schema diff --git a/calico_versioned_docs/version-3.29/reference/calicoctl/datastore/migrate/import.mdx b/calico_versioned_docs/version-3.29/reference/calicoctl/datastore/migrate/import.mdx deleted file mode 100644 index 7725629146..0000000000 --- a/calico_versioned_docs/version-3.29/reference/calicoctl/datastore/migrate/import.mdx +++ /dev/null @@ -1,61 +0,0 @@ ---- -description: Command and options for importing exported data to a kubernetes datastore. ---- - -# calicoctl datastore migrate import - -This sections describes the `calicoctl datastore migrate import` command. - -Read the [calicoctl Overview](../../overview.mdx) -for a full list of calicoctl commands. - -## Display the help text for 'calicoctl datastore migrate import' command - -Run `calicoctl datastore migrate import --help` to display the following help menu for the -command. - -``` -Usage: - calicoctl datastore migrate import --filename= [--config=] - -Options: - -h --help Show this screen. - -f --filename= Filename to use to import resources. If set to - "-" loads from stdin. - -c --config= Path to the file containing connection - configuration in YAML or JSON format. - [default: /etc/calico/calicoctl.cfg] - -Description: - Import the contents of the etcdv3 datastore from the file created by the - export command. -``` - -### Examples - -Import the contents of an etcdv3 datastore stored in a file named `etcd-migration`. - -```bash -calicoctl datastore migrate import -f etcd-migration -``` - -### Options - -``` --f --filename= Filename to use to import resources. If set to - "-" loads from stdin. -``` - -### General options - -``` --c --config= Path to the file containing connection - configuration in YAML or JSON format. - [default: /etc/calico/calicoctl.cfg] -``` - -## See also - -- [Install calicoctl](../../../../operations/calicoctl/install.mdx) -- [Resources](../../../resources/overview.mdx) for details on all valid resources, including file format - and schema diff --git a/calico_versioned_docs/version-3.29/reference/calicoctl/datastore/migrate/index.mdx b/calico_versioned_docs/version-3.29/reference/calicoctl/datastore/migrate/index.mdx deleted file mode 100644 index 2aa67cd9f3..0000000000 --- a/calico_versioned_docs/version-3.29/reference/calicoctl/datastore/migrate/index.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: calicoctl datastore migrate commands. -hide_table_of_contents: true ---- - -# Migrate - -import DocCardList from '@theme/DocCardList'; -import { useCurrentSidebarCategory } from '@docusaurus/theme-common'; - - diff --git a/calico_versioned_docs/version-3.29/reference/calicoctl/datastore/migrate/lock.mdx b/calico_versioned_docs/version-3.29/reference/calicoctl/datastore/migrate/lock.mdx deleted file mode 100644 index 24f1fc19e3..0000000000 --- a/calico_versioned_docs/version-3.29/reference/calicoctl/datastore/migrate/lock.mdx +++ /dev/null @@ -1,54 +0,0 @@ ---- -description: Command and options for locking a datastore for migration. ---- - -# calicoctl datastore migrate lock - -This sections describes the `calicoctl datastore migrate lock` command. - -Read the [calicoctl Overview](../../overview.mdx) -for a full list of calicoctl commands. - -## Display the help text for 'calicoctl datastore migrate unlock' command - -Run `calicoctl datastore migrate lock --help` to display the following help menu for the -command. - -``` -Usage: - calicoctl datastore migrate lock [--config=] - -Options: - -h --help Show this screen. - -c --config= Path to the file containing connection - configuration in YAML or JSON format. - [default: /etc/calico/calicoctl.cfg] - -Description: - Lock the datastore to prepare it for migration. This prevents any new - Calico resources from affecting the cluster but does not prevent updating - or creating new Calico resources. -``` - -### Examples - -Lock the datastore to prepare it for migration so that any changes to the -data will not affect the cluster during migration. - -```bash -calicoctl datastore migrate lock -``` - -### General options - -``` --c --config= Path to the file containing connection - configuration in YAML or JSON format. - [default: /etc/calico/calicoctl.cfg] -``` - -## See also - -- [Install calicoctl](../../../../operations/calicoctl/install.mdx) -- [Resources](../../../resources/overview.mdx) for details on all valid resources, including file format - and schema diff --git a/calico_versioned_docs/version-3.29/reference/calicoctl/datastore/migrate/overview.mdx b/calico_versioned_docs/version-3.29/reference/calicoctl/datastore/migrate/overview.mdx deleted file mode 100644 index 5cb1ac66e9..0000000000 --- a/calico_versioned_docs/version-3.29/reference/calicoctl/datastore/migrate/overview.mdx +++ /dev/null @@ -1,43 +0,0 @@ ---- -description: Commands for calicoctl datastore migrate. ---- - -# calicoctl datastore migrate - -This section describes the `calicoctl datastore migrate` commands. - -Read the [calicoctl Overview](../../overview.mdx) -for a full list of calicoctl commands. - -## Display the help text for 'calicoctl datastore migrate' commands - -Run `calicoctl datastore migrate --help` to display the following help menu for the -commands. - -``` -Usage: - calicoctl datastore migrate [...] - - export Export the contents of the etcdv3 datastore to yaml. - import Store and convert yaml of resources into the Kubernetes datastore. - lock Lock the datastore to prevent changes from occurring during datastore migration. - unlock Unlock the datastore to allow changes once the migration is completed. - -Options: - -h --help Show this screen. - -Description: - Migration specific commands for calicoctl. - - See 'calicoctl datastore migrate --help' to read about a specific subcommand. -``` - -## Migrate specific commands - -Details on the `calicoctl datastore migrate` commands are described in the documents linked below -organized by sub command. - -- [calicoctl datastore migrate export](export.mdx) -- [calicoctl datastore migrate import](import.mdx) -- [calicoctl datastore migrate lock](lock.mdx) -- [calicoctl datastore migrate unlock](unlock.mdx) diff --git a/calico_versioned_docs/version-3.29/reference/calicoctl/datastore/migrate/unlock.mdx b/calico_versioned_docs/version-3.29/reference/calicoctl/datastore/migrate/unlock.mdx deleted file mode 100644 index 96128a908e..0000000000 --- a/calico_versioned_docs/version-3.29/reference/calicoctl/datastore/migrate/unlock.mdx +++ /dev/null @@ -1,53 +0,0 @@ ---- -description: Command and options for unlocking a datastore after migration. ---- - -# calicoctl datastore migrate unlock - -This sections describes the `calicoctl datastore migrate lock` command. - -Read the [calicoctl Overview](../../overview.mdx) -for a full list of calicoctl commands. - -## Display the help text for 'calicoctl datastore migrate unlock' command - -Run `calicoctl datastore migrate unlock --help` to display the following help menu for the -command. - -``` -Usage: - calicoctl datastore migrate unlock [--config=] - -Options: - -h --help Show this screen. - -c --config= Path to the file containing connection - configuration in YAML or JSON format. - [default: /etc/calico/calicoctl.cfg] - -Description: - Unlock the datastore to complete migration. This once again allows - Calico resources to take effect in the cluster. -``` - -### Examples - -Unlock the datastore after migration to allow the Calico resources to affect -the cluster. - -```bash -calicoctl datastore migrate unlock -``` - -### General options - -``` --c --config= Path to the file containing connection - configuration in YAML or JSON format. - [default: /etc/calico/calicoctl.cfg] -``` - -## See also - -- [Install calicoctl](../../../../operations/calicoctl/install.mdx) -- [Resources](../../../resources/overview.mdx) for details on all valid resources, including file format - and schema diff --git a/calico_versioned_docs/version-3.29/reference/calicoctl/datastore/overview.mdx b/calico_versioned_docs/version-3.29/reference/calicoctl/datastore/overview.mdx deleted file mode 100644 index f1975d552f..0000000000 --- a/calico_versioned_docs/version-3.29/reference/calicoctl/datastore/overview.mdx +++ /dev/null @@ -1,37 +0,0 @@ ---- -description: Commands for calicoctl datastore ---- - -# calicoctl datastore - -This section describes the `calicoctl datastore` commands. - -Read the [calicoctl Overview](../overview.mdx) -for a full list of calicoctl commands. - -## Display the help text for 'calicoctl datastore migrate' commands - -Run `calicoctl datastore migrate --help` to display the following help menu for the -commands. - -``` -Usage: - calicoctl datastore [...] - - migrate Migrate the contents of an etcdv3 datastore to a Kubernetes datastore. - -Options: - -h --help Show this screen. - -Description: - Datastore specific commands for calicoctl. - - See 'calicoctl datastore --help' to read about a specific subcommand. -``` - -## Datastore specific commands - -Details on the `calicoctl datastore` commands are described in the documents linked below -organized by sub command. - -- [calicoctl datastore migrate](migrate/overview.mdx) diff --git a/calico_versioned_docs/version-3.29/reference/calicoctl/delete.mdx b/calico_versioned_docs/version-3.29/reference/calicoctl/delete.mdx deleted file mode 100644 index f2c36b8384..0000000000 --- a/calico_versioned_docs/version-3.29/reference/calicoctl/delete.mdx +++ /dev/null @@ -1,157 +0,0 @@ ---- -description: Command to delete a policy. ---- - -# calicoctl delete - -This sections describes the `calicoctl delete` command. - -Read the [calicoctl command line interface user reference](overview.mdx) -for a full list of calicoctl commands. - -:::note - -The available actions for a specific resource type may be -limited based on the datastore used for $[prodname] (etcdv3 / Kubernetes API). -Please refer to the -[Resources section](../resources/overview.mdx) -for details about each resource type. - -::: - -## Displaying the help text for 'calicoctl delete' command - -Run `calicoctl delete --help` to display the following help menu for the -command. - -``` -Usage: - calicoctl delete ( ( []) | - --filename=) [--recursive] [--skip-empty] - [--skip-not-exists] [--config=] [--namespace=] - -Examples: - # Delete a policy using the type and name specified in policy.yaml. - calicoctl delete -f ./policy.yaml - - # Delete a policy based on the type and name in the YAML passed into stdin. - cat policy.yaml | calicoctl delete -f - - - # Delete policies with names "foo" and "bar" - calicoctl delete policy foo bar - -Options: - -h --help Show this screen. - -s --skip-not-exists Skip over and treat as successful, resources that - don't exist. - -f --filename= Filename to use to delete the resource. If set to - "-" loads from stdin. If filename is a directory, this command is - invoked for each .json .yaml and .yml file within that directory, - terminating after the first failure. - -R --recursive Process the filename specified in -f or --filename recursively. - --skip-empty Do not error if any files or directory specified using -f or --filename contain no - data. - -c --config= Path to the file containing connection - configuration in YAML or JSON format. - [default: /etc/calico/calicoctl.cfg] - -n --namespace= Namespace of the resource. - Only applicable to NetworkPolicy and WorkloadEndpoint. - Uses the default namespace if not specified. - --context= The name of the kubeconfig context to use. - -Description: - The delete command is used to delete a set of resources by filename or stdin, - or by type and identifiers. JSON and YAML formats are accepted for file and - stdin format. - - Valid resource types are: - - - bgpconfiguration - - bgpfilter - - bgppeer - - clusterinformation - - felixconfiguration - - globalnetworkpolicy - - globalnetworkset - - hostendpoint - - ippool - - ipreservation - - kubecontrollersconfiguration - - networkpolicy - - networkset - - node - - profile - - tier - - workloadendpoint - - The resource type is case-insensitive and may be pluralized. - - Attempting to delete a resource that does not exists is treated as a - terminating error unless the --skip-not-exists flag is set. If this flag is - set, resources that do not exist are skipped. - - When deleting resources by type, only a single type may be specified at a - time. The name is required along with any and other identifiers required to - uniquely identify a resource of the specified type. - - The output of the command indicates how many resources were successfully - deleted, and the error reason if an error occurred. If the --skip-not-exists - flag is set then skipped resources are included in the success count. - - The resources are deleted in the order they are specified. In the event of a - failure deleting a specific resource it is possible to work out which - resource failed based on the number of resources successfully deleted. -``` - -### Examples - -1. Delete a set of resources (of mixed type) using the data in resources.yaml. - - ```bash - calicoctl delete -f ./resources.yaml - ``` - - Results indicate that 8 resources were successfully deleted. - - ``` - Successfully deleted 8 resource(s) - ``` - -1. Delete a policy resource by name. The policy is called "policy1". - - ```bash - bin/calicoctl delete policy policy1 - ``` - - Results indicate success. - - ``` - Successfully deleted 1 'policy' resource(s) - ``` - -### Options - -``` --s --skip-not-exists Skip over and treat as successful, resources that - don't exist. --f --filename= Filename to use to delete the resource. If set to - "-" loads from stdin. --n --namespace= Namespace of the resource. - Only applicable to NetworkPolicy and WorkloadEndpoint. - Uses the default namespace if not specified. -``` - -### General options - -``` --c --config= Path to the file containing connection - configuration in YAML or JSON format. - [default: /etc/calico/calicoctl.cfg] -``` - -## See also - -- [Installing calicoctl](../../operations/calicoctl/install.mdx). -- [Resources](../resources/overview.mdx) for details on all valid resources, including file format - and schema -- [NetworkPolicy](../resources/networkpolicy.mdx) for details on the $[prodname] selector-based policy model diff --git a/calico_versioned_docs/version-3.29/reference/calicoctl/get.mdx b/calico_versioned_docs/version-3.29/reference/calicoctl/get.mdx deleted file mode 100644 index 4392ad768d..0000000000 --- a/calico_versioned_docs/version-3.29/reference/calicoctl/get.mdx +++ /dev/null @@ -1,278 +0,0 @@ ---- -description: Command to list policies in the default output format. ---- - -# calicoctl get - -This sections describes the `calicoctl get` command. - -Read the [calicoctl command line interface user reference](overview.mdx) -for a full list of calicoctl commands. - -:::note - -The available actions for a specific resource type may be -limited based on the datastore used for $[prodname] (etcdv3 / Kubernetes API). -Please refer to the -[Resources section](../resources/overview.mdx) -for details about each resource type. - -::: - -## Displaying the help text for 'calicoctl get' command - -Run `calicoctl get --help` to display the following help menu for the -command. - -``` -Usage: - calicoctl get ( ( []) | - --filename=) [--recursive] [--skip-empty] - [--output=] [--config=] [--namespace=] [--all-namespaces] - -Examples: - # List all policy in default output format. - calicoctl get policy - - # List specific policies in YAML format - calicoctl get -o yaml policy my-policy-1 my-policy-2 - -Options: - -h --help Show this screen. - -f --filename= Filename to use to get the resource. If set to - "-" loads from stdin. If filename is a directory, this command is - invoked for each .json .yaml and .yml file within that directory, - terminating after the first failure. - -R --recursive Process the filename specified in -f or --filename recursively. - --skip-empty Do not error if any files or directory specified using -f or --filename contain no - data. - -o --output= Output format. One of: yaml, json, ps, wide, - custom-columns=..., go-template=..., - go-template-file=... [Default: ps] - -c --config= Path to the file containing connection - configuration in YAML or JSON format. - [default: /etc/calico/calicoctl.cfg] - -n --namespace= Namespace of the resource. - Only applicable to NetworkPolicy and WorkloadEndpoint. - Uses the default namespace if not specified. - -A --all-namespaces If present, list the requested object(s) across - all namespaces. - --export If present, returns the requested object(s) stripped of - cluster-specific information. This flag will be ignored - if is not specified. - --context= The name of the kubeconfig context to use. - -Description: - The get command is used to display a set of resources by filename or stdin, - or by type and identifiers. JSON and YAML formats are accepted for file and - stdin format. - - Valid resource types are: - - - bgpconfiguration - - bgpfilter - - bgppeer - - clusterinformation - - felixconfiguration - - globalnetworkpolicy - - globalnetworkset - - hostendpoint - - ippool - - ipreservation - - kubecontrollersconfiguration - - networkpolicy - - networkset - - node - - profile - - tier - - workloadendpoint - - The resource type is case-insensitive and may be pluralized. - - Attempting to get resources that do not exist will simply return no results. - - When getting resources by type, only a single type may be specified at a - time. The name and other identifiers (hostname, scope) are optional, and are - wildcarded when omitted. Thus if you specify no identifiers at all (other - than type), then all configured resources of the requested type will be - returned. - - By default the results are output in a ps-style table output. There are - alternative ways to display the data using the --output option: - - ps Display the results in ps-style output. - wide As per the ps option, but includes more headings. - custom-columns As per the ps option, but only display the columns - that are requested in the comma-separated list. - golang-template Display the results using the specified golang - template. This can be used to filter results, for - example to return a specific value. - golang-template-file Display the results using the golang template that is - contained in the specified file. - yaml Display the results in YAML output format. - json Display the results in JSON output format. - - Note that the data output using YAML or JSON format is always valid to use as - input to all of the resource management commands (create, apply, replace, - delete, get). - - Please refer to the docs at https://projectcalico.docs.tigera.io for more details on - the output formats, including example outputs, resource structure (required - for the golang template definitions) and the valid column names (required for - the custom-columns option). -``` - -### Options - -``` --h --help Show this screen. --f --filename= Filename to use to get the resource. If set to - "-" loads from stdin. --o --output= Output format. One of: yaml, json, ps, wide, - custom-columns=..., go-template=..., - go-template-file=... [Default: ps] --n --namespace= Namespace of the resource. - Only applicable to NetworkPolicy, NetworkSet, and WorkloadEndpoint. - Uses the default namespace if not specified. --A --all-namespaces If present, list the requested object(s) across - all namespaces. ---export If present, returns the requested object(s) stripped of - cluster-specific information. This flag will be ignored - if the resource name is not specified. -``` - -### General options - -``` --c --config= Path to the file containing connection - configuration in YAML or JSON format. - [default: /etc/calico/calicoctl.cfg] -``` - -### Output options - -#### `ps` - -This is the default output format. It displays output in ps-style table output with sufficient columns to -uniquely identify the resource. - -The headings displayed for each resource type is fixed. However, we `wide` option for displaying additional -columns, and `custom-columns` for selecting which columns to display. - -Example: - -```bash -calicoctl get hostEndpoint -``` - -Response: - -``` -NAME NODE -endpoint1 host1 -myhost-eth0 myhost -``` - -#### `wide` - -Similar to the `ps` format, the `wide` option displays output in ps-style table output but with additional columns. - -The headings displayed for each resource type is fixed. See `custom-columns` for selecting which columns to display. - -Example: - -```bash -calicoctl get hostEndpoint --output=wide -``` - -Response: - -``` -NAME NODE INTERFACE IPS PROFILES -endpoint1 host1 1.2.3.4,0:bb::aa prof1,prof2 -myhost-eth0 myhost profile1 -``` - -#### `custom-columns` - -Similar to the `ps` format, the `custom-columns` option displays output in ps-style table output but allows the user -to specify and ordered, comma-separated list of columns to display in the output. The valid heading names for each -resource type is documented in the [Resources](../resources/overview.mdx) guide. - -Example: - -``` -calicoctl get hostEndpoint --output=custom-columns=NAME,IPS -``` - -Response: - -``` -NAME IPS -endpoint1 1.2.3.4,0:bb::aa -myhost-eth0 -``` - -#### `yaml / json` - -The `yaml` and `json` options display the output as a list of YAML documents or JSON dictionaries. The fields for -resource type are documented in the [Resources](../resources/overview.mdx) guide. - -The output from either of these formats may be used as input for all of the resource management commands. - -Example: - -```bash -calicoctl get hostEndpoint --output=yaml -``` - -Response: - -```yaml -- apiVersion: projectcalico.org/v3 - kind: HostEndpoint - metadata: - labels: - type: database - name: endpoint1 - spec: - node: host1 - expectedIPs: - - 1.2.3.4 - - 0:bb::aa - profiles: - - prof1 - - prof2 -- apiVersion: projectcalico.org/v3 - kind: HostEndpoint - metadata: - name: myhost-eth0 - spec: - node: myhost - profiles: - - profile1 -``` - -#### `go-template / go-template-file` - -The `go-template` and `go-template-file` options display the output using a golang template specified as a string -on the CLI, or defined in a separate file. -When writing a template, be aware that the data passed to the template is a golang slice of resource-lists. The -resource-lists are defined in the [libcalico API](../resources/overview.mdx) and there is a resource-list defined for -each resource type. A resource-list contains an Items field which is itself a slice of resources. Thus, to output -the "Name" field from the supplied data, it is necessary to enumerate over the slice of resource-lists and the items -within that list. - -Example: - -```bash -bin/calicoctl get hostEndpoint --output=go-template="{{range .}}{{range .Items}}{{.ObjectMeta.Name}},{{end}}{{end}}" -endpoint1,eth0, -``` - -## See also - -- [Installing calicoctl](../../operations/calicoctl/install.mdx). -- [Resources](../resources/overview.mdx) for details on all valid resources, including file format - and schema -- [NetworkPolicy](../resources/networkpolicy.mdx) for details on the $[prodname] selector-based policy model diff --git a/calico_versioned_docs/version-3.29/reference/calicoctl/index.mdx b/calico_versioned_docs/version-3.29/reference/calicoctl/index.mdx deleted file mode 100644 index 710f6f7fb0..0000000000 --- a/calico_versioned_docs/version-3.29/reference/calicoctl/index.mdx +++ /dev/null @@ -1,17 +0,0 @@ ---- - -title: calicoctl -hide_table_of_contents: true - ---- - -import DocCardList from '@theme/DocCardList'; -import {useCurrentSidebarCategory} from '@docusaurus/theme-common'; - -Optional command line interface (CLI) to manage Calico resources. - -The calicoctl CLI tool allows management of Calico API resources, and can be used to perform other administrative tasks for managing a Calico installation. - -You can use kubectl to manage Calico resources instead by [installing the Calico API server](../../operations/install-apiserver.mdx). - - diff --git a/calico_versioned_docs/version-3.29/reference/calicoctl/ipam/check.mdx b/calico_versioned_docs/version-3.29/reference/calicoctl/ipam/check.mdx deleted file mode 100644 index c48cfa5959..0000000000 --- a/calico_versioned_docs/version-3.29/reference/calicoctl/ipam/check.mdx +++ /dev/null @@ -1,68 +0,0 @@ ---- -description: Command to check IPAM status ---- - -# calicoctl ipam check - -This section describes the `calicoctl ipam check` command. - -Read the [calicoctl overview](../overview.mdx) for a full list of calicoctl commands. - -## Displaying the help text for 'calicoctl ipam check' command - -Run `calicoctl ipam check --help` to display the following help menu for the command. - -``` -Usage: - calicoctl ipam check [--config=] [--show-all-ips] [--show-problem-ips] [-o ] - -Options: - -h --help Show this screen. - -o --output= Path to output report file. - --show-all-ips Print all IPs that are checked. - --show-problem-ips Print all IPs that are leaked or not allocated properly. - -c --config= Path to the file containing connection configuration in - YAML or JSON format. - [default: /etc/calico/calicoctl.cfg] - -Description: - The ipam check command checks the integrity of the IPAM datastructures against Kubernetes. -``` - -### Examples - -Example workflow for checking consistency and releasing leaked addresses. - -**Lock the data store** - -```bash -calicoctl datastore migrate lock -``` - -:::note - -Once the data store is locked, new pods will not be able to be launched until the data store is unlocked. - -::: - -**Generate a report using the check command** - -```bash -calicoctl ipam check -o report.json -``` - -**Release any unnecessary addresses** - -```bash -calicoctl ipam release --from-report report.json -``` - -**Unlock the data store** - -```bash -calicoctl datastore migrate unlock -``` - -## See also - -- [Installing calicoctl](../../../operations/calicoctl/install.mdx) diff --git a/calico_versioned_docs/version-3.29/reference/calicoctl/ipam/configure.mdx b/calico_versioned_docs/version-3.29/reference/calicoctl/ipam/configure.mdx deleted file mode 100644 index 6220e1840f..0000000000 --- a/calico_versioned_docs/version-3.29/reference/calicoctl/ipam/configure.mdx +++ /dev/null @@ -1,48 +0,0 @@ ---- -description: Command to change IPAM configuration. ---- - -# calicoctl ipam configure - -This section describes the `calicoctl ipam configure` command. - -Read the [calicoctl overview](../overview.mdx) for a full list of calicoctl commands. - -## Displaying the help text for 'calicoctl ipam configure' command - -Run `calicoctl ipam configure --help` to display the following help menu for the -command. - -``` -Usage: - calicoctl ipam configure --strictaffinity= [--config=] - -Options: - -h --help Show this screen. - --strictaffinity= Set StrictAffinity to true/false. When StrictAffinity - is true, borrowing IP addresses is not allowed. - -c --config= Path to the file containing connection configuration in - YAML or JSON format. - [default: /etc/calico/calicoctl.cfg] - -Description: - Modify configuration for Calico IP address management. -``` - -### Examples - -```bash -calicoctl ipam configure --strictaffinity=true -``` - -### General options - -``` --c --config= Path to the file containing connection - configuration in YAML or JSON format. - [default: /etc/calico/calicoctl.cfg] -``` - -## See also - -- [Installing calicoctl](../../../operations/calicoctl/install.mdx) diff --git a/calico_versioned_docs/version-3.29/reference/calicoctl/ipam/index.mdx b/calico_versioned_docs/version-3.29/reference/calicoctl/ipam/index.mdx deleted file mode 100644 index 1049df9db0..0000000000 --- a/calico_versioned_docs/version-3.29/reference/calicoctl/ipam/index.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: calicoctl IPAM commands for Calico-assigned IP addresses. -hide_table_of_contents: true ---- - -# ipam - -import DocCardList from '@theme/DocCardList'; -import { useCurrentSidebarCategory } from '@docusaurus/theme-common'; - - diff --git a/calico_versioned_docs/version-3.29/reference/calicoctl/ipam/overview.mdx b/calico_versioned_docs/version-3.29/reference/calicoctl/ipam/overview.mdx deleted file mode 100644 index 9eed90a72c..0000000000 --- a/calico_versioned_docs/version-3.29/reference/calicoctl/ipam/overview.mdx +++ /dev/null @@ -1,41 +0,0 @@ ---- -description: Commands for calicoctl IP address management (IPAM). ---- - -# calicoctl ipam - -This section describes the `calicoctl ipam` commands. - -Read the [calicoctl Overview](../overview.mdx) for a full list of calicoctl commands. - -## Displaying the help text for 'calicoctl ipam' commands - -Run `calicoctl ipam --help` to display the following help menu for the -commands. - -``` -Usage: - calicoctl ipam [...] - - release Release a Calico assigned IP address. - show Show details of a Calico assigned IP address, - or of overall IP usage. - configure Configure IPAM - -Options: - -h --help Show this screen. - -Description: - IP Address Management specific commands for calicoctl. - - See 'calicoctl ipam --help' to read about a specific subcommand. -``` - -## IPAM specific commands - -Details on the `calicoctl ipam` commands are described in the documents linked below -organized by sub command. - -- [calicoctl ipam release](release.mdx) -- [calicoctl ipam show](show.mdx) -- [calicoctl ipam configure](configure.mdx) diff --git a/calico_versioned_docs/version-3.29/reference/calicoctl/ipam/release.mdx b/calico_versioned_docs/version-3.29/reference/calicoctl/ipam/release.mdx deleted file mode 100644 index 9a4ac15b45..0000000000 --- a/calico_versioned_docs/version-3.29/reference/calicoctl/ipam/release.mdx +++ /dev/null @@ -1,58 +0,0 @@ ---- -description: Command to release an IP address from Calico IP management. ---- - -# calicoctl ipam release - -This section describes the `calicoctl ipam release` command. - -Read the [calicoctl overview](../overview.mdx) for a full list of calicoctl commands. - -## Displaying the help text for 'calicoctl ipam release' command - -Run `calicoctl ipam release --help` to display the following help menu for the -command. - -``` -Usage: - calicoctl ipam release [--ip=] [--from-report=] [--config=] - -Options: - -h --help Show this screen. - --ip= IP address to release. - --from-report= Release all leaked addresses from the report. - -c --config= Path to the file containing connection configuration in - YAML or JSON format. - [default: /etc/calico/calicoctl.cfg] - -Description: - The ipam release command releases an IP address from the Calico IP Address - Manager that was been previously assigned to an endpoint. When an IP address - is released, it becomes available for assignment to any endpoint. - - Note that this does not remove the IP from any existing endpoints that may be - using it, so only use this command to clean up addresses from endpoints that - were not cleanly removed from Calico. -``` - -### Examples - -```bash -calicoctl ipam release --ip=192.168.1.2 -``` - -```bash -calicoctl ipam release --from-report=./report.json -``` - -### General options - -``` --c --config= Path to the file containing connection - configuration in YAML or JSON format. - [default: /etc/calico/calicoctl.cfg] -``` - -## See also - -- [Installing calicoctl](../../../operations/calicoctl/install.mdx) diff --git a/calico_versioned_docs/version-3.29/reference/calicoctl/ipam/show.mdx b/calico_versioned_docs/version-3.29/reference/calicoctl/ipam/show.mdx deleted file mode 100644 index 0f09dd3707..0000000000 --- a/calico_versioned_docs/version-3.29/reference/calicoctl/ipam/show.mdx +++ /dev/null @@ -1,154 +0,0 @@ ---- -description: Command to see if IP address is being used. ---- - -# calicoctl ipam show - -This section describes the `calicoctl ipam show` command. - -Read the [calicoctl Overview](../overview.mdx) for a full list of calicoctl commands. - -## Displaying the help text for 'calicoctl ipam show' command - -Run `calicoctl ipam show --help` to display the following help menu for the -command. - -``` -Usage: - calicoctl ipam show [--ip= | --show-blocks] [--config=] - -Options: - -h --help Show this screen. - --ip= Report whether this specific IP address is in use. - --show-blocks Show detailed information for IP blocks as well as pools. - --show-borrowed Show detailed information for "borrowed" IP addresses. - --show-configuration Show current Calico IPAM configuration. - -c --config= Path to the file containing connection - configuration in YAML or JSON format. - [default: /etc/calico/calicoctl.cfg] - -Description: - The ipam show command prints information about a given IP address, or about - overall IP usage. -``` - -### Examples - -1. Print the information associated with an IP address. - - ```bash - calicoctl ipam show --ip=192.168.1.2 - ``` - - The following result indicates that the IP is not assigned to an endpoint. - - ``` - IP 192.168.1.2 is not currently assigned - ``` - -1. Print the information associated with a different IP address. - - ```bash - calicoctl ipam show --ip=10.244.118.70 - ``` - - For a Kubernetes pod IP, attributes indicate the pod name and namespace: - - ``` - IP 10.244.118.70 is in use - Attributes: - pod: nano-66d4c99f8b-jm5s9 - namespace: default - node: ip-172-16-101-160.us-west-2.compute.internal - ``` - -1. Print a summary of IP usage. - - ```bash - calicoctl ipam show - ``` - - The table shows usage for each IP Pool: - - ``` - +----------+-------------------+------------+------------+-------------------+ - | GROUPING | CIDR | IPS TOTAL | IPS IN USE | IPS FREE | - +----------+-------------------+------------+------------+-------------------+ - | IP Pool | 10.65.0.0/16 | 65536 | 5 (0%) | 65531 (100%) | - | IP Pool | fd5f:abcd:64::/48 | 1.2089e+24 | 7 (0%) | 1.2089e+24 (100%) | - +----------+-------------------+------------+------------+-------------------+ - ``` - -1. Print more detailed IP usage by blocks. - - ```bash - calicoctl ipam show --show-blocks - ``` - - As well as the total usage per IP Pool, the table shows usage for block that has been allocated from those pools: - - ``` - +----------+-------------------------------------------+------------+------------+-------------------+ - | GROUPING | CIDR | IPS TOTAL | IPS IN USE | IPS FREE | - +----------+-------------------------------------------+------------+------------+-------------------+ - | IP Pool | 10.65.0.0/16 | 65536 | 5 (0%) | 65531 (100%) | - | Block | 10.65.79.0/26 | 64 | 5 (8%) | 59 (92%) | - | IP Pool | fd5f:abcd:64::/48 | 1.2089e+24 | 7 (0%) | 1.2089e+24 (100%) | - | Block | fd5f:abcd:64:4f2c:ec1b:27b9:1989:77c0/122 | 64 | 7 (11%) | 57 (89%) | - +----------+-------------------------------------------+------------+------------+-------------------+ - ``` - -1. Print more detailed information about borrowed IP addresses. - - ```bash - calicoctl ipam show --show-borrowed - ``` - - Table shows which IP addresses have been borrowed by which node out of which block and the entity consuming it: - - ``` - +------------+-----------------+---------------+---------------+------+------------------------------------+ - | IP | BORROWING-NODE | BLOCK | BLOCK OWNER | TYPE | ALLOCATED-TO | - +------------+-----------------+---------------+---------------+------+------------------------------------+ - | 172.16.0.1 | worker-node-1 | 172.16.0.0/29 | worker-node-2 | pod | external-ns/nginx-6db489d4b7-gln7h | - | 172.16.0.2 | worker-node-3 | 172.16.0.0/29 | worker-node-2 | pod | external-ns/nginx-6db489d4b7-kzkbv | - +------------+-----------------+---------------+---------------+------+------------------------------------+ - ``` - -1. Print current IPAM configuration. - - ```bash - calicoctl ipam show --show-configuration - ``` - - Table shows current IPAM configuration: - - ``` - +--------------------+-------+ - | PROPERTY | VALUE | - +--------------------+-------+ - | StrictAffinity | false | - | AutoAllocateBlocks | true | - +--------------------+-------+ - ``` - -### Options - -``` ---ip= Specific IP address to show. ---show-blocks Show detailed information for IP blocks as well as pools. ---show-borrowed Show detailed information for "borrowed" IP addresses. ---show-configuration Show current Calico IPAM configuration -``` - -### General options - -``` --c --config= Path to the file containing connection - configuration in YAML or JSON format. - [default: /etc/calico/calicoctl.cfg] -``` - -## See also - -- [Installing calicoctl](../../../operations/calicoctl/install.mdx) diff --git a/calico_versioned_docs/version-3.29/reference/calicoctl/ipam/split.mdx b/calico_versioned_docs/version-3.29/reference/calicoctl/ipam/split.mdx deleted file mode 100644 index ea2e6881f9..0000000000 --- a/calico_versioned_docs/version-3.29/reference/calicoctl/ipam/split.mdx +++ /dev/null @@ -1,84 +0,0 @@ ---- -description: Command and options for splitting an existing IP pool ---- - -# calicoctl ipam split - -This section describes the `calicoctl ipam split` command. - -Read the [calicoctlOverview](../overview.mdx) -for a full list of calicoctl commands. - -## Display the help text for `calicoctl ipam split` command - -Run `calicoctl ipam split --help` to display the following help menu for the command. - -``` -Usage: - ipam split [--cidr=] [--name=] [--config=] [--allow-version-mismatch] - -Options: - -h --help Show this screen. - -c --config= Path to the file containing connection configuration in - YAML or JSON format. - [default: /etc/calico/calicoctl.cfg] - --cidr= CIDR of the IP pool to split. - --name= Name of the IP pool to split. - --allow-version-mismatch Allow client and cluster versions mismatch. - -Description: - The ipam split command splits an IP pool specified by the specified CIDR or name - into the specified number of smaller IP pools. Each child IP pool will be of equal - size. IP pools can only be split into a number of smaller pools that is a power - of 2. - -Examples: - # Split the IP pool specified by 172.0.0.0/8 into 2 smaller pools - ipam split --cidr=172.0.0.0/8 2 -``` - -### Prerequisites - -To split an IP pool, you will first need to lock the Calico database -so that no IPAM data can change during the split. This is accomplished by using the -[`calicoctl datastore migrate lock` command](../datastore/migrate/lock.mdx). -To continue normal IPAM operation, you will need to unlock the calico datastore -after the split with the -[`calicoctl datastore migrate unlock` command](../datastore/migrate/unlock.mdx). - -### Examples - -Lock the Calico datastore. - -```bash -calicoctl datastore migrate lock -``` - -Split the IP pool specified by 172.0.0.0/15 into 2 smaller pools. - -```bash -calicoctl ipam split --cidr=172.0.0.0/15 2 -``` - -This should create 2 IP pools, one covering CIDR `172.0.0.0/16` -and one covering CIDR `172.1.0.0/16`. - -Unlock the Calico datastore to restore normal IPAM operation. - -```bash -calicoctl datastore migrate unlock -``` - -### General options - -``` - -c --config= Path to the file containing connection configuration in - YAML or JSON format. - [default: /etc/calico/calicoctl.cfg] -``` - -## See also - -- [Install calicoctl](../../../operations/calicoctl/install.mdx) -- [Resources](../../resources/overview.mdx) for details on all valid resources, including file format - and schema diff --git a/calico_versioned_docs/version-3.29/reference/calicoctl/label.mdx b/calico_versioned_docs/version-3.29/reference/calicoctl/label.mdx deleted file mode 100644 index 56815ad938..0000000000 --- a/calico_versioned_docs/version-3.29/reference/calicoctl/label.mdx +++ /dev/null @@ -1,154 +0,0 @@ ---- -description: Command to change labels for workload endpoints or nodes. ---- - -# calicoctl label - -This section describes the `calicoctl label` command. - -Read the [calicoctl command line interface user reference](overview.mdx) -for a full list of calicoctl commands. - -:::note - -The available actions for a specific resource type may be -limited based on the datastore used for $[prodname] (etcdv3 / Kubernetes API). -Please refer to the -[Resources section](../resources/overview.mdx) -for details about each resource type. - -::: - -## Displaying the help text for 'calicoctl label' command - -Run `calicoctl label --help` to display the following help menu for the -command. - -``` -Usage: - calicoctl label ( - ( = [--overwrite] | - --remove ) - [--config=] [--namespace=]) - -Examples: - # Label a workload endpoint - calicoctl label workloadendpoints nginx --namespace=default app=web - - # Label a node and overwrite the original value of key 'cluster' - calicoctl label nodes node1 cluster=frontend --overwrite - - # Remove label with key 'cluster' of the node - calicoctl label nodes node1 cluster --remove - -Options: - -h --help Show this screen. - -c --config= Path to the file containing connection - configuration in YAML or JSON format. - [default: /etc/calico/calicoctl.cfg] - -n --namespace= Namespace of the resource. - Only applicable to NetworkPolicy, NetworkSet, and WorkloadEndpoint. - Uses the default namespace if not specified. - --overwrite If true, overwrite the value when the key is already - present in labels. Otherwise reports error when the - labeled resource already have the key in its labels. - Can not be used with --remove. - --remove If true, remove the specified key in labels of the - resource. Reports error when specified key does not - exist. Can not be used with --overwrite. - --context= The name of the kubeconfig context to use. - -Description: - The label command is used to add or update a label on a resource. Resource types - that can be labeled are: - - * bgpConfiguration - * bgpPeer - * felixConfiguration - * globalNetworkPolicy - * globalNetworkSet - * hostEndpoint - * ipPool - * networkPolicy - * networkSet - * node - * profile - * workloadEndpoint - - The resource type is case-insensitive and may be pluralized. - - Attempting to label resources that do not exist will get an error. - - Attempting to remove a label that does not exist in the resource will get an error. - - When labeling a resource on an existing key: - - gets an error if option --overwrite is not provided. - - value of the key updates to specified value if option --overwrite is provided. -``` - -### Examples - -1. Label a node. - - ```bash - calicoctl label nodes node1 cluster=backend - ``` - - Results indicate that label was successfully applied. - - ``` - Successfully set label cluster on nodes node1 - ``` - -1. Label a node and overwrite the original value of key `cluster`. - - ```bash - calicoctl label nodes node1 cluster=frontend --overwrite - ``` - - Results indicate that label was successfully overwritten. - - ``` - Successfully updated label cluster on nodes node1 - ``` - -1. Remove label with key `cluster` from the node. - - ```bash - calicoctl label nodes node1 cluster --remove - ``` - - Results indicate that the label was successfully removed. - - ``` - Successfully removed label cluster from nodes node1. - ``` - -### Options - -``` - -n --namespace= Namespace of the resource. - Only applicable to NetworkPolicy and WorkloadEndpoint. - Uses the default namespace if not specified. - --overwrite If true, overwrite the value when the key is already - present in labels. Otherwise reports error when the - labeled resource already have the key in its labels. - Can not be used with --remove. - --remove If true, remove the specified key in labels of the - resource. Reports error when specified key does not - exist. Can not be used with --overwrite. -``` - -### General options - -``` - -c --config= Path to the file containing connection - configuration in YAML or JSON format. - [default: /etc/calico/calicoctl.cfg] -``` - -## See also - -- [Installing calicoctl](../../operations/calicoctl/install.mdx) -- [Resources](../resources/overview.mdx) for details on all valid resources, including file format - and schema diff --git a/calico_versioned_docs/version-3.29/reference/calicoctl/node/checksystem.mdx b/calico_versioned_docs/version-3.29/reference/calicoctl/node/checksystem.mdx deleted file mode 100644 index a005110637..0000000000 --- a/calico_versioned_docs/version-3.29/reference/calicoctl/node/checksystem.mdx +++ /dev/null @@ -1,66 +0,0 @@ ---- -description: Command to check compatibility of host to run a Calico node instance. ---- - -# calicoctl node checksystem - -This section describes the `calicoctl node checksystem` command. - -Read the [calicoctl Overview](../overview.mdx) -for a full list of calicoctl commands. - -## Displaying the help text for 'calicoctl node checksystem' command - -Run `calicoctl node checksystem --help` to display the following help menu for the -command. - -``` -Usage: - calicoctl node checksystem [--kernel-config=] - -Options: - -h --help Show this screen. - -f --kernel-config= Override the Kernel config file location. - Expected format is plain text. - default search locations: - "/usr/src/linux/.config", - "/boot/config-kernelVersion, - "/usr/src/linux-kernelVersion/.config", - "/usr/src/linux-headers-kernelVersion/.config", - "/lib/modules/kernelVersion/build/.config" - -Description: - Check the compatibility of this compute host to run a Calico node instance. -``` - -### Procedure - -These are the steps that `calicoctl` takes to pinpoint what modules are available in your system. - -1. `calicoctl` checks the kernel version. -2. By executing `lsmod` it tries to find out what modules are enabled. -3. Modules without a match in step 2 will be checked against `/lib/modules//modules.dep` file. -4. Modules without a match in step 2 & 3 will be checked against `/lib/modules//modules.builtin` file. -5. Modules without a match in previous steps will be tested against `kernelconfig` file `/usr/src/linux/.config`. -6. Any remaining module will be tested against loaded iptables modules in `/proc/net/ip_tables_matches`. - -### Examples - -```bash -calicoctl node checksystem -``` - -An example response follows. - -``` -xt_conntrack OK -xt_u32 OK -WARNING: Unable to detect the xt_set module. Load with `modprobe xt_set` -WARNING: Unable to detect the ipip module. Load with `modprobe ipip` -``` - -It is possible to override the `kernel-config` file using `--kernel-config` argument. In this case `calicoctl` will try to resolve the modules against the provided file and skip the default locations. - -```bash -calicoctl node checksystem --kernel-config /root/MYKERNELFILE -``` diff --git a/calico_versioned_docs/version-3.29/reference/calicoctl/node/diags.mdx b/calico_versioned_docs/version-3.29/reference/calicoctl/node/diags.mdx deleted file mode 100644 index 86f87a07b8..0000000000 --- a/calico_versioned_docs/version-3.29/reference/calicoctl/node/diags.mdx +++ /dev/null @@ -1,76 +0,0 @@ ---- -description: Command to get diagnostics from a Calico node. ---- - -# calicoctl node diags - -This section describes the `calicoctl node diags` command. - -Read the [calicoctl Overview](../overview.mdx) -for a full list of calicoctl commands. - -## Displaying the help text for 'calicoctl node diags' command - -Run `calicoctl node diags --help` to display the following help menu for the -command. - -``` -Usage: - calicoctl node diags [--log-dir=] - -Options: - -h --help Show this screen. - --log-dir= The directory containing Calico logs - [default: /var/log/calico] - -Description: - This command is used to gather diagnostic information from a Calico node. - This is usually used when trying to diagnose an issue that may be related to - your Calico network. - - The output of the command explains how to automatically upload the - diagnostics to http://transfer.sh for easy sharing of the data. Note that the - uploaded files will be deleted after 14 days. - - This command must be run on the specific Calico node that you are gathering - diagnostics for. -``` - -### Examples - -```bash -sudo calicoctl node diags -``` - -An example response follows. - -``` -Collecting diagnostics -Using temp dir: /tmp/calico676127473 -Dumping netstat -Dumping routes (IPv4) -Dumping routes (IPv6) -Dumping interface info (IPv4) -Dumping interface info (IPv6) -Dumping iptables (IPv4) -Dumping iptables (IPv6) -Dumping ipsets -exit status 1 -Dumping ipsets (container) -Copying journal for calico-node.service -Dumping felix stats -Copying Calico logs - -Diags saved to /tmp/calico676127473/diags-20170522_151219.tar.gz -If required, you can upload the diagnostics bundle to a file sharing service -such as transfer.sh using curl or similar. For example: - - curl --upload-file /tmp/calico676127473/diags-20170522_151219.tar.gz https://transfer.sh//tmp/calico676127473/diags-20170522_151219.tar.gz -``` - -### Options - -``` - --log-dir= The directory containing Calico logs. - [default: /var/log/calico] -``` diff --git a/calico_versioned_docs/version-3.29/reference/calicoctl/node/index.mdx b/calico_versioned_docs/version-3.29/reference/calicoctl/node/index.mdx deleted file mode 100644 index 625828c02d..0000000000 --- a/calico_versioned_docs/version-3.29/reference/calicoctl/node/index.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: calicoctl node commands. -hide_table_of_contents: true ---- - -# node - -import DocCardList from '@theme/DocCardList'; -import { useCurrentSidebarCategory } from '@docusaurus/theme-common'; - - diff --git a/calico_versioned_docs/version-3.29/reference/calicoctl/node/overview.mdx b/calico_versioned_docs/version-3.29/reference/calicoctl/node/overview.mdx deleted file mode 100644 index 57880633f6..0000000000 --- a/calico_versioned_docs/version-3.29/reference/calicoctl/node/overview.mdx +++ /dev/null @@ -1,47 +0,0 @@ ---- -description: Commands for calicoctl node. ---- - -# calicoctl node - -This section describes the `calicoctl node` commands. - -Read the [calicoctl Overview](../overview.mdx) -for a full list of calicoctl commands. - -Note that if you run `calicoctl` in a container, `calicoctl node ...` commands will -not work (they need access to parts of the host filesystem). - -## Displaying the help text for 'calicoctl node' commands - -Run `calicoctl node --help` to display the following help menu for the -commands. - -``` -Usage: - calicoctl node [...] - - run Run the Calico node container image - status View the current status of a Calico node. - diags Gather a diagnostics bundle for a Calico node. - checksystem Verify the compute host is able to run a Calico node instance. - -Options: - -h --help Show this screen. - -Description: - Node specific commands for calicoctl. These commands must be run directly on - the compute host running the Calico node instance. - - See 'calicoctl node --help' to read about a specific subcommand. -``` - -## Node specific commands - -Details on the `calicoctl node` commands are described in the documents linked below -organized by sub command. - -- [calicoctl node run](run.mdx) -- [calicoctl node status](status.mdx) -- [calicoctl node diags](diags.mdx) -- [calicoctl node checksystem](checksystem.mdx) diff --git a/calico_versioned_docs/version-3.29/reference/calicoctl/node/run.mdx b/calico_versioned_docs/version-3.29/reference/calicoctl/node/run.mdx deleted file mode 100644 index 9ddf575ccc..0000000000 --- a/calico_versioned_docs/version-3.29/reference/calicoctl/node/run.mdx +++ /dev/null @@ -1,375 +0,0 @@ ---- -description: Command and options for running a Calico node. ---- - -# calicoctl node run - -This sections describes the `calicoctl node run` command. - -Read the [calicoctl Overview](../overview.mdx) -for a full list of calicoctl commands. - -## Displaying the help text for 'calicoctl node run' command - -Run `calicoctl node run --help` to display the following help menu for the -command. - -``` -Usage: - calicoctl node run [--ip=] [--ip6=] [--as=] - [--name=] - [--ip-autodetection-method=] - [--ip6-autodetection-method=] - [--log-dir=] - [--node-image=] - [--backend=(bird|none)] - [--config=] - [--felix-config=] - [--no-default-ippools] - [--dryrun] - [--init-system] - [--disable-docker-networking] - [--docker-networking-ifprefix=] - [--use-docker-networking-container-labels] - -Options: - -h --help Show this screen. - --name= The name of the Calico node. If this is not - supplied it defaults to the host name. - --as= Set the AS number for this node. If omitted, it - will use the value configured on the node resource. - If there is no configured value and --as option is - omitted, the node will inherit the global AS number - (see 'calicoctl config' for details). - --ip= Set the local IPv4 routing address for this node. - If omitted, it will use the value configured on the - node resource. If there is no configured value - and the --ip option is omitted, the node will - attempt to autodetect an IP address to use. Use a - value of 'autodetect' to always force autodetection - of the IP each time the node starts. - --ip6= Set the local IPv6 routing address for this node. - If omitted, it will use the value configured on the - node resource. If there is no configured value - and the --ip6 option is omitted, the node will not - route IPv6. Use a value of 'autodetect' to force - autodetection of the IP each time the node starts. - --ip-autodetection-method= - Specify the autodetection method for detecting the - local IPv4 routing address for this node. The valid - options are: - > first-found - Use the first valid IP address on the first - enumerated interface (common known exceptions are - filtered out, e.g. the docker bridge). It is not - recommended to use this if you have multiple - external interfaces on your host. - > can-reach= - Use the interface determined by your host routing - tables that will be used to reach the supplied - destination IP or domain name. - > interface= - Use the first valid IP address found on interfaces - named as per the first matching supplied interface - name regex. Regexes are separated by commas - (e.g. eth.*,enp0s.*). - > skip-interface= - Use the first valid IP address on the first - enumerated interface (same logic as first-found - above) that does NOT match with any of the - specified interface name regexes. Regexes are - separated by commas (e.g. eth.*,enp0s.*). - [default: first-found] - --ip6-autodetection-method= - Specify the autodetection method for detecting the - local IPv6 routing address for this node. See - ip-autodetection-method flag for valid options. - [default: first-found] - --log-dir= The directory containing Calico logs. - [default: /var/log/calico] - --node-image= - Docker image to use for Calico's per-node container. - [default: $[registry]$[imageNames.calico/node]:latest] - --backend=(bird|none) - Specify which networking backend to use. When set - to "none", Calico node runs in policy only mode. - [default: bird] - --dryrun Output the appropriate command, without starting the - container. - --init-system Run the appropriate command to use with an init - system. - --no-default-ippools Do not create default pools upon startup. - Default IP pools will be created if this is not set - and there are no pre-existing Calico IP pools. - --disable-docker-networking - Disable Docker networking. - --docker-networking-ifprefix= - Interface prefix to use for the network interface - within the Docker containers that have been networked - by the Calico driver. - [default: cali] - --use-docker-networking-container-labels - Extract the Calico-namespaced Docker container labels - (org.projectcalico.label.*) and apply them to the - container endpoints for use with Calico policy. - This option is only valid when using Calico Docker - networking, and when enabled traffic must be - explicitly allowed by configuring Calico policies. - -c --config= Path to the file containing connection - configuration in YAML or JSON format. - [default: /etc/calico/calicoctl.cfg] - --felix-config= - Path to the file containing Felix - configuration in YAML or JSON format. - -Description: - This command is used to start a $[nodecontainer] container instance which provides - Calico networking and network policy on your compute host. -``` - -### Kubernetes as the datastore - -When $[prodname] is configured to use the Kubernetes API as the datastore, BGP routing is _currently_ -not supported. Many of the command line options related to BGP routing will -have no effect. These include: - -- `--ip`, `--ip6`, `--ip-autodetection-method`, `--ip6-autodetection-method` -- `--as` -- `--backend` - -### Examples - -Start the $[nodecontainer] with a pre-configured IPv4 address for BGP. - -```bash -sudo calicoctl node run -``` - -An example response follows. - -``` -Running command to load modules: modprobe -a xt_set ip6_tables -Enabling IPv4 forwarding -Enabling IPv6 forwarding -Increasing conntrack limit -Running the following command: - -docker run --net=host --privileged --name=$[noderunning] -d --restart=always -e ETCD_SCHEME=http -e HOSTNAME=calico -e ETCD_AUTHORITY=127.0.0.1:2379 -e AS= -e NO_DEFAULT_POOLS= -e ETCD_ENDPOINTS= -e IP= -e IP6= -e CALICO_NETWORKING_BACKEND=bird -v /var/run/docker.sock:/var/run/docker.sock -v /var/run/calico:/var/run/calico -v /lib/modules:/lib/modules -v /var/log/calico:/var/log/calico -v /run/docker/plugins:/run/docker/plugins $[registry]$[imageNames.calico/node]:$[releaseTitle] - -Waiting for etcd connection... -Using configured IPv4 address: 192.0.2.0 -No IPv6 address configured -Using global AS number -WARNING: Could not confirm that the provided IPv4 address is assigned to this host. -Calico node name: calico -Calico node started successfully -``` - -#### IP Autodetection method examples - -The node resource includes IPv4 and IPv6 routing IP addresses that should -match those on one of the host interfaces. These IP addresses may be -configured in advance by configuring the node resource prior to starting the -`$[nodecontainer]` service, alternatively, the addresses may either be explicitly -specified or autodetected through options on the `calicoctl run` command. - -There are different autodetection methods available and you should use the one -best suited to your deployment. If you are able to explicitly specify the IP -addresses, that is always preferred over autodetection. This section describes -the available methods for autodetecting the hosts IP addresses. - -An IPv4 address is always required, and so if no address was previously -configured in the node resource, and no address was specified on the CLI, then -we will attempt to autodetect an IPv4 address. An IPv6 address, however, will -only be autodetected when explicitly requested. - -To force autodetection of an IPv4 address, use the option `--ip=autodetect`. To -force autodetection of an IPv6 address, use the option `--ip6=autodetect`. - -To set the autodetection method for IPv4, use the `--ip-autodetection-method` option. -To set the autodetection method for IPv6, use the `--ip6-autodetection-method` option. - -:::note - -If you are starting the `$[nodecontainer]` container directly (and not using the -`calicoctl run` helper command), the options are passed in environment -variables. These are described in -[Configuring `$[nodecontainer]`](../../configure-calico-node.mdx). - -::: - -**first-found** - -The `first-found` option enumerates all interface IP addresses and returns the -first valid IP address (based on IP version and type of address) on -the first valid interface. Certain known "local" interfaces -are omitted, such as the docker bridge. The order that both the interfaces -and the IP addresses are listed is system dependent. - -This is the default detection method. However, since this method only makes a -very simplified guess, it is recommended to either configure the node with a -specific IP address, or to use one of the other detection methods. - -An example with first-found auto detection method explicitly specified follows - -```bash -sudo calicoctl node run --ip autodetect --ip-autodetection-method first-found -``` - -**can-reach=DESTINATION** - -The `can-reach` method uses your local routing to determine which IP address -will be used to reach the supplied destination. Both IP addresses and domain -names may be used. - -An example with IP detection using a can-reach IP address: - -```bash -sudo calicoctl node run --ip autodetect --ip-autodetection-method can-reach=8.8.8.8 -``` - -An example with IP detection using a can-reach domain name: - -```bash -sudo calicoctl node run --ip autodetect --ip-autodetection-method can-reach=www.google.com -``` - -**interface=INTERFACE-REGEX,INTERFACE-REGEX,...** - -The `interface` method uses the supplied interface regular expressions (golang -syntax) to enumerate matching interfaces and to return the first IP address on -the first interface that matches any of the interface regexes provided. The -order that both the interfaces and the IP addresses are listed is system -dependent. - -Example with IP detection on interface eth0: - -```bash -sudo calicoctl node run --ip autodetect --ip-autodetection-method interface=eth0 -``` - -Example with IP detection on interfaces eth0, eth1, eth2 etc.: - -```bash -sudo calicoctl node run --ip autodetect --ip-autodetection-method interface=eth.* -``` - -An example with IP detection on interfaces eth0, eth1, eth2 etc. and wlp2s0: - -```bash -sudo calicoctl node run --ip-autodetect --ip-autodetection-method interface=eth.*,wlp2s0 -``` - -**skip-interface=INTERFACE-REGEX,INTERFACE-REGEX,...** - -The `skip-interface` method uses the supplied interface regular expressions (golang -syntax) to enumerate all interface IP addresses and returns the first valid IP address -(based on IP version and type of address) that does not match the listed regular -expressions. Like the `first-found` option, it also skips by default certain known -"local" interfaces such as the docker bridge. The order that both the interfaces -and the IP addresses are listed is system dependent. - -This method has the ability to take in multiple regular expressions separated by `,`. -Specifying only one regular expression for interfaces to skip will also work and a -terminating `,` character does not need to be specified for those cases. - -### Options - -``` - --name= The name of the Calico node. If this is not - supplied it defaults to the host name. - --as= Set the AS number for this node. If omitted, it - will use the value configured on the node resource. - If there is no configured value and --as option is - omitted, the node will inherit the global AS number - (see 'calicoctl config' for details). - --ip= Set the local IPv4 routing address for this node. - If omitted, it will use the value configured on the - node resource. If there is no configured value - and the --ip option is omitted, the node will - attempt to autodetect an IP address to use. Use a - value of 'autodetect' to always force autodetection - of the IP each time the node starts. - --ip6= Set the local IPv6 routing address for this node. - If omitted, it will use the value configured on the - node resource. If there is no configured value - and the --ip6 option is omitted, the node will not - route IPv6. Use a value of 'autodetect' to force - autodetection of the IP each time the node starts. - --ip-autodetection-method= - Specify the autodetection method for detecting the - local IPv4 routing address for this node. The valid - options are: - > first-found - Use the first valid IP address on the first - enumerated interface (common known exceptions are - filtered out, e.g. the docker bridge). It is not - recommended to use this if you have multiple - external interfaces on your host. - > can-reach= - Use the interface determined by your host routing - tables that will be used to reach the supplied - destination IP or domain name. - > interface= - Use the first valid IP address found on interfaces - named as per the first matching supplied interface - name regex. Regexes are separated by commas - (e.g. eth.*,enp0s.*). - > skip-interface= - Use the first valid IP address on the first - enumerated interface (same logic as first-found - above) that does NOT match with any of the - specified interface name regexes. Regexes are - separated by commas (e.g. eth.*,enp0s.*). - [default: first-found] - --ip6-autodetection-method= - Specify the autodetection method for detecting the - local IPv6 routing address for this node. See - ip-autodetection-method flag for valid options. - [default: first-found] - --log-dir= The directory containing Calico logs. - [default: /var/log/calico] - --node-image= - Docker image to use for Calico's per-node container. - [default: $[registry]$[imageNames.calico/node]:latest] - --backend=(bird|none) - Specify which networking backend to use. When set - to "none", Calico node runs in policy only mode. - [default: bird] - --dryrun Output the appropriate command, without starting the - container. - --init-system Run the appropriate command to use with an init - system. - --no-default-ippools Do not create default pools upon startup. - Default IP pools will be created if this is not set - and there are no pre-existing Calico IP pools. - --disable-docker-networking - Disable Docker networking. - --docker-networking-ifprefix= - Interface prefix to use for the network interface - within the Docker containers that have been networked - by the Calico driver. - [default: cali] - --use-docker-networking-container-labels - Extract the Calico-namespaced Docker container labels - (org.projectcalico.label.*) and apply them to the - container endpoints for use with Calico policy. - This option is only valid when using Calico Docker - networking, and when enabled traffic must be - explicitly allowed by configuring Calico policies. -``` - -### General options - -``` --c --config= Path to the file containing connection - configuration in YAML or JSON format. - [default: /etc/calico/calicoctl.cfg] -``` - -## See also - -- [Installing calicoctl](../../../operations/calicoctl/install.mdx) -- [Resources](../../resources/overview.mdx) for details on all valid resources, including file format - and schema -- [Policy](../../resources/networkpolicy.mdx) for details on the $[prodname] selector-based policy model diff --git a/calico_versioned_docs/version-3.29/reference/calicoctl/node/status.mdx b/calico_versioned_docs/version-3.29/reference/calicoctl/node/status.mdx deleted file mode 100644 index 6024a56cc6..0000000000 --- a/calico_versioned_docs/version-3.29/reference/calicoctl/node/status.mdx +++ /dev/null @@ -1,51 +0,0 @@ ---- -description: Command to check status of a Calico node instance. ---- - -# calicoctl node status - -This sections describes the `calicoctl node status` command. - -Read the [calicoctl Overview](../overview.mdx) -for a full list of calicoctl commands. - -## Displaying the help text for 'calicoctl node status' command - -Run `calicoctl node status --help` to display the following help menu for the -command. - -``` -Usage: - calicoctl node status - -Options: - -h --help Show this screen. - -Description: - Check the status of the Calico node instance. This includes the status and - uptime of the node instance, and BGP peering states. -``` - -### Examples - -Check the status of a $[prodname] instance. - -```bash -sudo calicoctl node status -``` - -Some sample results follow,. - -``` -Calico process is running. - -IPv4 BGP status -+--------------+-------------------+-------+----------+-------------+ -| PEER ADDRESS | PEER TYPE | STATE | SINCE | INFO | -+--------------+-------------------+-------+----------+-------------+ -| 172.17.8.102 | node-to-node mesh | up | 23:30:04 | Established | -+--------------+-------------------+-------+----------+-------------+ - -IPv6 BGP status -No IPv6 peers found. -``` diff --git a/calico_versioned_docs/version-3.29/reference/calicoctl/overview.mdx b/calico_versioned_docs/version-3.29/reference/calicoctl/overview.mdx deleted file mode 100644 index 0e5ef69c95..0000000000 --- a/calico_versioned_docs/version-3.29/reference/calicoctl/overview.mdx +++ /dev/null @@ -1,124 +0,0 @@ ---- -description: The command line interface tool (CLI) to manage Calico network and security policy. ---- - -# calicoctl user reference - -The command line tool, `calicoctl`, makes it easy to manage $[prodname] -network and security policy, as well as other $[prodname] configurations. - -The full list of resources that can be managed, including a description of each, -is described in the [Resource definitions](../resources/overview.mdx) -section. - -:::note - -This section provides full reference information for `calicoctl`. To learn -how to install and configure `calicoctl`, refer to -[Installing calicoctl](../../operations/calicoctl/install.mdx). - -::: - -The calicoctl command line interface provides a number of resource management -commands to allow you to create, modify, delete, and view the different -$[prodname] resources. This section is a command line reference for -`calicoctl`, organized based on the command hierarchy. - -## Top level help - -Run `calicoctl --help` to display the following help menu for the top level -calicoctl commands. - -``` -Usage: - calicoctl [options] [...] - - create Create a resource by file, directory or stdin. - replace Replace a resource by file, directory or stdin. - apply Apply a resource by file, directory or stdin. This creates a resource - if it does not exist, and replaces a resource if it does exists. - patch Patch a pre-existing resource in place. - delete Delete a resource identified by file, directory, stdin or resource type and - name. - get Get a resource identified by file, directory, stdin or resource type and - name. - label Add or update labels of resources. - convert Convert config files between different API versions. - ipam IP address management. - node Calico node management. - version Display the version of calicoctl. - -Options: - -h --help Show this screen. - -l --log-level= Set the log level (one of panic, fatal, error, - warn, info, debug) [default: panic] - --context= The name of the kubeconfig context to use. - --allow-version-mismatch Allow client and cluster versions mismatch. - -Description: - The calicoctl command line tool is used to manage Calico network and security - policy, to view and manage endpoint configuration, and to manage a Calico - node instance. - - See 'calicoctl --help' to read about a specific subcommand. -``` - -:::note - -In a multi cluster environment if you have a [kubeconfig](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) file with multiple cluster contexts it is possible to directly change the context using calicoctl `--context` argument. - -::: - -:::note - -The versions for Calico and calicoctl should be the same and calls to calicoctl will fail if the versions do not match. If needed, this can be overridden by using the `--allow-version-mismatch` argument. - -::: - -## Top level command line options - -Details on the `calicoctl` commands are described in the documents linked below -organized by top level command. - -- [calicoctl create](create.mdx) -- [calicoctl replace](replace.mdx) -- [calicoctl apply](apply.mdx) -- [calicoctl patch](patch.mdx) -- [calicoctl delete](delete.mdx) -- [calicoctl get](get.mdx) -- [calicoctl label](label.mdx) -- [calicoctl convert](convert.mdx) -- [calicoctl ipam](ipam/overview.mdx) -- [calicoctl node](node/index.mdx) -- [calicoctl version](version.mdx) - -## Modifying low-level component configurations - -To update low-level Felix or BGP settings (`FelixConfiguration` and `BGPConfiguration` resource types): - -1. Get the appropriate resource and store the yaml output in a file using `calicoctl get -o yaml --export > config.yaml`. -1. Modify the saved resource file. -1. Update the resource using `apply` or `replace` command: `calicoctl replace -f config.yaml`. - -See [Configuring Felix](../felix/configuration.mdx) for more details. - -## Supported resource definition aliases - -The following table lists supported aliases for $[prodname] resources when using `calicoctl`. Note that all aliases -are **case-insensitive**. - -| Resource definition | Supported calicoctl aliases | -| :----------------------------------- | :---------------------------------------------------------------------------- | -| BGP configuration | `bgpconfig`, `bgpconfigurations`, `bgpconfigs` | -| BGP peer | `bgppeer`, `bgppeers`, `bgpp`, `bgpps`, `bp`, `bps` | -| Felix configuration | `felixconfiguration`, `felixconfig`, `felixconfigurations`, `felixconfigs` | -| Global network policy | `globalnetworkpolicy`, `globalnetworkpolicies`, `gnp`, `gnps` | -| Global network set | `globalnetworkset`, `globalnetworksets` | -| Host endpoint | `hostendpoint`, `hostendpoints`, `hep`, `heps` | -| IP pool | `ippool`, `ippools`, `ipp`, `ipps`, `pool`, `pools` | -| IP reservation | `ipreservation`, `ipreservations`, `reservation`, `reservations` | -| Kubernetes controllers configuration | `kubecontrollersconfiguration`, `kubecontrollersconfig` | -| Network policy | `networkpolicy`, `networkpolicies`, `policy`, `np`, `policies`, `pol`, `pols` | -| Node | `node`, `nodes`, `no`, `nos` | -| Profiles | `profile`, `profiles`, `pro`, `pros` | -| Workload endpoint | `workloadendpoint`, `workloadendpoints`, `wep`, `weps` | diff --git a/calico_versioned_docs/version-3.29/reference/calicoctl/patch.mdx b/calico_versioned_docs/version-3.29/reference/calicoctl/patch.mdx deleted file mode 100644 index ca35018872..0000000000 --- a/calico_versioned_docs/version-3.29/reference/calicoctl/patch.mdx +++ /dev/null @@ -1,116 +0,0 @@ ---- -description: Command to update a node with a patch. ---- - -# calicoctl patch - -This sections describes the `calicoctl patch` command. - -Read the [calicoctl command line interface user reference](overview.mdx) -for a full list of calicoctl commands. - -## Displaying the help text for 'calicoctl patch' command - -Run `calicoctl patch --help` to display the following help menu for the -command. - -``` -Usage: - calicoctl patch --patch= [--type=] [--config=] [--namespace=] - -Examples: - # Partially update a node using a strategic merge patch. - calicoctl patch node node-0 --patch '{"spec":{"bgp": {"routeReflectorClusterID": "CLUSTER_ID"}}}' - - # Partially update a node using a json merge patch. - calicoctl patch node node-0 --patch '{"spec":{"bgp": {"routeReflectorClusterID": "CLUSTER_ID"}}}' --type json - -Options: - -h --help Show this screen. - -p --patch= Spec to use to patch the resource. - -t --type= Format of patch type: - strategic Strategic merge patch (default) - json JSON Patch, RFC 6902 (not yet implemented) - merge JSON Merge Patch, RFC 7386 (not yet implemented) - -c --config= Path to the file containing connection - configuration in YAML or JSON format. - [default: ` + constants.DefaultConfigPath + `] - -n --namespace= Namespace of the resource. - Only applicable to NetworkPolicy, NetworkSet, and WorkloadEndpoint. - Uses the default namespace if not specified. - --context= The name of the kubeconfig context to use. - -Description: - The patch command is used to patch a specific resource by type and identifiers in place. - Currently, only JSON format is accepted. - - Valid resource types are: - - - bgpconfiguration - - bgpfilter - - bgppeer - - clusterinformation - - felixconfiguration - - globalnetworkpolicy - - globalnetworkset - - hostendpoint - - ippool - - ipreservation - - kubecontrollersconfiguration - - networkpolicy - - networkset - - node - - profile - - tier - - workloadendpoint - - The resource type is case-insensitive and may be pluralized. - Attempting to patch a resource that does not exists is treated as a - terminating error unless the --skip-not-exists flag is set. If this flag is - set, resources that do not exist are skipped. - - When patching resources by type, only a single type may be specified at a - time. The name is required along with any and other identifiers required to - uniquely identify a resource of the specified type. -``` - -### Examples - -1. Patch an IP Pool to enable outgoing NAT: - - ```bash - calicoctl patch ippool ippool1 -p '{"spec":{"natOutgoing": true}}' - ``` - - Results indicate that a resource was successfully patched: - - ``` - Successfully patched 1 'ipPool' resource - ``` - -### Options - -``` --p --patch= Spec to use to patch the resource. --t --type= Format of patch type: - strategic Strategic merge patch (default) - json JSON Patch, RFC 6902 (not yet implemented) - merge JSON Merge Patch, RFC 7386 (not yet implemented) --n --namespace= Namespace of the resource. - Only applicable to NetworkPolicy and WorkloadEndpoint. - Uses the default namespace if not specified. -``` - -### General options - -``` --c --config= Path to the file containing connection - configuration in YAML or JSON format. - [default: /etc/calico/calicoctl.cfg] -``` - -## See also - -- [Installing calicoctl](../../operations/calicoctl/install.mdx) -- [Resources](../resources/overview.mdx) for details on all valid resources, including file format - and schema diff --git a/calico_versioned_docs/version-3.29/reference/calicoctl/replace.mdx b/calico_versioned_docs/version-3.29/reference/calicoctl/replace.mdx deleted file mode 100644 index 26d59c7278..0000000000 --- a/calico_versioned_docs/version-3.29/reference/calicoctl/replace.mdx +++ /dev/null @@ -1,139 +0,0 @@ ---- -description: Command to replace an existing policy with a different one. ---- - -# calicoctl replace - -This sections describes the `calicoctl replace` command. - -Read the [calicoctl command line interface user reference](overview.mdx) -for a full list of calicoctl commands. - -:::note - -The available actions for a specific resource type may be -limited based on the datastore used for $[prodname] (etcdv3 / Kubernetes API). -Please refer to the -[Resources section](../resources/overview.mdx) -for details about each resource type. - -::: - -## Displaying the help text for 'calicoctl replace' command - -Run `calicoctl replace --help` to display the following help menu for the -command. - -``` -Usage: - calicoctl replace --filename= [--recursive] [--skip-empty] [--config=] [--namespace=] - -Examples: - # Replace a policy using the data in policy.yaml. - calicoctl replace -f ./policy.yaml - - # Replace a policy based on the JSON passed into stdin. - cat policy.json | calicoctl replace -f - - -Options: - -h --help Show this screen. - -f --filename= Filename to use to replace the resource. If set - to "-" loads from stdin. If filename is a directory, this command is - invoked for each .json .yaml and .yml file within that directory, - terminating after the first failure. - -R --recursive Process the filename specified in -f or --filename recursively. - --skip-empty Do not error if any files or directory specified using -f or --filename contain no - data. - -c --config= Path to the file containing connection - configuration in YAML or JSON format. - [default: /etc/calico/calicoctl.cfg] - -n --namespace= Namespace of the resource. - Only applicable to NetworkPolicy, NetworkSet, and WorkloadEndpoint. - Uses the default namespace if not specified. - --context= The name of the kubeconfig context to use. - -Description: - The replace command is used to replace a set of resources by filename or - stdin. JSON and YAML formats are accepted. - - Valid resource types are: - - - bgpconfiguration - - bgpfilter - - bgppeer - - clusterinformation - - felixconfiguration - - globalnetworkpolicy - - globalnetworkset - - hostendpoint - - ippool - - ipreservation - - kubecontrollersconfiguration - - networkpolicy - - networkset - - node - - profile - - tier - - workloadendpoint - - Attempting to replace a resource that does not exist is treated as a - terminating error. - - The output of the command indicates how many resources were successfully - replaced, and the error reason if an error occurred. - - The resources are replaced in the order they are specified. In the event of - a failure replacing a specific resource it is possible to work out which - resource failed based on the number of resources successfully replaced. - - When replacing a resource, the complete resource spec must be provided, it is - not sufficient to supply only the fields that are being updated. -``` - -### Examples - -1. Replace a set of resources (of mixed type) using the data in resources.yaml. - - ```bash - calicoctl replace -f ./resources.yaml - ``` - - Results indicate that 8 resources were successfully replaced. - - ``` - Successfully replaced 8 resource(s) - ``` - -1. Replace a policy based on the JSON passed into stdin. - - ```bash - cat policy.json | calicoctl replace -f - - ``` - - Results indicate the policy does not exist. - - ``` - Failed to replace any 'policy' resources: resource does not exist: Policy(name=dbPolicy) - ``` - -### Options - -``` --f --filename= Filename to use to replace the resource. If set - to "-" loads from stdin. -``` - -### General options - -``` --c --config= Path to the file containing connection - configuration in YAML or JSON format. - [default: /etc/calico/calicoctl.cfg] -``` - -## See also - -- [Installing calicoctl](../../operations/calicoctl/install.mdx) -- [Resources](../resources/overview.mdx) for details on all valid resources, including file format - and schema -- [NetworkPolicy](../resources/networkpolicy.mdx) for details on the $[prodname] selector-based policy model diff --git a/calico_versioned_docs/version-3.29/reference/calicoctl/version.mdx b/calico_versioned_docs/version-3.29/reference/calicoctl/version.mdx deleted file mode 100644 index 2ef0f4e703..0000000000 --- a/calico_versioned_docs/version-3.29/reference/calicoctl/version.mdx +++ /dev/null @@ -1,46 +0,0 @@ ---- -description: Command to display the calicoctl CLI version. ---- - -# calicoctl version - -import CalicoctlVersion from '@site/calico_versioned_docs/version-3.29/_includes/content/_calicoctl-version.mdx'; - -This section describes the `calicoctl version` command. - -Read the [calicoctl Overview](overview.mdx) -for a full list of calicoctl commands. - -## Displaying the help text for 'calicoctl version' commands - -Run `calicoctl version --help` to display the following help menu for the -commands. - -``` -Usage: - calicoctl version [--config=] [--poll=] - -Options: - -h --help Show this screen. - -c --config= Path to the file containing connection configuration in - YAML or JSON format. - [default: /etc/calico/calicoctl.cfg] - --poll= Poll for changes to the cluster information at a frequency specified using POLL duration - (e.g. 1s, 10m, 2h etc.). A value of 0 (the default) disables polling. - -Description: - Display the version of calicoctl. -``` - -### Example - -Use `calicoctl version` to obtain the following data. - - - -\* To obtain these values, you must configure `calicoctl` -[to connect to your datastore](../../operations/calicoctl/configure/overview.mdx). - -## See also - -- [Installing calicoctl](../../operations/calicoctl/install.mdx). diff --git a/calico_versioned_docs/version-3.29/reference/component-versions.mdx b/calico_versioned_docs/version-3.29/reference/component-versions.mdx deleted file mode 100644 index c3a5f0b1e5..0000000000 --- a/calico_versioned_docs/version-3.29/reference/component-versions.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: A list of component versions for Calico ---- - -import ComponentVersions from '@site/calico_versioned_docs/version-3.29/_includes/components/ComponentVersions'; - -# Component versions - -This page lists the specific component versions that go into each release of $[prodname]. - - \ No newline at end of file diff --git a/calico_versioned_docs/version-3.29/reference/configure-calico-node.mdx b/calico_versioned_docs/version-3.29/reference/configure-calico-node.mdx deleted file mode 100644 index f63718cb71..0000000000 --- a/calico_versioned_docs/version-3.29/reference/configure-calico-node.mdx +++ /dev/null @@ -1,324 +0,0 @@ ---- -description: Customize calico/node using environment variables. ---- - -# Configuring calico/node - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - -The `$[nodecontainer]` container is deployed to every node (on Kubernetes, by a DaemonSet), and runs three internal daemons: - -- Felix, the Calico daemon that runs on every node and provides endpoints. -- BIRD, the BGP daemon that distributes routing information to other nodes. -- confd, a daemon that watches the Calico datastore for config changes and updates BIRD’s config files. - -For manifest-based installations, `$[nodecontainer]` is primarily configured through environment -variables, typically set in the deployment manifest. Individual nodes may also be updated through the Node -custom resource. `$[nodecontainer]` can also be configured through the Calico Operator. - -The rest of this page lists the available configuration options, and is followed by specific considerations for -various settings. - - - - -`$[nodecontainer]` does not need to be configured directly when installed by the operator. For a complete operator -configuration reference, see [the installation API reference documentation][installation]. - - - - -## Environment variables - -### Configuring the default IP pool(s) - -Calico uses IP pools to configure how addresses are allocated to pods, and how networking works for certain -sets of addresses. You can see the full schema for IP pools here. - -`$[nodecontainer]` can be configured to create a default IP pool for you, but only if none already -exist in the cluster. The following options control the parameters on the created pool. - -| Environment | Description | Schema | -| ---------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | -| CALICO_IPV4POOL_CIDR | The IPv4 Pool to create if none exists at start up. It is invalid to define this variable and NO_DEFAULT_POOLS. [Default: First not used in locally of (192.168.0.0/16, 172.16.0.0/16, .., 172.31.0.0/16) ] | IPv4 CIDR | -| CALICO_IPV4POOL_BLOCK_SIZE | Block size to use for the IPv4 Pool created at startup. Block size for IPv4 should be in the range 20-32 (inclusive) [Default: `26`] | int | -| CALICO_IPV4POOL_IPIP | IPIP Mode to use for the IPv4 Pool created at start up. If set to a value other than `Never`, `CALICO_IPV4POOL_VXLAN` should not be set. [Default: `Always`] | Always, CrossSubnet, Never ("Off" is also accepted as a synonym for "Never") | -| CALICO_IPV4POOL_VXLAN | VXLAN Mode to use for the IPv4 Pool created at start up. If set to a value other than `Never`, `CALICO_IPV4POOL_IPIP` should not be set. [Default: `Never`] | Always, CrossSubnet, Never | -| CALICO_IPV4POOL_NAT_OUTGOING | Controls NAT Outgoing for the IPv4 Pool created at start up. [Default: `true`] | boolean | -| CALICO_IPV4POOL_NODE_SELECTOR | Controls the NodeSelector for the IPv4 Pool created at start up. [Default: `all()`] | [selector](resources/ippool.mdx#node-selector) | -| CALICO_IPV6POOL_CIDR | The IPv6 Pool to create if none exists at start up. It is invalid to define this variable and NO_DEFAULT_POOLS. [Default: ``] | IPv6 CIDR | -| CALICO_IPV6POOL_BLOCK_SIZE | Block size to use for the IPv6 POOL created at startup. Block size for IPv6 should be in the range 116-128 (inclusive) [Default: `122`] | int | -| CALICO_IPV6POOL_VXLAN | VXLAN Mode to use for the IPv6 Pool created at start up. [Default: `Never`] | Always, CrossSubnet, Never | -| CALICO_IPV6POOL_NAT_OUTGOING | Controls NAT Outgoing for the IPv6 Pool created at start up. [Default: `false`] | boolean | -| CALICO_IPV6POOL_NODE_SELECTOR | Controls the NodeSelector for the IPv6 Pool created at start up. [Default: `all()`] | [selector](resources/ippool.mdx#node-selector) | -| CALICO_IPV4POOL_DISABLE_BGP_EXPORT | Disable exporting routes over BGP for the IPv4 Pool created at start up. [Default: `false`] | boolean | -| CALICO_IPV6POOL_DISABLE_BGP_EXPORT | Disable exporting routes over BGP for the IPv6 Pool created at start up. [Default: `false`] | boolean | -| NO_DEFAULT_POOLS | Prevents $[prodname] from creating a default pool if one does not exist. [Default: `false`] | boolean | - -### Configuring BGP Networking - -BGP configuration for Calico nodes is normally configured through the [Node](resources/node.mdx), [BGPConfiguration](resources/bgpconfig.mdx), and [BGPPeer](resources/bgppeer.mdx) resources. -`$[nodecontainer]` also exposes some options to allow setting certain fields on these objects, as described -below. - -| Environment | Description | Schema | -| ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------- | -| NODENAME | A unique identifier for this host. See [node name determination](#node-name-determination) for more details. | lowercase string | -| IP | The IPv4 address to assign this host or detection behavior at startup. Refer to [IP setting](#ip-setting) for the details of the behavior possible with this field. | IPv4 | -| IP6 | The IPv6 address to assign this host or detection behavior at startup. Refer to [IP setting](#ip-setting) for the details of the behavior possible with this field. | IPv6 | -| IP_AUTODETECTION_METHOD | The method to use to autodetect the IPv4 address for this host. This is only used when the IPv4 address is being autodetected. See [IP Autodetection methods](#ip-autodetection-methods) for details of the valid methods. [Default: `first-found`] | string | -| IP6_AUTODETECTION_METHOD | The method to use to autodetect the IPv6 address for this host. This is only used when the IPv6 address is being autodetected. See [IP Autodetection methods](#ip-autodetection-methods) for details of the valid methods. [Default: `first-found`] | string | -| AS | The AS number for this node. When specified, the value is saved in the node resource configuration for this host, overriding any previously configured value. When omitted, if an AS number has been previously configured in the node resource, that AS number is used for the peering. When omitted, if an AS number has not yet been configured in the node resource, the node will use the global value (see [example modifying Global BGP settings](../networking/configuring/bgp.mdx) for details.) | int | -| CALICO_ROUTER_ID | Sets the `router id` to use for BGP if no IPv4 address is set on the node. For an IPv6-only system, this may be set to `hash`. It then uses the hash of the nodename to create a 4 byte router id. See note below. [Default: ``] | string | -| CALICO_K8S_NODE_REF | The name of the corresponding node object in the Kubernetes API. When set, used for correlating this node with events from the Kubernetes API. | string | - -### Configuring Datastore Access - -| Environment | Description | Schema | -| -------------- | ------------------------------------------ | ------------------ | -| DATASTORE_TYPE | Type of datastore. [Default: `kubernetes`] | kubernetes, etcdv3 | - -#### Configuring Kubernetes Datastore Access - -| Environment | Description | Schema | -| ---------------- | ------------------------------------------------------------------------------ | ------ | -| KUBECONFIG | When using the Kubernetes datastore, the location of a kubeconfig file to use. | string | -| K8S_API_ENDPOINT | Location of the Kubernetes API. Not required if using kubeconfig. | string | -| K8S_CERT_FILE | Location of a client certificate for accessing the Kubernetes API. | string | -| K8S_KEY_FILE | Location of a client key for accessing the Kubernetes API. | string | -| K8S_CA_FILE | Location of a CA for accessing the Kubernetes API. | string | - -:::note - -When $[prodname] is configured to use the Kubernetes API as the datastore, the environments -used for BGP configuration are ignored—this includes selection of the node AS number (AS) -and all of the IP selection options (IP, IP6, IP_AUTODETECTION_METHOD, IP6_AUTODETECTION_METHOD). - -::: - -#### Configuring etcd Datastore Access - -| Environment | Description | Schema | -| ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------ | -| ETCD_ENDPOINTS | A comma separated list of etcd endpoints [Example: `http://127.0.0.1:2379,http://127.0.0.2:2379`] (required) | string | -| ETCD_DISCOVERY_SRV | Domain name to discover etcd endpoints via SRV records. Mutually exclusive with `ETCD_ENDPOINTS`. [Example: `example.com`] (optional) | string | -| ETCD_KEY_FILE | Path to the file containing the private key matching the `$[nodecontainer]` client certificate. Enables `$[nodecontainer]` to participate in mutual TLS authentication and identify itself to the etcd server. Example: `/etc/node/key.pem` (optional) | string | -| ETCD_CERT_FILE | Path to the file containing the client certificate issued to `$[nodecontainer]`. Enables `$[nodecontainer]` to participate in mutual TLS authentication and identify itself to the etcd server. Example: `/etc/node/cert.pem` (optional) | string | -| ETCD_CA_CERT_FILE | Path to the file containing the root certificate of the certificate authority (CA) that issued the etcd server certificate. Configures `$[nodecontainer]` to trust the CA that signed the root certificate. The file may contain multiple root certificates, causing `$[nodecontainer]` to trust each of the CAs included. Example: `/etc/node/ca.pem` | string | - -### Configuring Logging - -| Environment | Description | Schema | -| --------------------------- | -------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------- | -| CALICO_DISABLE_FILE_LOGGING | Disables logging to file. [Default: "false"] | string | -| CALICO_STARTUP_LOGLEVEL | The log severity above which startup `$[nodecontainer]` logs are sent to the stdout. [Default: `ERROR`] | DEBUG, INFO, WARNING, ERROR, CRITICAL, or NONE (case-insensitive) | - -### Configuring CNI Plugin - -`$[nodecontainer]` has a few options that are configurable based on the CNI plugin and CNI plugin -configuration used on the cluster. - -| Environment | Description | Schema | -| ----------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- | -| USE_POD_CIDR | Use the Kubernetes `Node.Spec.PodCIDR` field when using host-local IPAM. Requires Kubernetes API datastore. This field is required when using the Kubernetes API datastore with host-local IPAM. [Default: false] | boolean | -| CALICO_MANAGE_CNI | Tells Calico to update the kubeconfig file at /host/etc/cni/net.d/calico-kubeconfig on credentials change. [Default: true] | boolean | - -### Other Environment Variables - -| Environment | Description | Schema | -| ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------- | -| DISABLE_NODE_IP_CHECK | Skips checks for duplicate Node IPs. This can reduce the load on the cluster when a large number of Nodes are restarting. [Default: `false`] | boolean | -| WAIT_FOR_DATASTORE | Wait for connection to datastore before starting. If a successful connection is not made, node will shutdown. [Default: `false`] | boolean | -| CALICO_NETWORKING_BACKEND | The networking backend to use. In `bird` mode, Calico will provide BGP networking using the BIRD BGP daemon; VXLAN networking can also be used. In `vxlan` mode, only VXLAN networking is provided; BIRD and BGP are disabled. If set to `none` (also known as policy-only mode), both BIRD and VXLAN are disabled. [Default: `bird`] | bird, vxlan, none | -| CLUSTER_TYPE | Contains comma delimited list of indicators about this cluster. e.g. k8s, mesos, kubeadm, canal, bgp | string | - -## Appendix - -### Node name determination - -The `$[nodecontainer]` must know the name of the node on which it is running. The node name is used to -retrieve the [Node resource](resources/node.mdx) configured for this node if it exists, or to create a new node resource representing the node if it does not. It is -also used to associate the node with per-node [BGP configuration](resources/bgpconfig.mdx), [felix configuration](resources/felixconfig.mdx), and endpoints. - -When launched, the `$[nodecontainer]` container sets the node name according to the following order of precedence: - -1. The value specified in the `NODENAME` environment variable, if set. -1. The value specified in `/var/lib/calico/nodename`, if it exists. -1. The value specified in the `HOSTNAME` environment variable, if set. -1. The hostname as returned by the operating system, converted to lowercase. - -Once the node has determined its name, the value will be cached in `/var/lib/calico/nodename` for future use. - -For example, if given the following conditions: - -- `NODENAME=""` -- `/var/lib/calico/nodename` does not exist -- `HOSTNAME="host-A"` -- The operating system returns "host-A.internal.myorg.com" for the hostname - -$[nodecontainer] will use "host-a" for its name and will write the value in `/var/lib/calico/nodename`. If $[nodecontainer] -is then restarted, it will use the cached value of "host-a" read from the file on disk. - -### IP setting - -The IP (for IPv4) and IP6 (for IPv6) environment variables are used to set, -force autodetection, or disable auto detection of the address for the -appropriate IP version for the node. When the environment variable is set, -the address is saved in the -[node resource configuration](resources/node.mdx) -for this host, overriding any previously configured value. - -calico/node will attempt to detect subnet information from the host, and augment the provided address -if possible. - -#### IP setting special case values - -There are several special case values that can be set in the IP(6) environment variables, they are: - -- Not set or empty string: Any previously set address on the node - resource will be used. If no previous address is set on the node resource - the two versions behave differently: - - IP will do autodetection of the IPv4 address and set it on the node - resource. - - IP6 will not do autodetection. -- `autodetect`: Autodetection will always be performed for the IP address and - the detected address will overwrite any value configured in the node - resource. -- `none`: Autodetection will not be performed (this is useful to disable IPv4). - -### IP autodetection methods - -When $[prodname] is used for routing, each node must be configured with an IPv4 -address and/or an IPv6 address that will be used to route between -nodes. To eliminate node specific IP address configuration, the `$[nodecontainer]` -container can be configured to autodetect these IP addresses. In many systems, -there might be multiple physical interfaces on a host, or possibly multiple IP -addresses configured on a physical interface. In these cases, there are -multiple addresses to choose from and so autodetection of the correct address -can be tricky. - -The IP autodetection methods are provided to improve the selection of the -correct address, by limiting the selection based on suitable criteria for your -deployment. - -The following sections describe the available IP autodetection methods. - -#### first-found - -The `first-found` option enumerates all interface IP addresses and returns the -first valid IP address (based on IP version and type of address) on -the first valid interface. Certain known "local" interfaces -are omitted, such as the docker bridge. The order that both the interfaces -and the IP addresses are listed is system dependent. - -This is the default detection method. However, since this method only makes a -very simplified guess, it is recommended to either configure the node with a -specific IP address, or to use one of the other detection methods. - -e.g. - -``` -IP_AUTODETECTION_METHOD=first-found -IP6_AUTODETECTION_METHOD=first-found -``` - -#### kubernetes-internal-ip - -The `kubernetes-internal-ip` method will select the first internal IP address listed in the Kubernetes node's `Status.Addresses` field - -Example: - -``` -IP_AUTODETECTION_METHOD=kubernetes-internal-ip -IP6_AUTODETECTION_METHOD=kubernetes-internal-ip -``` - -#### can-reach=DESTINATION - -The `can-reach` method uses your local routing to determine which IP address -will be used to reach the supplied destination. Both IP addresses and domain -names may be used. - -Example using IP addresses: - -``` -IP_AUTODETECTION_METHOD=can-reach=8.8.8.8 -IP6_AUTODETECTION_METHOD=can-reach=2001:4860:4860::8888 -``` - -Example using domain names: - -``` -IP_AUTODETECTION_METHOD=can-reach=www.google.com -IP6_AUTODETECTION_METHOD=can-reach=www.google.com -``` - -#### interface=INTERFACE-REGEX - -The `interface` method uses the supplied interface [regular expression](https://pkg.go.dev/regexp) -to enumerate matching interfaces and to return the first IP address on -the first matching interface. The order that both the interfaces -and the IP addresses are listed is system dependent. - -Example with valid IP address on interface eth0, eth1, eth2 etc.: - -``` -IP_AUTODETECTION_METHOD=interface=eth.* -IP6_AUTODETECTION_METHOD=interface=eth.* -``` - -#### skip-interface=INTERFACE-REGEX - -The `skip-interface` method uses the supplied interface [regular expression](https://pkg.go.dev/regexp) -to exclude interfaces and to return the first IP address on the first -interface that does not match. The order that both the interfaces -and the IP addresses are listed is system dependent. - -Example with valid IP address on interface exclude enp6s0f0, eth0, eth1, eth2 etc.: - -``` -IP_AUTODETECTION_METHOD=skip-interface=enp6s0f0,eth.* -IP6_AUTODETECTION_METHOD=skip-interface=enp6s0f0,eth.* -``` - -#### cidr=CIDR - -The `cidr` method will select any IP address from the node that falls within the given CIDRs. For example: - -Example: - -``` -IP_AUTODETECTION_METHOD=cidr=10.0.1.0/24,10.0.2.0/24 -IP6_AUTODETECTION_METHOD=cidr=2001:4860::0/64 -``` - -### Node readiness - -The `calico/node` container supports an exec readiness endpoint. - -To access this endpoint, use the following command. - -```bash -docker exec calico-node /bin/calico-node [flag] -``` - -Substitute `[flag]` with one or more of the following. - -- `-bird-ready` -- `-bird6-ready` -- `-felix-ready` - -The BIRD readiness endpoint ensures that the BGP mesh is healthy by verifying that all BGP peers are established and -no graceful restart is in progress. If the BIRD readiness check is failing due to unreachable peers that are no longer -in the cluster, see [decommissioning a node](../operations/decommissioning-a-node.mdx). - -### Setting `CALICO_ROUTER_ID` for IPv6 only system - -Setting CALICO_ROUTER_ID to value `hash` will use a hash of the configured nodename for the router ID. This should only be used in IPv6-only systems with no IPv4 address to use for the router ID. Since each node chooses its own router ID in isolation, it is possible for two nodes to pick the same ID resulting in a clash. The probability of such a clash grows with cluster size so this feature should not be used in a large cluster (500+ nodes). - - - - - -[installation]: installation/api.mdx diff --git a/calico_versioned_docs/version-3.29/reference/configure-cni-plugins.mdx b/calico_versioned_docs/version-3.29/reference/configure-cni-plugins.mdx deleted file mode 100644 index b9e25cec42..0000000000 --- a/calico_versioned_docs/version-3.29/reference/configure-cni-plugins.mdx +++ /dev/null @@ -1,674 +0,0 @@ ---- -description: Details for configuring the Calico CNI plugins. ---- - -# Configure the Calico CNI plugins - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - -:::note - -The $[prodname] CNI plugins do not need to be configured directly when installed by the operator. -For a complete operator configuration reference, see [the installation API reference documentation][installation]. - -::: - -The $[prodname] CNI plugin is configured through the standard CNI -[configuration mechanism](https://github.com/containernetworking/cni/blob/master/SPEC.md#network-configuration) - -A minimal configuration file that uses $[prodname] for networking -and IPAM looks like this - -```json -{ - "name": "any_name", - "cniVersion": "0.1.0", - "type": "calico", - "ipam": { - "type": "calico-ipam" - } -} -``` - -If the `$[nodecontainer]` container on a node registered with a `NODENAME` other than the node hostname, the CNI plugin on this node must be configured with the same `nodename`: - -```json -{ - "name": "any_name", - "nodename": "", - "type": "calico", - "ipam": { - "type": "calico-ipam" - } -} -``` - -Additional configuration can be added as detailed below. - -## Generic - -### Datastore type - -The following option allows configuration of the $[prodname] datastore type. - -- `datastore_type` (default: etcdv3) - -The $[prodname] CNI plugin supports the following datastore types: - -- etcdv3 (default) -- kubernetes - -### etcd location - -The following options are valid when `datastore_type` is `etcdv3`. - -Configure access to your etcd cluster using the following options. - -| Option name | Default | Description | | -| -------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------ | -| `etcd_endpoints` | None | Comma-separated list of endpoints. Example: `http://127.0.0.1:2379,http://127.0.0.2:2379` | string | -| `etcd_discovery_srv` | None | Domain name to discover etcd endpoints via SRV records. Mutually exclusive with `etcdEndpoints`. Example: `example.com` (optional) | string | -| `etcd_key_file` | None | Path to the file containing the private key matching the CNI plugin's client certificate. Enables the CNI plugin to participate in mutual TLS authentication and identify itself to the etcd server. Example: `/etc/calico-cni/key.pem` (optional) | string | -| `etcd_cert_file` | None | Path to the file containing the client certificate issued to the CNI plugin. Enables the CNI plugin to participate in mutual TLS authentication and identify itself to the etcd server. Example: `/etc/calico-cni/cert.pem` (optional) | string | -| `etcd_ca_cert_file` | None | Path to the file containing the root certificate of the certificate authority (CA) that issued the etcd server certificate. Configures the CNI plugin to trust the CA that signed the root certificate. The file may contain multiple root certificates, causing the CNI plugin to trust each of the CAs included. | string | - -The following options are deprecated. - -- `etcd_authority` (default is `127.0.0.1:2379`) - - If `etcd_authority` is set at the same time as `etcd_endpoints` then `etcd_endpoints` is used. -- `etcd_scheme` (default is `http`) - -### Logging - -Logging is always to `stderr`. Logs are also written to `/var/log/calico/cni/cni.log` on each host by default. - -Logging can be configured using the following options in the netconf. - -| Option name | Default | Description | -| -------------------- | ----------------------------- | --------------------------------------------------------------------------------------------------------- | -| `log_level` | INFO | Logging level. Allowed levels are `ERROR`, `WARNING`, `INFO`, and `DEBUG`. | -| `log_file_path` | `/var/log/calico/cni/cni.log` | Location on each host to write CNI log files to. Logging to file can be disabled by removing this option. | -| `log_file_max_size` | 100 | Max file size in MB log files can reach before they are rotated. | -| `log_file_max_age` | 30 | Max age in days that old log files will be kept on the host before they are removed. | -| `log_file_max_count` | 10 | Max number of rotated log files allowed on the host before they are cleaned up. | - -```json -{ - "name": "any_name", - "cniVersion": "0.1.0", - "type": "calico", - "log_level": "DEBUG", - "log_file_path": "/var/log/calico/cni/cni.log", - "ipam": { - "type": "calico-ipam" - } -} -``` - -### IPAM - -When using $[prodname] IPAM, the following flags determine what IP addresses should be assigned. NOTE: These flags are strings and not boolean values. - -- `assign_ipv4` (default: `"true"`) -- `assign_ipv6` (default: `"false"`) - -A specific IP address can be chosen by using [`CNI_ARGS`](https://github.com/appc/cni/blob/master/SPEC.md#parameters) and setting `IP` to the desired value. - -By default, $[prodname] IPAM will assign IP addresses from all the available IP pools. - -Optionally, the list of possible IPv4 and IPv6 pools can also be specified via the following properties: - -- `ipv4_pools`: An array of CIDR strings or pool names. (e.g., `"ipv4_pools": ["10.0.0.0/24", "20.0.0.0/16", "default-ipv4-ippool"]`) -- `ipv6_pools`: An array of CIDR strings or pool names. (e.g., `"ipv6_pools": ["2001:db8::1/120", "namedpool"]`) - -Example CNI config: - -```json -{ - "name": "any_name", - "cniVersion": "0.1.0", - "type": "calico", - "ipam": { - "type": "calico-ipam", - "assign_ipv4": "true", - "assign_ipv6": "true", - "ipv4_pools": ["10.0.0.0/24", "20.0.0.0/16", "default-ipv4-ippool"], - "ipv6_pools": ["2001:db8::1/120", "default-ipv6-ippool"] - } -} -``` - -:::note - -`ipv6_pools` will be respected only when `assign_ipv6` is set to `"true"`. - -::: - -Any IP pools specified in the CNI config must have already been created. It is an error to specify IP pools in the config that do not exist. - -### Container settings - -The following options allow configuration of settings within the container namespace. - -- allow_ip_forwarding (default is `false`) - -```json -{ - "name": "any_name", - "cniVersion": "0.1.0", - "type": "calico", - "ipam": { - "type": "calico-ipam" - }, - "container_settings": { - "allow_ip_forwarding": true - } -} -``` - -### Readiness Gates - -The following option makes CNI plugin wait for specified endpoint(s) to be ready before configuring pod networking. - -- `readiness_gates` - -This is an optional property that takes an array of URLs. Each URL specified will be polled for readiness and pod networking will continue startup once all readiness_gates are ready. - -Example CNI config: - -```json -{ - "name": "any_name", - "cniVersion": "0.1.0", - "type": "calico", - "ipam": { - "type": "calico-ipam" - }, - "readiness_gates": ["http://localhost:9099/readiness", "http://localhost:8888/status"] -} -``` - -## Kubernetes specific - -When using the $[prodname] CNI plugin with Kubernetes, the plugin must be able to access the Kubernetes API server to find the labels assigned to the Kubernetes pods. The recommended way to configure access is through a `kubeconfig` file specified in the `kubernetes` section of the network config. e.g. - -```json -{ - "name": "any_name", - "cniVersion": "0.1.0", - "type": "calico", - "kubernetes": { - "kubeconfig": "/path/to/kubeconfig" - }, - "ipam": { - "type": "calico-ipam" - } -} -``` - -As a convenience, the API location can also be configured directly, e.g. - -```json -{ - "name": "any_name", - "cniVersion": "0.1.0", - "type": "calico", - "kubernetes": { - "k8s_api_root": "http://127.0.0.1:8080" - }, - "ipam": { - "type": "calico-ipam" - } -} -``` - -### Enabling Kubernetes policy - -If you wish to use the Kubernetes `NetworkPolicy` resource then you must set a policy type in the network config. -There is a single supported policy type, `k8s`. When set, -you must also run calico/kube-controllers with the policy, profile, and workloadendpoint controllers enabled. - -```json -{ - "name": "any_name", - "cniVersion": "0.1.0", - "type": "calico", - "policy": { - "type": "k8s" - }, - "kubernetes": { - "kubeconfig": "/path/to/kubeconfig" - }, - "ipam": { - "type": "calico-ipam" - } -} -``` - -When using `type: k8s`, the $[prodname] CNI plugin requires read-only Kubernetes API access to the `Pods` resource in all namespaces. - -### Enabling policy setup timeout - -The $[prodname] CNI plugin can be configured to prevent new pods from starting their containers until one of the following conditions occurs: - -- The pod's policy has finished being programmed. -- A specified amount of time has elapsed. - -By enabling this feature, you can avoid errors that can occur when a pod tries to start before the pod's policy is programmed by its host. - - - - -The policy setup timeout can be configured by setting the `linuxPolicySetupTimeoutSeconds` field in the [calicoNetwork spec](installation/api#caliconetworkspec) of the default `operator.tigera.io/v1/installation` resource. - -The following example configures the CNI to delay a pod from starting its containers for up to 10 seconds, or until the pod's data plane has been programmed: - -```yaml -kind: Installation -apiVersion: operator.tigera.io/v1 -metadata: - name: default -spec: - calicoNetwork: - linuxPolicySetupTimeoutSeconds: 10 -``` - - - - -The policy setup timeout can be configured by setting the `policy_setup_timeout_seconds` option in the CNI config. - -Example CNI config: - -```json -{ - "name": "any_name", - "cniVersion": "0.1.0", - "type": "calico", - "policy_setup_timeout_seconds": 10, - "ipam": { - "type": "calico-ipam" - } -} -``` - -The $[prodname] CNI plugin reads Felix's `endpoint-status` directory to determine when the data plane has been programmed for a pod. -If left unset, the $[prodname] CNI plugin will look for the directory at `/var/run/calico/endpoint-status`. The path `/var/run/calico` is commonly mounted to the $[prodname] DaemonSet, meaning it can be written to by the Felix container, and read by the (host-namespace) $[prodname] CNI plugin. -To enable the `endpoint-status` directory, and adjust which directory of the Felix container it is written to, the `endpointStatusPathPrefix` option must be configured for [Felix](./felix/configuration.mdx). - -To adjust where the $[prodname] CNI plugin looks for the `endpoint-status` directory in the host filesystem, you must set the `endpoint_status_dir` option. - -Example CNI config: - -```json -{ - "name": "any_name", - "cniVersion": "0.1.0", - "type": "calico", - "policy_setup_timeout_seconds": 10, - "endpoint_status_dir": "/path/to/endpoint-status", - "ipam": { - "type": "calico-ipam" - } -} -``` - - - -## IPAM - -### Using host-local IPAM - -Calico can be configured to use [host-local IPAM](https://www.cni.dev/plugins/current/ipam/host-local/) instead of the default `calico-ipam`. Host -local IPAM uses a pre-determined CIDR per-host, and stores allocations locally on each node. This is in contrast to Calico IPAM, which dynamically -allocates blocks of addresses and single addresses alike in response to cluster needs. - -Host local IPAM is generally only used on clusters where integration with the Kubernetes [route controller](https://kubernetes.io/docs/concepts/architecture/cloud-controller/#route-controller) is necessary. -Note that some Calico features - such as the ability to request a specific address or pool for a pod - require Calico IPAM to function, and will not work with host-local IPAM enabled. - - - - -The `host-local` IPAM plugin can be configured by setting the `Spec.CNI.IPAM.Plugin` field to `HostLocal` on the [operator.tigera.io/Installation](installation/api.mdx#installation) API. - -Calico will use the `host-local` IPAM plugin to allocate IPv4 addresses from the node's IPv4 pod CIDR if there is an IPv4 pool configured in `Spec.IPPools`, and an IPv6 address from the node's IPv6 pod CIDR if -there is an IPv6 pool configured in `Spec.IPPools`. - -The following example configures Calico to assign dual-stack IPs to pods using the host-local IPAM plugin. - -```yaml -kind: Installation -apiVersion: operator.tigera.io/v1 -metadata: - name: default -spec: - calicoNetwork: - ipPools: - - cidr: 192.168.0.0/16 - - cidr: 2001:db8::/64 - cni: - type: Calico - ipam: - type: HostLocal -``` - - - - -When using the CNI `host-local` IPAM plugin, two special values - `usePodCidr` and `usePodCidrIPv6` - are allowed for the subnet field (either at the top-level, or in a "range"). This tells the plugin to determine the subnet to use from the Kubernetes API based on the Node.podCIDR field. $[prodname] does not use the `gateway` field of a range so that field is not required and it will be ignored if present. - -:::note - -`usePodCidr` and `usePodCidrIPv6` can only be used as the value of the `subnet` field, it cannot be used in -`rangeStart` or `rangeEnd` so those values are not useful if `subnet` is set to `usePodCidr`. - -::: - -$[prodname] supports the host-local IPAM plugin's `routes` field as follows: - -- If there is no `routes` field, $[prodname] will install a default `0.0.0.0/0`, and/or `::/0` route into the pod (depending on whether the pod has an IPv4 and/or IPv6 address). -- If there is a `routes` field then $[prodname] will program _only_ the routes in the routes field into the pod. Since $[prodname] implements a point-to-point link into the pod, the `gw` field is not required and it will be ignored if present. All routes that $[prodname] installs will have $[prodname]'s link-local IP as the next hop. - -$[prodname] CNI plugin configuration: - -- `node_name` - - The node name to use when looking up the CIDR value (defaults to current hostname) - -```json -{ - "name": "any_name", - "cniVersion": "0.1.0", - "type": "calico", - "kubernetes": { - "kubeconfig": "/path/to/kubeconfig", - "node_name": "node-name-in-k8s" - }, - "ipam": { - "type": "host-local", - "ranges": [[{ "subnet": "usePodCidr" }], [{ "subnet": "usePodCidrIPv6" }]], - "routes": [{ "dst": "0.0.0.0/0" }, { "dst": "2001:db8::/96" }] - } -} -``` - -When making use of the `usePodCidr` or `usePodCidrIPv6` options, the $[prodname] CNI plugin requires read-only Kubernetes API access to the `Nodes` resource. - -#### Configuring node and typha - -When using `host-local` IPAM with the Kubernetes API datastore, you must configure both $[nodecontainer] and the Typha deployment to use the `Node.podCIDR` field by setting the environment variable `USE_POD_CIDR=true` in each. - -#### Disabling the `upgrade-ipam` init container - -When using `host-local` IPAM on a manifest-based installation of $[prodname], you should remove the `upgrade-ipam` init container from the `calico-node` DaemonSet definition in the manifest before applying it. - -If $[prodname] is already installed, you can remove the init container with the following command: - -```bash -kubectl get ds calico-node -n kube-system -o json | \ -jq 'del(.spec.template.spec.initContainers[]? | select(.name == "upgrade-ipam"))' | \ -kubectl apply -f - -``` - - - - -### Using Kubernetes annotations - -#### Specifying IP pools on a per-namespace or per-pod basis - -In addition to specifying IP pools in the CNI config as discussed above, $[prodname] IPAM supports specifying IP pools per-namespace or per-pod using the following [Kubernetes annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/). - -- `cni.projectcalico.org/ipv4pools`: A list of configured IPv4 Pools from which to choose an address for the pod. - - Example: - - ```yaml - annotations: - 'cni.projectcalico.org/ipv4pools': '["default-ipv4-ippool"]' - ``` - -- `cni.projectcalico.org/ipv6pools`: A list of configured IPv6 Pools from which to choose an address for the pod. - - Example: - - ```yaml - annotations: - 'cni.projectcalico.org/ipv6pools': '["2001:db8::1/120"]' - ``` - -If provided, these IP pools will override any IP pools specified in the CNI config. - -:::note - -This requires the IP pools to exist before `ipv4pools` or -`ipv6pools` annotations are used. Requesting a subset of an IP pool -is not supported. IP pools requested in the annotations must exactly -match a configured [IPPool](resources/ippool.mdx) resource. - -::: - -:::note - -The $[prodname] CNI plugin supports specifying an annotation per namespace. -If both the namespace and the pod have this annotation, the pod information will be used. -Otherwise, if only the namespace has the annotation the annotation of the namespace will -be used for each pod in it. - -::: - -#### Requesting a specific IP address - -You can also request a specific IP address through [Kubernetes annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/) with $[prodname] IPAM. -There are two annotations to request a specific IP address: - -- `cni.projectcalico.org/ipAddrs`: A list of IPv4 and/or IPv6 addresses to assign to the Pod. The requested IP addresses will be assigned from $[prodname] IPAM and must exist within a configured IP pool. - - Example: - - ```yaml - annotations: - 'cni.projectcalico.org/ipAddrs': '["192.168.0.1"]' - ``` - -- `cni.projectcalico.org/ipAddrsNoIpam`: A list of IPv4 and/or IPv6 addresses to assign to the Pod, bypassing IPAM. Any IP conflicts and routing have to be taken care of manually or by some other system. - $[prodname] will only distribute routes to a Pod if its IP address falls within a $[prodname] IP pool using BGP mode. Calico will not distribute ipAddrsNoIpam routes when operating in VXLAN mode. If you assign an IP address that is not in a $[prodname] IP pool or if its IP address falls within a $[prodname] IP pool that uses VXLAN encapsulation, you must ensure that routing to that IP address is taken care of through another mechanism. - - Example: - - ```yaml - annotations: - 'cni.projectcalico.org/ipAddrsNoIpam': '["10.0.0.1"]' - ``` - - The ipAddrsNoIpam feature is disabled by default. It can be enabled in the feature_control section of the CNI network config: - - ```json - { - "name": "any_name", - "cniVersion": "0.1.0", - "type": "calico", - "ipam": { - "type": "calico-ipam" - }, - "feature_control": { - "ip_addrs_no_ipam": true - } - } - ``` - - :::caution - - This feature allows for the bypassing of network policy via IP spoofing. - Users should make sure the proper admission control is in place to prevent users from selecting arbitrary IP addresses. - - ::: - -:::note - -- The `ipAddrs` and `ipAddrsNoIpam` annotations can't be used together. -- You can only specify one IPv4/IPv6 or one IPv4 and one IPv6 address with these annotations. -- When `ipAddrs` or `ipAddrsNoIpam` is used with `ipv4pools` or `ipv6pools`, `ipAddrs` / `ipAddrsNoIpam` take priority. - -::: - -#### Requesting a floating IP - -You can request a floating IP address for a pod through [Kubernetes annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/) with $[prodname]. - -:::note - -The specified address must belong to an IP Pool for advertisement to work properly. - -::: - -- `cni.projectcalico.org/floatingIPs`: A list of floating IPs which will be assigned to the pod's workload endpoint. - - Example: - - ```yaml - annotations: - 'cni.projectcalico.org/floatingIPs': '["10.0.0.1"]' - ``` - - The floatingIPs feature is disabled by default. It can be enabled in the feature_control section of the CNI network config: - - ```json - { - "name": "any_name", - "cniVersion": "0.1.0", - "type": "calico", - "ipam": { - "type": "calico-ipam" - }, - "feature_control": { - "floating_ips": true - } - } - ``` - - :::caution - - This feature can allow pods to receive traffic which may not have been intended for that pod. - Users should make sure the proper admission control is in place to prevent users from selecting arbitrary floating IP addresses. - - ::: - -### Using IP pools node selectors - -Nodes will only assign workload addresses from IP pools which select them. By -default, IP pools select all nodes, but this can be configured using the -`nodeSelector` field. Check out the [IP pool resource document](resources/ippool.mdx) - -for more details. - -Example: - -1. Create (or update) an IP pool that only allocates IPs for nodes where it - contains a label `rack=0`. - - ```bash - calicoctl create -f -< - - -This document does not apply to operator installations of Calico. - - - - -The paths listed here are the key or path prefixes that a particular $[prodname] -component needs access to in etcd to function successfully. - -:::note - -The path prefixes listed here may change in the future and at that point anything -referencing them (like etcd roles) would need to be updated appropriately. - -::: - -## $[nodecontainer] - -| Path | Access | -| ------------------------------------------------------------- | ------ | -| /calico/felix/v1/\* | RW | -| /calico/felix/v2/\* | RW | -| /calico/ipam/v2/\* | RW | -| /calico/resources/v3/projectcalico.org/felixconfigurations/\* | RW | -| /calico/resources/v3/projectcalico.org/nodes/\* | RW | -| /calico/resources/v3/projectcalico.org/workloadendpoints/\* | RW | -| /calico/resources/v3/projectcalico.org/clusterinformations/\* | RW | -| /calico/resources/v3/projectcalico.org/ippools/\* | RW | -| /calico/resources/v3/projectcalico.org/\* | R | - -## Felix as a stand alone process - -| Path | Access | -| ----------------------------------------- | ------ | -| /calico/felix/v1/\* | RW | -| /calico/felix/v2/\* | RW | -| /calico/resources/v3/projectcalico.org/\* | R | - -## CNI-plugin - -| Path | Access | -| ------------------------------------------------------------- | ------ | -| /calico/ipam/v2/\* | RW | -| /calico/resources/v3/projectcalico.org/workloadendpoints/\* | RW | -| /calico/resources/v3/projectcalico.org/ippools/\* | R | -| /calico/resources/v3/projectcalico.org/clusterinformations/\* | R | -| /calico/resources/v3/projectcalico.org/nodes/\* | R | - -## calico/kube-controllers - -| Path | Access | -| ----------------------------------------------------------------------- | ------ | -| /calico/ipam/v2/\* | RW | -| /calico/resources/v3/projectcalico.org/profiles/\* | RW | -| /calico/resources/v3/projectcalico.org/networkpolicies/\* | RW | -| /calico/resources/v3/projectcalico.org/nodes/\* | RW | -| /calico/resources/v3/projectcalico.org/clusterinformations/\* | RW | -| /calico/resources/v3/projectcalico.org/hostendpoints/\* | RW | -| /calico/resources/v3/projectcalico.org/kubecontrollersconfigurations/\* | RW | -| /calico/resources/v3/projectcalico.org/\* | R | - -:::note - -By default, `calico/kube-controllers` performs periodic -compaction of the etcd data store. If you limit it to just these -paths it will be unauthorized to perform this compaction, as that -operation requires root privileges on the etcd cluster. You should -[configure auto-compaction](https://etcd.io/docs/v3.3.12/op-guide/maintenance/) -on your etcd cluster and -[disable `calico/kube-controllers` periodic compaction](../kube-controllers/configuration.mdx). - -::: - -## OpenStack Calico driver for Neutron - -| Path | Access | -| ----------------------------------------- | ------ | -| /calico/resources/v3/projectcalico.org/\* | RW | -| /calico/dhcp/v1/\* | RW | -| /calico/dhcp/v2/\* | RW | -| /calico/compaction/v1/\* | RW | -| /calico/openstack/v1/\* | RW | -| /calico/openstack/v2/\* | RW | -| /calico/felix/v1/\* | R | -| /calico/felix/v2/\* | R | - -## OpenStack Calico DHCP agent - -| Path | Access | -| ----------------------------------------- | ------ | -| /calico/resources/v3/projectcalico.org/\* | R | -| /calico/dhcp/v1/\* | R | -| /calico/dhcp/v2/\* | R | - -## calicoctl (read only access) - -| Path | Access | -| ----------------------------------------- | ------ | -| /calico/ipam/v2/\* | R | -| /calico/resources/v3/projectcalico.org/\* | R | - -## calicoctl (policy editor access) - -| Path | Access | -| --------------------------------------------------------------- | ------ | -| /calico/ipam/v2/\* | R | -| /calico/resources/v3/projectcalico.org/\* | R | -| /calico/resources/v3/projectcalico.org/globalnetworkpolicies/\* | RW | -| /calico/resources/v3/projectcalico.org/globalnetworksets/\* | RW | -| /calico/resources/v3/projectcalico.org/networkpolicies/\* | RW | -| /calico/resources/v3/projectcalico.org/networksets/\* | RW | -| /calico/resources/v3/projectcalico.org/profiles/\* | RW | - -## calicoctl (full read/write access) - -| Path | Access | -| ----------------------------------------- | ------ | -| /calico/ipam/v2/\* | RW | -| /calico/resources/v3/projectcalico.org/\* | RW | - - - - diff --git a/calico_versioned_docs/version-3.29/reference/etcd-rbac/certificate-generation.mdx b/calico_versioned_docs/version-3.29/reference/etcd-rbac/certificate-generation.mdx deleted file mode 100644 index 6ec29d2aca..0000000000 --- a/calico_versioned_docs/version-3.29/reference/etcd-rbac/certificate-generation.mdx +++ /dev/null @@ -1,127 +0,0 @@ ---- -description: Generate Certificates of Authority (CA) to authenticate users with etcd datastore. ---- - -# Generating certificates - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - - - - -This document does not apply to operator installations of Calico. - - - - -The etcd datastore has the concept of users that are linked to roles, where -each role has a defined set of access permissions to the data stored in etcd. -This tutorial walks you through the process of generating the Certificate -Authority (CA), Certificates and Keys that can be used to authenticate a -specific user with etcd. There are many different tools that can be used to -generate these files. This tutorial tries to layout the unique or specific -details that are needed for each of the different certificates but uses the -[hack/tls-setup tool from the etcd repo](https://github.com/coreos/etcd/tree/master/hack/tls-setup), -to make certificate generation easy. - -The etcd server links a certificate to a specific user by using the Common -Name (CN) attribute in the certificate. It is important to ensure that the CN -in the certificate for each component that will be accessing etcd match the -username in etcd that has the appropriate etcd roles for accessing its -required keys or paths. - -## Using the hack/tls-setup tool - -If you use hack/tls-setup too, ensure you have followed the README -and are able to run `make` successfully. - -The directories of interest in tls-setup are `config` and `certs`. -As indicated by the names `config` is where the configuration files are that -are used in CA and certificate generation live and `certs` are where the -generated files are written. - -Generating certificates with hack/tls-setup: - -1. Edit the etcd certificate config. -2. Add the - per-user/per-component configuration files -3. Run `make`. (Re-running `make` will regenerate the CA and all certificates.) - -Generating the certificates creates: - -- the CA -- a certificate and key pair for 3 etcd servers -- a certificate and key pair for etcd proxies -- the certificate and key pairs for each user/component - -# Configuration for the Certificate Authority - -The default CA configuration included with hack/tls-setup works well with no -additional configuration. The file `certs/ca.pem` generated will need to be -provided to all components (etcd, Kubernetes apiserver, and all calico -components). - -# Configuration for the etcd certificates - -Update the file `config/req-csr.json` by adding the IP addresses of the -servers that will be running the etcd members to the `"hosts"` -section. After generating the certs, three certs are created that can be -used for three etcd member servers (though just using one works, when testing). -These certificate and key files are `certs/etcd[123].pem` and -`certs/etcd[123]-key.pem` and a matching pair will need to be provided to -each etcd member. - -If using etcd proxies, the cert/key pair generated by the tool -(the files `certs/proxy1.pem` and `certs/proxy1-key.pem`) can be used with all -proxies or you could create individual cert/key pairs for each proxy too. - -# Configuration for per-user/per-component's etcd certificates - -The certificates for $[prodname], Kubernetes, or any other component can be -generated with configuration files similar to the one provided below. -Replace the <etcd_username> placeholder with the username of the etcd user -that has roles allowing access to the paths/prefix keys required by the -associated component. - -```json -{ - "CN": "", - "hosts": ["localhost"], - "key": { - "algo": "ecdsa", - "size": 384 - }, - "names": [ - { - "O": "autogenerated", - "OU": "etcd cluster", - "L": "the internet" - } - ] -} -``` - -The additional configuration files you create should be added to the `config` -directory located in your hack/tls-setup folder. To build certificates for -each new configuration add lines similar to those below to -the `req:` target in the Makefile. For each configuration added, make sure the -configuration file name and cert/key file prefix are updated appropriately by -substituting an appropriate name for <component>. - -```bash - $(CFSSL) gencert \ - -ca certs/ca.pem \ - -ca-key certs/ca-key.pem \ - -config config/ca-config.json \ - config/req-.json | $(JSON) -bare certs/ -``` - -Once the certificate and key files are generated they will need to be provided -to the proper component which is beyond the scope of this particular document. -See [this](kubernetes.mdx) for how to provide certificates to Kubernetes and $[prodname] -components. - - - - diff --git a/calico_versioned_docs/version-3.29/reference/etcd-rbac/index.mdx b/calico_versioned_docs/version-3.29/reference/etcd-rbac/index.mdx deleted file mode 100644 index a779d8592a..0000000000 --- a/calico_versioned_docs/version-3.29/reference/etcd-rbac/index.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: Tasks for protecting your etcd datastore. -hide_table_of_contents: true ---- - -# Configuring etcd RBAC - -import DocCardList from '@theme/DocCardList'; -import { useCurrentSidebarCategory } from '@docusaurus/theme-common'; - - diff --git a/calico_versioned_docs/version-3.29/reference/etcd-rbac/kubernetes-advanced.mdx b/calico_versioned_docs/version-3.29/reference/etcd-rbac/kubernetes-advanced.mdx deleted file mode 100644 index 49c8fd6c5b..0000000000 --- a/calico_versioned_docs/version-3.29/reference/etcd-rbac/kubernetes-advanced.mdx +++ /dev/null @@ -1,92 +0,0 @@ ---- -description: Limit user access to Calico components or calicoctl. ---- - -# Segmenting etcd on Kubernetes (advanced) - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - - - - -This document does not apply to operator installations of Calico. - - - - -This document describes advanced segmentation of the etcd roles to limit -access of individual $[prodname] components or to limit calicoctl user access. -It assumes you have followed [this guide](kubernetes.mdx) for initial etcd -RBAC configuration of $[prodname] and Kubernetes. - -## Why you might be interested in this guide - -You want to limit access on a per-$[prodname] component level or create limited -access roles for calicoctl to the etcd datastore. - -## Components that need etcd Roles - -The following components need certificates with a Common Name that matches an -etcd user that has been given appropriate roles allowing access to the key -prefixes or paths listed or linked below. - -- [cni-plugin](calico-etcdv3-paths.mdx#cni-plugin) -- [$[prodname] Kubernetes controllers](calico-etcdv3-paths.mdx#calicokube-controllers) -- [$[nodecontainer]](calico-etcdv3-paths.mdx#caliconode) -- It may also be useful to create a certificate key pair for use with - calicoctl, even creating specific ones for - [read only access](calico-etcdv3-paths.mdx#calicoctl-read-only-access), - [policy editor access](calico-etcdv3-paths.mdx#calicoctl-policy-editor-access), - and [full read/write access](calico-etcdv3-paths.mdx#calicoctl-full-readwrite-access). - -All certificate/key pairs that are referenced below are assumed to have been -created for the specific component with the information above. - -## $[prodname] components - -Once the certificates are generated and the users and roles have been setup -in etcd the components using them must be configured. Here are the same -components listed above and links to their detailed configuration pages: - -- [cni-plugin](../configure-cni-plugins.mdx) -- [$[prodname] Kubernetes controllers](../kube-controllers/configuration.mdx) -- [$[nodecontainer]](../configure-calico-node.mdx) -- [calicoctl](../../operations/calicoctl/install.mdx) - -Below are examples and suggestions when using a hosted $[prodname] install where -the $[prodname] components are launched through a Kubernetes manifest file, this -is not required and the configuration could be achieved by configuring services -that run outside of Kubernetes. - -### Per component certificate setup - -A setup that needs a certificate for each component is possible while using a -hosted manifest. This setup requires a certificate for each different $[prodname] -component type listed above (cni-plugin, $[prodname] Kubernetes controllers, and -`$[nodecontainer]`). - -This setup needs similar updates to the manifest like what is described in -[Using etcd RBAC to segment Kubernetes and $[prodname]: Updating a hosted $[prodname] manifest](kubernetes.mdx#updating-a-hosted-calico-manifest), -with the in addition to those updates a separate Secret for _each_ component -must be created which holds the CA, certificate, and key data base64 encoded. -Then the specific Secret for each component must be in the `volumes` list -for the correct pod and the `volumeMounts` for the appropriate container must -reference the volume for the `/calico-secrets` mountPath. - -### Per node per component certificate setup - -While the above is a good step toward locking down access to etcd and would -probably satisfy the needs of many, there is a third option that could -utilize a different certificate for each component for each node. This type -of setup can be achieved multiple ways and will be left as an exercise for -the implementor. Some possibilities for achieving this are: - -- Installing and starting the $[prodname] components with a configuration management - tool which installs and configures the certificates. -- Creating a manifest with a side car container that pulls the proper - certificate information from Vault or other secret management tool. - - - - diff --git a/calico_versioned_docs/version-3.29/reference/etcd-rbac/kubernetes.mdx b/calico_versioned_docs/version-3.29/reference/etcd-rbac/kubernetes.mdx deleted file mode 100644 index 99cfffab25..0000000000 --- a/calico_versioned_docs/version-3.29/reference/etcd-rbac/kubernetes.mdx +++ /dev/null @@ -1,104 +0,0 @@ ---- -description: Limit user access to Kubernetes and Calico components. ---- - -# Segmenting etcd on Kubernetes (basic) - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - - - - -This document does not apply to operator installations of Calico. - - - - -When using etcd with RBAC, all components that access etcd must be configured -with the proper certificates. This document describes the users and roles -needed to segment etcd so that Kubernetes and $[prodname] can only read and write -within their respected subtrees/prefixes. To configure more compartmentalized -configurations of the $[prodname] components, see this add-on: -[guide](kubernetes-advanced.mdx). - -This guide assumes you are following the general -[Generating certificates](index.mdx) and using its guidance -for setting up certificates and etcd cluster, users, and roles. - -## Why you might be interested in this guide - -You are using Kubernetes and $[prodname] that share an etcd datastore and you wish -to ensure that $[prodname] and Kubernetes are unable to access each others' etcd -data. - -## Needed etcd Roles - -The following components need certificates with a Common Name that matches an -etcd user that has been given appropriate roles allowing access to the key -prefixes or paths listed below. - -- kube-apiserver - - Read and write access to `/registry/`. - - The etcd user needs to be given the root role to perform compaction when - using the etcd v3 API (this also means that Kubernetes will have - full read and write access to v3 data). -- $[prodname] - - Read and write access to `/calico/`. - -All certificate/key pairs that are referenced below are assumed to have been -created for the specific component with the information above. - -## Kubernetes API server - -The kube-apiserver is the only Kubernetes component that directly accesses etcd. -The flags required to provide the kube-apiserver with certificates for -accessing an etcd cluster are: - -- `--etcd-cafile=` -- `--etcd-keyfile=` - -Setting these will depend on the method used to deploy Kubernetes so refer -to your integrator's documentation for help setting these flags. - -## Updating a hosted $[prodname] manifest - -To deploy $[prodname] with the CA and $[prodname]-specific certificate/key pair, -use [this manifest template]($[manifestsUrl]/manifests/calico-etcd.yaml) -with the modifications described below. The same information could be added to -or updated in other manifests but the linked one is the most straight forward -example. - -The pieces that would need updating are: - -- The `calico-config` ConfigMap lines with `etcd_ca`, `etcd_cert`, and - `etcd_key` should be updated as follows - - ```yaml - etcd_ca: '/calico-secrets/etcd-ca' - etcd_cert: '/calico-secrets/etcd-cert' - etcd_key: '/calico-secrets/etcd-key' - ``` - -- The Secret named `calico-etcd-secrets` needs to be updated with the CA and - cert/key. The information stored in `data` in a Secret needs to be base64 - encoded. The files can be converted to base64 encoding by doing a command - like `cat | base64 -w 0` on each file and then inserting the output - to the appropriate field. - - - The `etcd-key` field needs the base64 encoded file contents from the - key file. - - The `etcd-cert` field needs the base64 encoded file contents from the - certificate file. - - The `etcd-ca` field needs the base64 encoded file contents from the - Certificate Authority certificate. - -- If sharing an etcd cluster with Kubernetes, disable etcd compaction in the - calico-kube-controllers deployment by setting the `COMPACTION_PERIOD` environment variable to 0. - -Once the updates above are made then the manifest can be applied in the normal manner. - - - - diff --git a/calico_versioned_docs/version-3.29/reference/etcd-rbac/overview.mdx b/calico_versioned_docs/version-3.29/reference/etcd-rbac/overview.mdx deleted file mode 100644 index ee14ec2b43..0000000000 --- a/calico_versioned_docs/version-3.29/reference/etcd-rbac/overview.mdx +++ /dev/null @@ -1,70 +0,0 @@ ---- -description: Protect your etcd datastore by restricting operation permissions. ---- - -# Setting up etcd certificates for RBAC - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - - - - -This document does not apply to operator installations of Calico. - - - - -When using etcd it is a good idea to protect the data stored there. This is -even more true when you have multiple components using a common etcd cluster. -This set of tutorials guides you through the process of locking down and -segmenting access to the data in your etcd datastore. - -## Why you might be interested in this guide - -- You want to restrict the operations that support staff are able to perform - to minimize accidental corruption or deletion of etcd data. -- You want to use a single etcd cluster for $[prodname] and Kubernetes (rather than - having an etcd cluster for $[prodname] and a separate etcd cluster for Kubernetes. -- You want to restrict the read/write access of the various $[prodname] components - as an additional safety measure. - -## Configuration Concept - -The central piece that will link the components together is the Certificate -Authority(CA). It will be used to -generate certificates and keys that the etcd members (and proxies) and components -(like $[prodname] and Kubernetes) will need to authenticate with the etcd cluster. -Because all the certificates will be generated from the same CA and all the -components will have the CA certificate, those connections can be mutually -authenticated. - -The certificates and keys generated for the components accessing etcd will allow -access to particular key prefixes or paths in etcd. The certificates are linked -with an etcd username by being generated with a Common Name (CN) that matches -the etcd username. The etcd username is linked with a role or multiple roles -that allow access to the appropriate data in etcd. - -## Requirements - -- If using only the v2 API with etcd, as $[prodname] does, then the minimum etcd - version required is 3.0.12. -- If using the v3 API with etcd, as Kubernetes can, then the minimum etcd - version required is 3.2. (Note: The 3.x version of etcd supports both the v2 - and the v3 API.) - -## Setup - -1. [Generate CA, certificates, and keys](certificate-generation.mdx). -2. Setup etcd with the CA certificate and the certificates generated in step 1. - See the - [etcd security op-guide](https://coreos.com/etcd/docs/latest/op-guide/security.html) - for help configuring etcd. -3. [Create Users and Roles in etcd](users-and-roles.mdx). -4. Configure components. For example: - - [Setting up Kubernetes with $[prodname] utilizing etcd RBAC](kubernetes.mdx). - - [Advanced Kubernetes set ups utilizing etcd RBAC](kubernetes-advanced.mdx). - - - - diff --git a/calico_versioned_docs/version-3.29/reference/etcd-rbac/users-and-roles.mdx b/calico_versioned_docs/version-3.29/reference/etcd-rbac/users-and-roles.mdx deleted file mode 100644 index 601a447395..0000000000 --- a/calico_versioned_docs/version-3.29/reference/etcd-rbac/users-and-roles.mdx +++ /dev/null @@ -1,59 +0,0 @@ ---- -description: Provide role-based access control to etcd datastore. ---- - -# Creating users and roles - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - - - - -This document does not apply to operator installations of Calico. - - - - -Providing role based access control within etcd requires the following: - -- Creation of etcd roles which provide appropriate access to the specific set - of etcd keys required by the role -- Creation of etcd users who are assigned roles - -:::note - -The etcd release 3.x+ supports both v2 and v3 of its API. The etcd server -keeps the roles and users separate, this means that if a user/role is created -with the v2 API it will not appear in the v3 API. When adding roles and users -they must be added through the API version that matches the version the -component will be using. This concern can be ignored if all roles and users -are added through both API versions. - -::: - -## Users and Roles creation guides - -Use the following guides to set up your users, roles, and assignment of roles -to users. Since this document assumes that you have configured your etcd cluster -to use certificates, you must pass a proper CA and cert/key pair to the -commands used in the below guides. - -- [etcd v2 guide](https://etcd.io/docs/v2/authentication/) -- [etcd v3 guide](https://etcd.io/docs/latest/op-guide/security/) - -## Suggestions for your roles and users - -- Create a root user under both the v2 and v3 etcd API to ensure access after - you enable authentication on your cluster. -- Create a guest role (particularly on the v2 API) and ensure it does not have - access to your cluster. -- Enable authentication on both the v2 and the v3 API, enabling it on one does - not enable it on the other. Make sure you enable authentication only after - you have created your root users. -- Ensure your usernames match the Common Name set in your certificates to allow - access without specifying the username to your components. - - - - diff --git a/calico_versioned_docs/version-3.29/reference/faq.mdx b/calico_versioned_docs/version-3.29/reference/faq.mdx deleted file mode 100644 index 3bfad1e4a2..0000000000 --- a/calico_versioned_docs/version-3.29/reference/faq.mdx +++ /dev/null @@ -1,501 +0,0 @@ ---- -description: Common questions that users ask about Calico. ---- - -# Frequently asked questions - -## Why use $[prodname]? - -The problem $[prodname] tries to solve is the networking of workloads (VMs, -containers, etc) in a high scale environment. Existing L2-based methods -for solving this problem have problems at high scale. Compared to these, -we think $[prodname] is more scalable, simpler, and more flexible. We think -you should look into it if you have more than a handful of nodes on a -single site. - -$[prodname] also provides a rich network security model that -allows operators and developers to declare intent-based network security -policy that is automatically rendered into distributed firewall rules -across a cluster of containers, VMs, and/or servers. - -For a more detailed discussion of this topic, see our blog post at -[Why Calico?](https://www.projectcalico.org/why-calico/). - -## Does $[prodname] work with IPv6? - -Yes! $[prodname]'s core components support IPv6 out of the box. However, -not all orchestrators that we integrate with support IPv6 yet. - -## Why does my container have a route to 169.254.1.1? - -In a $[prodname] network, each host acts as a gateway router for the -workloads that it hosts. In container deployments, $[prodname] uses -169.254.1.1 as the address for the $[prodname] router. By using a -link-local address, $[prodname] saves precious IP addresses and avoids -burdening the user with configuring a suitable address. - -While the routing table may look a little odd to someone who is used to -configuring LAN networking, using explicit routes rather than -subnet-local gateways is fairly common in WAN networking. - -## Why isn't $[prodname] working with a containerized kubelet? - -$[prodname] hosted install places the necessary CNI binaries and config on each -Kubernetes node in a directory on the host as specified in the manifest. By -default it places binaries in /opt/cni/bin and config /etc/cni/net.d. - -When running the kubelet as a container using hyperkube, -you need to make sure that the containerized kubelet can see the CNI network -plugins and config that have been installed by mounting them into the kubelet container. - -For example add the following arguments to the kubelet-wrapper service: - -``` ---volume /etc/cni/net.d:/etc/cni/net.d \ ---volume /opt/cni/bin:/opt/cni/bin \ -``` - -Without the above volume mounts, the kubelet will not call the $[prodname] CNI binaries, and so -$[prodname] [workload endpoints](resources/workloadendpoint.mdx) will -not be created, and $[prodname] policy will not be enforced. - -## How do I view $[prodname] CNI logs? - -The $[prodname] CNI plugin emits logs to stderr, which are then logged out by the kubelet. Where these logs end up -depend on how your kubelet is configured. For deployments using `systemd`, you can do this via `journalctl`. - -The log level can be configured via the CNI network configuration file, by changing the value of the -key `log_level`. See [Configuring the $[prodname] CNI plugins](configure-cni-plugins.mdx) for more information. - -CNI plugin logs can also be found in `/var/log/calico/cni`. - -## How do I configure the pod IP range? - -When using $[prodname] IPAM, IP addresses are assigned from [IP Pools](resources/ippool.mdx). - -By default, all enabled IP pools are used. However, you can specify which IP pools to use for IP address management in the [CNI network config](configure-cni-plugins.mdx#ipam), -or on a per-pod basis using [Kubernetes annotations](configure-cni-plugins.mdx#using-kubernetes-annotations). - -## How do I assign a specific IP address to a pod? - -For most use cases it's not necessary to assign specific IP addresses to a Kubernetes pod and it's recommended to use Kubernetes services instead. -However, if you do need to assign a particular address to a pod, $[prodname] provides two ways of doing this: - -- You can request an IP that is available in $[prodname] IPAM using the `cni.projectcalico.org/ipAddrs` annotation. -- You can request an IP using the `cni.projectcalico.org/ipAddrsNoIpam` annotation. Note that this annotation bypasses the configured IPAM plugin, and thus in most cases it is recommended to use the above annotation. - -See the [Requesting a specific IP address](configure-cni-plugins.mdx#requesting-a-specific-ip-address) section in the CNI plugin reference documentation for more details. - -## Why can't I see the 169.254.1.1 address mentioned above on my host? - -$[prodname] tries hard to avoid interfering with any other configuration -on the host. Rather than adding the gateway address to the host side -of each workload interface, $[prodname] sets the `proxy_arp` flag on the -interface. This makes the host behave like a gateway, responding to -ARPs for 169.254.1.1 without having to actually allocate the IP address -to the interface. - -## Why do all cali\* interfaces have the MAC address ee:ee:ee:ee:ee:ee? - -In some setups the kernel is unable to generate a persistent MAC address and so -$[prodname] assigns a MAC address itself. Since $[prodname] uses -point-to-point routed interfaces, traffic does not reach the data link layer -so the MAC Address is never used and can therefore be the same for all the -cali\* interfaces. - -## Can I prevent my Kubernetes pods from initiating outgoing connections? - -Yes! The Kubernetes [`NetworkPolicy`](https://kubernetes.io/docs/concepts/services-networking/network-policies/) -API added support for egress policies in v1.8. You can also use `calicoctl` -to configure egress policy to prevent Kubernetes pods from initiating outgoing -connections based on the full set of supported $[prodname] policy primitives -including labels, Kubernetes namespaces, CIDRs, and ports. - -## I've heard $[prodname] uses proxy ARP, doesn't proxy ARP cause a lot of problems? - -It can, but not in the way that $[prodname] uses it. - -In container deployments, $[prodname] only uses proxy ARP for resolving the -169.254.1.1 address. The routing table inside the container ensures -that all traffic goes via the 169.254.1.1 gateway so that is the only -IP that will be ARPed by the container. - -## Is $[prodname] compliant with PCI/DSS requirements? - -PCI certification applies to the whole end-to-end system, of which -$[prodname] would be a part. We understand that most current solutions use -VLANs, but after studying the PCI requirements documents, we believe -that $[prodname] does meet those requirements and that nothing in the -documents _mandates_ the use of VLANs. - -## How do I enable IP-in-IP and NAT outgoing on an IP pool? - -1. Retrieve current IP pool config. - - ```bash - calicoctl get ipPool --export -o yaml > pool.yaml - ``` - -2. Modify IP pool config. - - Modify the pool's spec to enable IP-in-IP and NAT outgoing. (See - [IP pools](resources/ippool.mdx) - for other settings that can be edited.) - - ```shell - - apiVersion: projectcalico.org/v3 - kind: IPPool - metadata: - name: ippool-1 - spec: - cidr: 192.168.0.0/16 - ipipMode: Always - natOutgoing: true - ``` - -3. Load the modified file. - - ```bash - calicoctl replace -f pool.yaml - ``` - -## How does $[prodname] maintain saved state? - -State is saved in a few places in a $[prodname] deployment, depending on -whether it's global or local state. - -Local state is state that belongs on a single compute host, associated -with a single running Felix instance (things like kernel routes, tap -devices etc.). Local state is entirely stored by the Linux kernel on the -host, with Felix storing it only as a temporary mirror. This makes Felix -effectively stateless, with the kernel acting as a backing data store on -one side and etcd as a data source on the other. - -If Felix is restarted, it learns current local state by interrogating -the kernel at start up. It then reads from `etcd` all the local state -which it should have, and updates the kernel to match. This approach has -strong resiliency benefits, in that if Felix restarts you don't suddenly -lose access to your VMs or containers. As long as the Linux kernel is -running, you've still got full functionality. - -The bulk of global state is mastered in whatever component hosts the -plugin. - -- In the case of OpenStack, this means a Neutron database. Our - OpenStack plugin (more strictly a Neutron ML2 driver) queries the - Neutron database to find out state about the entire deployment. That - state is then reflected to `etcd` and so to Felix. -- In certain cases, `etcd` itself contains the master copy of - the data. This is because some Docker deployments have an `etcd` - cluster that has the required resiliency characteristics, used to - store all system configuration and so `etcd` is configured so as to - be a suitable store for critical data. -- In other orchestration systems, it may be stored in distributed - databases, either owned directly by the plugin or by the - orchestrator itself. - -The only other state storage in a $[prodname] network is in the BGP sessions, -which approximate a distributed database of routes. This BGP state is -simply a replicated copy of the per-host routes configured by Felix -based on the global state provided by the orchestrator. - -This makes the $[prodname] design very simple, because we store very little -state. All of our components can be shut down and restarted without risk, -because they resynchronize state as necessary. This makes modeling -their behavior extremely simple, reducing the complexity of bugs. - -## I heard $[prodname] is suggesting layer 2: I thought you were layer 3! What's happening? - -It's important to distinguish what $[prodname] provides to the workloads -hosted in a data center (a purely layer 3 network) with what the $[prodname] -project _recommends_ operators use to build their underlying network -fabric. - -$[prodname]'s core principle is that _applications_ and _workloads_ -overwhelmingly need only IP connectivity to communicate. For this reason -we build an IP-forwarded network to connect the tenant applications and -workloads to each other and the broader world. - -However, the underlying physical fabric obviously needs to be set up -too. Here, $[prodname] has discussed how both a layer 2 (see -[here](architecture/design/l2-interconnect-fabric.mdx)) -or a layer 3 (see -[here](architecture/design/l3-interconnect-fabric.mdx)) -fabric -could be integrated with $[prodname]. This is one of the great strengths of -the $[prodname] model: it allows the infrastructure to be decoupled from what -we show to the tenant applications and workloads. - -We have some thoughts on different interconnect approaches (as noted -above), but just because we say that there are layer 2 and layer 3 ways -of building the fabric, and that those decisions may have an impact on -route scale, does not mean that $[prodname] is "going back to Ethernet" or -that we're recommending layer 2 for tenant applications. In all cases we -forward on IP packets, no matter what architecture is used to build the -fabric. - -## How do I control policy/connectivity without virtual/physical firewalls? - -$[prodname] provides an extremely rich security policy model, applying policy at the first and last hop -of the routed traffic within the $[prodname] network (the source and -destination compute hosts). - -This model is substantially more robust to failure than a centralized -firewall-based model. In particular, the $[prodname] approach has no -single point of failure: if the device enforcing the firewall has failed -then so has one of the workloads involved in the traffic (because the -firewall is enforced by the compute host). - -This model is also extremely amenable to scaling out. Because we have a -central repository of policy configuration, but apply it at the edges of -the network (the hosts) where it is needed, we automatically ensure that -the rules match the topology of the data center. This allows easy -scaling out, and gives us all the advantages of a single firewall (one -place to manage the rules), but none of the disadvantages (single points -of failure, state sharing, hairpinning of traffic, etc.). - -Lastly, we decouple the reachability of nodes and the policy applied to -them. We use BGP to distribute the topology of the network, telling -every node how to get to every endpoint in case two endpoints need to -communicate. We use policy to decide _if_ those two nodes should -communicate, and if so, how. If policy changes and two endpoints should -now communicate, where before they shouldn’t have, all we have to do is -update policy: the reachability information does not change. If later -they should be denied the ability to communicate, the policy is updated -again, and again the reachability doesn’t have to change. - -## How does $[prodname] interact with the Neutron API? - -[$[prodname]'s interpretation of Neutron API calls](../networking/openstack/neutron-api.mdx) -goes into extensive detail about how various Neutron API calls translate into -$[prodname] actions. - -## Why isn't the `-p` flag on `docker run` working as expected? - -The `-p` flag tells Docker to set up port mapping to connect a port on the -Docker host to a port on your container via the `docker0` bridge. - -If a host's containers are connected to the `docker0` bridge interface, $[prodname] -would be unable to enforce security rules between workloads on the same host; -all containers on the bridge would be able to communicate with one other. - -## Can $[prodname] containers use any IP address within a pool, even subnet network/broadcast addresses? - -Yes! $[prodname] is fully routed, so all IP address within a $[prodname] pool are usable as -private IP addresses to assign to a workload. This means addresses commonly -reserved in a L2 subnet, such as IPv4 addresses ending in .0 or .255, are perfectly -okay to use. - -## How do I get network traffic into and out of my $[prodname] cluster? - -The recommended way to get traffic to/from your $[prodname] network is by peering to -your existing data center L3 routers using BGP and by assigning globally -routable IPs (public IPs) to containers that need to be accessed from the internet. -This allows incoming traffic to be routed directly to your containers without the -need for NAT. This flat L3 approach delivers exceptional network scalability -and performance. - -A common scenario is for your container hosts to be on their own -isolated layer 2 network, like a rack in your server room or an entire data -center. Access to that network is via a router, which also is the default -router for all the container hosts. - -If this describes your infrastructure, -[Configure outgoing NAT](../networking/configuring/workloads-outside-cluster.mdx explains in more detail -what to do. Otherwise, if you have a layer 3 (IP) fabric, then there are -detailed datacenter networking recommendations given -in [$[prodname] over IP fabrics](architecture/design/l3-interconnect-fabric.mdx). -We'd also encourage you to [get in touch](https://www.projectcalico.org/contact) -to discuss your environment. - -### How can I enable NAT for outgoing traffic from containers with private IP addresses? - -If you want to allow containers with private IP addresses to be able to access the -internet then you can use your data center's existing outbound NAT capabilities -(typically provided by the data center's border routers). - -Alternatively you can use $[prodname]'s built in outbound NAT capability by enabling it on any -$[prodname] IP pool. In this case $[prodname] will perform outbound NAT locally on the compute -node on which each container is hosted. - -```bash -cat < - natOutgoing: true -EOF -``` - -Where `` is the CIDR of your IP pool, for example `192.168.0.0/16`. - -Remember: the security profile for the container will need to allow traffic to the -internet as well. Refer to the appropriate guide for your orchestration -system for details on how to configure policy. - -### How can I enable NAT for incoming traffic to containers with private IP addresses? - -As discussed, the recommended way to get traffic to containers that -need to be accessed from the internet is to give them public IP addresses and -to configure $[prodname] to peer with the data center's existing L3 routers. - -In cases where this is not possible then you can configure incoming NAT -(also known as DNAT) on your data centers existing border routers. Alternatively -you can configure incoming NAT with port mapping on the host on which the container -is running on. - -1. Create a new chain called `expose-ports` to hold the NAT rules. - - ```bash - iptables -t nat -N expose-ports - ``` - -1. Jump to that chain from the `OUTPUT` and `PREROUTING` chains. - - ```bash - iptables -t nat -A OUTPUT -j expose-ports - iptables -t nat -A PREROUTING -j expose-ports - ``` - - :::tip - - The `OUTPUT` chain is hit by traffic originating on the host itself; - the `PREROUTING` chain is hit by traffic coming from elsewhere. - - ::: - -1. For each port you want to expose, add a rule to the - expose-ports chain, replacing `` with the host IP that you - want to use to expose the port and `` with the host port. - - ```bash - iptables -t nat -A expose-ports -p tcp --destination \ - --dport -j DNAT --to : - ``` - -For example, you have a container to which you've assigned the `CALICO_IP` -of 192.168.7.4, and you have NGINX running on port 8080 inside the container. -If you want to expose this service on port 80 and your host has IP 192.0.2.1, -then you could run the following commands: - -```bash -iptables -t nat -N expose-ports -iptables -t nat -A OUTPUT -j expose-ports -iptables -t nat -A PREROUTING -j expose-ports - -iptables -t nat -A expose-ports -p tcp --destination 192.0.2.1 --dport 80 -j DNAT --to 192.168.7.4:8080 -``` - -The commands will need to be run each time the host is restarted. - -Remember: the security profile for the container will need to allow traffic to the exposed port as well. -Refer to the appropriate guide for your orchestration system for details on how to configure policy. - -### Can I run $[prodname] in a public cloud environment? - -Yes. If you are running in a public cloud that doesn't allow either L3 peering or L2 connectivity between $[prodname] hosts then you can enable IP-in-IP in your $[prodname] IP pool: - -```bash -cat < - ipipMode: Always - natOutgoing: true -EOF -``` - -$[prodname] will then route traffic between $[prodname] hosts using IP-in-IP. - -For best performance in AWS, you can disable [Source/Destination Check](resources/felixconfig.mdx#spec) instead of using IP-in-IP or VXLAN; but only if all your instances are in the same subnet of your VPC. The setting must be `Disable` for the EC2 instance(s) to process traffic not matching the host interface IP address. This is also applicable if your cluster is spread across multiple subnets. If your cluster traffic crosses subnets, set `ipipMode` (or `vxlanMode`) to `CrossSubnet` to reduce the encapsulation overhead. Check [configuring overlay networking](../networking/configuring/vxlan-ipip.mdx) for the details. - -You can disable Source/Destination Check using [Felix configuration](resources/felixconfig.mdx), the AWS CLI, or the EC2 console. For example, using the AWS CLI: - -```bash -aws ec2 modify-instance-attribute --instance-id --source-dest-check "{\"Value\": false}" - -cat < - natOutgoing: true -EOF -``` - -### On AWS with IP-in-IP, why do I see no connectivity between workloads or only see connectivity if I ping in both directions? - -By default, AWS security groups block incoming IP-in-IP traffic. - -However, if an instance has recently sent some IP-in-IP traffic out when it receives some incoming IP-in-IP traffic, -then AWS sees that as a response to an outgoing connection and it allows the incoming traffic. This leads to some very -confusing behavior where traffic can be blocked and then suddenly start working! - -To resolve the issue, add a rule to your security groups that allows inbound and outbound IP-in-IP traffic (IP protocol -number 4) between your hosts. - -## In Calico for OpenStack, why can't a VM ping its default gateway? - -The concept of default gateway makes sense with OpenStack networking drivers that simulate -direct layer 2 (Ethernet) connectivity between VMs in the same Neutron network. With that -kind of simulation, - -- When a VM sends to another VM in the same network, there is no routing at all, from the - VM point of view. (Of course there may be routing in the underlay network, because - compute hosts may be on different subnets.) - -- When a VM sends to something outside its own network, it goes - by simulated layer 2 - - to the default gateway first, and then is routed to wherever it is addressed to. - -However OpenStack also allows drivers, including Calico, that use routing between the VMs -of a Neutron network. With Calico specifically, any packet sent by a VM is -layer-2-terminated and IP-routed by the VM's compute host, whether the VM is sending to -another VM in the same network, or to anywhere else. So Calico doesn't need the "default -gateway" concept, and it doesn't really make any sense with Calico. If a VM thinks that -"my default gateway is the first hop at which the packets I send can be IP-routed", and in -any way relies on that, that will be wrong, with Calico networking. - -Now, with all that said, for detailed technical reasons to do with the DHCP server -(dnsmasq), Calico does actually configure the default gateway IP - i.e. bind it to a Linux -network interface - on every compute host with at least one VM in the relevant Neutron -network; and that is one of the ingredients needed, in Linux, for a VM to be able to ping -that IP. - -The reason why it still _isn't_ possible for a VM to ping that IP, is that Calico by -default configures iptables rules to block almost all communication _to_ its own host - -because in general, of course, a workload should not be able to access and possibly -compromise its host. There are a few pinholes here, e.g. for DHCP, but those do not -include ping (ICMP Echo). If you start running a command like `watch 'sudo iptables-save -c | grep DROP'` on a compute host, and then try pinging the default gateway IP from a VM -on that host, you will see the DROP count increasing as each ping packet is sent and -blocked. - -This behaviour is controlled by a config parameter named DefaultEndpointToHostAction, -whose default is DROP. For the sake of demonstration, you can change this by adding -`DefaultEndpointToHostAction = RETURN` to `/etc/calico/felix.cfg`, then use `sudo systemctl restart calico-felix` to restart Felix, and then you will observe that a VM on -that host _can_ ping its default gateway. However we do not recommend routinely operating -with `DefaultEndpointToHostAction = RETURN`, because that potentially allows a malicious -VM to compromise its host. - -In summary, then, there are two points behind why a VM cannot normally ping its default -gateway, with Calico. - -1. The default gateway concept just doesn't really fit, and isn't needed, given how - Calico routes everything at the compute node - which is a fundamental aspect of Calico - networking for OpenStack. - -1. Calico's iptables rules generally do not allow a VM to contact its host. - -## Can Calico do IP multicast? - -Calico is a routed L3 network where each pod gets a /32. There's no broadcast domain for pods. -That means that multicast doesn't just work as a side effect of broadcast. To get multicast to -work, the host needs to act as a multicast gateway of some kind. Calico's architecture was designed -to extend to cover that case but it's not part of the product as yet. diff --git a/calico_versioned_docs/version-3.29/reference/felix/configuration.mdx b/calico_versioned_docs/version-3.29/reference/felix/configuration.mdx deleted file mode 100644 index 56ea9beefd..0000000000 --- a/calico_versioned_docs/version-3.29/reference/felix/configuration.mdx +++ /dev/null @@ -1,173 +0,0 @@ ---- -description: Configure Felix, the daemon that runs on every machine that provides endpoints. ---- - -# Configuring Felix - -import FelixConfig from '../../_includes/components/FelixConfig'; - -:::tip - -The following tables detail the configuration file and -environment variable parameters. For `FelixConfiguration` resource settings, -refer to [Felix Configuration Resource](../resources/felixconfig.mdx). - -::: - -Configuration for Felix is read from one of four possible locations, in order, as follows. - -1. Environment variables. -2. The Felix configuration file. -3. Host-specific `FelixConfiguration` resources (`node.`). -4. The global `FelixConfiguration` resource (`default`). - -The value of any configuration parameter is the value read from the -_first_ location containing a value. For example, if an environment variable -contains a value, it takes top precedence. - -If not set in any of these locations, most configuration parameters have -defaults, and it should be rare to have to explicitly set them. - -The full list of parameters which can be set is as follows. - -## Spec - -### Datastore connection - - - -### Process: Feature detection/overrides - - - -### Process: Go runtime - - - -### Process: Health port and timeouts - - - -### Process: Logging - - - -### Process: Prometheus metrics - - - -### Data plane: Common - - - -### Data plane: iptables - - - -### Data plane: nftables - - - -### Data plane: eBPF - - - -### Data plane: Windows - - - -### Data plane: OpenStack support - - - -### Data plane: XDP acceleration for iptables data plane - - - -### Overlay: VXLAN overlay - - - -### Overlay: IP-in-IP - - - -### Overlay: WireGuard - - - -### AWS integration - - - -### Debug/test-only (generally unsupported) - - - -### Usage reporting - - - -## Environment variables - -The highest priority of configuration is that read from environment -variables. To set a configuration parameter via an environment variable, -set the environment variable formed by taking `FELIX_` and appending the -uppercase form of the variable name. For example, to set the etcd -address, set the environment variable `FELIX_ETCDADDR`. Other examples -include `FELIX_ETCDSCHEME`, `FELIX_ETCDKEYFILE`, `FELIX_ETCDCERTFILE`, -`FELIX_ETCDCAFILE`, `FELIX_FELIXHOSTNAME`, `FELIX_LOGFILEPATH` and -`FELIX_METADATAADDR`. - -:::note -To set a parameter to an empty value using an environment variable, assign an empty string to it (e.g., `FELIX_FAILSAFEINBOUNDHOSTPORTS=""`). -::: - -## Configuration file - -On startup, Felix reads an ini-style configuration file. The path to -this file defaults to `/etc/calico/felix.cfg` but can be overridden -using the `-c` or `--config-file` options on the command line. If the -file exists, then it is read (ignoring section names) and all parameters -are set from it. - -In OpenStack, we recommend putting all configuration into configuration -files, since the etcd database is transient (and may be recreated by the -OpenStack plugin in certain error cases). However, in a Docker -environment the use of environment variables or etcd is often more -convenient. - -## Datastore - -Felix also reads configuration parameters from the datastore. It supports -a global setting and a per-host override. - -1. Get the current felixconfig settings. - - ```bash - calicoctl get felixconfig default -o yaml --export > felix.yaml - ``` - -1. Modify logFilePath to your intended path, e.g. "/tmp/felix.log" - - ```bash - vim felix.yaml - ``` - - :::tip - - For a global change set name to "default". - For a node-specific change: set name to `node.`, e.g. "node.$[prodname]-node-1" - - ::: - -1. Replace the current felixconfig settings - - ```bash - calicoctl replace -f felix.yaml - ``` - -For more information, see [Felix Configuration Resource](../resources/felixconfig.mdx). - - - diff --git a/calico_versioned_docs/version-3.29/reference/felix/index.mdx b/calico_versioned_docs/version-3.29/reference/felix/index.mdx deleted file mode 100644 index b7c1e2d1c1..0000000000 --- a/calico_versioned_docs/version-3.29/reference/felix/index.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: Felix is a Calico component that runs on every machine that provides endpoints. -hide_table_of_contents: true ---- - -# Felix - -import DocCardList from '@theme/DocCardList'; -import { useCurrentSidebarCategory } from '@docusaurus/theme-common'; - - diff --git a/calico_versioned_docs/version-3.29/reference/felix/prometheus.mdx b/calico_versioned_docs/version-3.29/reference/felix/prometheus.mdx deleted file mode 100644 index 319f93b229..0000000000 --- a/calico_versioned_docs/version-3.29/reference/felix/prometheus.mdx +++ /dev/null @@ -1,231 +0,0 @@ ---- -description: Review metrics for the Felix component if you are using Prometheus. ---- - -# Monitoring Felix with Prometheus - -Felix can be configured to report a number of metrics through Prometheus. See the -[configuration reference](configuration.mdx) for how to enable metrics reporting. - -## Metric reference - -### Felix specific - -Felix exports a number of Prometheus metrics. The current set is as follows. Since some metrics -are tied to particular implementation choices inside Felix we can't make any hard guarantees that -metrics will persist across releases. However, we aim not to make any spurious changes to -existing metrics. - -#### Cluster-wide metrics - -| Name | Description | -|----------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| `felix_cluster_num_host_endpoints` | Total number of host endpoints cluster-wide. | -| `felix_cluster_num_hosts` | Total number of $[prodname] hosts in the cluster. | -| `felix_cluster_num_policies` | Total number of policies in the cluster. | -| `felix_cluster_num_profiles` | Total number of profiles in the cluster. | -| `felix_cluster_num_tiers` | Total number of $[prodname] tiers in the cluster. | -| `felix_cluster_num_workload_endpoints` | Total number of workload endpoints cluster-wide. | - -#### General metrics - -| Name | Description | -|----------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| `felix_active_local_endpoints` | Number of active endpoints (workload+host) on this host. | -| `felix_active_local_policies` | Number of active policies on this host. Only "active" policies that match a local endpoint have a significant cost. | -| `felix_active_local_selectors` | Number of active selectors on this host. Only "active" rule src/dest selectors have significant cost. | -| `felix_exec_time_micros` | Summary of time taken to fork/exec child processes. | -| `felix_log_errors` | Number of errors encountered while making normal "process" logs (for example to stdout). | -| `felix_logs_dropped` | Number of logs dropped because the output stream was blocked. | - -#### Calculation graph metrics - -The calculation graph processes updates from the datastore to calculate the active endpoints/policy/etc for this node. - -| Name | Description | -|----------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| `felix_calc_graph_output_events` | Number of events emitted by the calculation graph. | -| `felix_calc_graph_update_time_seconds` | Seconds to update calculation graph for each datastore OnUpdate call. | -| `felix_calc_graph_updates_processed` | Number of datastore updates processed by the calculation graph. | - -#### Common data plane metrics - -| Name | Description | -|----------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| `felix_resyncs_started` | Number of times Felix has started resyncing with the datastore. (Not meaningful in a Typha deployment.) | -| `felix_resync_state` | Current datastore-dataplane synchronisation state, encoded as a number 1="waiting for datastore", 2="resync in progress", 3="in sync with datastore". | -| `felix_int_dataplane_addr_msg_batch_size` | Number of interface address messages processed in each batch. Higher values indicate we're doing more batching to try to keep up. | -| `felix_int_dataplane_apply_time_seconds` | Time in seconds that it took to apply a data plane update. | -| `felix_int_dataplane_failures` | Number of times data plane updates failed and will be retried. | -| `felix_int_dataplane_iface_msg_batch_size` | Number of interface state messages processed in each batch. Higher values indicate we're doing more batching to try to keep up. | -| `felix_int_dataplane_messages` | Number data plane messages by type. | -| `felix_int_dataplane_msg_batch_size` | Number of messages processed in each batch. Higher values indicate we're doing more batching to try to keep up. | -| `felix_route_table_list_seconds` | Time taken to list all the interfaces during a resync. | -| `felix_route_table_per_iface_sync_seconds` | Time taken to sync each interface | - -#### iptables data plane metrics - -| Name | Description | -|----------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| `felix_iptables_chains` | Number of active iptables chains. | -| `felix_iptables_lines_executed` | Number of iptables rule updates executed. | -| `felix_iptables_lock_acquire_secs` | Time taken to acquire the iptables lock. | -| `felix_iptables_lock_retries` | Number of times the iptables lock was already held and felix had to retry to acquire it. | -| `felix_iptables_restore_calls` | Number of iptables-restore calls. | -| `felix_iptables_restore_errors` | Number of iptables-restore errors. | -| `felix_iptables_rules` | Number of active iptables rules. | -| `felix_iptables_save_calls` | Number of iptables-save calls. | -| `felix_iptables_save_errors` | Number of iptables-save errors. | - -#### BPF data plane metrics - -| Name | Description | -|----------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| `felix_bpf_dataplane_endpoints` | Number of BPF endpoints managed in the data plane. | -| `felix_bpf_dirty_dataplane_endpoints` | Number of BPF endpoints managed in the data plane that are left dirty after a failure. | -| `felix_bpf_happy_dataplane_endpoints` | Number of BPF endpoints that are successfully programmed. | -| `felix_bpf_num_ip_sets` | Number of BPF IP sets managed in the data plane. | - -Prometheus metrics are self-documenting, with metrics turned on, `curl` can be used to list the -metrics along with their help text and type information. - -```bash -curl -s http://localhost:9091/metrics | head -``` - -Example response: - -``` -# HELP felix_active_local_endpoints Number of active endpoints on this host. -# TYPE felix_active_local_endpoints gauge -felix_active_local_endpoints 91 -# HELP felix_active_local_policies Number of active policies on this host. -# TYPE felix_active_local_policies gauge -felix_active_local_policies 0 -# HELP felix_active_local_selectors Number of active selectors on this host. -# TYPE felix_active_local_selectors gauge -felix_active_local_selectors 82 -... -``` - -### Label indexing metrics - -The label index is a subcomponent of Felix that is responsible for calculating the set of endpoints and network sets -that match each selector that is in an active policy rule. Policy rules are active on a particular node if the policy -they belong to selects a workload or host endpoint on that node with its top-level selector (in `spec.selector`). -Inactive policies have minimal CPU cost because their selectors do not get indexed. - -Since the label index must match the active selectors against _all_ endpoints and network sets in the cluster, its -performance is critical and it supports various optimizations to minimize CPU usage. Its metrics can be used to -check that the optimizations are active for your policy set. - -#### `felix_label_index_num_endpoints` - -Reports the total number of endpoints (and similar objects such as network sets) being tracked by the index. -This should match the number of endpoints and network sets in your cluster. - -#### `felix_label_index_num_active_selectors{optimized="true|false"}` - -Reports the total number of active selectors, broken into `optimized="true"` and `optimized="false"` sub-totals. - -The `optimized="true"` total tracks the number of selectors that the label index was able to optimize. Those -selectors should be calculated efficiently even in clusters with hundreds of thousands of endpoints. In general the -CPU used to calculate them should be proportional to the number of endpoints that match them and the churn rate of -_those_ endpoints. - -The `optimized="false"` total tracks the number of selectors that could not be optimized. Unoptimized selectors are -much more costly to calculate; the CPU used to calculate them is proportional to the number of endpoints -in the cluster and their churn rate. It is generally OK to have a handful of unoptimized selectors, -but if many selectors are unoptimized the CPU usage can be substantial at high scale. - -For more information on writing selectors that can be optimized, see the [this](../resources/networkpolicy.mdx#selector-performance-in-entityrules) -section of the `NetworkPolicy` reference. - -#### `felix_label_index_selector_evals{result="true|false"}` - -Counts the total number of times that a selector was evaluated vs an endpoint to determine if it matches, broken -down by match (`true`) or no-match (`false`). The ratio of match to no-match shows how effective the selector -indexing optimizations are for your policy set. The more effectively the label index can optimize the selectors, -the fewer "no-match" results it will report relative to "match". - -If you have more than a handful of active selectors and `felix_label_index_selector_evals{result="false"}` is many -times `felix_label_index_selector_evals{result="true"}` then it is likely that some selectors in the policy set are -not being optimized effectively. - -#### `felix_label_index_strategy_evals{strategy="..."}` - -This is a technical statistic that shows how many times the label index has employed each optimization -strategy that it has available. The strategies will likely evolve over time but, at time of writing, they are -as follows: - -- `endpoint-full-scan`: the least efficient fall back strategy for unoptimized selectors. The index - scanned _all_ endpoints to find the matches for a selector. - -- `endpoint|parent-no-match`: the most efficient strategy; the index was able to prove that nothing matched the - selector so it was able to skip the scan entirely. - -- `endpoint|parent-single-value`: the label index was able to limit the scan to only those endpoints/parents that - have a particular label and value combination. For example, selector `label == "value"` would only scan items that - had exactly that label set to "value". - -- `endpoint|parent-multi-value`: the label index was able to limit the scan to only those endpoints/parents that - have a particular label and one of a few values. For example, selector `label in {"a", "b")` would only scan items - that had exactly that label with one of the given values. - -- `endpoint|parent-label-name`: the label index was able to limit the scan to only those endpoints/parents that - have a particular label (but was unable to limit it to a particular subset of values). For example, `has(label)` - would result in that kind of scan. - -Terminology: here "endpoint" means "endpoint or NetworkSet" and "parent" is Felix's internal name for resources like -Kubernetes Namespaces. A "parent" scan means that the label index scanned all endpoints that have a parent -matching the strategy. - -### CPU / memory metrics - -Felix also exports the default set of metrics that Prometheus makes available. Currently, those -include: - -| Name | Description | -| --------------------------------------- | ------------------------------------------------------------------ | -| `go_gc_duration_seconds` | A summary of the GC invocation durations. | -| `go_goroutines` | Number of goroutines that currently exist. | -| `go_memstats_alloc_bytes` | Number of bytes allocated and still in use. | -| `go_memstats_alloc_bytes_total` | Total number of bytes allocated, even if freed. | -| `go_memstats_buck_hash_sys_bytes` | Number of bytes used by the profiling bucket hash table. | -| `go_memstats_frees_total` | Total number of frees. | -| `go_memstats_gc_sys_bytes` | Number of bytes used for garbage collection system metadata. | -| `go_memstats_heap_alloc_bytes` | Number of heap bytes allocated and still in use. | -| `go_memstats_heap_idle_bytes` | Number of heap bytes waiting to be used. | -| `go_memstats_heap_inuse_bytes` | Number of heap bytes that are in use. | -| `go_memstats_heap_objects` | Number of allocated objects. | -| `go_memstats_heap_released_bytes_total` | Total number of heap bytes released to OS. | -| `go_memstats_heap_sys_bytes` | Number of heap bytes obtained from system. | -| `go_memstats_last_gc_time_seconds` | Number of seconds since 1970 of last garbage collection. | -| `go_memstats_lookups_total` | Total number of pointer lookups. | -| `go_memstats_mallocs_total` | Total number of mallocs. | -| `go_memstats_mcache_inuse_bytes` | Number of bytes in use by mcache structures. | -| `go_memstats_mcache_sys_bytes` | Number of bytes used for mcache structures obtained from system. | -| `go_memstats_mspan_inuse_bytes` | Number of bytes in use by mspan structures. | -| `go_memstats_mspan_sys_bytes` | Number of bytes used for mspan structures obtained from system. | -| `go_memstats_next_gc_bytes` | Number of heap bytes when next garbage collection will take place. | -| `go_memstats_other_sys_bytes` | Number of bytes used for other system allocations. | -| `go_memstats_stack_inuse_bytes` | Number of bytes in use by the stack allocator. | -| `go_memstats_stack_sys_bytes` | Number of bytes obtained from system for stack allocator. | -| `go_memstats_sys_bytes` | Number of bytes obtained by system. Sum of all system allocations. | -| `process_cpu_seconds_total` | Total user and system CPU time spent in seconds. | -| `process_max_fds` | Maximum number of open file descriptors. | -| `process_open_fds` | Number of open file descriptors. | -| `process_resident_memory_bytes` | Resident memory size in bytes. | -| `process_start_time_seconds` | Start time of the process since Unix epoch in seconds. | -| `process_virtual_memory_bytes` | Virtual memory size in bytes. | - -### WireGuard Metrics - -Felix also exports WireGuard device stats if found/detected. Can be disabled via Felix configuration. - -| Name | Description | -| ------------------------------------ | ------------------------------------------------------------------------------------------------- | -| `wireguard_meta` | Gauge. Device / interface information for a felix/calico node, values are in this metric's labels | -| `wireguard_bytes_rcvd` | Counter. Current bytes received from a peer identified by a peer public key and endpoint | -| `wireguard_bytes_sent` | Counter. Current bytes sent to a peer identified by a peer public key and endpoint | -| `wireguard_latest_handshake_seconds` | Gauge. Last handshake with a peer, Unix timestamp in seconds. | diff --git a/calico_versioned_docs/version-3.29/reference/host-endpoints/connectivity.mdx b/calico_versioned_docs/version-3.29/reference/host-endpoints/connectivity.mdx deleted file mode 100644 index 499c287500..0000000000 --- a/calico_versioned_docs/version-3.29/reference/host-endpoints/connectivity.mdx +++ /dev/null @@ -1,92 +0,0 @@ ---- -description: Customize the Calico failsafe policy to protect host endpoints. ---- - -# Creating policy for basic connectivity - -When a host endpoint is added, if there is no security policy for that -endpoint, $[prodname] will default to denying traffic to/from that endpoint, -except for traffic that is allowed by the [failsafe rules](failsafe.mdx). - -While the [failsafe rules](failsafe.mdx) provide protection against removing all -connectivity to a host: - -- They are overly broad in allowing inbound SSH on any interface and - allowing traffic out to etcd's ports on any interface. -- Depending on your network, they may not cover all the ports that are - required; for example, your network may rely on allowing ICMP, - or DHCP. - -Therefore, we recommend creating a failsafe $[prodname] security policy that -is tailored to your environment. The example command below shows one -example of how you might do that; the command uses `calicoctl` to create a single -policy resource, which: - -- Applies to all known endpoints. -- Allows inbound ssh access from a defined "management" subnet. -- Allows outbound connectivity to etcd on a particular IP; if - you have multiple etcd servers you should duplicate the rule - for each destination. -- Allows inbound ICMP. -- Allows outbound UDP on port 67, for DHCP. - -When running this command, replace the placeholders in angle brackets with -appropriate values for your deployment. - -{/* */} - -```bash -cat <" - destination: - ports: [22] - - action: Allow - protocol: ICMP - egress: - - action: Allow - protocol: TCP - destination: - nets: [/32] - ports: [] - - action: Allow - protocol: TCP - destination: - nets: [] - - action: Allow - protocol: UDP - destination: - ports: [67] -EOF -``` - -Once you have such a policy in place, you may want to disable the -[failsafe rules](failsafe.mdx). - -:::note - -Packets that reach the end of the list of rules fall-through to the -next policy (sorted by the `order` field). -The selector in the policy, `all()`, will match _all_ endpoints, -including any workload endpoints. If you have workload endpoints as -well as host endpoints then you may wish to use a more restrictive -selector. For example, you could label management interfaces with -label `endpoint_type = management` and then use selector -`endpoint_type == "management"` -If you are using $[prodname] for networking workloads, you should add -inbound and outbound rules to allow BGP: add an ingress and egress rule -to allow TCP traffic to destination port 179. - -::: diff --git a/calico_versioned_docs/version-3.29/reference/host-endpoints/conntrack.mdx b/calico_versioned_docs/version-3.29/reference/host-endpoints/conntrack.mdx deleted file mode 100644 index c7d6fa1255..0000000000 --- a/calico_versioned_docs/version-3.29/reference/host-endpoints/conntrack.mdx +++ /dev/null @@ -1,29 +0,0 @@ ---- -description: Workaround for Linux conntrack if Calico policy is not working as it should. ---- - -# Connection tracking - -$[prodname] uses Linux's connection tracking ('conntrack') as an important -optimization to its processing. It generally means that $[prodname] only needs to -check its policies for the first packet in an allowed flow—between a pair of -IP addresses and ports—and then conntrack automatically allows further -packets in the same flow, without $[prodname] rechecking every packet. - -This can, however, make it look like a $[prodname] policy is not working as it -should, if policy is changed to disallow a flow that was previously allowed. -If packets were recently exchanged on the previously allowed flow, and so there -is conntrack state for that flow that has not yet expired, that conntrack state -will allow further packets between the same IP addresses and ports, even after -the $[prodname] policy has been changed. - -Per $[prodname]'s current implementation, there are two workarounds for this: - -- Somehow ensure that no further packets flow between the relevant IP - addresses and ports until the conntrack state has expired (typically about - a minute). - -- Use the 'conntrack' tool to delete the relevant conntrack state; for example - `conntrack -D -p tcp --orig-port-dst 80`. - -Then you should observe that the new $[prodname] policy is enforced for new packets. diff --git a/calico_versioned_docs/version-3.29/reference/host-endpoints/failsafe.mdx b/calico_versioned_docs/version-3.29/reference/host-endpoints/failsafe.mdx deleted file mode 100644 index 90caf56626..0000000000 --- a/calico_versioned_docs/version-3.29/reference/host-endpoints/failsafe.mdx +++ /dev/null @@ -1,44 +0,0 @@ ---- -description: Avoid cutting off connectivity to hosts because of incorrect network policies. ---- - -# Failsafe rules - -To avoid completely cutting off a host via incorrect or malformed -policy, $[prodname] has a failsafe mechanism that keeps various pinholes open -in the firewall. - -By default, $[prodname] keeps the following ports open on _all_ host endpoints: - -| Port | Protocol | Direction | Purpose | -| ---- | -------- | ------------------ | ------------------------------- | -| 22 | TCP | Inbound | SSH access | -| 53 | UDP | Outbound | DNS queries | -| 67 | UDP | Outbound | DHCP access | -| 68 | UDP | Inbound | DHCP access | -| 179 | TCP | Inbound & Outbound | BGP access (Calico networking) | -| 2379 | TCP | Inbound & Outbound | etcd access | -| 2380 | TCP | Inbound & Outbound | etcd access | -| 5473 | TCP | Inbound & Outbound | etcd access | -| 6443 | TCP | Inbound & Outbound | Kubernetes API server access | -| 6666 | TCP | Inbound & Outbound | etcd self-hosted service access | -| 6667 | TCP | Inbound & Outbound | etcd self-hosted service access | - -The lists of failsafe ports can be configured via the configuration parameters -`FailsafeInboundHostPorts` and `FailsafeOutboundHostPorts` -described in [Configuring Felix](../felix/configuration.mdx) -. They -can be disabled by setting each configuration value to "[]". - -:::note - -Removing the inbound failsafe rules can leave a host inaccessible. - -Removing the outbound failsafe rules can leave Felix unable to connect -to etcd. - -Before disabling the failsafe rules, we recommend creating a policy to -replace it with more-specific rules for your environment: see -[Creating policy for basic connectivity](connectivity.mdx). - -::: diff --git a/calico_versioned_docs/version-3.29/reference/host-endpoints/forwarded.mdx b/calico_versioned_docs/version-3.29/reference/host-endpoints/forwarded.mdx deleted file mode 100644 index 92b6c0e087..0000000000 --- a/calico_versioned_docs/version-3.29/reference/host-endpoints/forwarded.mdx +++ /dev/null @@ -1,80 +0,0 @@ ---- -description: Learn the subtleties using the applyOnForward option in host endpoint policies. ---- - -# Apply on forwarded traffic - -If `applyOnForward` is `false`, the host endpoint policy applies to traffic to/from -local processes only. - -If `applyOnForward` is `true`, the host endpoint policy also applies to forwarded traffic: - -- Traffic that comes in via a host endpoint and is forwarded to a local workload (container/pod/VM). -- Traffic from a local workload that is forwarded out via a host endpoint. -- Traffic that comes in via a host endpoint and is forwarded out via another host endpoint. - -By default, `applyOnForward` is `false`. - -Untracked policies and pre-DNAT policies must have `applyOnForward` set to `true` -because they apply to all forwarded traffic. - -Forwarded traffic is allowed by default if no policies apply to the endpoint and direction. In -other words, if a host endpoint is configured, but there are no policies with `applyOnForward` -set to `true` that apply to that host endpoint and traffic direction, forwarded traffic is -allowed in that direction. For example if a forwarded flow is incoming via a host endpoint, but there are -no Ingress policies with `applyOnForward: true` that apply to that host endpoint, the flow is -allowed. If there are `applyOnForward: true` policies that select the host endpoint and direction, -but no rules in the policies allow the traffic, the traffic is denied. - -This is different from how $[prodname] treats traffic to or from a local process: -if a host endpoint is configured and there are no policies that select the host endpoint in -the traffic direction, or no rules that allow the traffic, the traffic is denied. - -Traffic that traverses a host endpoint and is forwarded to a workload endpoint must also pass -the applicable workload endpoint policy, if any. That is to say, if an `applyOnForward: true` host -endpoint policy allows the traffic, but workload endpoint policy denies it, the packet is still dropped. - -Traffic that ingresses one host endpoint, is forwarded, and egresses host endpoint must -pass ingress policy on the first host endpoint and egress policy on the second host endpoint. - -:::note - -$[prodname]'s handling of host endpoint policy has changed, since before -Calico v3.0, in two ways: - -- It will not apply at all to forwarded traffic, by default. If you have an existing - policy and you want it to apply to forwarded traffic, you need to add `applyOnForward: true` to the policy. -- Even with `applyOnForward: true`, the treatment is not quite the same in - Calico v3.0 as in previous releases, because–once a host endpoint is configured– - Calico v3.0 allows forwarded traffic through that endpoint by default, whereas - previous releases denied forwarded traffic through that endpoint by default. - If you want to maintain the default-deny behavior for all host-endpoint forwarded - traffic, you can create an empty policy with `applyOnForward` set to `true` - that applies to all traffic on all host endpoints. - -::: - -```bash -calicoctl apply -f - < diff --git a/calico_versioned_docs/version-3.29/reference/host-endpoints/objects.mdx b/calico_versioned_docs/version-3.29/reference/host-endpoints/objects.mdx deleted file mode 100644 index 881d42708c..0000000000 --- a/calico_versioned_docs/version-3.29/reference/host-endpoints/objects.mdx +++ /dev/null @@ -1,124 +0,0 @@ ---- -description: To protect a host interface, start by creating a host endpoint object in etcd. ---- - -# Creating host endpoint objects - -For each host endpoint that you want $[prodname] to secure, you'll need to -create a host endpoint object in etcd. Use the `calicoctl create` command -to create a host endpoint resource (`HostEndpoint`). - -There are two ways to specify the interface that a host endpoint should -refer to. You can either specify the name of the interface or its -expected IP address. In either case, you'll also need to know the name given to -the $[prodname] node running on the host that owns the interface; in most cases this -will be the same as the hostname of the host. - -For example, to secure the interface named `eth0` with IP 10.0.0.1 on -host `my-host`, run the command below. The name of the endpoint is an -arbitrary name required for endpoint identification. - -When running this command, replace the placeholders in angle brackets with -appropriate values for your deployment. - -```bash -calicoctl create -f - < - labels: - role: webserver - environment: production - spec: - interfaceName: eth0 - node: - profiles: [] - expectedIPs: ["10.0.0.1"] -EOF -``` - -:::note - -Felix tries to detect the correct hostname for a system. It logs -out the value it has determined at start-of-day in the following -format: -`2015-10-20 17:42:09,813 \[INFO\]\[30149/5\] calico.felix.config 285: Parameter FelixHostname (Felix compute host hostname) has value 'my-hostname' read from None` -The value (in this case `'my-hostname'`) needs to match the hostname -used in etcd. Ideally, the host's system hostname should be set -correctly but if that's not possible, the Felix value can be -overridden with the FelixHostname configuration setting. See -configuration for more details. - -::: - -Where `` is an optional list of security profiles -to apply to the endpoint and labels contains a set of arbitrary -key/value pairs that can be used in selector expressions. - -{/* TODO(smc) data-model: Link to new data model docs. */} - -:::note - -When rendering security rules on other hosts, $[prodname] uses the -`expectedIPs` field to resolve label selectors -to IP addresses. If the `expectedIPs` field is omitted -then security rules that use labels will fail to match -this endpoint. -Or, if you knew that the IP address should be 10.0.0.1, but not the name -of the interface: - -```bash -calicoctl create -f - < - labels: - role: webserver - environment: production - spec: - node: - profiles: [] - expectedIPs: ["10.0.0.1"] -EOF -``` - -::: - -After you create host endpoint objects, Felix will start policing -traffic to/from that interface. If you have no policy or profiles in -place, then you should see traffic being dropped on the interface. - -:::note - -By default, $[prodname] has a failsafe in place that allows certain -traffic such as ssh. See below for more details on -disabling/configuring the failsafe rules. - -::: - -If you don't see traffic being dropped, check the hostname, IP address -and (if used) the interface name in the configuration. If there was -something wrong with the endpoint data, Felix will log a validation -error at `WARNING` level and it will ignore the endpoint: - -A `grep` through the Felix logs for the string "Validation failed" should allow -you to locate the error. - -```bash -grep "Validation failed" /var/log/calico/felix.log -``` - -An example error follows. - -``` -2016-05-31 12:16:21,651 [WARNING][8657/3] calico.felix.fetcd 1017: - Validation failed for host endpoint HostEndpointId, treating as - missing: 'name' or 'expected_ipvX_addrs' must be present.; - '{ "labels": {"foo": "bar"}, "profile_ids": ["prof1"]}' -``` - -The error can be quite long but it should log the precise cause of the -rejection; in this case `'name' or 'expected\_ipvX\_addrs' must be present` tells us that either the interface's name or its expected IP -address must be specified. diff --git a/calico_versioned_docs/version-3.29/reference/host-endpoints/overview.mdx b/calico_versioned_docs/version-3.29/reference/host-endpoints/overview.mdx deleted file mode 100644 index 5582b36578..0000000000 --- a/calico_versioned_docs/version-3.29/reference/host-endpoints/overview.mdx +++ /dev/null @@ -1,57 +0,0 @@ ---- -description: Secure host network interfaces. ---- - -# Host endpoints - -This guide describes how to use $[prodname] to secure the network interfaces -of the host itself (as opposed to those of any container/VM workloads -that are present on the host). We call such interfaces "host endpoints", -to distinguish them from "workload endpoints" (such as containers or VMs). - -$[prodname] supports the same rich security policy model for host endpoints (host -endpoint policy) that it supports for workload endpoints. Host endpoints can -have labels, and their labels are in the same "namespace" as those of workload -endpoints. This allows security rules for either type of endpoint to refer to -the other type (or a mix of the two) using labels and selectors. - -$[prodname] does not support setting IPs or policing MAC addresses for host -interfaces, it assumes that the interfaces are configured by the -underlying network fabric. - -$[prodname] distinguishes workload endpoints from host endpoints by a configurable -prefix. Unless you happen to have host interfaces whose name matches the -default for that prefix (`cali`), you won't need to change it. In case you do, -see the `InterfacePrefix` configuration value at [Configuring Felix](../felix/configuration.mdx) -. -Interfaces that start with a value listed in `InterfacePrefix` are assumed to -be workload interfaces. Others are treated as host interfaces. - -$[prodname] blocks all traffic to/from workload interfaces by default; -allowing traffic only if the interface is known and policy is in place. -However, for host endpoints, $[prodname] is more lenient; it only polices -traffic to/from interfaces that it's been explicitly told about. Traffic -to/from other interfaces is left alone. - -You can use host endpoint policy to secure a NAT gateway or router. $[prodname] -supports selector-based policy when running on a gateway or router, allowing for -rich, dynamic security policy based on the labels attached to your host endpoints. - -You can apply host endpoint policies to three types of traffic: - -- Traffic that is terminated locally. -- Traffic that is forwarded between host endpoints. -- Traffic that is forwarded between a host endpoint and a workload endpoint on the - same host. - -Set the `applyOnForward` flag to `true` to apply a policy to forwarded traffic. -See [GlobalNetworkPolicy spec](../resources/globalnetworkpolicy.mdx#spec). - -:::note - -Both traffic forwarded between host endpoints and traffic forwarded -between a host endpoint and a workload endpoint on the same host is regarded as -`forwarded traffic`. -![Diagram showing packet flows for forwarded traffic between host endpoints and between host endpoints and workload endpoints](/img/calico/bare-metal-packet-flows.svg) - -::: diff --git a/calico_versioned_docs/version-3.29/reference/host-endpoints/pre-dnat.mdx b/calico_versioned_docs/version-3.29/reference/host-endpoints/pre-dnat.mdx deleted file mode 100644 index 298b001ce8..0000000000 --- a/calico_versioned_docs/version-3.29/reference/host-endpoints/pre-dnat.mdx +++ /dev/null @@ -1,46 +0,0 @@ ---- -description: Apply rules in a host endpoint policy before any DNAT. ---- - -# Pre-DNAT policy - -Policy for host endpoints can be marked as `preDNAT`. This means that rules in -that policy should be applied before any DNAT (Destination Network Address -Translation), which is useful if it is more convenient to specify $[prodname] policy -in terms of a packet's original destination IP address and port, than in terms -of that packet's destination IP address and port after it has been DNAT'd. - -An example is securing access to Kubernetes NodePorts from outside the cluster. -Traffic from outside is addressed to any node's IP address, on a known -NodePort, and Kubernetes (kube-proxy) then DNATs that to the IP address of one -of the pods that provides the corresponding service, and the relevant port -number on that pod (which is usually different from the NodePort). - -As NodePorts are the externally advertised way of connecting to services (and a -NodePort uniquely identifies a service, whereas an internal port number may -not), it makes sense to express $[prodname] policy to expose or secure particular -Services in terms of the corresponding NodePorts. But that is only possible if -the $[prodname] policy is applied before DNAT changes the NodePort to something -else. Hence this kind of policy needs `preDNAT` set to `true`. - -In addition to being applied before any DNAT, the enforcement of pre-DNAT -policy differs from that of normal host endpoint policy in three key details, -reflecting that it is designed for the policing of incoming traffic from -outside the cluster: - -- Pre-DNAT policy may only have ingress rules, not egress. (When incoming - traffic is allowed by the ingress rules, standard connection tracking is - sufficient to allow the return path traffic.) - -- Pre-DNAT policy is enforced for all traffic arriving through a host - endpoint, regardless of where that traffic is going, and - in particular - - even if that traffic is routed to a local workload on the same host. - (Whereas normal host endpoint policy is skipped, for traffic going to a - local workload.) - -- There is no 'default drop' semantic for pre-DNAT policy (as there is for - normal host endpoint policy). In other words, if a host endpoint is defined - but has no pre-DNAT policies that explicitly allow or deny a particular - incoming packet, that packet is allowed to continue on its way, and will - then be accepted or dropped according to workload policy (if it is going to - a local workload) or to normal host endpoint policy (if not). diff --git a/calico_versioned_docs/version-3.29/reference/host-endpoints/selector.mdx b/calico_versioned_docs/version-3.29/reference/host-endpoints/selector.mdx deleted file mode 100644 index 9fc2d1bc4d..0000000000 --- a/calico_versioned_docs/version-3.29/reference/host-endpoints/selector.mdx +++ /dev/null @@ -1,30 +0,0 @@ ---- -description: Apply ordered policies to endpoints that match specific label selectors. ---- - -# Selector-based policies - -We recommend using selector-based security policy with -host endpoints. This allows ordered policy to be applied to -endpoints that match particular label selectors. - -For example, you could add a second policy for webserver access: - -```bash -cat < - - - - - -## calicoctl reference - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -## Resource definitions - - - - - - - - - - - - - - - - - - - - - - -## Configuring etcd RBAC - - - - - - - - - -## Felix - - - - - -## Typha - - - - - - - -## Configuration on public clouds - - - - - - - - -## Host endpoints - - - - - - - - - - - - -## Architecture - - - - - -## VPP data plane - - - - - - -## Other reference topics - - - - - - - - - diff --git a/calico_versioned_docs/version-3.29/reference/installation/_README b/calico_versioned_docs/version-3.29/reference/installation/_README deleted file mode 100644 index aae49971ad..0000000000 --- a/calico_versioned_docs/version-3.29/reference/installation/_README +++ /dev/null @@ -1,7 +0,0 @@ -# Generating API reference docs - -The _api.md doc in this directory is generated using https://github.com/elastic/crd-ref-docs/ - -To generate an updated file, change to the root of the docs repository and run -the appropriate Makefile target `make build-crd-reference-docs` passing the correct `PRODUCT`. -See the `README.md` file for more details on how to list available targets and which ones to run. diff --git a/calico_versioned_docs/version-3.29/reference/installation/_api.mdx b/calico_versioned_docs/version-3.29/reference/installation/_api.mdx deleted file mode 100644 index c85436e50d..0000000000 --- a/calico_versioned_docs/version-3.29/reference/installation/_api.mdx +++ /dev/null @@ -1,1550 +0,0 @@ -Packages -- [operator.tigera.io/v1](#operatortigeraiov1) - - -{/* vale off */} - -## operator.tigera.io/v1 - -API Schema definitions for configuring the installation of Calico and Calico Enterprise - -Package v1 contains API Schema definitions for the operator v1 API group - -Resource Types -- [APIServer](#apiserver) -- [ImageSet](#imageset) -- [Installation](#installation) -- [TigeraStatus](#tigerastatus) - - - -### APIServer - - - -APIServer installs the Tigera API server and related resources. At most one instance -of this resource is supported. It must be named "default" or "tigera-secure". - -| Field | Description | -| --- | --- | -| `apiVersion` _string_ | `operator.tigera.io/v1` | -| `kind` _string_ | `APIServer` | -| `metadata` _[ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#objectmeta-v1-meta)_ | Refer to Kubernetes API documentation for fields of `metadata`. | -| `spec` _[APIServerSpec](#apiserverspec)_ | Specification of the desired state for the Tigera API server. | -| `status` _[APIServerStatus](#apiserverstatus)_ | Most recently observed status for the Tigera API server. | - - -### APIServerDeployment - - - -APIServerDeployment is the configuration for the API server Deployment. - -_Appears in:_ -- [APIServerSpec](#apiserverspec) - -| Field | Description | -| --- | --- | -| `metadata` _[Metadata](#metadata)_ | (Optional) Refer to Kubernetes API documentation for fields of `metadata`. | -| `spec` _[APIServerDeploymentSpec](#apiserverdeploymentspec)_ | (Optional) Spec is the specification of the API server Deployment. | - - -### APIServerDeploymentContainer - - - -APIServerDeploymentContainer is an API server Deployment container. - -_Appears in:_ -- [APIServerDeploymentPodSpec](#apiserverdeploymentpodspec) - -| Field | Description | -| --- | --- | -| `name` _string_ | Name is an enum which identifies the API server Deployment container by name.
    Supported values are: calico-apiserver, tigera-queryserver | -| `resources` _[ResourceRequirements](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#resourcerequirements-v1-core)_ | (Optional) Resources allows customization of limits and requests for compute resources such as cpu and memory. If specified, this overrides the named API server Deployment container's resources. If omitted, the API server Deployment will use its default value for this container's resources. If used in conjunction with the deprecated ComponentResources, then this value takes precedence. | - - -### APIServerDeploymentInitContainer - - - -APIServerDeploymentInitContainer is an API server Deployment init container. - -_Appears in:_ -- [APIServerDeploymentPodSpec](#apiserverdeploymentpodspec) - -| Field | Description | -| --- | --- | -| `name` _string_ | Name is an enum which identifies the API server Deployment init container by name.
    Supported values are: calico-apiserver-certs-key-cert-provisioner | -| `resources` _[ResourceRequirements](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#resourcerequirements-v1-core)_ | (Optional) Resources allows customization of limits and requests for compute resources such as cpu and memory. If specified, this overrides the named API server Deployment init container's resources. If omitted, the API server Deployment will use its default value for this init container's resources. | - - -### APIServerDeploymentPodSpec - - - -APIServerDeploymentDeploymentPodSpec is the API server Deployment's PodSpec. - -_Appears in:_ -- [APIServerDeploymentPodTemplateSpec](#apiserverdeploymentpodtemplatespec) - -| Field | Description | -| --- | --- | -| `initContainers` _[APIServerDeploymentInitContainer](#apiserverdeploymentinitcontainer) array_ | (Optional) InitContainers is a list of API server init containers. If specified, this overrides the specified API server Deployment init containers. If omitted, the API server Deployment will use its default values for its init containers. | -| `containers` _[APIServerDeploymentContainer](#apiserverdeploymentcontainer) array_ | (Optional) Containers is a list of API server containers. If specified, this overrides the specified API server Deployment containers. If omitted, the API server Deployment will use its default values for its containers. | -| `affinity` _[Affinity](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#affinity-v1-core)_ | (Optional) Affinity is a group of affinity scheduling rules for the API server pods. If specified, this overrides any affinity that may be set on the API server Deployment. If omitted, the API server Deployment will use its default value for affinity.
    WARNING: Please note that this field will override the default API server Deployment affinity. | -| `nodeSelector` _object (keys:string, values:string)_ | NodeSelector is the API server pod's scheduling constraints. If specified, each of the key/value pairs are added to the API server Deployment nodeSelector provided the key does not already exist in the object's nodeSelector. If used in conjunction with ControlPlaneNodeSelector, that nodeSelector is set on the API server Deployment and each of this field's key/value pairs are added to the API server Deployment nodeSelector provided the key does not already exist in the object's nodeSelector. If omitted, the API server Deployment will use its default value for nodeSelector.
    WARNING: Please note that this field will modify the default API server Deployment nodeSelector. | -| `topologySpreadConstraints` _[TopologySpreadConstraint](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#topologyspreadconstraint-v1-core) array_ | (Optional) TopologySpreadConstraints describes how a group of pods ought to spread across topology domains. Scheduler will schedule pods in a way which abides by the constraints. All topologySpreadConstraints are ANDed. | -| `tolerations` _[Toleration](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#toleration-v1-core) array_ | (Optional) Tolerations is the API server pod's tolerations. If specified, this overrides any tolerations that may be set on the API server Deployment. If omitted, the API server Deployment will use its default value for tolerations.
    WARNING: Please note that this field will override the default API server Deployment tolerations. | -| `priorityClassName` _string_ | (Optional) PriorityClassName allows to specify a PriorityClass resource to be used. | - - -### APIServerDeploymentPodTemplateSpec - - - -APIServerDeploymentPodTemplateSpec is the API server Deployment's PodTemplateSpec - -_Appears in:_ -- [APIServerDeploymentSpec](#apiserverdeploymentspec) - -| Field | Description | -| --- | --- | -| `metadata` _[Metadata](#metadata)_ | (Optional) Refer to Kubernetes API documentation for fields of `metadata`. | -| `spec` _[APIServerDeploymentPodSpec](#apiserverdeploymentpodspec)_ | (Optional) Spec is the API server Deployment's PodSpec. | - - -### APIServerDeploymentSpec - - - -APIServerDeploymentSpec defines configuration for the API server Deployment. - -_Appears in:_ -- [APIServerDeployment](#apiserverdeployment) - -| Field | Description | -| --- | --- | -| `minReadySeconds` _integer_ | (Optional) MinReadySeconds is the minimum number of seconds for which a newly created Deployment pod should be ready without any of its container crashing, for it to be considered available. If specified, this overrides any minReadySeconds value that may be set on the API server Deployment. If omitted, the API server Deployment will use its default value for minReadySeconds. | -| `template` _[APIServerDeploymentPodTemplateSpec](#apiserverdeploymentpodtemplatespec)_ | (Optional) Template describes the API server Deployment pod that will be created. | - - -### APIServerSpec - - - -APIServerSpec defines the desired state of Tigera API server. - -_Appears in:_ -- [APIServer](#apiserver) - -| Field | Description | -| --- | --- | -| `apiServerDeployment` _[APIServerDeployment](#apiserverdeployment)_ | APIServerDeployment configures the calico-apiserver (or tigera-apiserver in Enterprise) Deployment. If used in conjunction with ControlPlaneNodeSelector or ControlPlaneTolerations, then these overrides take precedence. | - - -### APIServerStatus - - - -APIServerStatus defines the observed state of Tigera API server. - -_Appears in:_ -- [APIServer](#apiserver) - -| Field | Description | -| --- | --- | -| `state` _string_ | State provides user-readable status. | -| `conditions` _[Condition](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#condition-v1-meta) array_ | (Optional) Conditions represents the latest observed set of conditions for the component. A component may be one or more of Ready, Progressing, Degraded or other customer types. | - - - - -### Azure - - - - - -_Appears in:_ -- [InstallationSpec](#installationspec) - -| Field | Description | -| --- | --- | -| `policyMode` _[PolicyMode](#policymode)_ | (Optional) PolicyMode determines whether the "control-plane" label is applied to namespaces. It offers two options: Default and Manual. The Default option adds the "control-plane" label to the required namespaces. The Manual option does not apply the "control-plane" label to any namespace.
    Default: Default | - - -### BGPOption - -_Underlying type:_ _string_ - -BGPOption describes the mode of BGP to use. - -One of: Enabled, Disabled - -_Appears in:_ -- [CalicoNetworkSpec](#caliconetworkspec) - -| Value | Description | -| --- | --- | -| `Enabled` | | -| `Disabled` | | - - - - -### CNILogging - - - - - -_Appears in:_ -- [Logging](#logging) - -| Field | Description | -| --- | --- | -| `logSeverity` _[LogLevel](#loglevel)_ | (Optional)
    Default: Info | -| `logFileMaxSize` _[Quantity](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#quantity-resource-api)_ | (Optional)
    Default: 100Mi | -| `logFileMaxAgeDays` _integer_ | (Optional)
    Default: 30 (days) | -| `logFileMaxCount` _integer_ | (Optional)
    Default: 10 | - - -### CNIPluginType - -_Underlying type:_ _string_ - -CNIPluginType describes the type of CNI plugin used. - -One of: Calico, GKE, AmazonVPC, AzureVNET - -_Appears in:_ -- [CNISpec](#cnispec) - -| Value | Description | -| --- | --- | -| `Calico` | | -| `GKE` | | -| `AmazonVPC` | | -| `AzureVNET` | | - - -### CNISpec - - - -CNISpec contains configuration for the CNI plugin. - -_Appears in:_ -- [InstallationSpec](#installationspec) - -| Field | Description | -| --- | --- | -| `type` _[CNIPluginType](#cniplugintype)_ | Specifies the CNI plugin that will be used in the Calico or Calico Enterprise installation. * For KubernetesProvider GKE, this field defaults to GKE. * For KubernetesProvider AKS, this field defaults to AzureVNET. * For KubernetesProvider EKS, this field defaults to AmazonVPC. * If aws-node daemonset exists in kube-system when the Installation resource is created, this field defaults to AmazonVPC. * For all other cases this field defaults to Calico. For the value Calico, the CNI plugin binaries and CNI config will be installed as part of deployment, for all other values the CNI plugin binaries and CNI config is a dependency that is expected to be installed separately.
    Default: Calico | -| `ipam` _[IPAMSpec](#ipamspec)_ | (Optional) IPAM specifies the pod IP address management that will be used in the Calico or Calico Enterprise installation. | - - -### CSINodeDriverDaemonSet - - - -CSINodeDriverDaemonSet is the configuration for the csi-node-driver DaemonSet. - -_Appears in:_ -- [InstallationSpec](#installationspec) - -| Field | Description | -| --- | --- | -| `metadata` _[Metadata](#metadata)_ | (Optional) Refer to Kubernetes API documentation for fields of `metadata`. | -| `spec` _[CSINodeDriverDaemonSetSpec](#csinodedriverdaemonsetspec)_ | (Optional) Spec is the specification of the csi-node-driver DaemonSet. | - - -### CSINodeDriverDaemonSetContainer - - - -CSINodeDriverDaemonSetContainer is a csi-node-driver DaemonSet container. - -_Appears in:_ -- [CSINodeDriverDaemonSetPodSpec](#csinodedriverdaemonsetpodspec) - -| Field | Description | -| --- | --- | -| `name` _string_ | Name is an enum which identifies the csi-node-driver DaemonSet container by name.
    Supported values are: calico-csi, csi-node-driver-registrar. | -| `resources` _[ResourceRequirements](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#resourcerequirements-v1-core)_ | (Optional) Resources allows customization of limits and requests for compute resources such as cpu and memory. If specified, this overrides the named csi-node-driver DaemonSet container's resources. If omitted, the csi-node-driver DaemonSet will use its default value for this container's resources. | - - -### CSINodeDriverDaemonSetPodSpec - - - -CSINodeDriverDaemonSetPodSpec is the csi-node-driver DaemonSet's PodSpec. - -_Appears in:_ -- [CSINodeDriverDaemonSetPodTemplateSpec](#csinodedriverdaemonsetpodtemplatespec) - -| Field | Description | -| --- | --- | -| `containers` _[CSINodeDriverDaemonSetContainer](#csinodedriverdaemonsetcontainer) array_ | (Optional) Containers is a list of csi-node-driver containers. If specified, this overrides the specified csi-node-driver DaemonSet containers. If omitted, the csi-node-driver DaemonSet will use its default values for its containers. | -| `affinity` _[Affinity](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#affinity-v1-core)_ | (Optional) Affinity is a group of affinity scheduling rules for the csi-node-driver pods. If specified, this overrides any affinity that may be set on the csi-node-driver DaemonSet. If omitted, the csi-node-driver DaemonSet will use its default value for affinity.
    WARNING: Please note that this field will override the default csi-node-driver DaemonSet affinity. | -| `nodeSelector` _object (keys:string, values:string)_ | (Optional) NodeSelector is the csi-node-driver pod's scheduling constraints. If specified, each of the key/value pairs are added to the csi-node-driver DaemonSet nodeSelector provided the key does not already exist in the object's nodeSelector. If omitted, the csi-node-driver DaemonSet will use its default value for nodeSelector.
    WARNING: Please note that this field will modify the default csi-node-driver DaemonSet nodeSelector. | -| `tolerations` _[Toleration](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#toleration-v1-core) array_ | (Optional) Tolerations is the csi-node-driver pod's tolerations. If specified, this overrides any tolerations that may be set on the csi-node-driver DaemonSet. If omitted, the csi-node-driver DaemonSet will use its default value for tolerations.
    WARNING: Please note that this field will override the default csi-node-driver DaemonSet tolerations. | - - -### CSINodeDriverDaemonSetPodTemplateSpec - - - -CSINodeDriverDaemonSetPodTemplateSpec is the csi-node-driver DaemonSet's PodTemplateSpec - -_Appears in:_ -- [CSINodeDriverDaemonSetSpec](#csinodedriverdaemonsetspec) - -| Field | Description | -| --- | --- | -| `metadata` _[Metadata](#metadata)_ | (Optional) Refer to Kubernetes API documentation for fields of `metadata`. | -| `spec` _[CSINodeDriverDaemonSetPodSpec](#csinodedriverdaemonsetpodspec)_ | (Optional) Spec is the csi-node-driver DaemonSet's PodSpec. | - - -### CSINodeDriverDaemonSetSpec - - - -CSINodeDriverDaemonSetSpec defines configuration for the csi-node-driver DaemonSet. - -_Appears in:_ -- [CSINodeDriverDaemonSet](#csinodedriverdaemonset) - -| Field | Description | -| --- | --- | -| `minReadySeconds` _integer_ | (Optional) MinReadySeconds is the minimum number of seconds for which a newly created DaemonSet pod should be ready without any of its container crashing, for it to be considered available. If specified, this overrides any minReadySeconds value that may be set on the csi-node-driver DaemonSet. If omitted, the csi-node-driver DaemonSet will use its default value for minReadySeconds. | -| `template` _[CSINodeDriverDaemonSetPodTemplateSpec](#csinodedriverdaemonsetpodtemplatespec)_ | (Optional) Template describes the csi-node-driver DaemonSet pod that will be created. | - - -### CalicoKubeControllersDeployment - - - -CalicoKubeControllersDeployment is the configuration for the calico-kube-controllers Deployment. - -_Appears in:_ -- [InstallationSpec](#installationspec) - -| Field | Description | -| --- | --- | -| `metadata` _[Metadata](#metadata)_ | (Optional) Refer to Kubernetes API documentation for fields of `metadata`. | -| `spec` _[CalicoKubeControllersDeploymentSpec](#calicokubecontrollersdeploymentspec)_ | (Optional) Spec is the specification of the calico-kube-controllers Deployment. | - - -### CalicoKubeControllersDeploymentContainer - - - -CalicoKubeControllersDeploymentContainer is a calico-kube-controllers Deployment container. - -_Appears in:_ -- [CalicoKubeControllersDeploymentPodSpec](#calicokubecontrollersdeploymentpodspec) - -| Field | Description | -| --- | --- | -| `name` _string_ | Name is an enum which identifies the calico-kube-controllers Deployment container by name.
    Supported values are: calico-kube-controllers, es-calico-kube-controllers | -| `resources` _[ResourceRequirements](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#resourcerequirements-v1-core)_ | (Optional) Resources allows customization of limits and requests for compute resources such as cpu and memory. If specified, this overrides the named calico-kube-controllers Deployment container's resources. If omitted, the calico-kube-controllers Deployment will use its default value for this container's resources. If used in conjunction with the deprecated ComponentResources, then this value takes precedence. | - - -### CalicoKubeControllersDeploymentPodSpec - - - -CalicoKubeControllersDeploymentPodSpec is the calico-kube-controller Deployment's PodSpec. - -_Appears in:_ -- [CalicoKubeControllersDeploymentPodTemplateSpec](#calicokubecontrollersdeploymentpodtemplatespec) - -| Field | Description | -| --- | --- | -| `containers` _[CalicoKubeControllersDeploymentContainer](#calicokubecontrollersdeploymentcontainer) array_ | (Optional) Containers is a list of calico-kube-controllers containers. If specified, this overrides the specified calico-kube-controllers Deployment containers. If omitted, the calico-kube-controllers Deployment will use its default values for its containers. | -| `affinity` _[Affinity](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#affinity-v1-core)_ | (Optional) Affinity is a group of affinity scheduling rules for the calico-kube-controllers pods. If specified, this overrides any affinity that may be set on the calico-kube-controllers Deployment. If omitted, the calico-kube-controllers Deployment will use its default value for affinity.
    WARNING: Please note that this field will override the default calico-kube-controllers Deployment affinity. | -| `nodeSelector` _object (keys:string, values:string)_ | NodeSelector is the calico-kube-controllers pod's scheduling constraints. If specified, each of the key/value pairs are added to the calico-kube-controllers Deployment nodeSelector provided the key does not already exist in the object's nodeSelector. If used in conjunction with ControlPlaneNodeSelector, that nodeSelector is set on the calico-kube-controllers Deployment and each of this field's key/value pairs are added to the calico-kube-controllers Deployment nodeSelector provided the key does not already exist in the object's nodeSelector. If omitted, the calico-kube-controllers Deployment will use its default value for nodeSelector.
    WARNING: Please note that this field will modify the default calico-kube-controllers Deployment nodeSelector. | -| `tolerations` _[Toleration](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#toleration-v1-core) array_ | (Optional) Tolerations is the calico-kube-controllers pod's tolerations. If specified, this overrides any tolerations that may be set on the calico-kube-controllers Deployment. If omitted, the calico-kube-controllers Deployment will use its default value for tolerations.
    WARNING: Please note that this field will override the default calico-kube-controllers Deployment tolerations. | - - -### CalicoKubeControllersDeploymentPodTemplateSpec - - - -CalicoKubeControllersDeploymentPodTemplateSpec is the calico-kube-controllers Deployment's PodTemplateSpec - -_Appears in:_ -- [CalicoKubeControllersDeploymentSpec](#calicokubecontrollersdeploymentspec) - -| Field | Description | -| --- | --- | -| `metadata` _[Metadata](#metadata)_ | (Optional) Refer to Kubernetes API documentation for fields of `metadata`. | -| `spec` _[CalicoKubeControllersDeploymentPodSpec](#calicokubecontrollersdeploymentpodspec)_ | (Optional) Spec is the calico-kube-controllers Deployment's PodSpec. | - - -### CalicoKubeControllersDeploymentSpec - - - -CalicoKubeControllersDeploymentSpec defines configuration for the calico-kube-controllers Deployment. - -_Appears in:_ -- [CalicoKubeControllersDeployment](#calicokubecontrollersdeployment) - -| Field | Description | -| --- | --- | -| `minReadySeconds` _integer_ | (Optional) MinReadySeconds is the minimum number of seconds for which a newly created Deployment pod should be ready without any of its container crashing, for it to be considered available. If specified, this overrides any minReadySeconds value that may be set on the calico-kube-controllers Deployment. If omitted, the calico-kube-controllers Deployment will use its default value for minReadySeconds. | -| `template` _[CalicoKubeControllersDeploymentPodTemplateSpec](#calicokubecontrollersdeploymentpodtemplatespec)_ | (Optional) Template describes the calico-kube-controllers Deployment pod that will be created. | - - -### CalicoNetworkSpec - - - -CalicoNetworkSpec specifies configuration options for Calico provided pod networking. - -_Appears in:_ -- [InstallationSpec](#installationspec) - -| Field | Description | -| --- | --- | -| `linuxDataplane` _[LinuxDataplaneOption](#linuxdataplaneoption)_ | (Optional) LinuxDataplane is used to select the dataplane used for Linux nodes. In particular, it causes the operator to add required mounts and environment variables for the particular dataplane. If not specified, iptables mode is used.
    Default: Iptables | -| `windowsDataplane` _[WindowsDataplaneOption](#windowsdataplaneoption)_ | (Optional) WindowsDataplane is used to select the dataplane used for Windows nodes. In particular, it causes the operator to add required mounts and environment variables for the particular dataplane. If not specified, it is disabled and the operator will not render the Calico Windows nodes daemonset.
    Default: Disabled | -| `bgp` _[BGPOption](#bgpoption)_ | (Optional) BGP configures whether or not to enable Calico's BGP capabilities. | -| `ipPools` _[IPPool](#ippool) array_ | (Optional) IPPools contains a list of IP pools to manage. If nil, a single IP pool will be defaulted. If an empty list is provided, the operator will not create any IP pools and will instead wait for IP pools to be created out-of-band. IP pools in this list will be reconciled by the operator and should not be modified out-of-band. | -| `mtu` _integer_ | (Optional) MTU specifies the maximum transmission unit to use on the pod network. If not specified, Calico will perform MTU auto-detection based on the cluster network. | -| `nodeAddressAutodetectionV4` _[NodeAddressAutodetection](#nodeaddressautodetection)_ | (Optional) NodeAddressAutodetectionV4 specifies an approach to automatically detect node IPv4 addresses. If not specified, will use default auto-detection settings to acquire an IPv4 address for each node. | -| `nodeAddressAutodetectionV6` _[NodeAddressAutodetection](#nodeaddressautodetection)_ | (Optional) NodeAddressAutodetectionV6 specifies an approach to automatically detect node IPv6 addresses. If not specified, IPv6 addresses will not be auto-detected. | -| `hostPorts` _[HostPortsType](#hostportstype)_ | (Optional) HostPorts configures whether or not Calico will support Kubernetes HostPorts. Valid only when using the Calico CNI plugin.
    Default: Enabled | -| `multiInterfaceMode` _[MultiInterfaceMode](#multiinterfacemode)_ | (Optional) MultiInterfaceMode configures what will configure multiple interface per pod. Only valid for Calico Enterprise installations using the Calico CNI plugin.
    Default: None | -| `containerIPForwarding` _[ContainerIPForwardingType](#containeripforwardingtype)_ | (Optional) ContainerIPForwarding configures whether ip forwarding will be enabled for containers in the CNI configuration.
    Default: Disabled | -| `sysctl` _[Sysctl](#sysctl) array_ | (Optional) Sysctl configures sysctl parameters for tuning plugin | -| `linuxPolicySetupTimeoutSeconds` _integer_ | (Optional) LinuxPolicySetupTimeoutSeconds delays new pods from running containers until their policy has been programmed in the dataplane. The specified delay defines the maximum amount of time that the Calico CNI plugin will wait for policy to be programmed. Only applies to pods created on Linux nodes. * A value of 0 disables pod startup delays.
    Default: 0 | - - -### CalicoNodeDaemonSet - - - -CalicoNodeDaemonSet is the configuration for the calico-node DaemonSet. - -_Appears in:_ -- [InstallationSpec](#installationspec) - -| Field | Description | -| --- | --- | -| `metadata` _[Metadata](#metadata)_ | (Optional) Refer to Kubernetes API documentation for fields of `metadata`. | -| `spec` _[CalicoNodeDaemonSetSpec](#caliconodedaemonsetspec)_ | (Optional) Spec is the specification of the calico-node DaemonSet. | - - -### CalicoNodeDaemonSetContainer - - - -CalicoNodeDaemonSetContainer is a calico-node DaemonSet container. - -_Appears in:_ -- [CalicoNodeDaemonSetPodSpec](#caliconodedaemonsetpodspec) - -| Field | Description | -| --- | --- | -| `name` _string_ | Name is an enum which identifies the calico-node DaemonSet container by name.
    Supported values are: calico-node | -| `resources` _[ResourceRequirements](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#resourcerequirements-v1-core)_ | (Optional) Resources allows customization of limits and requests for compute resources such as cpu and memory. If specified, this overrides the named calico-node DaemonSet container's resources. If omitted, the calico-node DaemonSet will use its default value for this container's resources. If used in conjunction with the deprecated ComponentResources, then this value takes precedence. | - - -### CalicoNodeDaemonSetInitContainer - - - -CalicoNodeDaemonSetInitContainer is a calico-node DaemonSet init container. - -_Appears in:_ -- [CalicoNodeDaemonSetPodSpec](#caliconodedaemonsetpodspec) - -| Field | Description | -| --- | --- | -| `name` _string_ | Name is an enum which identifies the calico-node DaemonSet init container by name.
    Supported values are: install-cni, hostpath-init, flexvol-driver, mount-bpffs, node-certs-key-cert-provisioner, calico-node-prometheus-server-tls-key-cert-provisioner | -| `resources` _[ResourceRequirements](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#resourcerequirements-v1-core)_ | (Optional) Resources allows customization of limits and requests for compute resources such as cpu and memory. If specified, this overrides the named calico-node DaemonSet init container's resources. If omitted, the calico-node DaemonSet will use its default value for this container's resources. If used in conjunction with the deprecated ComponentResources, then this value takes precedence. | - - -### CalicoNodeDaemonSetPodSpec - - - -CalicoNodeDaemonSetPodSpec is the calico-node DaemonSet's PodSpec. - -_Appears in:_ -- [CalicoNodeDaemonSetPodTemplateSpec](#caliconodedaemonsetpodtemplatespec) - -| Field | Description | -| --- | --- | -| `initContainers` _[CalicoNodeDaemonSetInitContainer](#caliconodedaemonsetinitcontainer) array_ | (Optional) InitContainers is a list of calico-node init containers. If specified, this overrides the specified calico-node DaemonSet init containers. If omitted, the calico-node DaemonSet will use its default values for its init containers. | -| `containers` _[CalicoNodeDaemonSetContainer](#caliconodedaemonsetcontainer) array_ | (Optional) Containers is a list of calico-node containers. If specified, this overrides the specified calico-node DaemonSet containers. If omitted, the calico-node DaemonSet will use its default values for its containers. | -| `affinity` _[Affinity](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#affinity-v1-core)_ | (Optional) Affinity is a group of affinity scheduling rules for the calico-node pods. If specified, this overrides any affinity that may be set on the calico-node DaemonSet. If omitted, the calico-node DaemonSet will use its default value for affinity.
    WARNING: Please note that this field will override the default calico-node DaemonSet affinity. | -| `nodeSelector` _object (keys:string, values:string)_ | (Optional) NodeSelector is the calico-node pod's scheduling constraints. If specified, each of the key/value pairs are added to the calico-node DaemonSet nodeSelector provided the key does not already exist in the object's nodeSelector. If omitted, the calico-node DaemonSet will use its default value for nodeSelector.
    WARNING: Please note that this field will modify the default calico-node DaemonSet nodeSelector. | -| `tolerations` _[Toleration](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#toleration-v1-core) array_ | (Optional) Tolerations is the calico-node pod's tolerations. If specified, this overrides any tolerations that may be set on the calico-node DaemonSet. If omitted, the calico-node DaemonSet will use its default value for tolerations.
    WARNING: Please note that this field will override the default calico-node DaemonSet tolerations. | - - -### CalicoNodeDaemonSetPodTemplateSpec - - - -CalicoNodeDaemonSetPodTemplateSpec is the calico-node DaemonSet's PodTemplateSpec - -_Appears in:_ -- [CalicoNodeDaemonSetSpec](#caliconodedaemonsetspec) - -| Field | Description | -| --- | --- | -| `metadata` _[Metadata](#metadata)_ | (Optional) Refer to Kubernetes API documentation for fields of `metadata`. | -| `spec` _[CalicoNodeDaemonSetPodSpec](#caliconodedaemonsetpodspec)_ | (Optional) Spec is the calico-node DaemonSet's PodSpec. | - - -### CalicoNodeDaemonSetSpec - - - -CalicoNodeDaemonSetSpec defines configuration for the calico-node DaemonSet. - -_Appears in:_ -- [CalicoNodeDaemonSet](#caliconodedaemonset) - -| Field | Description | -| --- | --- | -| `minReadySeconds` _integer_ | (Optional) MinReadySeconds is the minimum number of seconds for which a newly created DaemonSet pod should be ready without any of its container crashing, for it to be considered available. If specified, this overrides any minReadySeconds value that may be set on the calico-node DaemonSet. If omitted, the calico-node DaemonSet will use its default value for minReadySeconds. | -| `template` _[CalicoNodeDaemonSetPodTemplateSpec](#caliconodedaemonsetpodtemplatespec)_ | (Optional) Template describes the calico-node DaemonSet pod that will be created. | - - -### CalicoNodeWindowsDaemonSet - - - -CalicoNodeWindowsDaemonSet is the configuration for the calico-node-windows DaemonSet. - -_Appears in:_ -- [InstallationSpec](#installationspec) - -| Field | Description | -| --- | --- | -| `metadata` _[Metadata](#metadata)_ | (Optional) Refer to Kubernetes API documentation for fields of `metadata`. | -| `spec` _[CalicoNodeWindowsDaemonSetSpec](#caliconodewindowsdaemonsetspec)_ | (Optional) Spec is the specification of the calico-node-windows DaemonSet. | - - -### CalicoNodeWindowsDaemonSetContainer - - - -CalicoNodeWindowsDaemonSetContainer is a calico-node-windows DaemonSet container. - -_Appears in:_ -- [CalicoNodeWindowsDaemonSetPodSpec](#caliconodewindowsdaemonsetpodspec) - -| Field | Description | -| --- | --- | -| `name` _string_ | Name is an enum which identifies the calico-node-windows DaemonSet container by name.
    Supported values are: calico-node-windows | -| `resources` _[ResourceRequirements](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#resourcerequirements-v1-core)_ | (Optional) Resources allows customization of limits and requests for compute resources such as cpu and memory. If specified, this overrides the named calico-node-windows DaemonSet container's resources. If omitted, the calico-node-windows DaemonSet will use its default value for this container's resources. If used in conjunction with the deprecated ComponentResources, then this value takes precedence. | - - -### CalicoNodeWindowsDaemonSetInitContainer - - - -CalicoNodeWindowsDaemonSetInitContainer is a calico-node-windows DaemonSet init container. - -_Appears in:_ -- [CalicoNodeWindowsDaemonSetPodSpec](#caliconodewindowsdaemonsetpodspec) - -| Field | Description | -| --- | --- | -| `name` _string_ | Name is an enum which identifies the calico-node-windows DaemonSet init container by name.
    Supported values are: install-cni;hostpath-init, flexvol-driver, mount-bpffs, node-certs-key-cert-provisioner, calico-node-windows-prometheus-server-tls-key-cert-provisioner | -| `resources` _[ResourceRequirements](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#resourcerequirements-v1-core)_ | (Optional) Resources allows customization of limits and requests for compute resources such as cpu and memory. If specified, this overrides the named calico-node-windows DaemonSet init container's resources. If omitted, the calico-node-windows DaemonSet will use its default value for this container's resources. If used in conjunction with the deprecated ComponentResources, then this value takes precedence. | - - -### CalicoNodeWindowsDaemonSetPodSpec - - - -CalicoNodeWindowsDaemonSetPodSpec is the calico-node-windows DaemonSet's PodSpec. - -_Appears in:_ -- [CalicoNodeWindowsDaemonSetPodTemplateSpec](#caliconodewindowsdaemonsetpodtemplatespec) - -| Field | Description | -| --- | --- | -| `initContainers` _[CalicoNodeWindowsDaemonSetInitContainer](#caliconodewindowsdaemonsetinitcontainer) array_ | (Optional) InitContainers is a list of calico-node-windows init containers. If specified, this overrides the specified calico-node-windows DaemonSet init containers. If omitted, the calico-node-windows DaemonSet will use its default values for its init containers. | -| `containers` _[CalicoNodeWindowsDaemonSetContainer](#caliconodewindowsdaemonsetcontainer) array_ | (Optional) Containers is a list of calico-node-windows containers. If specified, this overrides the specified calico-node-windows DaemonSet containers. If omitted, the calico-node-windows DaemonSet will use its default values for its containers. | -| `affinity` _[Affinity](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#affinity-v1-core)_ | (Optional) Affinity is a group of affinity scheduling rules for the calico-node-windows pods. If specified, this overrides any affinity that may be set on the calico-node-windows DaemonSet. If omitted, the calico-node-windows DaemonSet will use its default value for affinity.
    WARNING: Please note that this field will override the default calico-node-windows DaemonSet affinity. | -| `nodeSelector` _object (keys:string, values:string)_ | (Optional) NodeSelector is the calico-node-windows pod's scheduling constraints. If specified, each of the key/value pairs are added to the calico-node-windows DaemonSet nodeSelector provided the key does not already exist in the object's nodeSelector. If omitted, the calico-node-windows DaemonSet will use its default value for nodeSelector.
    WARNING: Please note that this field will modify the default calico-node-windows DaemonSet nodeSelector. | -| `tolerations` _[Toleration](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#toleration-v1-core) array_ | (Optional) Tolerations is the calico-node-windows pod's tolerations. If specified, this overrides any tolerations that may be set on the calico-node-windows DaemonSet. If omitted, the calico-node-windows DaemonSet will use its default value for tolerations.
    WARNING: Please note that this field will override the default calico-node-windows DaemonSet tolerations. | - - -### CalicoNodeWindowsDaemonSetPodTemplateSpec - - - -CalicoNodeWindowsDaemonSetPodTemplateSpec is the calico-node-windows DaemonSet's PodTemplateSpec - -_Appears in:_ -- [CalicoNodeWindowsDaemonSetSpec](#caliconodewindowsdaemonsetspec) - -| Field | Description | -| --- | --- | -| `metadata` _[Metadata](#metadata)_ | (Optional) Refer to Kubernetes API documentation for fields of `metadata`. | -| `spec` _[CalicoNodeWindowsDaemonSetPodSpec](#caliconodewindowsdaemonsetpodspec)_ | (Optional) Spec is the calico-node-windows DaemonSet's PodSpec. | - - -### CalicoNodeWindowsDaemonSetSpec - - - -CalicoNodeWindowsDaemonSetSpec defines configuration for the calico-node-windows DaemonSet. - -_Appears in:_ -- [CalicoNodeWindowsDaemonSet](#caliconodewindowsdaemonset) - -| Field | Description | -| --- | --- | -| `minReadySeconds` _integer_ | (Optional) MinReadySeconds is the minimum number of seconds for which a newly created DaemonSet pod should be ready without any of its container crashing, for it to be considered available. If specified, this overrides any minReadySeconds value that may be set on the calico-node-windows DaemonSet. If omitted, the calico-node-windows DaemonSet will use its default value for minReadySeconds. | -| `template` _[CalicoNodeWindowsDaemonSetPodTemplateSpec](#caliconodewindowsdaemonsetpodtemplatespec)_ | (Optional) Template describes the calico-node-windows DaemonSet pod that will be created. | - - -### CalicoWindowsUpgradeDaemonSet - - - -Deprecated. The CalicoWindowsUpgradeDaemonSet is deprecated and will be removed from the API in the future. -CalicoWindowsUpgradeDaemonSet is the configuration for the calico-windows-upgrade DaemonSet. - -_Appears in:_ -- [InstallationSpec](#installationspec) - -| Field | Description | -| --- | --- | -| `metadata` _[Metadata](#metadata)_ | (Optional) Refer to Kubernetes API documentation for fields of `metadata`. | -| `spec` _[CalicoWindowsUpgradeDaemonSetSpec](#calicowindowsupgradedaemonsetspec)_ | (Optional) Spec is the specification of the calico-windows-upgrade DaemonSet. | - - -### CalicoWindowsUpgradeDaemonSetContainer - - - -CalicoWindowsUpgradeDaemonSetContainer is a calico-windows-upgrade DaemonSet container. - -_Appears in:_ -- [CalicoWindowsUpgradeDaemonSetPodSpec](#calicowindowsupgradedaemonsetpodspec) - -| Field | Description | -| --- | --- | -| `name` _string_ | Name is an enum which identifies the calico-windows-upgrade DaemonSet container by name. | -| `resources` _[ResourceRequirements](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#resourcerequirements-v1-core)_ | (Optional) Resources allows customization of limits and requests for compute resources such as cpu and memory. If specified, this overrides the named calico-windows-upgrade DaemonSet container's resources. If omitted, the calico-windows-upgrade DaemonSet will use its default value for this container's resources. | - - -### CalicoWindowsUpgradeDaemonSetPodSpec - - - -CalicoWindowsUpgradeDaemonSetPodSpec is the calico-windows-upgrade DaemonSet's PodSpec. - -_Appears in:_ -- [CalicoWindowsUpgradeDaemonSetPodTemplateSpec](#calicowindowsupgradedaemonsetpodtemplatespec) - -| Field | Description | -| --- | --- | -| `containers` _[CalicoWindowsUpgradeDaemonSetContainer](#calicowindowsupgradedaemonsetcontainer) array_ | (Optional) Containers is a list of calico-windows-upgrade containers. If specified, this overrides the specified calico-windows-upgrade DaemonSet containers. If omitted, the calico-windows-upgrade DaemonSet will use its default values for its containers. | -| `affinity` _[Affinity](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#affinity-v1-core)_ | (Optional) Affinity is a group of affinity scheduling rules for the calico-windows-upgrade pods. If specified, this overrides any affinity that may be set on the calico-windows-upgrade DaemonSet. If omitted, the calico-windows-upgrade DaemonSet will use its default value for affinity.
    WARNING: Please note that this field will override the default calico-windows-upgrade DaemonSet affinity. | -| `nodeSelector` _object (keys:string, values:string)_ | (Optional) NodeSelector is the calico-windows-upgrade pod's scheduling constraints. If specified, each of the key/value pairs are added to the calico-windows-upgrade DaemonSet nodeSelector provided the key does not already exist in the object's nodeSelector. If omitted, the calico-windows-upgrade DaemonSet will use its default value for nodeSelector.
    WARNING: Please note that this field will modify the default calico-windows-upgrade DaemonSet nodeSelector. | -| `tolerations` _[Toleration](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#toleration-v1-core) array_ | (Optional) Tolerations is the calico-windows-upgrade pod's tolerations. If specified, this overrides any tolerations that may be set on the calico-windows-upgrade DaemonSet. If omitted, the calico-windows-upgrade DaemonSet will use its default value for tolerations.
    WARNING: Please note that this field will override the default calico-windows-upgrade DaemonSet tolerations. | - - -### CalicoWindowsUpgradeDaemonSetPodTemplateSpec - - - -CalicoWindowsUpgradeDaemonSetPodTemplateSpec is the calico-windows-upgrade DaemonSet's PodTemplateSpec - -_Appears in:_ -- [CalicoWindowsUpgradeDaemonSetSpec](#calicowindowsupgradedaemonsetspec) - -| Field | Description | -| --- | --- | -| `metadata` _[Metadata](#metadata)_ | (Optional) Refer to Kubernetes API documentation for fields of `metadata`. | -| `spec` _[CalicoWindowsUpgradeDaemonSetPodSpec](#calicowindowsupgradedaemonsetpodspec)_ | (Optional) Spec is the calico-windows-upgrade DaemonSet's PodSpec. | - - -### CalicoWindowsUpgradeDaemonSetSpec - - - -CalicoWindowsUpgradeDaemonSetSpec defines configuration for the calico-windows-upgrade DaemonSet. - -_Appears in:_ -- [CalicoWindowsUpgradeDaemonSet](#calicowindowsupgradedaemonset) - -| Field | Description | -| --- | --- | -| `minReadySeconds` _integer_ | (Optional) MinReadySeconds is the minimum number of seconds for which a newly created Deployment pod should be ready without any of its container crashing, for it to be considered available. If specified, this overrides any minReadySeconds value that may be set on the calico-windows-upgrade DaemonSet. If omitted, the calico-windows-upgrade DaemonSet will use its default value for minReadySeconds. | -| `template` _[CalicoWindowsUpgradeDaemonSetPodTemplateSpec](#calicowindowsupgradedaemonsetpodtemplatespec)_ | (Optional) Template describes the calico-windows-upgrade DaemonSet pod that will be created. | - - -### CertificateManagement - - - -CertificateManagement configures pods to submit a CertificateSigningRequest to the certificates.k8s.io/v1beta1 API in order -to obtain TLS certificates. This feature requires that you bring your own CSR signing and approval process, otherwise -pods will be stuck during initialization. - -_Appears in:_ -- [InstallationSpec](#installationspec) - -| Field | Description | -| --- | --- | -| `caCert` _integer array_ | Certificate of the authority that signs the CertificateSigningRequests in PEM format. | -| `signerName` _string_ | When a CSR is issued to the certificates.k8s.io API, the signerName is added to the request in order to accommodate for clusters with multiple signers. Must be formatted as: `/`. | -| `keyAlgorithm` _string_ | (Optional) Specify the algorithm used by pods to generate a key pair that is associated with the X.509 certificate request.
    Default: RSAWithSize2048 | -| `signatureAlgorithm` _string_ | (Optional) Specify the algorithm used for the signature of the X.509 certificate request.
    Default: SHA256WithRSA | - - - - -### ComponentName - -_Underlying type:_ _string_ - -ComponentName represents a single component. - -One of: Node, Typha, KubeControllers - -_Appears in:_ -- [ComponentResource](#componentresource) - -| Value | Description | -| --- | --- | -| `Node` | | -| `NodeWindows` | | -| `FelixWindows` | | -| `ConfdWindows` | | -| `Typha` | | -| `KubeControllers` | | - - -### ComponentResource - - - -Deprecated. Please use component resource config fields in Installation.Spec instead. -The ComponentResource struct associates a ResourceRequirements with a component by name - -_Appears in:_ -- [InstallationSpec](#installationspec) - -| Field | Description | -| --- | --- | -| `componentName` _[ComponentName](#componentname)_ | ComponentName is an enum which identifies the component | -| `resourceRequirements` _[ResourceRequirements](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#resourcerequirements-v1-core)_ | ResourceRequirements allows customization of limits and requests for compute resources such as cpu and memory. | - - -### ConditionStatus - -_Underlying type:_ _string_ - -ConditionStatus represents the status of a particular condition. A condition may be one of: True, False, Unknown. - -_Appears in:_ -- [TigeraStatusCondition](#tigerastatuscondition) - -| Value | Description | -| --- | --- | -| `True` | | -| `False` | | -| `Unknown` | | - - -### ContainerIPForwardingType - -_Underlying type:_ _string_ - -ContainerIPForwardingType specifies whether the CNI config for container ip forwarding is enabled. - -_Appears in:_ -- [CalicoNetworkSpec](#caliconetworkspec) - -| Value | Description | -| --- | --- | -| `Enabled` | | -| `Disabled` | | - - - - - - - - -### EncapsulationType - -_Underlying type:_ _string_ - -EncapsulationType is the type of encapsulation to use on an IP pool. - -One of: IPIP, VXLAN, IPIPCrossSubnet, VXLANCrossSubnet, None - -_Appears in:_ -- [IPPool](#ippool) - -| Value | Description | -| --- | --- | -| `IPIPCrossSubnet` | | -| `IPIP` | | -| `VXLAN` | | -| `VXLANCrossSubnet` | | -| `None` | | - - - - - - - - -### FIPSMode - -_Underlying type:_ _string_ - - - -_Appears in:_ -- [InstallationSpec](#installationspec) - -| Value | Description | -| --- | --- | -| `Enabled` | | -| `Disabled` | | - - - - -### HostPortsType - -_Underlying type:_ _string_ - -HostPortsType specifies host port support. - -One of: Enabled, Disabled - -_Appears in:_ -- [CalicoNetworkSpec](#caliconetworkspec) - -| Value | Description | -| --- | --- | -| `Enabled` | | -| `Disabled` | | - - - - -### IPAMPluginType - -_Underlying type:_ _string_ - - - -_Appears in:_ -- [IPAMSpec](#ipamspec) - -| Value | Description | -| --- | --- | -| `Calico` | | -| `HostLocal` | | -| `AmazonVPC` | | -| `AzureVNET` | | - - -### IPAMSpec - - - -IPAMSpec contains configuration for pod IP address management. - -_Appears in:_ -- [CNISpec](#cnispec) - -| Field | Description | -| --- | --- | -| `type` _[IPAMPluginType](#ipamplugintype)_ | Specifies the IPAM plugin that will be used in the Calico or Calico Enterprise installation. * For CNI Plugin Calico, this field defaults to Calico. * For CNI Plugin GKE, this field defaults to HostLocal. * For CNI Plugin AzureVNET, this field defaults to AzureVNET. * For CNI Plugin AmazonVPC, this field defaults to AmazonVPC. The IPAM plugin is installed and configured only if the CNI plugin is set to Calico, for all other values of the CNI plugin the plugin binaries and CNI config is a dependency that is expected to be installed separately.
    Default: Calico | - - -### IPPool - - - - - -_Appears in:_ -- [CalicoNetworkSpec](#caliconetworkspec) - -| Field | Description | -| --- | --- | -| `name` _string_ | Name is the name of the IP pool. If omitted, this will be generated. | -| `cidr` _string_ | CIDR contains the address range for the IP Pool in classless inter-domain routing format. | -| `encapsulation` _[EncapsulationType](#encapsulationtype)_ | (Optional) Encapsulation specifies the encapsulation type that will be used with the IP Pool.
    Default: IPIP | -| `natOutgoing` _[NATOutgoingType](#natoutgoingtype)_ | (Optional) NATOutgoing specifies if NAT will be enabled or disabled for outgoing traffic.
    Default: Enabled | -| `nodeSelector` _string_ | (Optional) NodeSelector specifies the node selector that will be set for the IP Pool.
    Default: 'all()' | -| `blockSize` _integer_ | (Optional) BlockSize specifies the CIDR prefex length to use when allocating per-node IP blocks from the main IP pool CIDR.
    Default: 26 (IPv4), 122 (IPv6) | -| `disableBGPExport` _boolean_ | (Optional) DisableBGPExport specifies whether routes from this IP pool's CIDR are exported over BGP.
    Default: false | -| `disableNewAllocations` _boolean_ | DisableNewAllocations specifies whether or not new IP allocations are allowed from this pool. This is useful when you want to prevent new pods from receiving IP addresses from this pool, without impacting any existing pods that have already been assigned addresses from this pool. | -| `allowedUses` _[IPPoolAllowedUse](#ippoolalloweduse) array_ | AllowedUse controls what the IP pool will be used for. If not specified or empty, defaults to ["Tunnel", "Workload"] for back-compatibility | - - -### IPPoolAllowedUse - -_Underlying type:_ _string_ - - - -_Appears in:_ -- [IPPool](#ippool) - -| Value | Description | -| --- | --- | -| `Workload` | | -| `Tunnel` | | - - -### Image - - - - - -_Appears in:_ -- [ImageSetSpec](#imagesetspec) - -| Field | Description | -| --- | --- | -| `image` _string_ | Image is an image that the operator deploys and instead of using the built in tag the operator will use the Digest for the image identifier. The value should be the image name without registry or tag or digest. For the image `docker.io/calico/node:v3.17.1` it should be represented as `calico/node` | -| `digest` _string_ | Digest is the image identifier that will be used for the Image. The field should not include a leading `@` and must be prefixed with `sha256:`. | - - -### ImageSet - - - -ImageSet is used to specify image digests for the images that the operator deploys. -The name of the ImageSet is expected to be in the format `-`. -The `variant` used is `enterprise` if the InstallationSpec Variant is -`TigeraSecureEnterprise` otherwise it is `calico`. -The `release` must match the version of the variant that the operator is built to deploy, -this version can be obtained by passing the `--version` flag to the operator binary. - -| Field | Description | -| --- | --- | -| `apiVersion` _string_ | `operator.tigera.io/v1` | -| `kind` _string_ | `ImageSet` | -| `metadata` _[ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#objectmeta-v1-meta)_ | Refer to Kubernetes API documentation for fields of `metadata`. | -| `spec` _[ImageSetSpec](#imagesetspec)_ | | - - -### ImageSetSpec - - - -ImageSetSpec defines the desired state of ImageSet. - -_Appears in:_ -- [ImageSet](#imageset) - -| Field | Description | -| --- | --- | -| `images` _[Image](#image) array_ | Images is the list of images to use digests. All images that the operator will deploy must be specified. | - - -### Installation - - - -Installation configures an installation of Calico or Calico Enterprise. At most one instance -of this resource is supported. It must be named "default". The Installation API installs core networking -and network policy components, and provides general install-time configuration. - -| Field | Description | -| --- | --- | -| `apiVersion` _string_ | `operator.tigera.io/v1` | -| `kind` _string_ | `Installation` | -| `metadata` _[ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#objectmeta-v1-meta)_ | Refer to Kubernetes API documentation for fields of `metadata`. | -| `spec` _[InstallationSpec](#installationspec)_ | Specification of the desired state for the Calico or Calico Enterprise installation. | -| `status` _[InstallationStatus](#installationstatus)_ | Most recently observed state for the Calico or Calico Enterprise installation. | - - -### InstallationSpec - - - -InstallationSpec defines configuration for a Calico or Calico Enterprise installation. - -_Appears in:_ -- [Installation](#installation) -- [InstallationStatus](#installationstatus) - -| Field | Description | -| --- | --- | -| `variant` _[ProductVariant](#productvariant)_ | (Optional) Variant is the product to install - one of Calico or TigeraSecureEnterprise
    Default: Calico | -| `registry` _string_ | (Optional) Registry is the default Docker registry used for component Docker images. If specified then the given value must end with a slash character (`/`) and all images will be pulled from this registry. If not specified then the default registries will be used. A special case value, UseDefault, is supported to explicitly specify the default registries will be used. Image format: `/:` This option allows configuring the `` portion of the above format. | -| `imagePath` _string_ | (Optional) ImagePath allows for the path part of an image to be specified. If specified then the specified value will be used as the image path for each image. If not specified or empty, the default for each image will be used. A special case value, UseDefault, is supported to explicitly specify the default image path will be used for each image. Image format: `/:` This option allows configuring the `` portion of the above format. | -| `imagePrefix` _string_ | (Optional) ImagePrefix allows for the prefix part of an image to be specified. If specified then the given value will be used as a prefix on each image. If not specified or empty, no prefix will be used. A special case value, UseDefault, is supported to explicitly specify the default image prefix will be used for each image. Image format: `/:` This option allows configuring the `` portion of the above format. | -| `imagePullSecrets` _[LocalObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#localobjectreference-v1-core) array_ | (Optional) ImagePullSecrets is an array of references to container registry pull secrets to use. These are applied to all images to be pulled. | -| `kubernetesProvider` _[Provider](#provider)_ | (Optional) KubernetesProvider specifies a particular provider of the Kubernetes platform and enables provider-specific configuration. If the specified value is empty, the Operator will attempt to automatically determine the current provider. If the specified value is not empty, the Operator will still attempt auto-detection, but will additionally compare the auto-detected value to the specified value to confirm they match. | -| `cni` _[CNISpec](#cnispec)_ | (Optional) CNI specifies the CNI that will be used by this installation. | -| `calicoNetwork` _[CalicoNetworkSpec](#caliconetworkspec)_ | (Optional) CalicoNetwork specifies networking configuration options for Calico. | -| `typhaAffinity` _[TyphaAffinity](#typhaaffinity)_ | (Optional) Deprecated. Please use Installation.Spec.TyphaDeployment instead. TyphaAffinity allows configuration of node affinity characteristics for Typha pods. | -| `controlPlaneNodeSelector` _object (keys:string, values:string)_ | (Optional) ControlPlaneNodeSelector is used to select control plane nodes on which to run Calico components. This is globally applied to all resources created by the operator excluding daemonsets. | -| `controlPlaneTolerations` _[Toleration](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#toleration-v1-core) array_ | (Optional) ControlPlaneTolerations specify tolerations which are then globally applied to all resources created by the operator. | -| `controlPlaneReplicas` _integer_ | (Optional) ControlPlaneReplicas defines how many replicas of the control plane core components will be deployed. This field applies to all control plane components that support High Availability. Defaults to 2. | -| `nodeMetricsPort` _integer_ | (Optional) NodeMetricsPort specifies which port calico/node serves prometheus metrics on. By default, metrics are not enabled. If specified, this overrides any FelixConfiguration resources which may exist. If omitted, then prometheus metrics may still be configured through FelixConfiguration. | -| `typhaMetricsPort` _integer_ | (Optional) TyphaMetricsPort specifies which port calico/typha serves prometheus metrics on. By default, metrics are not enabled. | -| `flexVolumePath` _string_ | (Optional) FlexVolumePath optionally specifies a custom path for FlexVolume. If not specified, FlexVolume will be enabled by default. If set to 'None', FlexVolume will be disabled. The default is based on the kubernetesProvider. | -| `kubeletVolumePluginPath` _string_ | (Optional) KubeletVolumePluginPath optionally specifies enablement of Calico CSI plugin. If not specified, CSI will be enabled by default. If set to 'None', CSI will be disabled.
    Default: /var/lib/kubelet | -| `nodeUpdateStrategy` _[DaemonSetUpdateStrategy](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#daemonsetupdatestrategy-v1-apps)_ | (Optional) NodeUpdateStrategy can be used to customize the desired update strategy, such as the MaxUnavailable field. | -| `componentResources` _[ComponentResource](#componentresource) array_ | (Optional) Deprecated. Please use CalicoNodeDaemonSet, TyphaDeployment, and KubeControllersDeployment. ComponentResources can be used to customize the resource requirements for each component. Node, Typha, and KubeControllers are supported for installations. | -| `certificateManagement` _[CertificateManagement](#certificatemanagement)_ | (Optional) CertificateManagement configures pods to submit a CertificateSigningRequest to the certificates.k8s.io/v1beta1 API in order to obtain TLS certificates. This feature requires that you bring your own CSR signing and approval process, otherwise pods will be stuck during initialization. | -| `nonPrivileged` _[NonPrivilegedType](#nonprivilegedtype)_ | (Optional) NonPrivileged configures Calico to be run in non-privileged containers as non-root users where possible. | -| `calicoNodeDaemonSet` _[CalicoNodeDaemonSet](#caliconodedaemonset)_ | CalicoNodeDaemonSet configures the calico-node DaemonSet. If used in conjunction with the deprecated ComponentResources, then these overrides take precedence. | -| `csiNodeDriverDaemonSet` _[CSINodeDriverDaemonSet](#csinodedriverdaemonset)_ | CSINodeDriverDaemonSet configures the csi-node-driver DaemonSet. | -| `calicoKubeControllersDeployment` _[CalicoKubeControllersDeployment](#calicokubecontrollersdeployment)_ | CalicoKubeControllersDeployment configures the calico-kube-controllers Deployment. If used in conjunction with the deprecated ComponentResources, then these overrides take precedence. | -| `typhaDeployment` _[TyphaDeployment](#typhadeployment)_ | TyphaDeployment configures the typha Deployment. If used in conjunction with the deprecated ComponentResources or TyphaAffinity, then these overrides take precedence. | -| `calicoWindowsUpgradeDaemonSet` _[CalicoWindowsUpgradeDaemonSet](#calicowindowsupgradedaemonset)_ | Deprecated. The CalicoWindowsUpgradeDaemonSet is deprecated and will be removed from the API in the future. CalicoWindowsUpgradeDaemonSet configures the calico-windows-upgrade DaemonSet. | -| `calicoNodeWindowsDaemonSet` _[CalicoNodeWindowsDaemonSet](#caliconodewindowsdaemonset)_ | CalicoNodeWindowsDaemonSet configures the calico-node-windows DaemonSet. | -| `fipsMode` _[FIPSMode](#fipsmode)_ | (Optional) FIPSMode uses images and features only that are using FIPS 140-2 validated cryptographic modules and standards.
    Default: Disabled | -| `logging` _[Logging](#logging)_ | (Optional) Logging Configuration for Components | -| `windowsNodes` _[WindowsNodeSpec](#windowsnodespec)_ | (Optional) Windows Configuration | -| `serviceCIDRs` _string array_ | (Optional) Kubernetes Service CIDRs. Specifying this is required when using Calico for Windows. | -| `azure` _[Azure](#azure)_ | (Optional) Azure is used to configure azure provider specific options. | - - -### InstallationStatus - - - -InstallationStatus defines the observed state of the Calico or Calico Enterprise installation. - -_Appears in:_ -- [Installation](#installation) - -| Field | Description | -| --- | --- | -| `variant` _[ProductVariant](#productvariant)_ | Variant is the most recently observed installed variant - one of Calico or TigeraSecureEnterprise | -| `mtu` _integer_ | MTU is the most recently observed value for pod network MTU. This may be an explicitly configured value, or based on Calico's native auto-detetion. | -| `imageSet` _string_ | (Optional) ImageSet is the name of the ImageSet being used, if there is an ImageSet that is being used. If an ImageSet is not being used then this will not be set. | -| `computed` _[InstallationSpec](#installationspec)_ | (Optional) Computed is the final installation including overlaid resources. | -| `calicoVersion` _string_ | CalicoVersion shows the current running version of calico. CalicoVersion along with Variant is needed to know the exact version deployed. | -| `conditions` _[Condition](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#condition-v1-meta) array_ | (Optional) Conditions represents the latest observed set of conditions for the component. A component may be one or more of Ready, Progressing, Degraded or other customer types. | - - -### KubernetesAutodetectionMethod - -_Underlying type:_ _string_ - -KubernetesAutodetectionMethod is a method of detecting an IP address based on the Kubernetes API. - -One of: NodeInternalIP - -_Appears in:_ -- [NodeAddressAutodetection](#nodeaddressautodetection) - -| Value | Description | -| --- | --- | -| `NodeInternalIP` | NodeInternalIP detects a node IP using the first status.Addresses entry of the relevant IP family with type NodeInternalIP on the Kubernetes nodes API. | - - -### LinuxDataplaneOption - -_Underlying type:_ _string_ - -LinuxDataplaneOption controls which dataplane is to be used on Linux nodes. - -One of: Iptables, BPF, VPP, Nftables - -_Validation:_ -- Enum: [Iptables BPF VPP Nftables] - - -_Appears in:_ -- [CalicoNetworkSpec](#caliconetworkspec) - -| Value | Description | -| --- | --- | -| `Iptables` | | -| `BPF` | | -| `VPP` | | -| `Nftables` | | - - -### LogLevel - -_Underlying type:_ _string_ - - - -_Appears in:_ -- [CNILogging](#cnilogging) - -| Value | Description | -| --- | --- | -| `Trace` | | -| `Info` | | -| `Debug` | | -| `Warn` | | -| `Fatal` | | -| `Error` | | - - -### Logging - - - - - -_Appears in:_ -- [InstallationSpec](#installationspec) - -| Field | Description | -| --- | --- | -| `cni` _[CNILogging](#cnilogging)_ | (Optional) Customized logging specification for calico-cni plugin | - - -### Metadata - - - -Metadata contains the standard Kubernetes labels and annotations fields. - -_Appears in:_ -- [APIServerDeployment](#apiserverdeployment) -- [APIServerDeploymentPodTemplateSpec](#apiserverdeploymentpodtemplatespec) -- [CSINodeDriverDaemonSet](#csinodedriverdaemonset) -- [CSINodeDriverDaemonSetPodTemplateSpec](#csinodedriverdaemonsetpodtemplatespec) -- [CalicoKubeControllersDeployment](#calicokubecontrollersdeployment) -- [CalicoKubeControllersDeploymentPodTemplateSpec](#calicokubecontrollersdeploymentpodtemplatespec) -- [CalicoNodeDaemonSet](#caliconodedaemonset) -- [CalicoNodeDaemonSetPodTemplateSpec](#caliconodedaemonsetpodtemplatespec) -- [CalicoNodeWindowsDaemonSet](#caliconodewindowsdaemonset) -- [CalicoNodeWindowsDaemonSetPodTemplateSpec](#caliconodewindowsdaemonsetpodtemplatespec) -- [CalicoWindowsUpgradeDaemonSet](#calicowindowsupgradedaemonset) -- [CalicoWindowsUpgradeDaemonSetPodTemplateSpec](#calicowindowsupgradedaemonsetpodtemplatespec) -- [TyphaDeployment](#typhadeployment) -- [TyphaDeploymentPodTemplateSpec](#typhadeploymentpodtemplatespec) - -| Field | Description | -| --- | --- | -| `labels` _object (keys:string, values:string)_ | (Optional) Labels is a map of string keys and values that may match replicaset and service selectors. Each of these key/value pairs are added to the object's labels provided the key does not already exist in the object's labels. | -| `annotations` _object (keys:string, values:string)_ | (Optional) Annotations is a map of arbitrary non-identifying metadata. Each of these key/value pairs are added to the object's annotations provided the key does not already exist in the object's annotations. | - - - - - - -### MultiInterfaceMode - -_Underlying type:_ _string_ - -MultiInterfaceMode describes the method of providing multiple pod interfaces. - -One of: None, Multus - -_Appears in:_ -- [CalicoNetworkSpec](#caliconetworkspec) - -| Value | Description | -| --- | --- | -| `None` | | -| `Multus` | | - - -### NATOutgoingType - -_Underlying type:_ _string_ - -NATOutgoingType describe the type of outgoing NAT to use. - -One of: Enabled, Disabled - -_Appears in:_ -- [IPPool](#ippool) - -| Value | Description | -| --- | --- | -| `Enabled` | | -| `Disabled` | | - - - - -### NodeAddressAutodetection - - - -NodeAddressAutodetection provides configuration options for auto-detecting node addresses. At most one option -can be used. If no detection option is specified, then IP auto detection will be disabled for this address family and IPs -must be specified directly on the Node resource. - -_Appears in:_ -- [CalicoNetworkSpec](#caliconetworkspec) - -| Field | Description | -| --- | --- | -| `firstFound` _boolean_ | (Optional) FirstFound uses default interface matching parameters to select an interface, performing best-effort filtering based on well-known interface names. | -| `kubernetes` _[KubernetesAutodetectionMethod](#kubernetesautodetectionmethod)_ | (Optional) Kubernetes configures Calico to detect node addresses based on the Kubernetes API. | -| `interface` _string_ | (Optional) Interface enables IP auto-detection based on interfaces that match the given regex. | -| `skipInterface` _string_ | (Optional) SkipInterface enables IP auto-detection based on interfaces that do not match the given regex. | -| `canReach` _string_ | (Optional) CanReach enables IP auto-detection based on which source address on the node is used to reach the specified IP or domain. | -| `cidrs` _string array_ | CIDRS enables IP auto-detection based on which addresses on the nodes are within one of the provided CIDRs. | - - -### NodeAffinity - - - -NodeAffinity is similar to *v1.NodeAffinity, but allows us to limit available schedulers. - -_Appears in:_ -- [TyphaAffinity](#typhaaffinity) - -| Field | Description | -| --- | --- | -| `preferredDuringSchedulingIgnoredDuringExecution` _[PreferredSchedulingTerm](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#preferredschedulingterm-v1-core) array_ | (Optional) The scheduler will prefer to schedule pods to nodes that satisfy the affinity expressions specified by this field, but it may choose a node that violates one or more of the expressions. | -| `requiredDuringSchedulingIgnoredDuringExecution` _[NodeSelector](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#nodeselector-v1-core)_ | (Optional)
    WARNING: Please note that if the affinity requirements specified by this field are not met at scheduling time, the pod will NOT be scheduled onto the node. There is no fallback to another affinity rules with this setting. This may cause networking disruption or even catastrophic failure! PreferredDuringSchedulingIgnoredDuringExecution should be used for affinity unless there is a specific well understood reason to use RequiredDuringSchedulingIgnoredDuringExecution and you can guarantee that the RequiredDuringSchedulingIgnoredDuringExecution will always have sufficient nodes to satisfy the requirement. NOTE: RequiredDuringSchedulingIgnoredDuringExecution is set by default for AKS nodes, to avoid scheduling Typhas on virtual-nodes. If the affinity requirements specified by this field cease to be met at some point during pod execution (e.g. due to an update), the system may or may not try to eventually evict the pod from its node. | - - -### NonPrivilegedType - -_Underlying type:_ _string_ - -NonPrivilegedType specifies whether Calico runs as permissioned or not - -One of: Enabled, Disabled - -_Appears in:_ -- [InstallationSpec](#installationspec) - -| Value | Description | -| --- | --- | -| `Enabled` | | -| `Disabled` | | - - - - - - -### PolicyMode - -_Underlying type:_ _string_ - - - -_Appears in:_ -- [Azure](#azure) - -| Value | Description | -| --- | --- | -| `Default` | | -| `Manual` | | - - -### ProductVariant - -_Underlying type:_ _string_ - -ProductVariant represents the variant of the product. - -One of: Calico, TigeraSecureEnterprise - -_Appears in:_ -- [InstallationSpec](#installationspec) -- [InstallationStatus](#installationstatus) - - - - - -### Provider - -_Underlying type:_ _string_ - -Provider represents a particular provider or flavor of Kubernetes. Valid options -are: EKS, GKE, AKS, RKE2, OpenShift, DockerEnterprise, TKG. - -_Appears in:_ -- [InstallationSpec](#installationspec) - - - - - - - - - -### StatusConditionType - -_Underlying type:_ _string_ - -StatusConditionType is a type of condition that may apply to a particular component. - -_Appears in:_ -- [TigeraStatusCondition](#tigerastatuscondition) - -| Value | Description | -| --- | --- | -| `Available` | Available indicates that the component is healthy. | -| `Progressing` | Progressing means that the component is in the process of being installed or upgraded. | -| `Degraded` | Degraded means the component is not operating as desired and user action is required. | -| `Ready` | Ready indicates that the component is healthy and ready.it is identical to Available and used in Status conditions for CRs. | - - -### Sysctl - - - - - -_Appears in:_ -- [CalicoNetworkSpec](#caliconetworkspec) - -| Field | Description | -| --- | --- | -| `key` _string_ | | -| `value` _string_ | | - - - - - - -### TigeraStatus - - - -TigeraStatus represents the most recently observed status for Calico or a Calico Enterprise functional area. - -| Field | Description | -| --- | --- | -| `apiVersion` _string_ | `operator.tigera.io/v1` | -| `kind` _string_ | `TigeraStatus` | -| `metadata` _[ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#objectmeta-v1-meta)_ | Refer to Kubernetes API documentation for fields of `metadata`. | -| `spec` _[TigeraStatusSpec](#tigerastatusspec)_ | | -| `status` _[TigeraStatusStatus](#tigerastatusstatus)_ | | - - -### TigeraStatusCondition - - - -TigeraStatusCondition represents a condition attached to a particular component. - -_Appears in:_ -- [TigeraStatusStatus](#tigerastatusstatus) - -| Field | Description | -| --- | --- | -| `type` _[StatusConditionType](#statusconditiontype)_ | The type of condition. May be Available, Progressing, or Degraded. | -| `status` _[ConditionStatus](#conditionstatus)_ | The status of the condition. May be True, False, or Unknown. | -| `lastTransitionTime` _[Time](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#time-v1-meta)_ | The timestamp representing the start time for the current status. | -| `reason` _string_ | A brief reason explaining the condition. | -| `message` _string_ | Optionally, a detailed message providing additional context. | -| `observedGeneration` _integer_ | (Optional) observedGeneration represents the generation that the condition was set based upon. For instance, if generation is currently 12, but the .status.conditions[x].observedGeneration is 9, the condition is out of date with respect to the current state of the instance. | - - - - -### TigeraStatusSpec - - - -TigeraStatusSpec defines the desired state of TigeraStatus - -_Appears in:_ -- [TigeraStatus](#tigerastatus) - - - -### TigeraStatusStatus - - - -TigeraStatusStatus defines the observed state of TigeraStatus - -_Appears in:_ -- [TigeraStatus](#tigerastatus) - -| Field | Description | -| --- | --- | -| `conditions` _[TigeraStatusCondition](#tigerastatuscondition) array_ | Conditions represents the latest observed set of conditions for this component. A component may be one or more of Available, Progressing, or Degraded. | - - -### TyphaAffinity - - - -Deprecated. Please use TyphaDeployment instead. -TyphaAffinity allows configuration of node affinity characteristics for Typha pods. - -_Appears in:_ -- [InstallationSpec](#installationspec) - -| Field | Description | -| --- | --- | -| `nodeAffinity` _[NodeAffinity](#nodeaffinity)_ | (Optional) NodeAffinity describes node affinity scheduling rules for typha. | - - -### TyphaDeployment - - - -TyphaDeployment is the configuration for the typha Deployment. - -_Appears in:_ -- [InstallationSpec](#installationspec) - -| Field | Description | -| --- | --- | -| `metadata` _[Metadata](#metadata)_ | (Optional) Refer to Kubernetes API documentation for fields of `metadata`. | -| `spec` _[TyphaDeploymentSpec](#typhadeploymentspec)_ | (Optional) Spec is the specification of the typha Deployment. | - - -### TyphaDeploymentContainer - - - -TyphaDeploymentContainer is a typha Deployment container. - -_Appears in:_ -- [TyphaDeploymentPodSpec](#typhadeploymentpodspec) - -| Field | Description | -| --- | --- | -| `name` _string_ | Name is an enum which identifies the typha Deployment container by name.
    Supported values are: calico-typha | -| `resources` _[ResourceRequirements](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#resourcerequirements-v1-core)_ | (Optional) Resources allows customization of limits and requests for compute resources such as cpu and memory. If specified, this overrides the named typha Deployment container's resources. If omitted, the typha Deployment will use its default value for this container's resources. If used in conjunction with the deprecated ComponentResources, then this value takes precedence. | - - -### TyphaDeploymentInitContainer - - - -TyphaDeploymentInitContainer is a typha Deployment init container. - -_Appears in:_ -- [TyphaDeploymentPodSpec](#typhadeploymentpodspec) - -| Field | Description | -| --- | --- | -| `name` _string_ | Name is an enum which identifies the typha Deployment init container by name.
    Supported values are: typha-certs-key-cert-provisioner | -| `resources` _[ResourceRequirements](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#resourcerequirements-v1-core)_ | (Optional) Resources allows customization of limits and requests for compute resources such as cpu and memory. If specified, this overrides the named typha Deployment init container's resources. If omitted, the typha Deployment will use its default value for this init container's resources. If used in conjunction with the deprecated ComponentResources, then this value takes precedence. | - - -### TyphaDeploymentPodSpec - - - -TyphaDeploymentPodSpec is the typha Deployment's PodSpec. - -_Appears in:_ -- [TyphaDeploymentPodTemplateSpec](#typhadeploymentpodtemplatespec) - -| Field | Description | -| --- | --- | -| `initContainers` _[TyphaDeploymentInitContainer](#typhadeploymentinitcontainer) array_ | (Optional) InitContainers is a list of typha init containers. If specified, this overrides the specified typha Deployment init containers. If omitted, the typha Deployment will use its default values for its init containers. | -| `containers` _[TyphaDeploymentContainer](#typhadeploymentcontainer) array_ | (Optional) Containers is a list of typha containers. If specified, this overrides the specified typha Deployment containers. If omitted, the typha Deployment will use its default values for its containers. | -| `affinity` _[Affinity](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#affinity-v1-core)_ | (Optional) Affinity is a group of affinity scheduling rules for the typha pods. If specified, this overrides any affinity that may be set on the typha Deployment. If omitted, the typha Deployment will use its default value for affinity. If used in conjunction with the deprecated TyphaAffinity, then this value takes precedence.
    WARNING: Please note that this field will override the default calico-typha Deployment affinity. | -| `nodeSelector` _object (keys:string, values:string)_ | NodeSelector is the calico-typha pod's scheduling constraints. If specified, each of the key/value pairs are added to the calico-typha Deployment nodeSelector provided the key does not already exist in the object's nodeSelector. If omitted, the calico-typha Deployment will use its default value for nodeSelector.
    WARNING: Please note that this field will modify the default calico-typha Deployment nodeSelector. | -| `terminationGracePeriodSeconds` _integer_ | (Optional) Optional duration in seconds the pod needs to terminate gracefully. May be decreased in delete request. Value must be non-negative integer. The value zero indicates stop immediately via the kill signal (no opportunity to shut down). If this value is nil, the default grace period will be used instead. The grace period is the duration in seconds after the processes running in the pod are sent a termination signal and the time when the processes are forcibly halted with a kill signal. Set this value longer than the expected cleanup time for your process. Defaults to 30 seconds. | -| `topologySpreadConstraints` _[TopologySpreadConstraint](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#topologyspreadconstraint-v1-core) array_ | (Optional) TopologySpreadConstraints describes how a group of pods ought to spread across topology domains. Scheduler will schedule pods in a way which abides by the constraints. All topologySpreadConstraints are ANDed. | -| `tolerations` _[Toleration](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#toleration-v1-core) array_ | (Optional) Tolerations is the typha pod's tolerations. If specified, this overrides any tolerations that may be set on the typha Deployment. If omitted, the typha Deployment will use its default value for tolerations.
    WARNING: Please note that this field will override the default calico-typha Deployment tolerations. | - - -### TyphaDeploymentPodTemplateSpec - - - -TyphaDeploymentPodTemplateSpec is the typha Deployment's PodTemplateSpec - -_Appears in:_ -- [TyphaDeploymentSpec](#typhadeploymentspec) - -| Field | Description | -| --- | --- | -| `metadata` _[Metadata](#metadata)_ | (Optional) Refer to Kubernetes API documentation for fields of `metadata`. | -| `spec` _[TyphaDeploymentPodSpec](#typhadeploymentpodspec)_ | (Optional) Spec is the typha Deployment's PodSpec. | - - -### TyphaDeploymentSpec - - - -TyphaDeploymentSpec defines configuration for the typha Deployment. - -_Appears in:_ -- [TyphaDeployment](#typhadeployment) - -| Field | Description | -| --- | --- | -| `minReadySeconds` _integer_ | (Optional) MinReadySeconds is the minimum number of seconds for which a newly created Deployment pod should be ready without any of its container crashing, for it to be considered available. If specified, this overrides any minReadySeconds value that may be set on the typha Deployment. If omitted, the typha Deployment will use its default value for minReadySeconds. | -| `template` _[TyphaDeploymentPodTemplateSpec](#typhadeploymentpodtemplatespec)_ | (Optional) Template describes the typha Deployment pod that will be created. | -| `strategy` _[TyphaDeploymentStrategy](#typhadeploymentstrategy)_ | (Optional) The deployment strategy to use to replace existing pods with new ones. | - - -### TyphaDeploymentStrategy - - - -TyphaDeploymentStrategy describes how to replace existing pods with new ones. Only RollingUpdate is supported -at this time so the Type field is not exposed. - -_Appears in:_ -- [TyphaDeploymentSpec](#typhadeploymentspec) - -| Field | Description | -| --- | --- | -| `rollingUpdate` _[RollingUpdateDeployment](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#rollingupdatedeployment-v1-apps)_ | (Optional) Rolling update config params. Present only if DeploymentStrategyType = RollingUpdate. to be. | - - - - -### WindowsDataplaneOption - -_Underlying type:_ _string_ - - - -_Validation:_ -- Enum: [HNS Disabled] - - -_Appears in:_ -- [CalicoNetworkSpec](#caliconetworkspec) - -| Value | Description | -| --- | --- | -| `Disabled` | | -| `HNS` | | - - -### WindowsNodeSpec - - - - - -_Appears in:_ -- [InstallationSpec](#installationspec) - -| Field | Description | -| --- | --- | -| `cniBinDir` _string_ | (Optional) CNIBinDir is the path to the CNI binaries directory on Windows, it must match what is used as 'bin_dir' under [plugins] [plugins."io.containerd.grpc.v1.cri"] [plugins."io.containerd.grpc.v1.cri".cni] on the containerd 'config.toml' file on the Windows nodes. | -| `cniConfigDir` _string_ | (Optional) CNIConfigDir is the path to the CNI configuration directory on Windows, it must match what is used as 'conf_dir' under [plugins] [plugins."io.containerd.grpc.v1.cri"] [plugins."io.containerd.grpc.v1.cri".cni] on the containerd 'config.toml' file on the Windows nodes. | -| `cniLogDir` _string_ | (Optional) CNILogDir is the path to the Calico CNI logs directory on Windows. | -| `vxlanMACPrefix` _string_ | (Optional) VXLANMACPrefix is the prefix used when generating MAC addresses for virtual NICs | -| `vxlanAdapter` _string_ | (Optional) VXLANAdapter is the Network Adapter used for VXLAN, leave blank for primary NIC | - diff --git a/calico_versioned_docs/version-3.29/reference/installation/_crd-ref-docs/config.yaml b/calico_versioned_docs/version-3.29/reference/installation/_crd-ref-docs/config.yaml deleted file mode 100644 index 162ff7febb..0000000000 --- a/calico_versioned_docs/version-3.29/reference/installation/_crd-ref-docs/config.yaml +++ /dev/null @@ -1,69 +0,0 @@ -processor: - # RE2 regular expressions describing types that should be excluded from the generated documentation. - ignoreTypes: - - "List$" - - "AdditionalLogStoreSpec" - - "AdditionalLogSourceSpec" - - "AmazonCloudIntegration" - - "ApplicationLayer" - - "AuthType" - - "MetadataAccessAllowedType" - - "Authentication" - - "Auth" - - "AuthMethod" - - "Compliance" - - "Dashboards*" - - "DeepPacketInspectionDaemonset*" - - "DexDeployment*" - - "DPIDaemonset*" - - "ECKOperator*" - - "EgressGateway" - - "EksCloudwatchLogsSpec" - - "EKSLogForwarder*" - - "Elasticsearch*" - - "EmailVerificationType" - - "ESGateway*" - - "FluentdDaemon*" - - "GuardianDeployment*" - - "GroupSearch" - - "Index" - - "Indices" - - "IntrusionDetection" - - "Kibana*" - - "LinseedDeployment*" - - "LogCollect*" - - "LogStorage" - - "ManagementCluster" - - "Manager" - - "Monitor*$" - - "Nodes" - - "NodeSet" - - "NodeSetSelectionAttribute" - - "NonClusterHost*" - - "PacketCaptureAPI" - - "PolicyRecommendation*" - - "Prometheus*" - - "Retention" - - "S3StoreSpec" - - "SplunkStoreSpec" - - "SyslogStoreSpec" - - "SyslogLogType" - - "Tenant*" - - "TLS.*Route" - - "UserMatch" - - "UserSearch" - # RE2 regular expressions describing type fields that should be excluded from the generated documentation. - ignoreFields: - - "TypeMeta$" - customMarkers: - - name: "optional" - target: field - -render: - # Version of Kubernetes to use when generating links to Kubernetes API documentation. - kubernetesVersion: 1.32 - # Generate better link for known types - #knownTypes: - # - name: SecretObjectReference - # package: sigs.k8s.io/gateway-api/apis/v1beta1 - # link: https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.SecretObjectReference diff --git a/calico_versioned_docs/version-3.29/reference/installation/_crd-ref-docs/templates/gv_details.tpl b/calico_versioned_docs/version-3.29/reference/installation/_crd-ref-docs/templates/gv_details.tpl deleted file mode 100644 index 3bd48c66bc..0000000000 --- a/calico_versioned_docs/version-3.29/reference/installation/_crd-ref-docs/templates/gv_details.tpl +++ /dev/null @@ -1,21 +0,0 @@ -{{- define "gvDetails" -}} -{{- $gv := . -}} - -{/* vale off */} - -## {{ $gv.GroupVersionString }} - -{{ $gv.Doc }} - -{{- if $gv.Kinds }} -Resource Types -{{- range $gv.SortedKinds }} -- {{ $gv.TypeForKind . | markdownRenderTypeLink }} -{{- end }} -{{ end }} - -{{ range $gv.SortedTypes }} -{{ template "type" . }} -{{ end }} - -{{- end -}} diff --git a/calico_versioned_docs/version-3.29/reference/installation/_crd-ref-docs/templates/gv_list.tpl b/calico_versioned_docs/version-3.29/reference/installation/_crd-ref-docs/templates/gv_list.tpl deleted file mode 100644 index 30ad594057..0000000000 --- a/calico_versioned_docs/version-3.29/reference/installation/_crd-ref-docs/templates/gv_list.tpl +++ /dev/null @@ -1,13 +0,0 @@ -{{- define "gvList" -}} -{{- $groupVersions := . -}} - -Packages -{{- range $groupVersions }} -- {{ markdownRenderGVLink . }} -{{- end }} - -{{ range $groupVersions }} -{{ template "gvDetails" . -}} -{{ end }} - -{{- end -}} diff --git a/calico_versioned_docs/version-3.29/reference/installation/_crd-ref-docs/templates/type.tpl b/calico_versioned_docs/version-3.29/reference/installation/_crd-ref-docs/templates/type.tpl deleted file mode 100644 index bcf45a0967..0000000000 --- a/calico_versioned_docs/version-3.29/reference/installation/_crd-ref-docs/templates/type.tpl +++ /dev/null @@ -1,51 +0,0 @@ -{{- define "type" -}} -{{- $type := . -}} -{{- if markdownShouldRenderType $type -}} - -### {{ $type.Name }} - -{{ if $type.IsAlias }}_Underlying type:_ _{{ markdownRenderTypeLink $type.UnderlyingType }}_{{ end }} - -{{ $type.Doc }} - -{{- if $type.Validation }} - -_Validation:_ -{{- range $type.Validation }} -- {{ . }} -{{ end }} -{{- end -}} - -{{- if $type.References }} - -_Appears in:_ -{{- range $type.SortedReferences }} -- {{ markdownRenderTypeLink . }} -{{- end }} -{{- end }} - -{{ if $type.Members -}} -| Field | Description | -| --- | --- | -{{ if $type.GVK -}} -| `apiVersion` _string_ | `{{ $type.GVK.Group }}/{{ $type.GVK.Version }}` | -| `kind` _string_ | `{{ $type.GVK.Kind }}` | -{{ end -}} - -{{ range $type.Members -}} -| `{{ .Name }}` _{{ markdownRenderType .Type }}_ | {{ with .Markers.optional -}}(Optional) {{ end -}} {{ template "type_members" . }} | -{{ end -}} - -{{ end -}} - -{{ if $type.EnumValues -}} -| Value | Description | -| --- | --- | -{{ range $type.EnumValues -}} -| `{{ .Name }}` | {{ markdownRenderFieldDoc .Doc }} | -{{ end -}} -{{ end -}} - - -{{- end -}} -{{- end -}} diff --git a/calico_versioned_docs/version-3.29/reference/installation/_crd-ref-docs/templates/type_members.tpl b/calico_versioned_docs/version-3.29/reference/installation/_crd-ref-docs/templates/type_members.tpl deleted file mode 100644 index 041758a872..0000000000 --- a/calico_versioned_docs/version-3.29/reference/installation/_crd-ref-docs/templates/type_members.tpl +++ /dev/null @@ -1,8 +0,0 @@ -{{- define "type_members" -}} -{{- $field := . -}} -{{- if eq $field.Name "metadata" -}} -Refer to Kubernetes API documentation for fields of `metadata`. -{{- else -}} -{{ markdownRenderFieldDoc $field.Doc }} -{{- end -}} -{{- end -}} diff --git a/calico_versioned_docs/version-3.29/reference/installation/api.mdx b/calico_versioned_docs/version-3.29/reference/installation/api.mdx deleted file mode 100644 index 8875695a61..0000000000 --- a/calico_versioned_docs/version-3.29/reference/installation/api.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: Installation API reference ---- - -# Installation reference - -import API from '@site/calico_versioned_docs/version-3.29/reference/installation/_api.mdx'; - -The Kubernetes resources below configure $[prodname] installation when using the operator. Each resource is responsible for installing and configuring a different subsystem of $[prodname] during installation. Most options can be modified on a running cluster using `kubectl`. - - diff --git a/calico_versioned_docs/version-3.29/reference/installation/config.json b/calico_versioned_docs/version-3.29/reference/installation/config.json deleted file mode 100644 index 3e407e8c58..0000000000 --- a/calico_versioned_docs/version-3.29/reference/installation/config.json +++ /dev/null @@ -1,56 +0,0 @@ -{ - "hideMemberFields": [ - "TypeMeta" - ], - "hideTypePatterns": [ - "ParseError$", - "List$", - "AmazonCloudIntegration", - "MetadataAccessAllowedType", - "Authentication", - "Auth", - "AuthMethod", - "EmailVerificationType", - "Compliance", - "IntrusionDetection", - "LogCollector", - "S3StoreSpec", - "SyslogStoreSpec", - "SyslogLogType", - "LogStorage", - "Retention", - "Nodes", - "NodeSet", - "NodeSetSelectionAttribute", - "Indices", - "AdditionalLogStoreSpec", - "AdditionalLogSourceSpec", - "EksCloudwatchLogsSpec", - "SplunkStoreSpec", - "ManagementCluster", - "Manager", - "AuthType", - "GroupSearch", - "UserMatch", - "UserSearch" - ], - "externalPackages": [ - { - "typeMatchPrefix": "^k8s\\.io/apimachinery/pkg/apis/meta/v1\\.Duration$", - "docsURLTemplate": "https://godoc.org/k8s.io/apimachinery/pkg/apis/meta/v1#Duration" - }, - { - "typeMatchPrefix": "^k8s\\.io/(api|apimachinery/pkg/apis)/", - "docsURLTemplate": "https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.31/#{{lower .TypeIdentifier}}-{{arrIndex .PackageSegments -1}}-{{arrIndex .PackageSegments -2}}" - }, - { - "typeMatchPrefix": "^github\\.com/knative/pkg/apis/duck/", - "docsURLTemplate": "https://godoc.org/github.com/knative/pkg/apis/duck/{{arrIndex .PackageSegments -1}}#{{.TypeIdentifier}}" - } - ], - "typeDisplayNamePrefixOverrides": { - "k8s.io/api/": "Kubernetes ", - "k8s.io/apimachinery/pkg/apis/": "Kubernetes " - }, - "markdownDisabled": false -} diff --git a/calico_versioned_docs/version-3.29/reference/installation/helm_customization.mdx b/calico_versioned_docs/version-3.29/reference/installation/helm_customization.mdx deleted file mode 100644 index ee5dc8352c..0000000000 --- a/calico_versioned_docs/version-3.29/reference/installation/helm_customization.mdx +++ /dev/null @@ -1,44 +0,0 @@ ---- -description: Helm installation reference ---- - -# Helm installation reference - -You can customize the following resources and settings during $[prodname] Helm-based installation using the file, `values.yaml`. - -- [Installation](api.mdx#installationspec) -- [Default felix configuration](../resources/felixconfig.mdx#spec) - -:::note -If you customize felix configuration when you install $[prodname], the `v1 apiVersion` is used. However, when you apply -felix configuration customization after installation (when the tigera-apiserver is running), use the `v3 apiVersion`. -::: - -### Sample values.yaml - -Here is a sample `values.yaml` file with settings for custom resources. You must enable the custom resource using -`enabled: true` to provide custom configurations; custom resources set to false are ignored. - -```yaml -installation: - enabled: true - - -defaultFelixConfiguration: - enabled: false - -``` - -## Common customizations - -Example of common customizations that you might want to configure in you values.yaml for your Helm-based installation: - -### Encryption using WireGuard -WireGuard encryption is configured in the FelixConfiguration. To set encryption for your cluster, update the `values.yaml` file. - -```yaml -defaultFelixConfiguration: - enabled: true - wireguardEnabled: true - wireguardEnabledV6: true -``` \ No newline at end of file diff --git a/calico_versioned_docs/version-3.29/reference/involved.mdx b/calico_versioned_docs/version-3.29/reference/involved.mdx deleted file mode 100644 index f1a3777948..0000000000 --- a/calico_versioned_docs/version-3.29/reference/involved.mdx +++ /dev/null @@ -1,33 +0,0 @@ ---- -description: Contribute to Calico open source project. ---- - -# Getting involved - -Calico is an open source project, and we'd love you to get involved. -Whether that might be by reading and participating on our slack, -or by diving into the code to propose enhancements or integrate with -other systems. To see the options for getting involved with Calico the -project, please take a look at the following. - -## Join us on Slack - -Our [public slack](https://calicousers.slack.com/) is the quickest way to get -in touch for help debugging any issues with Calico. - -## Read the source, Luke! - -All of Calico's code is on [GitHub](https://github.com/projectcalico/calico). - -## Contributing - -Calico follows the "Fork & Pull" model of collaborative development, -with changes being offered to the main Calico codebase via pull -requests. So you can contribute a fix, change, or enhancement by forking -one of our repositories and making a GitHub pull request. If you're -interested in doing that: - -- Thanks! -- See the [GitHub docs](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) for how - to create a pull request. -- Check the [contribution and developer docs](https://github.com/projectcalico/calico/blob/master/CONTRIBUTING.md). diff --git a/calico_versioned_docs/version-3.29/reference/kube-controllers/configuration.mdx b/calico_versioned_docs/version-3.29/reference/kube-controllers/configuration.mdx deleted file mode 100644 index 5b0a52daeb..0000000000 --- a/calico_versioned_docs/version-3.29/reference/kube-controllers/configuration.mdx +++ /dev/null @@ -1,177 +0,0 @@ ---- -description: Calico Kubernetes controllers monitor the Kubernetes API and perform actions based on cluster state. ---- - -# Configuring the Calico Kubernetes controllers - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - -The $[prodname] Kubernetes controllers are deployed in a Kubernetes cluster. The different controllers monitor the Kubernetes API -and perform actions based on cluster state. - - - - -If you have installed Calico using the operator, see the [KubeControllersConfiguration](../resources/kubecontrollersconfig.mdx) resource instead. - - - - -The controllers are primarily configured through environment variables. When running -the controllers as a Kubernetes pod, this is accomplished through the pod manifest `env` -section. - -## The $[imageNames.calico/kube-controllers] container - -The `$[imageNames.calico/kube-controllers]` container includes the following controllers: - -1. policy controller: watches Kubernetes network policies in the Kubernetes API, and syncs the policies to the datastore (etcd) as $[prodname] network policies. Felix implements network policies in the data plane. -1. namespace controller: watches namespaces and programs $[prodname] profiles. -1. serviceaccount controller: watches service accounts and programs $[prodname] profiles. -1. workloadendpoint controller: watches for changes to pod labels and updates $[prodname] workload endpoints. -1. node controller: watches for the removal of Kubernetes nodes and removes corresponding data from $[prodname], and optionally watches for node updates to create and sync host endpoints for each node. - -The $[prodname] Kubernetes manifests run these controllers within a single pod in the `calico-kube-controllers` deployment. - -### Configuring datastore access - -The datastore type can be configured via the `DATASTORE_TYPE` environment variable. Supported values are `etcdv3` and `kubernetes`. - -#### etcdv3 - -The $[prodname] Kubernetes controllers support the following environment variables to configure etcd access: - -| Environment | Description | Schema | -| -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------ | -| `ETCD_ENDPOINTS` | Comma-delimited list of etcd endpoints to connect to. Example: `http://10.0.0.1:2379,http://10.0.0.2:2379`. | string | -| `ETCD_DISCOVERY_SRV` | Domain name to discover etcd endpoints via SRV records. Mutually exclusive with `ETCD_ENDPOINTS`. Example: `example.com` | string | -| `ETCD_CA_CERT_FILE` | Path to the file containing the root certificate of the CA that issued the etcd server certificate. Configures the Kubernetes controllers to trust the signature on the certificates provided by the etcd server. To disable authentication of the server by the Kubernetes controllers, set the value to `none`. | path | -| `ETCD_CERT_FILE` | Path to the file containing the client certificate issued to the Kubernetes controllers. Enables the Kubernetes controllers to participate in mutual TLS authentication and identify themselves to the etcd server. Example: `/etc/kube-controllers/cert.pem` | path | -| `ETCD_KEY_FILE` | Path to the file containing the private key of the Kubernetes controllers' client certificate. Enables the Kubernetes controllers to participate in mutual TLS authentication and identify themselves to the etcd server. Example: `/etc/kube-controllers/key.pem` | path | - -The `*_FILE` variables are _paths_ to the corresponding certificates/keys. As such, when the controllers are running as a Kubernetes pod, you -must ensure that the files exist within the pod. This is usually done in one of two ways: - -- Mount the certificates from the host. This requires that the certificates be present on the host running the controller. -- Use Kubernetes [Secrets](https://kubernetes.io/docs/concepts/configuration/secret/) to mount the certificates into the pod as files. - -#### kubernetes - -When running the controllers as a Kubernetes pod, Kubernetes API access is [configured automatically][in-cluster-config] and -no additional configuration is required. However, the controllers can also be configured to use an explicit [kubeconfig][kubeconfig] file override to -configure API access if needed. - -| Environment | Description | Schema | -| ------------ | ------------------------------------------------------------------ | ------ | -| `KUBECONFIG` | Path to a Kubernetes kubeconfig file mounted within the container. | path | - -### Other configuration - -:::note - -Whenever possible, prefer configuring the kube-controllers component using the [KubeControllersConfiguration](../resources/kubecontrollersconfig.mdx) API resource, -Some configuration options may not be available through environment variables. - -::: - -The following environment variables can be used to configure the $[prodname] Kubernetes controllers. - -| Environment | Description | Schema | Default | -| --------------------- | --------------------------------------------------------------------------- | --------------------------------------------------------- | ----------------------------------------------------- | -| `DATASTORE_TYPE` | Which datastore type to use | etcdv3, kubernetes | kubernetes | -| `ENABLED_CONTROLLERS` | Which controllers to run | namespace, node, policy, serviceaccount, workloadendpoint | policy,namespace,serviceaccount,workloadendpoint,node | -| `LOG_LEVEL` | Minimum log level to be displayed. | debug, info, warning, error | info | -| `KUBECONFIG` | Path to a kubeconfig file for Kubernetes API access | path | -| `SYNC_NODE_LABELS` | When enabled, Kubernetes node labels will be copied to Calico node objects. | boolean | true | -| `AUTO_HOST_ENDPOINTS` | When set to enabled, automatically create a host endpoint for each node. | enabled, disabled | disabled | -| `COMPACTION_PERIOD` | Compact the etcd database on this interval. Set to "0" to disable. | [duration](https://golang.org/pkg/time/#ParseDuration) | 10m | - -## About each controller - -### Node controller - -The node controller has several functions depending on the datastore in use. - -**Either datastore** - -- Garbage collects IP addresses. -- Automatically provisions host endpoints for Kubernetes nodes. - -**etcdv3 only** - -- Garbage collects projectcalico.org/v3 Node resources when the Kubernetes node is deleted. -- Synchronizes labels between Kubernetes and Calico Node resources. - -The node controller is not enabled by default if `ENABLED_CONTROLLERS` is not explicitly specified. -However, the $[prodname] Kubernetes manifests explicitly specify the `ENABLED_CONTROLLERS` and enable this controller -within the calico-kube-controllers deployment. - -This controller is valid when using either the `etcdv3` or `kubernetes` datastore types. - -#### etcdv3 - -To enable the node controller when using `etcdv3`, perform the following two steps. - -1. Enable the controller in your [KubeControllersConfiguration](../resources/kubecontrollersconfig.mdx) or add "node" to the list of enabled controllers in the environment for kube-controllers. For example: `ENABLED_CONTROLLERS=workloadendpoint,profile,policy,node` -1. Configure $[nodecontainer] with a Kubernetes node reference by adding the following snippet to the environment section of the $[noderunning] daemon set. - - ```yaml - - name: CALICO_K8S_NODE_REF - valueFrom: - fieldRef: - fieldPath: spec.nodeName - ``` - -Set `SYNC_NODE_LABELS` to true (enabled by default) to ensure that labels on -Kubernetes node resources remain in-sync with labels on the corresponding $[prodname] -node resource. If both node resources specify a label with different values, -the Kubernetes node resource takes precedence. Labels on the $[prodname] -resource that don't exist in the Kubernetes node will remain as is. - -#### kubernetes - -To enable the node controller when using `kubernetes`, enable the controller in your [KubeControllersConfiguration](../resources/kubecontrollersconfig.mdx) or set the list of enabled controllers in the environment for kube-controllers to `node`. For example: `ENABLED_CONTROLLERS=node` - -### Policy controller - -The policy controller syncs Kubernetes network policies to the $[prodname] datastore. The controller must have read -access to the Kubernetes API to monitor `NetworkPolicy` events. - -The policy controller is enabled by default if `ENABLED_CONTROLLERS` is not explicitly specified. - -This controller is only valid when using etcd as the $[prodname] datastore. - -### Workload endpoint controller - -The workload endpoint controller automatically syncs Kubernetes pod label changes to the $[prodname] datastore by updating -the corresponding workload endpoints appropriately. The controller must have read -access to the Kubernetes API to monitor `Pod` events. - -The workload endpoint controller is enabled by default if `ENABLED_CONTROLLERS` is not explicitly specified. - -This controller is only valid when using etcd as the $[prodname] datastore. - -### Namespace controller - -The namespace controller syncs Kubernetes namespace label changes to the $[prodname] datastore. The controller must have read -access to the Kubernetes API to monitor `Namespace` events. - -The namespace controller is enabled by default if `ENABLED_CONTROLLERS` is not explicitly specified. - -This controller is only valid when using etcd as the $[prodname] datastore. - -### Service account controller - -The service account controller syncs Kubernetes service account changes to the $[prodname] datastore. -The controller must have read access to the Kubernetes API to monitor `ServiceAccount` events. - -The service account controller is enabled by default if `ENABLED_CONTROLLERS` is not explicitly specified. - -This controller is only valid when using etcd as the $[prodname] datastore. - - - - -[in-cluster-config]: https://kubernetes.io/docs/tasks/access-application-cluster/access-cluster/#accessing-the-api-from-a-pod -[kubeconfig]: https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/ diff --git a/calico_versioned_docs/version-3.29/reference/kube-controllers/index.mdx b/calico_versioned_docs/version-3.29/reference/kube-controllers/index.mdx deleted file mode 100644 index 303cb85423..0000000000 --- a/calico_versioned_docs/version-3.29/reference/kube-controllers/index.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: kube-controllers is a set of Kubernetes controllers for Calico -hide_table_of_contents: true ---- - -# kube-controllers - -import DocCardList from '@theme/DocCardList'; -import { useCurrentSidebarCategory } from '@docusaurus/theme-common'; - - diff --git a/calico_versioned_docs/version-3.29/reference/kube-controllers/prometheus.mdx b/calico_versioned_docs/version-3.29/reference/kube-controllers/prometheus.mdx deleted file mode 100644 index adec4bd5e7..0000000000 --- a/calico_versioned_docs/version-3.29/reference/kube-controllers/prometheus.mdx +++ /dev/null @@ -1,84 +0,0 @@ ---- -description: Review metrics for the kube-controllers component if you are using Prometheus. ---- - -# Monitoring kube-controllers with Prometheus - -kube-controllers can be configured to report a number of metrics through Prometheus. This reporting is enabled by default on port 9094. See the -[configuration reference](../resources/kubecontrollersconfig.mdx) for how to change metrics reporting configuration (or disable it completely). - -## Metric reference - -#### kube-controllers specific - -kube-controllers exports a number of Prometheus metrics. The current set is as follows. Since some metrics -may be tied to particular implementation choices inside kube-controllers we can't make any hard guarantees that -metrics will persist across releases. However, we aim not to make any spurious changes to -existing metrics. - -| Metric Name | Labels | Description | -| ------------------------------------ | ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `ipam_allocations_in_use` | ippool, node | Number of Calico IP allocations currently in use by a workload or interface. | -| `ipam_allocations_borrowed` | ippool, node | Number of Calico IP allocations currently in use where the allocation was borrowed from a block affine to another node. | -| `ipam_allocations_gc_candidates` | ippool, node | Number of Calico IP allocations currently marked by the GC as potential leaks. This metric returns to zero under normal GC operation. | -| `ipam_allocations_gc_reclamations` | ippool, node | Count of Calico IP allocations that have been reclaimed by the GC. Increase of this counter corresponds with a decrease of the candidates gauge under normal operation. | -| `ipam_blocks` | ippool, node | Number of IPAM blocks. | -| `ipam_ippool_size` | ippool | Number of IP addresses in the IP Pool CIDR. | -| `ipam_blocks_per_node` | node | Number of IPAM blocks, indexed by the node to which they have affinity. Prefer `ipam_blocks` for new integrations. | -| `ipam_allocations_per_node` | node | Number of Calico IP allocations, indexed by node on which the allocation was made. Prefer `ipam_allocations_in_use` for new integrations. | -| `ipam_allocations_borrowed_per_node` | node | Number of Calico IP allocations borrowed from a non-affine block, indexed by node on which the allocation was made. Prefer `ipam_allocations_borrowed` for new integrations. | - -Labels can be interpreted as follows: - -| Label Name | Description | -| ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `node` | For allocation metrics, the node on which the allocation was made. For block metrics, the node for which the block has affinity. If the block has no affinity, value will be `no_affinity`. | -| `ippool` | The IP Pool that the IPAM block occupies. If there is no IP Pool which matches the block, value will be `no_ippool`. | - -Prometheus metrics are self-documenting, with metrics turned on, `curl` can be used to list the -metrics along with their help text and type information. - -```bash -curl -s http://localhost:9094/metrics | head -``` - -#### CPU / memory metrics - -kube-controllers also exports the default set of metrics that Prometheus makes available. Currently, those -include: - -| Name | Description | -| -------------------------------------------- | ------------------------------------------------------------------ | -| `go_gc_duration_seconds` | A summary of the GC invocation durations. | -| `go_goroutines` | Number of goroutines that currently exist. | -| `go_memstats_alloc_bytes` | Number of bytes allocated and still in use. | -| `go_memstats_alloc_bytes_total` | Total number of bytes allocated, even if freed. | -| `go_memstats_buck_hash_sys_bytes` | Number of bytes used by the profiling bucket hash table. | -| `go_memstats_frees_total` | Total number of frees. | -| `go_memstats_gc_sys_bytes` | Number of bytes used for garbage collection system metadata. | -| `go_memstats_heap_alloc_bytes` | Number of heap bytes allocated and still in use. | -| `go_memstats_heap_idle_bytes` | Number of heap bytes waiting to be used. | -| `go_memstats_heap_inuse_bytes` | Number of heap bytes that are in use. | -| `go_memstats_heap_objects` | Number of allocated objects. | -| `go_memstats_heap_released_bytes_total` | Total number of heap bytes released to OS. | -| `go_memstats_heap_sys_bytes` | Number of heap bytes obtained from system. | -| `go_memstats_last_gc_time_seconds` | Number of seconds since 1970 of last garbage collection. | -| `go_memstats_lookups_total` | Total number of pointer lookups. | -| `go_memstats_mallocs_total` | Total number of mallocs. | -| `go_memstats_mcache_inuse_bytes` | Number of bytes in use by mcache structures. | -| `go_memstats_mcache_sys_bytes` | Number of bytes used for mcache structures obtained from system. | -| `go_memstats_mspan_inuse_bytes` | Number of bytes in use by mspan structures. | -| `go_memstats_mspan_sys_bytes` | Number of bytes used for mspan structures obtained from system. | -| `go_memstats_next_gc_bytes` | Number of heap bytes when next garbage collection will take place. | -| `go_memstats_other_sys_bytes` | Number of bytes used for other system allocations. | -| `go_memstats_stack_inuse_bytes` | Number of bytes in use by the stack allocator. | -| `go_memstats_stack_sys_bytes` | Number of bytes obtained from system for stack allocator. | -| `go_memstats_sys_bytes` | Number of bytes obtained by system. Sum of all system allocations. | -| `process_cpu_seconds_total` | Total user and system CPU time spent in seconds. | -| `process_max_fds` | Maximum number of open file descriptors. | -| `process_open_fds` | Number of open file descriptors. | -| `process_resident_memory_bytes` | Resident memory size in bytes. | -| `process_start_time_seconds` | Start time of the process since Unix epoch in seconds. | -| `process_virtual_memory_bytes` | Virtual memory size in bytes. | -| `promhttp_metric_handler_requests_in_flight` | Current number of scrapes being served. | -| `promhttp_metric_handler_requests_total` | Total number of scrapes by HTTP status code. | diff --git a/calico_versioned_docs/version-3.29/reference/public-cloud/aws.mdx b/calico_versioned_docs/version-3.29/reference/public-cloud/aws.mdx deleted file mode 100644 index 3ddfc95f3d..0000000000 --- a/calico_versioned_docs/version-3.29/reference/public-cloud/aws.mdx +++ /dev/null @@ -1,85 +0,0 @@ ---- -description: Advantages of using Calico in AWS. ---- - -# Amazon Web Services - -$[prodname] provides the following advantages when running in Amazon Web Services (AWS): - -- **Network Policy for Containers**: $[prodname] provides fine-grained network security policy for individual containers. -- **No Overlays**: Within each VPC subnet $[prodname] doesn't need an overlay, which means high performance networking for your containers. -- **No 50 Node Limit**: $[prodname] allows you to surpass the 50 node limit, which exists as a consequence of the [AWS 50 route limit](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Appendix_Limits.html#vpc-limits-route-tables) when using the VPC routing table. - -## Routing traffic within a single VPC subnet - -Since $[prodname] assigns IP addresses outside the range used by AWS for EC2 instances, you must disable AWS src/dst -checks on each EC2 instance in your cluster -[as described in the AWS documentation](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_NAT_Instance.html#EIP_Disable_SrcDestCheck). This -allows $[prodname] to route traffic natively within a single VPC subnet without using an overlay or any of the limited VPC routing table entries. - -## Routing traffic across different VPC subnets / VPCs - -If you need to split your deployment across multiple AZs for high availability then each AZ will have its own VPC subnet. To -use $[prodname] across multiple different VPC subnets or [peered VPCs](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-peering.html), -in addition to disabling src/dst checks as described above you must also enable IPIP encapsulation and outgoing NAT -on your $[prodname] IP pools. - -See the [IP pool configuration reference](../resources/ippool.mdx) -for information on how to configure $[prodname] IP pools. - -By default, $[prodname]'s IPIP encapsulation applies to all container-to-container traffic. However, -encapsulation is only required for container traffic that crosses a VPC subnet boundary. For better -performance, you can configure $[prodname] to perform IPIP encapsulation only across VPC subnet boundaries. - -To enable the "CrossSubnet" IPIP feature, configure your $[prodname] IP pool resources -to enable IPIP and set the mode to "CrossSubnet". - -:::note - -This feature was introduced in $[prodname] v2.1, if your deployment was created with -an older version of $[prodname], or if you if you are unsure whether your deployment -is configured correctly, follow the [Configuring IP-in-IP guide](../../networking/configuring/vxlan-ipip.mdx) -which discusses this in more detail. - -::: - -The following `calicoctl` command will create or modify an IPv4 pool with -CIDR 192.168.0.0/16 using IPIP mode `CrossSubnet`. Adjust the pool CIDR for your deployment. - -```bash -calicoctl apply -f - < diff --git a/calico_versioned_docs/version-3.29/reference/resources/bgpconfig.mdx b/calico_versioned_docs/version-3.29/reference/resources/bgpconfig.mdx deleted file mode 100644 index e38e89d07e..0000000000 --- a/calico_versioned_docs/version-3.29/reference/resources/bgpconfig.mdx +++ /dev/null @@ -1,80 +0,0 @@ ---- -description: API for this Calico resource. ---- - -# BGP configuration - -A BGP configuration resource (`BGPConfiguration`) represents BGP specific configuration options for the cluster or a -specific node. - -## Sample YAML - -```yaml -apiVersion: projectcalico.org/v3 -kind: BGPConfiguration -metadata: - name: default -spec: - logSeverityScreen: Info - nodeToNodeMeshEnabled: true - nodeMeshMaxRestartTime: 120s - asNumber: 63400 - serviceClusterIPs: - - cidr: 10.96.0.0/12 - serviceExternalIPs: - - cidr: 104.244.42.129/32 - - cidr: 172.217.3.0/24 - listenPort: 178 - bindMode: NodeIP - communities: - - name: bgp-large-community - value: 63400:300:100 - prefixAdvertisements: - - cidr: 172.218.4.0/26 - communities: - - bgp-large-community - - 63400:120 -``` - -## BGP configuration definition - -### Metadata - -| Field | Description | Accepted Values | Schema | -| ----- | --------------------------------------------------------- | --------------------------------------------------- | ------ | -| name | Unique name to describe this resource instance. Required. | Alphanumeric string with optional `.`, `_`, or `-`. | string | - -- The resource with the name `default` has a specific meaning - this contains the BGP global default configuration. -- The resources with the name `node.` contain the node-specific overrides, and will be applied to the node ``. When deleting a node the BGPConfiguration resource associated with the node will also be deleted. Only prefixAdvertisements, listenPort, and logSeverityScreen can be overridden this way. - -### Spec - -| Field | Description | Accepted Values | Schema | Default | -| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------- | --------------------------------------------------------------- | -| logSeverityScreen | Global log level | Debug, Info, Warning, Error, Fatal | string | `Info` | -| nodeToNodeMeshEnabled | Full BGP node-to-node mesh. Only valid on the global `default` BGPConfiguration. | true, false | string | true | -| asNumber | The default local AS Number that $[prodname] should use when speaking with BGP peers. Only valid on the global `default` BGPConfiguration; to set a per-node override, use the `bgp` field on the [Node resource](node.mdx). | A valid AS Number, may be specified in dotted notation. | integer/string | 64512 | -| serviceClusterIPs | The CIDR blocks for Kubernetes Service Cluster IPs to be advertised over BGP. Only valid on the global `default` BGPConfiguration: will be ignored otherwise. | A list of valid IPv4 or IPv6 CIDR blocks. | List of `cidr: /` values. | Empty List | -| serviceExternalIPs | The CIDR blocks for Kubernetes Service External IPs to be advertised over BGP. Kubernetes Service External IPs will only be advertised if they are within one of these blocks. Only valid on the global `default` BGPConfiguration: will be ignored otherwise. | A list of valid IPv4 or IPv6 CIDR blocks. | List of `cidr: /` values. | Empty List | -| serviceLoadBalancerIPs | The CIDR blocks for Kubernetes Service status.LoadBalancer IPs to be advertised over BGP. Kubernetes LoadBalancer IPs will only be advertised if they are within one of these blocks. Only valid on the global `default` BGPConfiguration: will be ignored otherwise. | A list of valid IPv4 or IPv6 CIDR blocks. | List of `cidr: /` values. | Empty List | -| listenPort | The port where BGP protocol should listen. | A valid port number. | integer | 179 | -| bindMode | Indicates whether to listen for BGP connections on all addresses (None) or only on the node's canonical IP address Node.Spec.BGP.IPvXAddress (NodeIP). If this field is changed when calico-node is already running, the change will not take effect until calico-node is manually restarted. | None, NodeIP. | string | None | -| communities | List of BGP community names and their values, communities are not advertised unless they are used in [prefixAdvertisements](#prefixadvertisements). | | List of [communities](#communities) | -| prefixAdvertisements | List of per-prefix advertisement properties, like BGP communities. | | List of [prefixAdvertisements](#prefixadvertisements) | -| nodeMeshPassword | BGP password for the all the peerings in a full mesh configuration. | | [BGPPassword](bgppeer.mdx#bgppassword) | `nil` (no password) | -| nodeMeshMaxRestartTime | Restart time that is announced by BIRD in the BGP graceful restart capability and that specifies how long the neighbor would wait for the BGP session to re-establish after a restart before deleting stale routes in full mesh configurations. Note: extra care should be taken when changing this configuration, as it may break networking in your cluster. When not specified, BIRD uses the default value of 120 seconds. | `10s`, `120s`, `2m` etc. | [Duration string][parse-duration] | `nil` (empty config, BIRD will use the default value of `120s`) | -| ignoredInterfaces | List of network interfaces to be excluded when reading device routes. | A list of network interface names. The names can contain the wildcard character asterisk `*` to specify groups of interface names. | List of strings | `nil` (no extra interfaces to be ignored) | - -### communities - -| Field | Description | Accepted Values | Schema | -| ----- | -------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------ | -| name | Name or identifier for the community. This should be used in [prefixAdvertisements](#prefixadvertisements) to advertise the community value. | | string | -| value | Standard or large BGP community value. | For standard community, value should be in `aa:nn` format, where both `aa` and `nn` are 16 bit integers.
    For large community, value should be `aa:nn:mm` format, where `aa`, `nn` and `mm` are all 32 bit integers.
    Where `aa` is an AS Number, `nn` and `mm` are per-AS identifier. | string | - -### prefixAdvertisements - -| Field | Description | Accepted Values | Schema | -| ----------- | ----------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------- | -| cidr | CIDR for which properties should be advertised. | `cidr: XXX.XXX.XXX.XXX/XX` | string | -| communities | BGP communities to be advertised. | Communities can be list of either community names already defined in [communities](#communities) or community value of format `aa:nn` or `aa:nn:mm`.
    For standard community, value should be in `aa:nn` format, where both `aa` and `nn` are 16 bit integers.
    For large community, value should be `aa:nn:mm` format, where `aa`, `nn` and `mm` are all 32 bit integers.
    Where `aa` is an AS Number, `nn` and `mm` are per-AS identifier. | List of string | \ No newline at end of file diff --git a/calico_versioned_docs/version-3.29/reference/resources/bgpfilter.mdx b/calico_versioned_docs/version-3.29/reference/resources/bgpfilter.mdx deleted file mode 100644 index 27b638e2a2..0000000000 --- a/calico_versioned_docs/version-3.29/reference/resources/bgpfilter.mdx +++ /dev/null @@ -1,102 +0,0 @@ ---- -description: API for this Calico resource. ---- - -# BGP Filter - -A BGP filter resource (`BGPFilter`) represents a way to control -routes imported by and exported to BGP peers specified using a -BGP peer resource (`BGPPeer`). - -The BGPFilter rules are applied sequentially: the `action` for -the **first** rule that matches is executed immediately. -If an address does not match any explicit BGP filter rule, -the default action is `Accept`. - -In order for a BGPFilter to be used in a BGP peering, its `name` -must be added to `filters` of the corresponding BGPPeer resource. - -For `kubectl` commands, the following case-sensitive aliases may -be used to specify the resource type on the CLI: `bgpfilters.projectcalico.org` - -## Sample YAML - -```yaml -apiVersion: projectcalico.org/v3 -kind: BGPFilter -metadata: - name: my-filter -spec: - exportV4: - - action: Accept - matchOperator: In - cidr: 77.0.0.0/16 - source: RemotePeers - - action: Reject - interface: '*.calico' - importV4: - - action: Accept - matchOperator: In - cidr: 55.0.0.0/16 - prefixLength: - min: 30 - - action: Reject - matchOperator: NotIn - cidr: 44.0.0.0/16 - exportV6: - - action: Reject - source: RemotePeers - - action: Reject - interface: '*.calico' - importV6: - - action: Accept - matchOperator: Equal - cidr: 5000::0/64 - - action: Reject -``` - -## BGP filter definition - -### Metadata - -| Field | Description | Accepted Values | Schema | -| ----- | ------------------------------------------------------------------ | --------------------------------------------------- | ------ | -| name | Unique name to describe this resource instance. Must be specified. | Alphanumeric string with optional `.`, `_`, or `-`. | string | - -### Spec - -| Field | Description | Accepted Values | Schema | Default | -| -------- | ---------------------------------- | --------------- | ----------------------------------------- | ------- | -| exportV4 | List of v4 CIDRs and export action | | [BGP Filter Rule v4](#bgp-filter-rule-v4) | | -| importV4 | List of v4 CIDRs and import action | | [BGP Filter Rule v4](#bgp-filter-rule-v4) | | -| exportV6 | List of v6 CIDRs and export action | | [BGP Filter Rule v6](#bgp-filter-rule-v6) | | -| importV6 | List of v6 CIDRs and import action | | [BGP Filter Rule v6](#bgp-filter-rule-v6) | | - -### BGP Filter Rule v4 - -| Field | Description | Accepted Values | Schema | Default | -| ------------- | ------------------------------------------ | ------------------------------------------------------------------- | ------ | ------- | -| cidr | IPv6 range | A valid IPv6 CIDR | string | | -| prefixLength | [PrefixLength](#bgp-filter-prefix-length) | Valid integers between 0 and ipv4/6 max (32, 128) | | | -| matchOperator | Method by which to match candidate routes | `In`, `NotIn`, `Equal`, `NotEqual` | string | | -| source | Indicator of the source of route | `RemotePeers` means any route learned from other BGP peers | string | | -| interface | String to match interface names | A valid pattern to match interfaces. "*" can be used as a wildcard. | string | | -| action | Action to be taken for this rule | `Accept` or `Reject` | string | | - -### BGP Filter Rule v6 - -| Field | Description | Accepted Values | Schema | Default | -| ------------- | ------------------------------------------ | ------------------------------------------------------------------- | ------ | ------- | -| cidr | IPv6 range | A valid IPv6 CIDR | string | | -| prefixLength | [PrefixLength](#bgp-filter-prefix-length) | Valid integers between 0 and ipv4/6 max (32, 128) | | | -| matchOperator | Method by which to match candidate routes | `In`, `NotIn`, `Equal`, `NotEqual` | string | | -| source | Indicator of the source of route | `RemotePeers` means any route learned from other BGP peers | string | | -| interface | String to match interface names | A valid pattern to match interfaces. "*" can be used as a wildcard. | string | | -| action | Action to be taken for this rule | `Accept` or `Reject` | string | | - -### BGP Filter Prefix Length - -| Field | Description | Accepted Values | Schema | Default | -| ------ | --------------------------------------------- | ------------------------------------------------------------------- | ------ | ------- | -| min | Smallest matched mask size (0 by default) | Valid integers between 0 and ipv4/6 max (32, 128) | int | | -| max | Largest matched mask size (32/128 by default) | Valid integers between 1 and ipv4/6 max (32, 128) | int | | diff --git a/calico_versioned_docs/version-3.29/reference/resources/bgppeer.mdx b/calico_versioned_docs/version-3.29/reference/resources/bgppeer.mdx deleted file mode 100644 index 8d3f826c93..0000000000 --- a/calico_versioned_docs/version-3.29/reference/resources/bgppeer.mdx +++ /dev/null @@ -1,185 +0,0 @@ ---- -description: API for this Calico resource. ---- - -# BGP peer - -import Selectors from '@site/calico_versioned_docs/version-3.29/_includes/content/_selectors.mdx'; - -A BGP peer resource (`BGPPeer`) represents a remote BGP peer with -which the node(s) in a $[prodname] cluster will peer. -Configuring BGP peers allows you to peer a $[prodname] network -with your datacenter fabric (e.g. ToR). For more -information on cluster layouts, see $[prodname]'s documentation on -[$[prodname] over IP fabrics](../architecture/design/l3-interconnect-fabric.mdx). - -## Sample YAML - -```yaml -apiVersion: projectcalico.org/v3 -kind: BGPPeer -metadata: - name: some.name -spec: - node: rack1-host1 - peerIP: 192.168.1.1 - asNumber: 63400 -``` - -## BGP peer definition - -### Metadata - -| Field | Description | Accepted Values | Schema | -| ----- | ------------------------------------------------------------------ | --------------------------------------------------- | ------ | -| name | Unique name to describe this resource instance. Must be specified. | Alphanumeric string with optional `.`, `_`, or `-`. | string | - -### Spec - -| Field | Description | Accepted Values | Schema | Default | -| ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | --------------------------------- | ---------------------------------------------------------------------------- | -| node | If specified, the scope is node level, otherwise the scope is global. | The hostname of the node to which this peer applies. | string | | -| peerIP | The IP address of this peer and an optional port number. If port number is not set, and peer is Calico node with `listenPort` set, then `listenPort` is used. | Valid IPv4 or IPv6 address. If port number is set use, `IPv4:port` or `[IPv6]:port` format. | string | | -| asNumber | The remote AS Number of the peer. | A valid AS Number, may be specified in dotted notation. | integer/string | -| nodeSelector | Selector for the nodes that should have this peering. When this is set, the `node` field must be empty. | | [selector](#selectors) | -| peerSelector | Selector for the remote nodes to peer with. When this is set, the `peerIP` and `asNumber` fields must be empty. | | [selector](#selectors) | -| keepOriginalNextHop | Maintain and forward the original next hop BGP route attribute to a specific Peer within a different AS. | | boolean | -| password | BGP password for the peerings generated by this BGPPeer resource. | | [BGPPassword](#bgppassword) | `nil` (no password) | -| sourceAddress | Specifies whether and how to configure a source address for the peerings generated by this BGPPeer resource. Default value "UseNodeIP" means to configure the node IP as the source address. "None" means not to configure a source address. | "UseNodeIP", "None" | string | "UseNodeIP" | -| maxRestartTime | Restart time that is announced by BIRD in the BGP graceful restart capability and that specifies how long the neighbor would wait for the BGP session to re-establish after a restart before deleting stale routes. Note: extra care should be taken when changing this configuration, as it may break networking in your cluster. When not specified, BIRD uses the default value of 120 seconds. | `10s`, `120s`, `2m` etc. | [Duration string][parse-duration] | `nil` (empty config, BIRD will use the default value of `120s`) | -| numAllowedLocalASNumbers | The number of local AS numbers to allow in the AS path for received routes. This disables BGP loop prevention and should only be used if necessary. | | integer | `nil` (BIRD will default to 0 meaning no change to loop prevention behavior) | -| ttlSecurity | Enables the generalized TTL security mechanism (GTSM) which protects against spoofed packets by ignoring received packets with a smaller than expected TTL value. The provided value is the number of hops (edges) between the peers. | 0 - 255 | 8-bit integer | `nil` (results in BIRD configuration `ttl security off`) | -| filters | List of names of [BGPFilter](bgpfilter.mdx) resources to apply to this peering. | [ "my-calico-bgp-filter1","my-calico-bgp-filter2" ] | List of strings | | -| reachableBy | Adds a static route that may be needed to connect to a peer. In some cases, not having a static route for BGP peering results in route flapping. By adding the address of the gateway that the peer is connected to, a static route is added to prevent route flapping. | The address of the gateway that the peer is connected to | string | | - -:::tip - -The cluster-wide default local AS number used when speaking with a peer is controlled by the -[BGPConfiguration resource](bgpconfig.mdx). That value can be overridden per-node by using the `bgp` field of -the [node resource](node.mdx). - -::: - -:::note - -If you want to use `BGPPeer` resources to configure BGP sessions between nodes within the cluster - for example, to set non-default BGPPeer parameters - you must disable node-to-node mesh by setting the `nodeToNodeMeshEnabled` parameter to false in the [BGPConfiguration](./bgpconfig) resource. - -::: - -### BGPPassword - -:::note - -BGP passwords must be 80 characters or fewer. If a password longer than that -is configured, the BGP sessions with that password will fail to be established. - -::: - -| Field | Description | Schema | -| ------------ | ------------------------------- | ----------------- | -| secretKeyRef | Get the password from a secret. | [KeyRef](#keyref) | - -### KeyRef - -KeyRef tells $[prodname] where to get a BGP password. The referenced Kubernetes -secret must be in the same namespace as the $[nodecontainer] pod. - -| Field | Description | Schema | -| ----- | ------------------------- | ------ | -| name | The name of the secret | string | -| key | The key within the secret | string | - -:::warning - -$[prodname] must be able to read the referenced secret. - -This means that the `calico-node` ServiceAccount must have permissions to `list, get, watch` the secret referenced in the KeyRef. - -In practice, this can be done by creating a Role (which allows to `list, get, watch` the secret) and a RoleBinding (which grants the Role's permission to the `calico-node` ServiceAccount). - -Example: - -```yaml ---- -apiVersion: rbac.authorization.k8s.io/v1 -kind: Role -metadata: - name: bgp-passwords-reader - namespace: calico-system # Or kube-system if installed using manifests. -rules: - - apiGroups: [""] - resources: ["secrets"] - resourceNames: ["bgp-passwords"] - verbs: ["list", "watch", "get"] - ---- -apiVersion: rbac.authorization.k8s.io/v1 -kind: RoleBinding -metadata: - name: calico-read-bgp-passwords - namespace: calico-system # Or kube-system if installed using manifests. -roleRef: - apiGroup: rbac.authorization.k8s.io - kind: Role - name: bgp-passwords-reader -subjects: - - kind: ServiceAccount - name: calico-node - ---- -apiVersion: v1 -kind: Secret -metadata: - name: "bgp-passwords" - namespace: calico-system # Or kube-system if installed using manifests. -data: - peer_a_pw: "base64-encoded Password for Peer A" - peer_b_pw: "base64-encoded Password for Peer B" - ---- -apiVersion: projectcalico.org/v3 -kind: BGPPeer -metadata: - name: "peer-a" -spec: - password: - secretKeyRef: - name: "bgp-passwords" - key: "peer_a_pw" - ---- -apiVersion: projectcalico.org/v3 -kind: BGPPeer -metadata: - name: "peer-b" -spec: - password: - secretKeyRef: - name: "bgp-passwords" - key: "peer_b_pw" -``` - -::: - -## Peer scopes - -BGP Peers can exist at either global or node-specific scope. A peer's scope -determines which `$[nodecontainer]`s will attempt to establish a BGP session with that peer. -If `$[nodecontainer]` has a `listenPort` set in `BGPConfiguration`, it will be used in peering. - -### Global peer - -To assign a BGP peer a global scope, omit the `node` and `nodeSelector` fields. All nodes in -the cluster will attempt to establish BGP connections with it - -### Node-specific peer - -A BGP peer can also be node-specific. When the `node` field is included, only the specified node -will peer with it. When the `nodeSelector` field is included, the nodes with labels that match that selector -will peer with it. - -## Selectors - - - -[parse-duration]: https://golang.org/pkg/time/#ParseDuration diff --git a/calico_versioned_docs/version-3.29/reference/resources/blockaffinity.mdx b/calico_versioned_docs/version-3.29/reference/resources/blockaffinity.mdx deleted file mode 100644 index 54e42bfbf3..0000000000 --- a/calico_versioned_docs/version-3.29/reference/resources/blockaffinity.mdx +++ /dev/null @@ -1,24 +0,0 @@ ---- -description: IP address management block affinity ---- - -# Block affinity - -A block affinity resource (`BlockAffinity`) represents the affinity for an IPAM block. These are managed by Calico IPAM. - -## Block affinity definition - -### Metadata - -| Field | Description | Accepted Values | Schema | -| ----- | ------------------------------------------------------------------ | --------------------------------------------------- | ------ | -| name | Unique name to describe this resource instance. Must be specified. | Alphanumeric string with optional `.`, `_`, or `-`. | string | - -### Spec - -| Field | Description | Accepted Values | Schema | Default | -| ------- | -------------------------------------------------------------------------- | ----------------------------------- | ------- | ------- | -| state | State of the affinity with regard to any referenced IPAM blocks. | confirmed, pending, pendingDeletion | string | | -| node | The node that this affinity is assigned to. | The hostname of the node | string | | -| cidr | The CIDR range this block affinity references. | A valid IPv4 or IPv6 CIDR. | string | | -| deleted | When set to true, clients should treat this block as if it does not exist. | true, false | boolean | `false` | \ No newline at end of file diff --git a/calico_versioned_docs/version-3.29/reference/resources/caliconodestatus.mdx b/calico_versioned_docs/version-3.29/reference/resources/caliconodestatus.mdx deleted file mode 100644 index 69fdb137eb..0000000000 --- a/calico_versioned_docs/version-3.29/reference/resources/caliconodestatus.mdx +++ /dev/null @@ -1,216 +0,0 @@ ---- -description: API for this Calico resource. ---- - -# Calico node status - -A Calico node status resource (`CalicoNodeStatus`) represents a collection of status information for a node that $[prodname] reports back to the user for use during troubleshooting. - -As of today, status of BGP agents, BGP sessions and routes exposed to BGP agents are collected from Linux nodes only. **Windows nodes are not supported at this time.** -Calico node status resource is only valid when $[prodname] BGP networking is in use. - -### Notes - -The updating of `CalicoNodeStatus` will have a small performance impact on CPU/Memory usage of the node as well as adding load to kubernetes apiserver. - -In our testing on a ten node, full mesh cluster, a `CalicoNodeStatus` resource was created for each node where the update interval was set to ten seconds. On each node, this resulted in an increase in CPU use of 5% of a vCPU and an increase of 4MB of memory. The control plane node recorded an increase in CPU usage of 5% of a vCPU for these 10 nodes. - -:::caution - -The implementation of `CalicoNodeStatus` is designed to handle a small number of nodes (less than 10 is recommended) reporting back status in the same time. If `CalicoNodeStatus` are created for a large number of nodes, and with short update interval, -the kubernetes apiserver may become slower and less responsive. -You should create `CalicoNodeStatus` for the node you are interested in and for debugging purpose only. `CalicoNodeStatus` resource should be deleted upon the completion of the debugging process. - -::: - -## Sample YAML - -To use this function, the user creates a CalicoNodeStatus object for the node, specifying the information to collect and the interval it should be collected at. This example collects information for node "my-kadm-node-0" with an update interval of 10 seconds. - -```bash -kubectl apply -f -<` contain the node-specific overrides, and will be applied to the node ``. When deleting a node the FelixConfiguration resource associated with the node will also be deleted. - -### Spec - -#### Process: Feature detection/overrides - - - -#### Process: Go runtime - - - -#### Process: Health port and timeouts - - - -#### Process: Logging - - - -#### Process: Prometheus metrics - - - -#### Data plane: Common - - - -#### Data plane: iptables - - - -#### Data plane: nftables - - - -#### Data plane: eBPF - - - -#### Data plane: Windows - - - -#### Data plane: OpenStack support - - - -#### Data plane: XDP acceleration for iptables data plane - - - -#### Overlay: VXLAN overlay - - - -#### Overlay: IP-in-IP - - - -#### Overlay: WireGuard - - - -#### AWS integration - - - -#### Debug/test-only (generally unsupported) - - - -#### Usage reporting - - - -### Metadata - -| Field | Description | Accepted Values | Schema | -| ----- | --------------------------------------------------------- | --------------------------------------------------- | ------ | -| name | Unique name to describe this resource instance. Required. | Alphanumeric string with optional `.`, `_`, or `-`. | string | - -- $[prodname] automatically creates a resource named `default` containing the global default configuration settings for Felix. You can use [calicoctl](../calicoctl/overview.mdx) to view and edit these settings -- The resources with the name `node.` contain the node-specific overrides, and will be applied to the node ``. When deleting a node the FelixConfiguration resource associated with the node will also be deleted. - -`genericXDPEnabled` and `xdpRefreshInterval` are only relevant when `bpfEnabled` is `false` and -`xdpEnabled` is `true`; in other words when XDP is being used to accelerate denial-of-service -prevention policies in the iptables data plane. - -When `bpfEnabled` is `true` the "xdp" settings all have no effect; in BPF mode the implementation of -policy is always accelerated, using the best available BPF technology. - -### Health Timeout Overrides - -Felix has internal liveness and readiness watchdog timers that monitor its various loops. -If a loop fails to "check in" within the allotted timeout then Felix will report non-Ready -or non-Live on its health port (which is monitored by kubelet in a Kubernetes system). -If Felix reports non-Live, this can result in the Pod being restarted. - -In Kubernetes, if you see the calico-node Pod readiness or liveness checks fail -intermittently, check the calico-node Pod log for a log from Felix that gives the -overall health status (the list of components will depend on which features are enabled): - -``` -+---------------------------+---------+----------------+-----------------+--------+ -| COMPONENT | TIMEOUT | LIVENESS | READINESS | DETAIL | -+---------------------------+---------+----------------+-----------------+--------+ -| CalculationGraph | 30s | reporting live | reporting ready | | -| FelixStartup | 0s | reporting live | reporting ready | | -| InternalDataplaneMainLoop | 1m30s | reporting live | reporting ready | | -+---------------------------+---------+----------------+-----------------+--------+ -``` - -If some health timeouts show as "timed out" it may help to apply an override -using the `healthTimeoutOverrides` field: - -```yaml noValidation -... -spec: - healthTimeoutOverrides: - - name: InternalDataplaneMainLoop - timeout: "5m" - - name: CalculationGraph - timeout: "1m30s" - ... -``` - -A timeout value of 0 disables the timeout. - -### ProtoPort - -| Field | Description | Accepted Values | Schema | -| -------- | -------------------- | ------------------------------------ | ------ | -| port | The exact port match | 0-65535 | int | -| protocol | The protocol match | tcp, udp, sctp | string | -| net | The CIDR match | any valid CIDR (e.g. 192.168.0.0/16) | string | - -Keep in mind that in the following example, `net: ""` and `net: "0.0.0.0/0"` are processed as the same in the policy enforcement. - -```yaml noValidation - ... -spec: - failsafeInboundHostPorts: - - net: "192.168.1.1/32" - port: 22 - protocol: tcp - - net: "" - port: 67 - protocol: udp -failsafeOutboundHostPorts: - - net: "0.0.0.0/0" - port: 67 - protocol: udp - ... -``` - -### RouteTableRange - -The `RouteTableRange` option is now deprecated in favor of [RouteTableRanges](#routetableranges). - -| Field | Description | Accepted Values | Schema | -| ----- | -------------------- | --------------- | ------ | -| min | Minimum index to use | 1-250 | int | -| max | Maximum index to use | 1-250 | int | - -### RouteTableRanges - -`RouteTableRanges` is a list of `RouteTableRange` objects: - -| Field | Description | Accepted Values | Schema | -| ----- | -------------------- | --------------- | ------ | -| min | Minimum index to use | 1 - 4294967295 | int | -| max | Maximum index to use | 1 - 4294967295 | int | - -Each item in the `RouteTableRanges` list designates a range of routing tables available to Calico. By default, Calico will use a single range of `1-250`. If a range spans Linux's reserved table range (`253-255`) then those tables are automatically excluded from the list. It's possible that other table ranges may also be reserved by third-party systems unknown to Calico. In that case, multiple ranges can be defined to target tables below and above the sensitive ranges: - -```sh - target tables 65-99, and 256-1000, skipping 100-255 -calicoctl patch felixconfig default --type=merge -p '{"spec":{"routeTableRanges": [{"Min": 65, "Max": 99}, {"Min": 256, "Max": 1000}] }} -``` - -_Note_, for performance reasons, the maximum total number of routing tables that Felix will accept is 65535 (or 2\*16). - -Specifying both the `RouteTableRange` and `RouteTableRanges` arguments is not supported and will result in an error from the api. - -### AWS IAM Role/Policy for source-destination-check configuration - -Setting `awsSrcDstCheck` to `Disable` will automatically disable source-destination-check on EC2 instances in a cluster, provided necessary IAM roles and policies are set. One of the policies assigned to IAM role of cluster nodes must contain a statement similar to the following: - -``` -{ - "Effect": "Allow", - "Action": [ - "ec2:DescribeInstances", - "ec2:ModifyNetworkInterfaceAttribute" - ], - "Resource": "*" -} -``` - -If there are no policies attached to node roles containing the above statement, attach a new policy. For example, if a node role is `test-cluster-nodeinstance-role`, click on the IAM role in AWS console. In the `Permission policies` list, add a new inline policy with the above statement to the new policy JSON definition. For detailed information, see [AWS documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html?icmpid=docs_iam_console). - -For an EKS cluster, the necessary IAM role and policy is available by default. No further actions are needed. \ No newline at end of file diff --git a/calico_versioned_docs/version-3.29/reference/resources/globalnetworkpolicy.mdx b/calico_versioned_docs/version-3.29/reference/resources/globalnetworkpolicy.mdx deleted file mode 100644 index 8a026b3cb4..0000000000 --- a/calico_versioned_docs/version-3.29/reference/resources/globalnetworkpolicy.mdx +++ /dev/null @@ -1,173 +0,0 @@ ---- -description: API for this Calico resource. ---- - -# Global network policy - -import Httpmatch from '@site/calico_versioned_docs/version-3.29/_includes/content/_httpmatch.mdx'; - -import Servicematch from '@site/calico_versioned_docs/version-3.29/_includes/content/_servicematch.mdx'; - -import Serviceaccountmatch from '@site/calico_versioned_docs/version-3.29/_includes/content/_serviceaccountmatch.mdx'; - -import Ports from '@site/calico_versioned_docs/version-3.29/_includes/content/_ports.mdx'; - -import SelectorScopes from '@site/calico_versioned_docs/version-3.29/_includes/content/_selector-scopes.mdx'; - -import Selectors from '@site/calico_versioned_docs/version-3.29/_includes/content/_selectors.mdx'; - -import Entityrule from '@site/calico_versioned_docs/version-3.29/_includes/content/_entityrule.mdx'; - -import Icmp from '@site/calico_versioned_docs/version-3.29/_includes/content/_icmp.mdx'; - -import Rule from '@site/calico_versioned_docs/version-3.29/_includes/content/_rule.mdx'; - -A global network policy resource (`GlobalNetworkPolicy`) represents an ordered set of rules which are applied -to a collection of endpoints that match a [label selector](#selectors). - -`GlobalNetworkPolicy` is not a namespaced resource. `GlobalNetworkPolicy` applies to [workload endpoint resources](workloadendpoint.mdx) in all namespaces, and to [host endpoint resources](hostendpoint.mdx). -Select a namespace in a `GlobalNetworkPolicy` in the standard selector by using -`projectcalico.org/namespace` as the label name and a `namespace` name as the -value to compare against, e.g., `projectcalico.org/namespace == "default"`. -See [network policy resource](networkpolicy.mdx) for namespaced network policy. - -`GlobalNetworkPolicy` resources can be used to define network connectivity rules between groups of $[prodname] endpoints and host endpoints, and -take precedence over [Profile resources](profile.mdx) if any are defined. - -## Sample YAML - -This sample policy allows TCP traffic from `frontend` endpoints to port 6379 on -`database` endpoints. - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: allow-tcp-6379 -spec: - selector: role == 'database' - types: - - Ingress - - Egress - ingress: - - action: Allow - metadata: - annotations: - from: frontend - to: database - protocol: TCP - source: - selector: role == 'frontend' - destination: - ports: - - 6379 - egress: - - action: Allow -``` - -## Definition - -### Metadata - -| Field | Description | Accepted Values | Schema | Default | -| ----- | ----------------------------------------- | --------------------------------------------------- | ------ | ------- | -| name | The name of the network policy. Required. | Alphanumeric string with optional `.`, `_`, or `-`. | string | | - -### Spec - -| Field | Description | Accepted Values | Schema | Default | -| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------- | ---------------------- | --------------------------------------------- | -| order | Controls the order of precedence. $[prodname] applies the policy with the lowest value first. | | float | | -| selector | Selects the endpoints to which this policy applies. | | [selector](#selectors) | all() | -| serviceAccountSelector | Selects the service account(s) to which this policy applies. Select all service accounts in the cluster with a specific name using the `projectcalico.org/name` label. | | [selector](#selectors) | all() | -| namespaceSelector | Selects the namespace(s) to which this policy applies. Select a specific namespace by name using the `projectcalico.org/name` label. | | [selector](#selectors) | all() | -| types | Applies the policy based on the direction of the traffic. To apply the policy to inbound traffic, set to `Ingress`. To apply the policy to outbound traffic, set to `Egress`. To apply the policy to both, set to `Ingress, Egress`. | `Ingress`, `Egress` | List of strings | Depends on presence of ingress/egress rules\* | -| ingress | Ordered list of ingress rules applied by policy. | | List of [Rule](#rule) | | -| egress | Ordered list of egress rules applied by this policy. | | List of [Rule](#rule) | | -| doNotTrack\*\* | Indicates to apply the rules in this policy before any data plane connection tracking, and that packets allowed by these rules should not be tracked. | true, false | boolean | false | -| preDNAT\*\* | Indicates to apply the rules in this policy before any DNAT. | true, false | boolean | false | -| applyOnForward\*\* | Indicates to apply the rules in this policy on forwarded traffic as well as to locally terminated traffic. | true, false | boolean | false | -| performanceHints | Contains a list of hints to Calico's policy engine to help process the policy more efficiently. Hints never change the enforcement behaviour of the policy. The available hints are described [below](#performance-hints). | `AssumeNeededOnEveryNode` | List of strings | | - -\* If `types` has no value, $[prodname] defaults as follows. - -> | Ingress Rules Present | Egress Rules Present | `Types` value | -> | --------------------- | -------------------- | ----------------- | -> | No | No | `Ingress` | -> | Yes | No | `Ingress` | -> | No | Yes | `Egress` | -> | Yes | Yes | `Ingress, Egress` | - -\*\* The `doNotTrack` and `preDNAT` and `applyOnForward` fields are meaningful -only when applying policy to a [host endpoint](hostendpoint.mdx). - -Only one of `doNotTrack` and `preDNAT` may be set to `true` (in a given policy). If they are both `false`, or when applying the policy to a -[workload endpoint](workloadendpoint.mdx), -the policy is enforced after connection tracking and any DNAT. - -`applyOnForward` must be set to `true` if either `doNotTrack` or `preDNAT` is -`true` because for a given policy, any untracked rules or rules before DNAT will -in practice apply to forwarded traffic. - -See [Policy for hosts](../../network-policy/hosts/index.mdx) -for how `doNotTrack` and `preDNAT` and `applyOnForward` can be useful for host endpoints. - -### Rule - - - -### ICMP - - - -### EntityRule - - - -### Selectors - - - - -### Ports - - - -### ServiceAccountMatch - - - -### ServiceMatch - - - -### Performance Hints - -Performance hints provide a way to tell $[prodname] about the intended use of the policy so that it may -process it more efficiently. Currently only one hint is defined: - -* `AssumeNeededOnEveryNode`: normally, $[prodname] only calculates a policy's rules and selectors on nodes where - the policy is actually in use (i.e. its selector matches a local endpoint). This saves work in most cases. - The `AssumeNeededOnEveryNode` hint tells $[prodname] to treat the policy as "in use" on *every* node. This is - useful for large policy sets that are known to apply to all (or nearly all) endpoints. It effectively "preloads" - the policy on every node so that there is less work to do when the first endpoint matching the policy shows up. - It also prevents work from being done to tear down the policy when the last endpoint is drained. - -## Application layer policy - -Application layer policy is an optional feature of $[prodname] and -[must be enabled](../../network-policy/istio/app-layer-policy.mdx) -to use the following match criteria. - -:::note - -Application layer policy match criteria are supported with the following restrictions. - -- Only ingress policy is supported. Egress policy must not contain any application layer policy match clauses. -- Rules must have the action `Allow` if they contain application layer policy match clauses. - -::: - -### HTTPMatch - - \ No newline at end of file diff --git a/calico_versioned_docs/version-3.29/reference/resources/globalnetworkset.mdx b/calico_versioned_docs/version-3.29/reference/resources/globalnetworkset.mdx deleted file mode 100644 index 3fe1b15546..0000000000 --- a/calico_versioned_docs/version-3.29/reference/resources/globalnetworkset.mdx +++ /dev/null @@ -1,55 +0,0 @@ ---- -description: API for this Calico resource. ---- - -# Global network set - -A global network set resource (GlobalNetworkSet) represents an arbitrary set of IP subnetworks/CIDRs, -allowing it to be matched by $[prodname] policy. Network sets are useful for applying policy to traffic -coming from (or going to) external, non-$[prodname], networks. - -The metadata for each network set includes a set of labels. When $[prodname] is calculating the set of -IPs that should match a source/destination selector within a -[global network policy](globalnetworkpolicy.mdx) rule, or within a -[network policy](networkpolicy.mdx) rule whose `namespaceSelector` includes `global()`, it includes -the CIDRs from any network sets that match the selector. - -:::note - -Since $[prodname] matches packets based on their source/destination IP addresses, -$[prodname] rules may not behave as expected if there is NAT between the $[prodname]-enabled node and the -networks listed in a network set. For example, in Kubernetes, incoming traffic via a service IP is -typically SNATed by the kube-proxy before reaching the destination host so $[prodname]'s workload -policy will see the kube-proxy's host's IP as the source instead of the real source. - -::: - -## Sample YAML - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkSet -metadata: - name: a-name-for-the-set - labels: - role: external-database -spec: - nets: - - 198.51.100.0/28 - - 203.0.113.0/24 -``` - -## Global network set definition - -### Metadata - -| Field | Description | Accepted Values | Schema | -| ------ | ------------------------------------------ | ------------------------------------------------- | ------ | -| name | The name of this network set. | Lower-case alphanumeric with optional `-` or `-`. | string | -| labels | A set of labels to apply to this endpoint. | | map | - -### Spec - -| Field | Description | Accepted Values | Schema | Default | -| ----- | -------------------------------------------- | ------------------------------------------------------ | ------ | ------- | -| nets | The IP networks/CIDRs to include in the set. | Valid IPv4 or IPv6 CIDRs, for example "192.0.2.128/25" | list | | diff --git a/calico_versioned_docs/version-3.29/reference/resources/hostendpoint.mdx b/calico_versioned_docs/version-3.29/reference/resources/hostendpoint.mdx deleted file mode 100644 index bb6140d698..0000000000 --- a/calico_versioned_docs/version-3.29/reference/resources/hostendpoint.mdx +++ /dev/null @@ -1,109 +0,0 @@ ---- -description: API for this Calico resource. ---- - -# Host endpoint - -import Endpointport from '@site/calico_versioned_docs/version-3.29/_includes/content/_endpointport.mdx'; - -A host endpoint resource (`HostEndpoint`) represents one or more real or virtual interfaces -attached to a host that is running $[prodname]. It enforces $[prodname] policy on -the traffic that is entering or leaving the host's default network namespace through those -interfaces. - -- A host endpoint with `interfaceName: *` represents _all_ of a host's real or virtual - interfaces. - -- A host endpoint for one specific real interface is configured by `interfaceName: `, - for example `interfaceName: eth0`, or by leaving `interfaceName` - empty and including one of the interface's IPs in `expectedIPs`. - -Each host endpoint may include a set of labels and list of profiles that $[prodname] -will use to apply -[policy](networkpolicy.mdx) -to the interface. - -**Default behavior of external traffic to/from host** - -If a host endpoint is created and network policy is not in place, the $[prodname] default is to deny traffic to/from that endpoint (except for traffic allowed by failsafe rules). -For a named host endpoint (i.e. a host endpoint representing a specific interface), $[prodname] blocks traffic only to/from the interface specified in the host endpoint. Traffic to/from other interfaces is ignored. - -:::note - -Host endpoints with `interfaceName: *` do not support [untracked policy](../../network-policy/extreme-traffic/high-connection-workloads.mdx). - -::: - -For a wildcard host endpoint (i.e. a host endpoint representing all of a host's interfaces), $[prodname] blocks traffic to/from _all_ interfaces on the host (except for traffic allowed by failsafe rules). - -However, profiles can be used in conjunction with host endpoints to modify default behavior of external traffic to/from the host in the absence of network policy. -$[prodname] provides a default profile resource named `projectcalico-default-allow` that consists of allow-all ingress and egress rules. -Host endpoints with the `projectcalico-default-allow` profile attached will have "allow-all" semantics instead of "deny-all" in the absence of policy. - -Note: If you have custom iptables rules, using host endpoints with allow-all rules (with no policies) will accept all traffic and therefore bypass those custom rules. - -:::note - -Auto host endpoints specify the `projectcalico-default-allow` profile so they behave similarly to pod workload endpoints. - -::: - -:::note - -When rendering security rules on other hosts, $[prodname] uses the -`expectedIPs` field to resolve label selectors to IP addresses. If the `expectedIPs` field -is omitted then security rules that use labels will fail to match this endpoint. - -::: - -**Host to local workload traffic**: Traffic from a host to its workload endpoints (e.g. Kubernetes pods) is always allowed, despite any policy in place. This ensures that `kubelet` liveness and readiness probes always work. - -## Sample YAML - -```yaml -apiVersion: projectcalico.org/v3 -kind: HostEndpoint -metadata: - name: some.name - labels: - type: production -spec: - interfaceName: eth0 - node: myhost - expectedIPs: - - 192.168.0.1 - - 192.168.0.2 - profiles: - - profile1 - - profile2 - ports: - - name: some-port - port: 1234 - protocol: TCP - - name: another-port - port: 5432 - protocol: UDP -``` - -## Host endpoint definition - -### Metadata - -| Field | Description | Accepted Values | Schema | -| ------ | ------------------------------------------ | --------------------------------------------------- | ------ | -| name | The name of this hostEndpoint. Required. | Alphanumeric string with optional `.`, `_`, or `-`. | string | -| labels | A set of labels to apply to this endpoint. | | map | - -### Spec - -| Field | Description | Accepted Values | Schema | Default | -| ------------- | -------------------------------------------------------------------------- | -------------------------- | -------------------------------------- | ------- | -| node | The name of the node where this HostEndpoint resides. | | string | -| interfaceName | Either `*` or the name of the specific interface on which to apply policy. | | string | -| expectedIPs | The expected IP addresses associated with the interface. | Valid IPv4 or IPv6 address | list | -| profiles | The list of profiles to apply to the endpoint. | | list | -| ports | List of named ports that this workload exposes. | | List of [EndpointPorts](#endpointport) | - -### EndpointPort - - \ No newline at end of file diff --git a/calico_versioned_docs/version-3.29/reference/resources/index.mdx b/calico_versioned_docs/version-3.29/reference/resources/index.mdx deleted file mode 100644 index 2285c6bf97..0000000000 --- a/calico_versioned_docs/version-3.29/reference/resources/index.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: APIs for all Calico networking and network policy resources. -hide_table_of_contents: true ---- - -# Resource definitions - -import DocCardList from '@theme/DocCardList'; -import { useCurrentSidebarCategory } from '@docusaurus/theme-common'; - - diff --git a/calico_versioned_docs/version-3.29/reference/resources/ipamconfig.mdx b/calico_versioned_docs/version-3.29/reference/resources/ipamconfig.mdx deleted file mode 100644 index e19e6cec69..0000000000 --- a/calico_versioned_docs/version-3.29/reference/resources/ipamconfig.mdx +++ /dev/null @@ -1,36 +0,0 @@ ---- -description: IP address management global configuration ---- - -# IPAM configuration - -An IPAM configuration resource (`IPAMConfiguration`) represents global IPAM configuration options. - -## Sample YAML - -```yaml -apiVersion: projectcalico.org/v3 -kind: IPAMConfiguration -metadata: - name: default -spec: - strictAffinity: false - maxBlocksPerHost: 4 -``` - -## IPAM configuration definition - -### Metadata - -| Field | Description | Accepted Values | Schema | -| ----- | --------------------------------------------------------- | --------------- | ------ | -| name | Unique name to describe this resource instance. Required. | default | string | - -The resource is a singleton which must have the name `default`. - -### Spec - -| Field | Description | Accepted Values | Schema | Default | -| ---------------- | ------------------------------------------------------------------- | --------------- | ------ | --------- | -| strictAffinity | When StrictAffinity is true, borrowing IP addresses is not allowed. | true, false | bool | false | -| maxBlocksPerHost | The max number of blocks that can be affine to each host. | 0 - max(int32) | int | 20 | \ No newline at end of file diff --git a/calico_versioned_docs/version-3.29/reference/resources/ippool.mdx b/calico_versioned_docs/version-3.29/reference/resources/ippool.mdx deleted file mode 100644 index 43f74a42cc..0000000000 --- a/calico_versioned_docs/version-3.29/reference/resources/ippool.mdx +++ /dev/null @@ -1,139 +0,0 @@ ---- -description: API for this Calico resource. ---- - -# IP pool - -import Selectors from '@site/calico_versioned_docs/version-3.29/_includes/content/_selectors.mdx'; - -An IP pool resource (`IPPool`) represents a collection of IP addresses from which $[prodname] expects -endpoint IPs to be assigned. - -## Sample YAML - -```yaml -apiVersion: projectcalico.org/v3 -kind: IPPool -metadata: - name: my.ippool-1 -spec: - cidr: 10.1.0.0/16 - ipipMode: CrossSubnet - natOutgoing: true - disabled: false - nodeSelector: all() - allowedUses: - - Workload - - Tunnel -``` - -## IP pool definition - -### Metadata - -| Field | Description | Accepted Values | Schema | -| ----- | ------------------------------------------- | --------------------------------------------------- | ------ | -| name | The name of this IPPool resource. Required. | Alphanumeric string with optional `.`, `_`, or `-`. | string | - -### Spec - -| Field | Description | Accepted Values | Schema | Default | -| ---------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------- | --------------------------------------------- | -| cidr | IP range to use for this pool. | A valid IPv4 or IPv6 CIDR. Subnet length must be at least big enough to fit a single block (by default `/26` for IPv4 or `/122` for IPv6). Must not overlap with the Link Local range `169.254.0.0/16` or `fe80::/10`. | string | | -| blockSize | The CIDR size of allocation blocks used by this pool. Blocks are allocated on demand to hosts and are used to aggregate routes. The value can only be set when the pool is created. | 20 to 32 (inclusive) for IPv4 and 116 to 128 (inclusive) for IPv6 | int | `26` for IPv4 pools and `122` for IPv6 pools. | -| ipipMode | The mode defining when IPIP will be used. Cannot be set at the same time as `vxlanMode`. | Always, CrossSubnet, Never | string | `Never` | -| vxlanMode | The mode defining when VXLAN will be used. Cannot be set at the same time as `ipipMode`. | Always, CrossSubnet, Never | string | `Never` | -| natOutgoing | When enabled, packets sent from $[prodname] networked containers in this pool to destinations outside of any Calico IP pools will be masqueraded. | true, false | boolean | `false` | -| disabled | When set to true, $[prodname] IPAM will not assign addresses from this pool. | true, false | boolean | `false` | -| disableBGPExport _(since v3.21.0)_ | Disable exporting routes from this IP Pool’s CIDR over BGP. | true, false | boolean | `false` | -| nodeSelector | Selects the nodes that $[prodname] IPAM should assign addresses from this pool to. | | [selector](#node-selector) | all() | -| allowedUses _(since v3.21.0)_ | Controls whether the pool will be used for automatic assignments of certain types. See [below](#allowed-uses). | Workload, Tunnel | list of strings | `["Workload", "Tunnel"]` | - -:::note - -Do not use a custom `blockSize` until **all** $[prodname] components have been updated to a version that -supports it (at least v3.3.0). Older versions of components do not understand the field so they may corrupt the -IP pool by creating blocks of incorrect size. - -::: - -### Allowed uses - -When automatically assigning IP addresses to workloads, only pools with "Workload" in their `allowedUses` field are -consulted. Similarly, when assigning IPs for tunnel devices, only "Tunnel" pools are eligible. - -If the `allowedUses` field is not specified, it defaults to `["Workload", "Tunnel"]` for compatibility with older -versions of Calico. It is not possible to specify a pool with no allowed uses. - -The `allowedUses` field is only consulted for new allocations, changing the field has no effect on previously allocated -addresses. - -$[prodname] supports Kubernetes [annotations that force the use of specific IP addresses](../configure-cni-plugins.mdx#requesting-a-specific-ip-address). These annotations take precedence over the `allowedUses` field. - -### IPIP - -Routing of packets using IP-in-IP will be used when the destination IP address -is in an IP Pool that has IPIP enabled. In addition, if the `ipipMode` is set to `CrossSubnet`, -$[prodname] will only route using IP-in-IP if the IP address of the destination node is in a different -subnet. The subnet of each node is configured on the node resource (which may be automatically -determined when running the `$[nodecontainer]` service). - -For details on configuring IP-in-IP on your deployment, please refer to -[Configuring IP-in-IP](../../networking/configuring/vxlan-ipip.mdx). - -:::note - -Setting `natOutgoing` is recommended on any IP Pool with `ipip` enabled. -When `ipip` is enabled without `natOutgoing` routing between Workloads and -Hosts running $[prodname] is asymmetric and may cause traffic to be filtered due to -[RPF](https://en.wikipedia.org/wiki/Reverse_path_forwarding) checks failing. - -::: - -### VXLAN - -Routing of packets using VXLAN will be used when the destination IP address -is in an IP Pool that has VXLAN enabled. In addition, if the `vxlanMode` is set to `CrossSubnet`, -$[prodname] will only route using VXLAN if the IP address of the destination node is in a different -subnet. The subnet of each node is configured on the node resource (which may be automatically -determined when running the `$[nodecontainer]` service). - -:::note - -Setting `natOutgoing` is recommended on any IP Pool with `vxlan` enabled. -When `vxlan` is enabled without `natOutgoing` routing between Workloads and -Hosts running $[prodname] is asymmetric and may cause traffic to be filtered due to -[RPF](https://en.wikipedia.org/wiki/Reverse_path_forwarding) checks failing. - -::: - -### Block sizes - -The default block sizes of `26` for IPv4 and `122` for IPv6 provide blocks of 64 addresses. This allows addresses to be allocated in groups to workloads running on the same host. By grouping addresses, fewer routes need to be exchanged between hosts and to other BGP peers. If a host allocates all of the addresses in a block then it will be allocated an additional block. If there are no more blocks available then the host can take addresses from blocks allocated to other hosts. Specific routes are added for the borrowed addresses which has an impact on route table size. - -Increasing the block size from the default (e.g., using `24` for IPv4 to give 256 addresses per block) means fewer blocks per host, and potentially fewer routes. But try to ensure that there are at least as many blocks in the pool as there are hosts. - -Reducing the block size from the default (e.g., using `28` for IPv4 to give 16 addresses per block) means more blocks per host and therefore potentially more routes. This can be beneficial if it allows the blocks to be more fairly distributed amongst the hosts. - -### Node Selector - -For details on configuring IP pool node selectors, please read the -[Assign IP addresses based on topology guide.](../../networking/ipam/assign-ip-addresses-topology.mdx). - -:::tip - -To prevent an IP pool from being used automatically by $[prodname] IPAM, while still allowing -it to be used manually for static assignments, set the `IPPool`'s `nodeSelector` to `!all()`. Since the selector -matches no nodes, the IPPool will not be used automatically and, unlike setting `disabled: true`, it can still be -used for manual assignments. - -::: - -#### Selector reference - - - -## See also - -The [`IPReservation` resource](ipreservation.mdx) allows for small parts of an IP pool to be reserved so that they will -not be used for automatic IPAM assignments. diff --git a/calico_versioned_docs/version-3.29/reference/resources/ipreservation.mdx b/calico_versioned_docs/version-3.29/reference/resources/ipreservation.mdx deleted file mode 100644 index c5893805ca..0000000000 --- a/calico_versioned_docs/version-3.29/reference/resources/ipreservation.mdx +++ /dev/null @@ -1,56 +0,0 @@ ---- -description: API for this Calico resource. ---- - -# IP reservation - -An IP reservation resource (`IPReservation`) represents a collection of IP addresses that $[prodname] should -not use when automatically assigning new IP addresses. It only applies when $[prodname] IPAM is in use. - -## Sample YAML - -```yaml -apiVersion: projectcalico.org/v3 -kind: IPReservation -metadata: - name: my-ipreservation-1 -spec: - reservedCIDRs: - - 192.168.2.3 - - 10.0.2.3/32 - - cafe:f00d::/123 -``` - -## IP reservation definition - -### Metadata - -| Field | Description | Accepted Values | Schema | -| ----- | -------------------------------------------------- | --------------------------------------------------- | ------ | -| name | The name of this IPReservation resource. Required. | Alphanumeric string with optional `.`, `_`, or `-`. | string | - -### Spec - -| Field | Description | Accepted Values | Schema | Default | -| ------------- | --------------------------------------------------------------- | -------------------------------------------------- | ------ | ------- | -| reservedCIDRs | List of IP addresses and/or networks specified in CIDR notation | List of valid IP addresses (v4 or v6) and/or CIDRs | list | | - -### Notes - -The implementation of `IPReservation`s is designed to handle reservation of a small number of IP addresses/CIDRs from -(generally much larger) IP pools. If a significant portion of an IP pool is reserved (say more than 10%) then -$[prodname] may become significantly slower when searching for free IPAM blocks. - -Since `IPReservations` must be consulted for every IPAM assignment request, it's best to have one or two -`IPReservation` resources with multiple addresses per `IPReservation` resource (rather than having many IPReservation -resources), each with one address inside. - -If an `IPReservation` is created after an IP from its range is already in use then the IP is not automatically -released back to the pool. The reservation check is only done at auto allocation time. - -$[prodname] supports Kubernetes [annotations that force the use of specific IP addresses](../configure-cni-plugins.mdx#requesting-a-specific-ip-address). These annotations override any `IPReservation`s that -are in place. - -When Windows nodes claim blocks of IPs they automatically assign the first three IPs -in each block and the final IP for internal purposes. These assignments cannot be blocked by an `IPReservation`. -However, if a whole IPAM block is reserved with an `IPReservation`, Windows nodes will not claim such a block. diff --git a/calico_versioned_docs/version-3.29/reference/resources/kubecontrollersconfig.mdx b/calico_versioned_docs/version-3.29/reference/resources/kubecontrollersconfig.mdx deleted file mode 100644 index a3ddcdd47f..0000000000 --- a/calico_versioned_docs/version-3.29/reference/resources/kubecontrollersconfig.mdx +++ /dev/null @@ -1,120 +0,0 @@ ---- -description: API for KubeControllersConfiguration resource. ---- - -# Kubernetes controllers configuration - -A $[prodname] [Kubernetes controllers](../kube-controllers/configuration.mdx) configuration resource (`KubeControllersConfiguration`) represents configuration options for the $[prodname] Kubernetes controllers. - -## Sample YAML - -```yaml -apiVersion: projectcalico.org/v3 -kind: KubeControllersConfiguration -metadata: - name: default -spec: - logSeverityScreen: Info - healthChecks: Enabled - etcdV3CompactionPeriod: 10m - prometheusMetricsPort: 9094 - controllers: - node: - reconcilerPeriod: 5m - leakGracePeriod: 15m - syncLabels: Enabled - hostEndpoint: - autoCreate: Disabled - policy: - reconcilerPeriod: 5m - workloadEndpoint: - reconcilerPeriod: 5m - serviceAccount: - reconcilerPeriod: 5m - namespace: - reconcilerPeriod: 5m -``` - -## Kubernetes controllers configuration definition - -### Metadata - -| Field | Description | Accepted Values | Schema | -| ----- | --------------------------------------------------------- | ----------------- | ------ | -| name | Unique name to describe this resource instance. Required. | Must be `default` | string | - -- $[prodname] automatically creates a resource named `default` containing the configuration settings, only the name `default` is used and only one object of this type is allowed. You can use [calicoctl](../calicoctl/overview.mdx) to view and edit these settings - -### Spec - -| Field | Description | Accepted Values | Schema | Default | -| ---------------------- | ---------------------------------------------------------------------------------------------------------- | ----------------------------------- | --------------------------------- | ------- | -| logSeverityScreen | The log severity above which logs are sent to the stdout. | Debug, Info, Warning, Error, Fatal | string | Info | -| healthChecks | Enable support for health checks | Enabled, Disabled | string | Enabled | -| prometheusMetricsPort | Port on which to serve prometheus metrics. | Set to 0 to disable, > 0 to enable. | TCP port | 9094 | -| etcdV3CompactionPeriod | The period between etcdv3 compaction requests. Only applies when using etcd as the $[prodname] datastore. | Set to 0 to disable, > 0 to enable | [Duration string][parse-duration] | 10m | -| controllers | Enabled controllers and their settings | | [Controllers](#controllers) | | - -### Controllers - -| Field | Description | Schema | -| ---------------- | ----------------------------------------------------- | ----------------------------------------------------------------------------- | -| node | Enable and configure the node controller | omit to disable, or [NodeController](#nodecontroller) | -| policy | Enable and configure the network policy controller | omit to disable, or [PolicyController](#policycontroller) | -| workloadEndpoint | Enable and configure the workload endpoint controller | omit to disable, or [WorkloadEndpointController](#workloadendpointcontroller) | -| serviceAccount | Enable and configure the service account controller | omit to disable, or [ServiceAccountController](#serviceaccountcontroller) | -| namespace | Enable and configure the namespace controller | omit to disable, or [NamespaceController](#namespacecontroller) | - -### NodeController - -The node controller automatically cleans up configuration for nodes that no longer exist. Optionally, it can create host endpoints for all Kubernetes nodes. - -| Field | Description | Accepted Values | Schema | Default | -| ---------------- | --------------------------------------------------------------------------------- | ----------------- | --------------------------------- | ------- | -| reconcilerPeriod | Period to perform reconciliation with the $[prodname] datastore | | [Duration string][parse-duration] | 5m | -| syncLabels | When enabled, Kubernetes node labels will be copied to $[prodname] node objects. | Enabled, Disabled | string | Enabled | -| hostEndpoint | Controls allocation of host endpoints | | [HostEndpoint](#hostendpoint) | | -| leakGracePeriod | Grace period to use when garbage collecting suspected leaked IP addresses. | | [Duration string][parse-duration] | 15m | - -### HostEndpoint - -| Field | Description | Accepted Values | Schema | Default | -| ---------- | ---------------------------------------------------------------- | ----------------- | ------ | -------- | -| autoCreate | When enabled, automatically create a host endpoint for each node | Enabled, Disabled | string | Disabled | - -### PolicyController - -The policy controller syncs Kubernetes network policies to the Calico datastore. This controller is only valid when using etcd as the $[prodname] datastore. - -| Field | Description | Schema | Default | -| ---------------- | ---------------------------------------------------------------- | --------------------------------- | ------- | -| reconcilerPeriod | Period to perform reconciliation with the $[prodname] datastore | [Duration string][parse-duration] | 5m | - -### WorkloadEndpointController - -The workload endpoint controller automatically syncs Kubernetes pod label changes to the $[prodname] datastore by updating the corresponding workload -endpoints appropriately. This controller is only valid when using etcd as the $[prodname] datastore. - -| Field | Description | Schema | Default | -| ---------------- | ---------------------------------------------------------------- | --------------------------------- | ------- | -| reconcilerPeriod | Period to perform reconciliation with the $[prodname] datastore | [Duration string][parse-duration] | 5m | - -### ServiceAccountController - -The service account controller syncs Kubernetes service account changes to the $[prodname] datastore. This controller is only valid when using etcd as -the $[prodname] datastore. - -| Field | Description | Schema | Default | -| ---------------- | ---------------------------------------------------------------- | --------------------------------- | ------- | -| reconcilerPeriod | Period to perform reconciliation with the $[prodname] datastore | [Duration string][parse-duration] | 5m | - -### NamespaceController - -The namespace controller syncs Kubernetes namespace label changes to the $[prodname] datastore. This controller is only valid when using etcd as the -$[prodname] datastore. - -| Field | Description | Schema | Default | -| ---------------- | ---------------------------------------------------------------- | --------------------------------- | ------- | -| reconcilerPeriod | Period to perform reconciliation with the $[prodname] datastore | [Duration string][parse-duration] | 5m | - -[parse-duration]: https://golang.org/pkg/time/#ParseDuration diff --git a/calico_versioned_docs/version-3.29/reference/resources/networkpolicy.mdx b/calico_versioned_docs/version-3.29/reference/resources/networkpolicy.mdx deleted file mode 100644 index a85fcf99fa..0000000000 --- a/calico_versioned_docs/version-3.29/reference/resources/networkpolicy.mdx +++ /dev/null @@ -1,157 +0,0 @@ ---- -description: API for this Calico resource. ---- - -# Network policy - -import Httpmatch from '@site/calico_versioned_docs/version-3.29/_includes/content/_httpmatch.mdx'; - -import Servicematch from '@site/calico_versioned_docs/version-3.29/_includes/content/_servicematch.mdx'; - -import Serviceaccountmatch from '@site/calico_versioned_docs/version-3.29/_includes/content/_serviceaccountmatch.mdx'; - -import Ports from '@site/calico_versioned_docs/version-3.29/_includes/content/_ports.mdx'; - -import SelectorScopes from '@site/calico_versioned_docs/version-3.29/_includes/content/_selector-scopes.mdx'; - -import Selectors from '@site/calico_versioned_docs/version-3.29/_includes/content/_selectors.mdx'; - -import Entityrule from '@site/calico_versioned_docs/version-3.29/_includes/content/_entityrule.mdx'; - -import Icmp from '@site/calico_versioned_docs/version-3.29/_includes/content/_icmp.mdx'; - -import Rule from '@site/calico_versioned_docs/version-3.29/_includes/content/_rule.mdx'; - -A network policy resource (`NetworkPolicy`) represents an ordered set of rules which are applied -to a collection of endpoints that match a [label selector](#selectors). - -`NetworkPolicy` is a namespaced resource. `NetworkPolicy` in a specific namespace -only applies to [workload endpoint resources](workloadendpoint.mdx) -in that namespace. Two resources are in the same namespace if the `namespace` -value is set the same on both. -See [global network policy resource](globalnetworkpolicy.mdx) for non-namespaced network policy. - -`NetworkPolicy` resources can be used to define network connectivity rules between groups of $[prodname] endpoints and host endpoints, and -take precedence over [profile resources](profile.mdx) if any are defined. - -## Sample YAML - -This sample policy allows TCP traffic from `frontend` endpoints to port 6379 on -`database` endpoints. - -```yaml -apiVersion: projectcalico.org/v3 -kind: NetworkPolicy -metadata: - name: allow-tcp-6379 - namespace: production -spec: - selector: role == 'database' - types: - - Ingress - - Egress - ingress: - - action: Allow - metadata: - annotations: - from: frontend - to: database - protocol: TCP - source: - selector: role == 'frontend' - destination: - ports: - - 6379 - egress: - - action: Allow -``` - -## Definition - -### Metadata - -| Field | Description | Accepted Values | Schema | Default | -| --------- | ------------------------------------------------------------------ | --------------------------------------------------- | ------ | --------- | -| name | The name of the network policy. Required. | Alphanumeric string with optional `.`, `_`, or `-`. | string | | -| namespace | Namespace provides an additional qualification to a resource name. | | string | "default" | - -### Spec - -| Field | Description | Accepted Values | Schema | Default | -| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------- | ---------------------- | --------------------------------------------- | -| order | Controls the order of precedence. $[prodname] applies the policy with the lowest value first. | | float | | -| selector | Selects the endpoints to which this policy applies. | | [selector](#selectors) | all() | -| types | Applies the policy based on the direction of the traffic. To apply the policy to inbound traffic, set to `Ingress`. To apply the policy to outbound traffic, set to `Egress`. To apply the policy to both, set to `Ingress, Egress`. | `Ingress`, `Egress` | List of strings | Depends on presence of ingress/egress rules\* | -| ingress | Ordered list of ingress rules applied by policy. | | List of [Rule](#rule) | | -| egress | Ordered list of egress rules applied by this policy. | | List of [Rule](#rule) | | -| serviceAccountSelector | Selects the service account(s) to which this policy applies. Select a specific service account by name using the `projectcalico.org/name` label. | | [selector](#selectors) | all() | -| performanceHints | Contains a list of hints to Calico's policy engine to help process the policy more efficiently. Hints never change the enforcement behaviour of the policy. The available hints are described [below](#performance-hints). | `AssumeNeededOnEveryNode` | List of strings | | - -\* If `types` has no value, $[prodname] defaults as follows. - -> | Ingress Rules Present | Egress Rules Present | `Types` value | -> | --------------------- | -------------------- | ----------------- | -> | No | No | `Ingress` | -> | Yes | No | `Ingress` | -> | No | Yes | `Egress` | -> | Yes | Yes | `Ingress, Egress` | - -### Rule - - - -### ICMP - - - -### EntityRule - - - -### Selectors - - - - -### Ports - - - -### ServiceAccountMatch - - - -### ServiceMatch - - - -### Performance Hints - -Performance hints provide a way to tell $[prodname] about the intended use of the policy so that it may -process it more efficiently. Currently only one hint is defined: - -* `AssumeNeededOnEveryNode`: normally, $[prodname] only calculates a policy's rules and selectors on nodes where - the policy is actually in use (i.e. its selector matches a local endpoint). This saves work in most cases. - The `AssumeNeededOnEveryNode` hint tells $[prodname] to treat the policy as "in use" on *every* node. This is - useful for large policy sets that are known to apply to all (or nearly all) endpoints. It effectively "preloads" - the policy on every node so that there is less work to do when the first endpoint matching the policy shows up. - It also prevents work from being done to tear down the policy when the last endpoint is drained. - -## Application layer policy - -Application layer policy is an optional feature of $[prodname] and -[must be enabled](../../network-policy/istio/app-layer-policy.mdx) -to use the following match criteria. - -:::note - -Application layer policy match criteria are supported with the following restrictions. - -- Only ingress policy is supported. Egress policy must not contain any application layer policy match clauses. -- Rules must have the action `Allow` if they contain application layer policy match clauses. - -::: - -### HTTPMatch - - \ No newline at end of file diff --git a/calico_versioned_docs/version-3.29/reference/resources/networkset.mdx b/calico_versioned_docs/version-3.29/reference/resources/networkset.mdx deleted file mode 100644 index cfdcb3b97b..0000000000 --- a/calico_versioned_docs/version-3.29/reference/resources/networkset.mdx +++ /dev/null @@ -1,63 +0,0 @@ ---- -description: API for this Calico resource. ---- - -# Network set - -A network set resource (NetworkSet) represents an arbitrary set of IP subnetworks/CIDRs, -allowing it to be matched by $[prodname] policy. Network sets are useful for applying policy to traffic -coming from (or going to) external, non-$[prodname], networks. - -`NetworkSet` is a namespaced resource. `NetworkSets` in a specific namespace -only applies to [network policies](networkpolicy.mdx) -in that namespace. Two resources are in the same namespace if the `namespace` -value is set the same on both. (See [GlobalNetworkSet](globalnetworkset.mdx) for non-namespaced network sets.) - -The metadata for each network set includes a set of labels. When $[prodname] is calculating the set of -IPs that should match a source/destination selector within a -[network policy](networkpolicy.mdx) rule, it includes -the CIDRs from any network sets that match the selector. - -:::note - -Since $[prodname] matches packets based on their source/destination IP addresses, -$[prodname] rules may not behave as expected if there is NAT between the $[prodname]-enabled node and the -networks listed in a network set. For example, in Kubernetes, incoming traffic via a service IP is -typically SNATed by the kube-proxy before reaching the destination host so $[prodname]'s workload -policy will see the kube-proxy's host's IP as the source instead of the real source. -For `calicoctl` commands that specify a resource type on the CLI, the following -aliases are supported (all case-insensitive): `networkset`, `networksets`, `netsets`. - -::: - -## Sample YAML - -```yaml -apiVersion: projectcalico.org/v3 -kind: NetworkSet -metadata: - name: external-database - namespace: staging - labels: - role: db -spec: - nets: - - 198.51.100.0/28 - - 203.0.113.0/24 -``` - -## Network set definition - -### Metadata - -| Field | Description | Accepted Values | Schema | Default | -| --------- | ------------------------------------------------------------------ | ------------------------------------------------- | ------ | --------- | -| name | The name of this network set. Required. | Lower-case alphanumeric with optional `_` or `-`. | string | | -| namespace | Namespace provides an additional qualification to a resource name. | | string | "default" | -| labels | A set of labels to apply to this endpoint. | | map | | - -### Spec - -| Field | Description | Accepted Values | Schema | Default | -| ----- | -------------------------------------------- | ------------------------------------------------------ | ------ | ------- | -| nets | The IP networks/CIDRs to include in the set. | Valid IPv4 or IPv6 CIDRs, for example "192.0.2.128/25" | list | | diff --git a/calico_versioned_docs/version-3.29/reference/resources/node.mdx b/calico_versioned_docs/version-3.29/reference/resources/node.mdx deleted file mode 100644 index 8b41cce574..0000000000 --- a/calico_versioned_docs/version-3.29/reference/resources/node.mdx +++ /dev/null @@ -1,74 +0,0 @@ ---- -description: API for this Calico resource. ---- - -# Node - -A node resource (`Node`) represents a node running $[prodname]. When adding a host -to a $[prodname] cluster, a node resource needs to be created which contains the -configuration for the `$[nodecontainer]` instance running on the host. - -When starting a `$[nodecontainer]` instance, the name supplied to the instance should -match the name configured in the Node resource. - -By default, starting a `$[nodecontainer]` instance will automatically create a node resource -using the `hostname` of the compute host. - -## Sample YAML - -```yaml -apiVersion: projectcalico.org/v3 -kind: Node -metadata: - name: node-hostname -spec: - bgp: - asNumber: 64512 - ipv4Address: 10.244.0.1/24 - ipv6Address: 2001:db8:85a3::8a2e:370:7334/120 - ipv4IPIPTunnelAddr: 192.168.0.1 -``` - -## Definition - -### Metadata - -| Field | Description | Accepted Values | Schema | -| ----- | -------------------------------- | --------------------------------------------------- | ------ | -| name | The name of this node. Required. | Alphanumeric string with optional `.`, `_`, or `-`. | string | - -### Spec - -| Field | Description | Accepted Values | Schema | Default | -| -------------------- | --------------------------------------------------------------------------------------------------------------------------------- | --------------- | ---------------------------- | ------- | -| bgp | BGP configuration for this node. Omit if using $[prodname] for policy only. | | [BGP](#bgp) | -| ipv4VXLANTunnelAddr | IPv4 address of the VXLAN tunnel. This is system configured and should not be updated manually. | | string | -| vxlanTunnelMACAddr | MAC address of the IPv4 VXLAN tunnel. This is system configured and should not be updated manually. | | string | -| ipv6VXLANTunnelAddr | IPv6 address of the VXLAN tunnel. This is system configured and should not be updated manually. | | string | -| vxlanTunnelMACAddrV6 | MAC address of the IPv6 VXLAN tunnel. This is system configured and should not be updated manually. | | string | -| orchRefs | Correlates this node to a node in another orchestrator. | | list of [OrchRefs](#orchref) | -| wireguard | WireGuard configuration for this node. This is applicable only if WireGuard is enabled in [Felix Configuration](felixconfig.mdx). | | [WireGuard](#wireguard) | - -### OrchRef - -| Field | Description | Accepted Values | Schema | Default | -| ------------ | ------------------------------------------------ | --------------- | ------ | ------- | -| nodeName | Name of this node according to the orchestrator. | | string | -| orchestrator | Name of the orchestrator. | k8s | string | - -### BGP - -| Field | Description | Accepted Values | Schema | Default | -| ----------------------- | -------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- | ------- | -| asNumber | The AS Number of your `$[nodecontainer]`. | Optional. If omitted the global value is used (see [example modifying Global BGP settings](../../networking/configuring/bgp.mdx) for details about modifying the `asNumber` setting). | integer | -| ipv4Address | The IPv4 address and subnet exported as the next-hop for the $[prodname] endpoints on the host | The IPv4 address must be specified if BGP is enabled. | string | -| ipv6Address | The IPv6 address and subnet exported as the next-hop for the $[prodname] endpoints on the host | Optional | string | -| ipv4IPIPTunnelAddr | IPv4 address of the IP-in-IP tunnel. This is system configured and should not be updated manually. | Optional IPv4 address | string | -| routeReflectorClusterID | Enables this node as a route reflector within the given cluster | Optional IPv4 address | string | - -### WireGuard - -| Field | Description | Accepted Values | Schema | Default | -| -------------------- | ----------------------------------------------------------------------------------------- | --------------- | ------ | ------- | -| interfaceIPv4Address | The IP address and subnet for the IPv4 WireGuard interface created by Felix on this node. | Optional | string | -| interfaceIPv6Address | The IP address and subnet for the IPv6 WireGuard interface created by Felix on this node. | Optional | string | \ No newline at end of file diff --git a/calico_versioned_docs/version-3.29/reference/resources/overview.mdx b/calico_versioned_docs/version-3.29/reference/resources/overview.mdx deleted file mode 100644 index 1ec057d3ad..0000000000 --- a/calico_versioned_docs/version-3.29/reference/resources/overview.mdx +++ /dev/null @@ -1,101 +0,0 @@ ---- -description: Calico resources (APIs) that you can manage using calicoctl. ---- - -# Resource definitions - -This section describes the set of valid resource types that can be managed -through `calicoctl` or `kubectl`. - -While resources may be supplied in YAML or JSON format, this guide provides examples in YAML. - -## Overview of resource structure - -The calicoctl commands for resource management (create, apply, delete, replace, get) -all take resource manifests as input. - -Each manifest may contain a single resource -(e.g. a profile resource), or a list of multiple resources (e.g. a profile and two -hostEndpoint resources). - -The general structure of a single resource is as follows: - -```yaml noValidation -apiVersion: projectcalico.org/v3 -kind: -metadata: - # Identifying information - name: - ... -spec: - # Specification of the resource - ... -``` - -### Schema - -| Field | Description | Accepted Values | Schema | -| ---------- | --------------------------------------------------------------------------------------- | -------------------- | ------------------------ | -| apiVersion | Indicates the version of the API that the data corresponds to. | projectcalico.org/v3 | string | -| kind | Specifies the type of resource described by the YAML document. | | [kind](#supported-kinds) | -| metadata | Contains information used to uniquely identify the particular instance of the resource. | | map | -| spec | Contains the resource specification. | | map | - -### Supported kinds - -The following resources are supported: - -- [BGPConfiguration](bgpconfig.mdx) -- [BGPPeer](bgppeer.mdx) -- [FelixConfiguration](felixconfig.mdx) -- [GlobalNetworkPolicy](globalnetworkpolicy.mdx) -- [GlobalNetworkSet](globalnetworkset.mdx) -- [HostEndpoint](hostendpoint.mdx) -- [IPPool](ippool.mdx) -- [NetworkPolicy](networkpolicy.mdx) -- [NetworkSet](networkset.mdx) -- [Node](node.mdx) -- [Profile](profile.mdx) -- [WorkloadEndpoint](workloadendpoint.mdx) - -### Resource name requirements - -Every resource must have the `name` field specified. Name must be unique within a namespace. -Name required when creating resources, and cannot be updated. -A valid resource name can have alphanumeric characters with optional `.`, `_`, or `-`. of up to 128 characters total. - -### Multiple resources in a single file - -A file may contain multiple resource documents specified in a YAML list format. For example, the following is the contents of a file containing two `HostEndpoint` resources: - -```yaml -- apiVersion: projectcalico.org/v3 - kind: HostEndpoint - metadata: - name: endpoint1 - labels: - type: database - spec: - interface: eth0 - node: host1 - profiles: - - prof1 - - prof2 - expectedIPs: - - 1.2.3.4 - - '00:bb::aa' -- apiVersion: projectcalico.org/v3 - kind: HostEndpoint - metadata: - name: endpoint2 - labels: - type: frontend - spec: - interface: eth1 - node: host1 - profiles: - - prof1 - - prof2 - expectedIPs: - - 1.2.3.5 -``` diff --git a/calico_versioned_docs/version-3.29/reference/resources/profile.mdx b/calico_versioned_docs/version-3.29/reference/resources/profile.mdx deleted file mode 100644 index 59ad46b8ca..0000000000 --- a/calico_versioned_docs/version-3.29/reference/resources/profile.mdx +++ /dev/null @@ -1,46 +0,0 @@ ---- -description: API for this Calico resource. ---- - -# Profile - -Profiles provide a way to group multiple endpoints so that they inherit a shared set of labels. For historic reasons, Profiles can also include -policy rules, but that feature is deprecated in favor of the much more -flexible [NetworkPolicy](networkpolicy.mdx) and -[GlobalNetworkPolicy](globalnetworkpolicy.mdx) resources. - -Each $[prodname] endpoint or host endpoint can be assigned to zero or more profiles. - -## Sample YAML - -The following sample profile applies the label `stage: development` to any endpoint that includes `dev-apps` in its list of profiles. - -```yaml -apiVersion: projectcalico.org/v3 -kind: Profile -metadata: - name: dev-apps -spec: - labelsToApply: - stage: development -``` - -## Definition - -### Metadata - -| Field | Description | Accepted Values | Schema | Default | -| ------ | ---------------------------------- | --------------------------------------------------- | ---------------------------------- | ------- | -| name | The name of the profile. Required. | Alphanumeric string with optional `.`, `_`, or `-`. | string | -| labels | A set of labels for this profile. | | map of string key to string values | - -### Spec - -| Field | Description | Accepted Values | Schema | Default | -| -------------------- | -------------------------------------------------------------------------------------------------------------- | --------------- | -------------------------------------- | ------- | -| ingress (deprecated) | The ingress rules belonging to this profile. | | List of [Rule](networkpolicy.mdx#rule) | -| egress (deprecated) | The egress rules belonging to this profile. | | List of [Rule](networkpolicy.mdx#rule) | -| labelsToApply | An optional set of labels to apply to each endpoint in this profile (in addition to the endpoint's own labels) | | map | - -For `Rule` details please see the [NetworkPolicy](networkpolicy.mdx) or -[GlobalNetworkPolicy](globalnetworkpolicy.mdx) resource. \ No newline at end of file diff --git a/calico_versioned_docs/version-3.29/reference/resources/tier.mdx b/calico_versioned_docs/version-3.29/reference/resources/tier.mdx deleted file mode 100644 index 546dc23f94..0000000000 --- a/calico_versioned_docs/version-3.29/reference/resources/tier.mdx +++ /dev/null @@ -1,62 +0,0 @@ ---- -description: API for this Calico resource. ---- - -# Tier - -A tier resource (`Tier`) represents an ordered collection of [NetworkPolicies](networkpolicy.mdx) -and/or [GlobalNetworkPolicies](globalnetworkpolicy.mdx). -Tiers are used to divide these policies into groups of different priorities. These policies -are ordered within a Tier: the additional hierarchy of Tiers provides more flexibility -because the `Pass` `action` in a Rule jumps to the next Tier. Some example use cases for this are. - -- Allowing privileged users to define security policy that takes precedence over other users. -- Translating hierarchies of physical firewalls directly into $[prodname] policy. - -For `kubectl` [commands](https://kubernetes.io/docs/reference/kubectl/overview/), the following case-insensitive aliases -may be used to specify the resource type on the CLI: -`tier.projectcalico.org`, `tiers.projectcalico.org` and abbreviations such as -`tier.p` and `tiers.p`. - -## How policy is evaluated - -When a new connection is processed by $[prodname], each tier that contains a policy that applies to the endpoint processes the packet. -Tiers are sorted by their `order` - smallest number first. - -Policies in each Tier are then processed in order. - -- If a [NetworkPolicy](networkpolicy.mdx) or [GlobalNetworkPolicy](globalnetworkpolicy.mdx) in the Tier `Allow`s or `Deny`s the packet, then evaluation is done: the packet is handled accordingly. -- If a [NetworkPolicy](networkpolicy.mdx) or [GlobalNetworkPolicy](globalnetworkpolicy.mdx) in the Tier `Pass`es the packet, the next Tier containing a Policy that applies to the endpoint processes the packet. - -If the Tier applies to the endpoint, but takes no action on the packet the packet is dropped. This behaviour can be changed by setting the `defaultAction` of a tier to `Pass`. - -If the last Tier applying to the endpoint `Pass`es the packet, that endpoint's [Profiles](profile.mdx) are evaluated. - -## Sample YAML - -```yaml -apiVersion: projectcalico.org/v3 -kind: Tier -metadata: - name: internal-access -spec: - order: 100 - defaultAction: Deny -``` - -## Definition - -### Metadata - -| Field | Description | Accepted Values | Schema | -| ----- | --------------------- | --------------- | ------ | -| name | The name of the tier. | | string | - -### Spec - -| Field | Description | Accepted Values | Schema | Default | -| ------------- | ------------------------------------------------------------------------------------------------------------------------------------ | --------------- | ------ | --------------------- | -| order | (Optional) Indicates priority of this Tier, with lower order taking precedence. No value indicates highest order (lowest precedence) | | float | `nil` (highest order) | -| defaultAction | (Optional) Indicates the default action, when this Tier applies to an endpoint, but takes no action on the packet | `Deny`, `Pass` | string | `Deny` | - -All Policies created by $[prodname] orchestrator integrations are created in the default (last) Tier. diff --git a/calico_versioned_docs/version-3.29/reference/resources/workloadendpoint.mdx b/calico_versioned_docs/version-3.29/reference/resources/workloadendpoint.mdx deleted file mode 100644 index d494e893bc..0000000000 --- a/calico_versioned_docs/version-3.29/reference/resources/workloadendpoint.mdx +++ /dev/null @@ -1,123 +0,0 @@ ---- -description: API for this Calico resource. ---- - -# Workload endpoint - -import Ipnat from '@site/calico_versioned_docs/version-3.29/_includes/content/_ipnat.mdx'; - -A workload endpoint resource (`WorkloadEndpoint`) represents an interface -connecting a $[prodname] networked container or VM to its host. - -Each endpoint may specify a set of labels and list of profiles that $[prodname] will use -to apply policy to the interface. - -A workload endpoint is a namespaced resource, that means a -[NetworkPolicy](networkpolicy.mdx) -in a specific namespace only applies to the WorkloadEndpoint in that namespace. -Two resources are in the same namespace if the namespace value is set the same -on both. - -:::note - -While `calicoctl` allows the user to fully manage Workload Endpoint resources, -the lifecycle of these resources is generally handled by an orchestrator-specific -plugin such as the $[prodname] CNI plugin, the $[prodname] Docker network plugin, -or the $[prodname] OpenStack Neutron Driver. In general, we recommend that you only -use `calicoctl` to view this resource type. - -::: - -## Sample YAML - -```yaml -apiVersion: projectcalico.org/v3 -kind: WorkloadEndpoint -metadata: - name: node1-k8s-my--nginx--b1337a-eth0 - namespace: default - labels: - app: frontend - projectcalico.org/namespace: default - projectcalico.org/orchestrator: k8s -spec: - node: node1 - orchestrator: k8s - endpoint: eth0 - containerID: 1337495556942031415926535 - pod: my-nginx-b1337a - endpoint: eth0 - interfaceName: cali0ef24ba - mac: ca:fe:1d:52:bb:e9 - ipNetworks: - - 192.168.0.0/32 - profiles: - - profile1 - ports: - - name: some-port - port: 1234 - protocol: TCP - - name: another-port - port: 5432 - protocol: UDP -``` - -## Definitions - -### Metadata - -| Field | Description | Accepted Values | Schema | Default | -| --------- | ------------------------------------------------------------------ | -------------------------------------------------- | ------ | --------- | -| name | The name of this workload endpoint resource. Required. | Alphanumeric string with optional `.`, `_`, or `-` | string | | -| namespace | Namespace provides an additional qualification to a resource name. | | string | "default" | -| labels | A set of labels to apply to this endpoint. | | map | | - -### Spec - -| Field | Description | Accepted Values | Schema | Default | -| ------------- | ------------------------------------------------------------- | --------------- | ---------------------------------------------- | ------- | -| workload | The name of the workload to which this endpoint belongs. | | string | -| orchestrator | The orchestrator that created this endpoint. | | string | -| node | The node where this endpoint resides. | | string | -| containerID | The CNI CONTAINER_ID of the workload endpoint. | | string | -| pod | Kubernetes pod name for this workload endpoint. | | string | -| endpoint | Container network interface name. | | string | -| ipNetworks | The CIDRs assigned to the interface. | | List of strings | -| ipNATs | List of 1:1 NAT mappings to apply to the endpoint. | | List of [IPNATs](#ipnat) | -| ipv4Gateway | The gateway IPv4 address for traffic from the workload. | | string | -| ipv6Gateway | The gateway IPv6 address for traffic from the workload. | | string | -| profiles | List of profiles assigned to this endpoint. | | List of strings | -| interfaceName | The name of the host-side interface attached to the workload. | | string | -| mac | The source MAC address of traffic generated by the workload. | | IEEE 802 MAC-48, EUI-48, or EUI-64 | -| ports | List on named ports that this workload exposes. | | List of [WorkloadEndpointPorts](#endpointport) | - -### IPNAT - - - -### EndpointPort - -A WorkloadEndpointPort associates a name with a particular TCP/UDP/SCTP port of the endpoint, allowing it to -be referenced as a named port in [policy rules](networkpolicy.mdx#entityrule). - -| Field | Description | Accepted Values | Schema | Default | -| -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------- | ------ | ------- | -| name | The name to attach to this port, allowing it to be referred to in [policy rules](networkpolicy.mdx#entityrule). Names must be unique within an endpoint. | | string | | -| protocol | The protocol of this named port. | `TCP`, `UDP`, `SCTP` | string | | -| port | The workload port number. | `1`-`65535` | int | | -| hostPort | Port on the host that is forwarded to this port. | `1`-`65535` | int | | -| hostIP | IP address on the host on which the hostPort is accessible. | `1`-`65535` | int | | - -:::note - -On their own, WorkloadEndpointPort entries don't result in any change to the connectivity of the port. -They only have an effect if they are referred to in policy. - -::: - -:::note - -The hostPort and hostIP fields are read-only and determined from Kubernetes hostPort configuration. -These fields are used only when host ports are enabled in Calico. - -::: \ No newline at end of file diff --git a/calico_versioned_docs/version-3.29/reference/rest-api-reference.mdx b/calico_versioned_docs/version-3.29/reference/rest-api-reference.mdx deleted file mode 100644 index 13b5395dee..0000000000 --- a/calico_versioned_docs/version-3.29/reference/rest-api-reference.mdx +++ /dev/null @@ -1,15 +0,0 @@ ---- -description: REST API reference ---- - -# REST API Reference - -import SwaggerUI from 'swagger-ui-react'; - - - - diff --git a/calico_versioned_docs/version-3.29/reference/typha/configuration.mdx b/calico_versioned_docs/version-3.29/reference/typha/configuration.mdx deleted file mode 100644 index ce7dbf8290..0000000000 --- a/calico_versioned_docs/version-3.29/reference/typha/configuration.mdx +++ /dev/null @@ -1,100 +0,0 @@ ---- -description: Configure Typha for scaling Kubernetes API datastore (kdd). ---- - -# Configuring Typha - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - - - - -Typha configuration cannot be modified when Calico is installed via the operator. - - - - -Configuration for Typha is read from one of two possible locations, in -order, as follows. - -1. Environment variables, prefixed with `TYPHA_`. - -2. The Typha configuration file. The path to this file defaults to - `/etc/calico/typha.cfg` but can be overridden using the `-c` or - `--config-file` options on the command line. - -The value of any configuration parameter is the value read from the -_first_ location containing a value. For example, if an environment variable -contains a value, it takes precedence. - -If not set in any of these locations, most configuration parameters have -defaults, and it should be rare to have to explicitly set them. - -The full list of parameters which can be set is as follows. - -### General configuration - -| Configuration parameter | Environment variable | Description | Schema | -| --------------------------------------- | --------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------- | -| `DatastoreType` | `TYPHA_DATASTORETYPE` | The datastore that Typha should read endpoints and policy information from. [Default: `etcdv3`] | `etcdv3`, `kubernetes` | -| `HealthEnabled` | `TYPHA_HEALTHENABLED` | When enabled, exposes Typha health information via an http endpoint. | boolean | -| `HealthPort` | `TYPHA_HEALTHPORT` | The port that Typha will serve health information over. [Default: `9098`] | int | -| `HealthHost` | `TYPHA_HEALTHHOST` | The address that Typha will bind its health endpoint to. [Default: `localhost`] | string | -| `LogFilePath` | `TYPHA_LOGFILEPATH` | The full path to the Typha log. Set to `none` to disable file logging. [Default: `/var/log/calico/typha.log`] | string | -| `LogSeverityFile` | `TYPHA_LOGSEVERITYFILE` | The log severity above which logs are sent to the log file. [Default: `Info`] | `Debug`, `Info`, `Warning`, `Error`, `Fatal` | -| `LogSeverityScreen` | `TYPHA_LOGSEVERITYSCREEN` | The log severity above which logs are sent to the stdout. [Default: `Info`] | `Debug`, `Info`, `Warning`, `Error`, `Fatal` | -| `LogSeveritySys` | `TYPHA_LOGSEVERITYSYS` | The log severity above which logs are sent to the syslog. Set to `""` for no logging to syslog. [Default: `Info`] | `Debug`, `Info`, `Warning`, `Error`, `Fatal` | -| `PrometheusGoMetricsEnabled` | `TYPHA_PROMETHEUSGOMETRICSENABLED` | Set to `false` to disable Go runtime metrics collection, which the Prometheus client does by default. This reduces the number of metrics reported, reducing Prometheus load. [Default: `true`] | boolean | -| `PrometheusMetricsEnabled` | `TYPHA_PROMETHEUSMETRICSENABLED` | Set to `true` to enable the Prometheus metrics server in Typha. [Default: `false`] | boolean | -| `PrometheusMetricsHost` | `TYPHA_PROMETHEUSMETRICSHOST` | TCP network address that the Prometheus metrics server should bind to. [Default: `""`] | string | -| `PrometheusMetricsPort` | `TYPHA_PROMETHEUSMETRICSPORT` | TCP port that the Prometheus metrics server should bind to. [Default: `9091`] | int | -| `PrometheusProcessMetricsEnabled` | `TYPHA_PROMETHEUSPROCESSMETRICSENABLED` | Set to `false` to disable process metrics collection, which the Prometheus client does by default. This reduces the number of metrics reported, reducing Prometheus load. [Default: `true`] | boolean | -| `ServerHandshakeTimeoutSecs` | `TYPHA_SERVERHANDSHAKETIMEOUTSECS` | Maximum time that Typha server should wait for the client TLS handshake to be performed. | int | -| `ShutdownTimeoutSecs` | `TYPHA_SHUTDOWNTIMEOUTSECS` | Maximum time that Typha should take to do a graceful shut down. In Kubernetes, this should match Typha's `terminationGracePeriodSeconds`. | int | -| `ShutdownConnectionDropIntervalMaxSecs` | `TYPHA_SHUTDOWNCONNECTIONDROPINTERVALMAXSECS` | Maximum time between terminating two connections when doing a graceful shutdown. Prevents very slow shut downs if `ShutdownTimeoutSecs` is large but Typha only has a small number of clients. | int | - -:::note - -By default, if the health endpoint is enabled Typha listens on localhost. However, if Typha is used in -Kubernetes, the kubelet will do health checks using the pod IP. To work around this discrepancy, the Typha image -supports a health-check CLI command that fetches the health endpoint: -`calico-typha check (readiness|liveness) --port=`. If you modify the health port, you will need to add the -`--port=` argument to the liveness and readiness probe commands in the manifest. - -::: - -### etcd datastore configuration - -| Configuration parameter | Environment variable | Description | Schema | -| ----------------------- | --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------- | -| `EtcdCaFile` | `TYPHA_ETCDCAFILE` | Path to the file containing the root certificate of the certificate authority (CA) that issued the etcd server certificate. Configures Typha to trust the CA that signed the root certificate. The file may contain multiple root certificates, causing Typha to trust each of the CAs included. To disable authentication of the server by Typha, set the value to `none`. [Default: `/etc/ssl/certs/ca-certificates.crt`] | string | -| `EtcdCertFile` | `TYPHA_ETCDCERTFILE` | Path to the file containing the client certificate issued to Typha. Enables Typha to participate in mutual TLS authentication and identify itself to the etcd server. Example: `/etc/typha/cert.pem` (optional) | string | -| `EtcdEndpoints` | `TYPHA_ETCDENDPOINTS` | Comma-delimited list of etcd endpoints to connect to. Example: `http://127.0.0.1:2379,http://127.0.0.2:2379`. | `://:` | -| `EtcdKeyFile` | `TYPHA_ETCDKEYFILE` | Path to the file containing the private key matching the Typha client certificate. Enables Typha to participate in mutual TLS authentication and identify itself to the etcd server. Example: `/etc/typha/key.pem` (optional) | string | - -### Kubernetes API datastore configuration - -The Kubernetes API datastore driver reads its configuration from Kubernetes-provided environment variables. - -#### Environment variables - -| Environment | Description | Schema | -| ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------- | ------- | -| USE_POD_CIDR | Use the Kubernetes `Node.Spec.PodCIDR` field. This field is required when using the Kubernetes API datastore with host-local IPAM. [Default: false] | boolean | - -### Felix-Typha TLS configuration - -| Configuration parameter | Environment variable | Description | Schema | -| ----------------------- | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------ | -| `CAFile` | `TYPHA_CAFILE` | Path to the file containing the root certificate of the CA that issued the Felix client certificate. Configures Typha to trust the CA that signed the Felix client certificate. The file may contain multiple root certificates, causing Typha to trust each of the CAs included. Example: `/etc/typha/ca.pem` | string | -| `ClientCN` | `TYPHA_CLIENTCN` | If set, the `Common Name` that Felix's certificate must have. If you have enabled TLS on the communications from Felix to Typha, you must set a value here or in `ClientURISAN`. You can set values in both, as well, such as to facilitate a migration from using one to the other. If either matches, the communication succeeds. [Default: none] | string | -| `ClientURISAN` | `TYPHA_CLIENTURISAN` | If set, a URI SAN that Felix's certificate must have. We recommend populating this with a [SPIFFE](https://github.com/spiffe/spiffe/blob/master/standards/SPIFFE-ID.md#2-spiffe-identity) string that identifies Felix. All Felix instances should use the same SPIFFE ID. If you have enabled TLS on the communications from Felix to Typha, you must set a value here or in `ClientCN`. You can set values in both, as well, such as to facilitate a migration from using one to the other. If either matches, the communication succeeds. [Default: none] | string | -| `ServerCertFile` | `TYPHA_SERVERCERTFILE` | Path to the file containing the server certificate issued to Typha. Typha presents this to Felix clients during the TLS handshake. Example: `/etc/typha/cert.pem` | string | -| `ServerKeyFile` | `TYPHA_SERVERKEYFILE` | Path to the file containing the private key matching the Typha server certificate. Example: `/etc/typha/key.pem` (optional) | string | - -For more information on how to use and set these variables, refer to -[Connections from Felix to Typha (Kubernetes)](../../network-policy/comms/crypto-auth.mdx#connections-from-felix-to-typha-kubernetes). - - - diff --git a/calico_versioned_docs/version-3.29/reference/typha/index.mdx b/calico_versioned_docs/version-3.29/reference/typha/index.mdx deleted file mode 100644 index caea3ab03c..0000000000 --- a/calico_versioned_docs/version-3.29/reference/typha/index.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: Typha is the component for scaling Kubernetes deployments. -hide_table_of_contents: true ---- - -# Typha - -import DocCardList from '@theme/DocCardList'; -import { useCurrentSidebarCategory } from '@docusaurus/theme-common'; - - diff --git a/calico_versioned_docs/version-3.29/reference/typha/overview.mdx b/calico_versioned_docs/version-3.29/reference/typha/overview.mdx deleted file mode 100644 index aa7935526d..0000000000 --- a/calico_versioned_docs/version-3.29/reference/typha/overview.mdx +++ /dev/null @@ -1,18 +0,0 @@ ---- -description: Use the Calico Typha daemon to increase scale and reduce impact on the datastore. ---- - -# Typha overview - -The Typha daemon sits between the datastore (such as the Kubernetes API server) and many instances of Felix. Typha's main purpose is to increase scale by reducing each node's impact on the datastore. Services such as [Felix](https://github.com/projectcalico/felix) and [confd](https://github.com/projectcalico/confd) connect to Typha instead of connecting directly to the datastore as Typha maintains a single datastore connection on behalf of all its clients. It caches the datastore state and deduplicates events so that they can be fanned out to many listeners. - -:::note - -If you are using the Kubernetes API Datastore, we recommend using Typha. Although Typha can be used with etcd, etcd v3 is already optimized to handle many clients so using it is redundant and not recommended. Operator installations always install Typha. - -::: - -## Advantages - -- Since one Typha instance can support hundreds of Felix instances, it reduces the load on the datastore by a large factor. -- Since Typha can filter out updates that are not relevant to Felix, it also reduces Felix's CPU usage. In a high-scale Kubernetes cluster, this is essential because the number of updates generated by the API server scales with the number of nodes. diff --git a/calico_versioned_docs/version-3.29/reference/typha/prometheus.mdx b/calico_versioned_docs/version-3.29/reference/typha/prometheus.mdx deleted file mode 100644 index 09469a949b..0000000000 --- a/calico_versioned_docs/version-3.29/reference/typha/prometheus.mdx +++ /dev/null @@ -1,120 +0,0 @@ ---- -description: Review metrics for the Typha component if you are using Prometheus. ---- - -# Monitoring Typha with Prometheus - -Typha can be configured to report a number of metrics through Prometheus. See the -[configuration reference](configuration.mdx) for how to enable metrics reporting. - -## Metric reference - -#### Typha specific - -Typha exports a number of Prometheus metrics. The current set is as follows. Since some metrics -are tied to particular implementation choices inside Typha we can't make any hard guarantees that -metrics will persist across releases. However, we aim not to make any spurious changes to -existing metrics. - -##### Terminology - -**Syncer:** Many of Typha's metrics are now parameterised by "syncer type"; Typha runs one "syncer" for each -type of client that it supports. The "syncer" is the component that synchronises Typha's local cache -of the datastore with the upstream datastore. The syncer type is attached to the metrics via a -Prometheus label `syncer="..."`. - -**Breadcrumb:** Typha's internal cache stores a series of snapshots of the state of the datastore along with -a list of changes when compared to the previous snapshot. We call the combination of a snapshot and the list of -changes a "breadcrumb". Breadcrumbs are linked together into a linked list as they are created. When a client -connects, Typha sends the snapshot from the most recent breadcrumb to the client; then, it "follows the breadcrumbs" -on behalf of that client, sending it the change list from each breadcrumb. - -| Name | Description | -| ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `typha_cache_size` | The total number of key/value pairs in Typha's in-memory cache. | -| `typha_snapshots_generated` | The total number of binary snapshots generated by Typha. Binary snapshots are generated once and then shared between multiple clients for performance. | -| `typha_snapshots_reused` | The number of binary snapshots that Typha was able to reuse for multiple clients, thus reducing CPU usage. | -| `typha_snapshot_raw_bytes` | The size of the most recent binary snapshot in bytes pre-compression. | -| `typha_snapshot_compressed_bytes` | The size of the most recent binary snapshot in bytes post-compression. | -| `typha_breadcrumb_block` | Count of the number of times Typha got the next Breadcrumb after blocking. | -| `typha_breadcrumb_non_block` | typha_breadcrumb_non_block Count of the number of times Typha got the next Breadcrumb without blocking. | -| `typha_breadcrumb_seq_number` | Current (server-local) sequence number; number of snapshot deltas processed. | -| `typha_breadcrumb_size` | Number of KVs recorded in each breadcrumb. | -| `typha_client_latency_secs` | Per-client latency. I.e. how far behind the current state is each client. | -| `typha_client_snapshot_send_secs` | How long it took to send the initial snapshot to each client. | -| `typha_client_write_latency_secs` | Per-client write. How long each write call is taking. | -| `typha_connections_accepted` | Total number of connections accepted over time. | -| `typha_connections_active` | Number of open client connections (including connections that have not completed the handshake). | -| `typha_connections_streaming` | Number of client connections that are actively streaming (i.e. connections that successfully completed the handshake). | -| `typha_connections_dropped` | Total number of connections dropped due to rebalancing. | -| `typha_kvs_per_msg` | Number of KV pairs sent in each message. | -| `typha_log_errors` | Number of errors encountered while logging. | -| `typha_logs_dropped` | Number of logs dropped because the output stream was blocked. | -| `typha_next_breadcrumb_latency_secs` | Time to retrieve next breadcrumb when already behind. | -| `typha_ping_latency` | Round-trip ping/pong latency to client. Typha's protocol includes a regular ping/pong keepalive to verify that the connection is still up. | -| `typha_updates_skipped` | Total number of updates skipped because the datastore change was not relevant. (For example, an update to a Kubernetes Pod field that $[prodname] does not read.) | -| `typha_updates_total` | Total number of updates received from the datastore. | -| `remote_cluster_connection_status` | Status of the remote cluster connection in federation. Represented as numeric values 0 (NotConnecting), 1 (Connecting), 2 (InSync), 3 (ReSyncInProgress), 4 (ConfigChangeRestartRequired), 5 (ConfigInComplete). Uses `remote_cluster_name` label to represent name of the remote cluster in federation.| - -Prometheus metrics are self-documenting, with metrics turned on, `curl` can be used to list the -metrics along with their help text and type information. - -```bash -curl -s http://localhost:9091/metrics | head -``` - -Example response: - -``` -# HELP typha_breadcrumb_block Count of the number of times Typha got the next Breadcrumb after blocking. -# TYPE typha_breadcrumb_block counter -typha_breadcrumb_block 57 -# HELP typha_breadcrumb_non_block Count of the number of times Typha got the next Breadcrumb without blocking. -# TYPE typha_breadcrumb_non_block counter -typha_breadcrumb_non_block 0 -# HELP typha_breadcrumb_seq_number Current (server-local) sequence number; number of snapshot deltas processed. -# TYPE typha_breadcrumb_seq_number gauge -typha_breadcrumb_seq_number 22215 -... -``` - -#### CPU / memory metrics - -Typha also exports the default set of metrics that Prometheus makes available. Currently, those -include: - -| Name | Description | -| -------------------------------------------- | ------------------------------------------------------------------ | -| `go_gc_duration_seconds` | A summary of the GC invocation durations. | -| `go_goroutines` | Number of goroutines that currently exist. | -| `go_memstats_alloc_bytes` | Number of bytes allocated and still in use. | -| `go_memstats_alloc_bytes_total` | Total number of bytes allocated, even if freed. | -| `go_memstats_buck_hash_sys_bytes` | Number of bytes used by the profiling bucket hash table. | -| `go_memstats_frees_total` | Total number of frees. | -| `go_memstats_gc_sys_bytes` | Number of bytes used for garbage collection system metadata. | -| `go_memstats_heap_alloc_bytes` | Number of heap bytes allocated and still in use. | -| `go_memstats_heap_idle_bytes` | Number of heap bytes waiting to be used. | -| `go_memstats_heap_inuse_bytes` | Number of heap bytes that are in use. | -| `go_memstats_heap_objects` | Number of allocated objects. | -| `go_memstats_heap_released_bytes_total` | Total number of heap bytes released to OS. | -| `go_memstats_heap_sys_bytes` | Number of heap bytes obtained from system. | -| `go_memstats_last_gc_time_seconds` | Number of seconds since 1970 of last garbage collection. | -| `go_memstats_lookups_total` | Total number of pointer lookups. | -| `go_memstats_mallocs_total` | Total number of mallocs. | -| `go_memstats_mcache_inuse_bytes` | Number of bytes in use by mcache structures. | -| `go_memstats_mcache_sys_bytes` | Number of bytes used for mcache structures obtained from system. | -| `go_memstats_mspan_inuse_bytes` | Number of bytes in use by mspan structures. | -| `go_memstats_mspan_sys_bytes` | Number of bytes used for mspan structures obtained from system. | -| `go_memstats_next_gc_bytes` | Number of heap bytes when next garbage collection will take place. | -| `go_memstats_other_sys_bytes` | Number of bytes used for other system allocations. | -| `go_memstats_stack_inuse_bytes` | Number of bytes in use by the stack allocator. | -| `go_memstats_stack_sys_bytes` | Number of bytes obtained from system for stack allocator. | -| `go_memstats_sys_bytes` | Number of bytes obtained by system. Sum of all system allocations. | -| `process_cpu_seconds_total` | Total user and system CPU time spent in seconds. | -| `process_max_fds` | Maximum number of open file descriptors. | -| `process_open_fds` | Number of open file descriptors. | -| `process_resident_memory_bytes` | Resident memory size in bytes. | -| `process_start_time_seconds` | Start time of the process since Unix epoch in seconds. | -| `process_virtual_memory_bytes` | Virtual memory size in bytes. | -| `promhttp_metric_handler_requests_in_flight` | Current number of scrapes being served. | -| `promhttp_metric_handler_requests_total` | Total number of scrapes by HTTP status code. | diff --git a/calico_versioned_docs/version-3.29/reference/vpp/host-network.mdx b/calico_versioned_docs/version-3.29/reference/vpp/host-network.mdx deleted file mode 100644 index ae144d08b0..0000000000 --- a/calico_versioned_docs/version-3.29/reference/vpp/host-network.mdx +++ /dev/null @@ -1,98 +0,0 @@ ---- -description: Description of the host network configuration performed by VPP. ---- - -# Host network configuration - -## Big picture - -The VPP-Host connection is a bit particular in the sense that the address of the primary interface is shared by both VPP and Linux. -Let's say the primary interface (uplink interface on the diagram below) is called `enp216s0f1` and configured with an `192.168.0.1/24` address. - -This address must also be the one the api-server will be listening on, as the first address of the uplink (a.k.a main interface for the host). - -![Network architecture](/img/calico/vpp-host-net.svg) - -## When VPP starts - -- It grabs the primary interface with the chosen driver, either placing it in a dedicated network namespace, or removing it entirely as a Linux netdev depending on the driver. In any case, the interface disappears from the host's root network namespace. -- It configures it in VPP with the same configuration (addresses, routes) it had in Linux. So issuing `show int addr` in VPP will give something like - ``` - vpp# sh int addr - avf-0/d8/a/0 (up): - L3 192.168.0.1/24 - ``` -- It creates a `tap` interface between VPP and the host -- This tap interface is given the same name and MAC address as the original interface in the host's root network namespace -- This interface is also reconfigured with all the addresses and routes that the host had configured on the original interface - ```bash - ip addr show enp216s0f1 - 3: enp216s0f1: mtu 1500 qdisc mq state UP group default qlen 1000 - link/ether 52:54:00:40:46:8e brd ff:ff:ff:ff:ff:ff - inet 192.168.0.1/24 brd 192.168.0.255 scope global eth1 - valid_lft forever preferred_lft forever - - ip route - default via 192.168.0.254 dev enp216s0f1 proto dhcp src 192.168.0.1 metric 100 - ${SERVICE_CIDR} via 192.168.0.254 dev enp216s0f1 proto static mtu 1440 - ${POD_CIDR} via 192.168.0.254 dev enp216s0f1 proto static mtu 1440 - 192.168.0.0/24 dev enp216s0f1 proto kernel scope link src 192.168.0.254 - ``` - - The new `tap` interface (named `enp216s0f1` in this example) is also configured with routes towards the Kubernetes service CIDR and the pod CIDR, so that the Linux host can reach the workloads through VPP. These routes use a reduced MTU to accommodate for encapsulations. - -- In VPP you will find it with the name `tap0`. It is configured unnumbered, as a child of the primary interface `avf-0/d8/a/0`. - ``` - vpp# sh int addr - tun0 (up): - unnumbered, use avf-0/d8/a/0 - L3 192.168.0.1/24 - ``` - -- It is also registered as the default punt path. This means that all the traffic that would be dropped by VPP (which includes the traffic to the VPP address that is not handled by VPP itself, but not the tunnel traffic which is decapsulated/decrypted by VPP) will be passed to this interface, so the Linux host will receive and process it. - - ``` - vpp# sh ip punt redirect - rx local0 via: - path-list:[31] locks:1 flags:no-uRPF, uPRF-list:24 len:1 itfs:[2, ] - path:[41] pl-index:31 ip4 weight=1 pref=0 attached-nexthop: oper-flags:resolved, - 169.254.0.1 tap0 - [@0]: ipv4 via 169.254.0.1 tap0: mtu:1500 next:6 flags:[features ] 52540040468e02ca11c0fd100800 - forwarding - [@1]: ipv4 via 169.254.0.1 tap0: mtu:1500 next:6 flags:[features ] 52540040468e02ca11c0fd100800 - ``` - - For the v6 configuration: - ``` - vpp# sh ip6 punt redirect - ``` - -## Packet flow - incoming packet on the uplink - -A packet destined to the host arrives on the uplink, let's say it has `src=192.168.0.2,dst=192.168.0.1` - -- VPP receives it, sees that the destination address is the one configured on its interface -- As it doesn't have specific handling configured for this packet, it looks up the punt path, and sends it into `tap0` -- Linux receives it on the tap interface which is configured with `192.168.0.1/32` and so processes it normally - -The reply is now emitted by the host with `src=192.168.0.1,dst=192.168.0.2` - -- Linux looks up the route for `192.168.0.0/24`, forwards it into the tap interface -- VPP receives it on the interface `tap0` -- It looks up `192.168.0.2` in the fib, finds a route on the uplink interface (configured with `192.168.0.1/24`) -- The packet is sent on the uplink - -## Packet flow - pod talking to the api-server - -Let's say the api server lives on `Node A`. - -If a pod on `Node B` wants to talk to the api-server on `Node A`, the packet flow will be the same as described above. - -- In `Node B`, standard routing happens (`sh ip fib ` will give details on this node) -- When reaching `Node A`, we're in the same situation as previously - -If a pod on `Node A` wants to talk to the api-server on `Node A`, let's say the packet is `src=10.0.0.1,dst=192.168.0.1` with `10.0.0.1` being the pod address, then: - -- Things happen exactly the same way as if the packet was coming from the uplink -- This time packets come into vpp through `tunN` corresponding to the pod interface, and is then punted to `tap0` towards the host -- The return traffic from the host is received by VPP on `tap0`, and is routed directly to the pod on `tunN` diff --git a/calico_versioned_docs/version-3.29/reference/vpp/index.mdx b/calico_versioned_docs/version-3.29/reference/vpp/index.mdx deleted file mode 100644 index 37410e1668..0000000000 --- a/calico_versioned_docs/version-3.29/reference/vpp/index.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: Configuration settings and architecture of the VPP data plane. -hide_table_of_contents: true ---- - -# VPP data plane - -import DocCardList from '@theme/DocCardList'; -import { useCurrentSidebarCategory } from '@docusaurus/theme-common'; - - diff --git a/calico_versioned_docs/version-3.29/reference/vpp/technical-details.mdx b/calico_versioned_docs/version-3.29/reference/vpp/technical-details.mdx deleted file mode 100644 index 18aa3ff92d..0000000000 --- a/calico_versioned_docs/version-3.29/reference/vpp/technical-details.mdx +++ /dev/null @@ -1,80 +0,0 @@ ---- -description: Technical details on the VPP data plane integration. ---- - -# VPP data plane implementation details - -## Software architecture - -The VPP data plane integration is split in two components, `vpp-manager` which handles the VPP startup configuration and lifecycle; and `calico-vpp-agent` which is responsible for all the runtime configuration of VPP for $[prodname]. Both processes run in separate containers in the `calico-vpp-node` pod, which runs in the host's root network namespace. - -![Implementation architecture](/img/calico/vpp-soft-arch.svg) - -### vpp-manager - -VPP Manager is a very lightweight process responsible for the bootstrap of VPP, including uplink interface addressing and routing configuration. It also restores the Linux configuration on shutdown. The code can be found in this directory: [https://github.com/projectcalico/vpp-dataplane/tree/$[vppbranch]/vpp-manager](https://github.com/projectcalico/vpp-dataplane/tree/$[vppbranch]/vpp-manager). - -On startup, `vpp-manager` starts by determining the desired configuration for the VPP uplink by checking it's configuration in Linux, including addresses and routes. It then renders an appropriate configuration file for VPP, and starts the VPP process. - -Once VPP is running, `vpp-manager` connects to it using the API and starts configuring the uplink interface as it was configured in Linux. Once this is done, it configures a tap interface in the host to restore its connectivity. - -Once it is running, `vpp-manager` forwards all received Unix signals to VPP to handle stops gracefully. - -When VPP stops, either in reaction to a received signal or in case of a crash, `vpp-manager` restores the configuration of the Linux interface so that the host recovers its connectivity to the outside through the original uplink interface. - -`vpp-manager` is voluntarily kept as simple as possible, to minimize the risk of bugs, as these could leave the host without connectivity, requiring a reboot. - -### calico-vpp-agent - -The $[prodname] VPP agent is the process responsible for all the $[prodname]-specific configuration in VPP. Its code lives in this directory: [https://github.com/projectcalico/vpp-dataplane/tree/$[vppbranch]/calico-vpp-agent](https://github.com/projectcalico/vpp-dataplane/tree/$[vppbranch]/calico-vpp-agent). - -This agent is split in four main components, which interact with the k8s and $[prodname] APIs to configure VPP. These components are the routing manager, the CNI server, the services manager and the policies manager. - -**Routing manager** - -The $[prodname] VPP agent embeds a GoBGP daemon, and dynamically updates its configuration (including peers, ASN, etc.) according to the $[prodname] configuration. As the `calico-vpp-node` pod runs in the host network namespace, the BGP daemon uses the host's TCP stack, and sends and receives traffic through the host's interface `vpptap0`. - -When routes are added or removed in BGP, the routing manager reflects the changes in VPP. The routes are installed differently depending on the $[prodname] configuration. If the configuration requires the use of an IPIP or VXLAN tunnel, then the tunnel interface will be created on demand in VPP, and the route will be added through the tunnel. Otherwise, the route is simply added as-is in VPP. - -**CNI server** - -This component implements a server that receives gRPC request from the $[prodname] CNI (configured with a gRPC data plane) through a Unix socket mounted on the host. - -When it receives an ADD request, the CNI server creates a tap interface in the container's namespace, and configures it with the IP address and routes chosen by $[prodname]. The routes' next hop is an otherwise unused link-local address, both in IPv4 and in IPv6. A /32 or /128 route is added in VPP as well for the container address through the tap. When it receives a DEL request, the CNI servers cleans up the tap from VPP and from the container's namespace. - -**Services manager** - -This component is the equivalent of kube-proxy for VPP, i.e. it configures NAT load-balancing rules to implement Kubernetes services in VPP. It watches the Kubernetes Services and Endpoints APIs, and updates the VPP configuration on each change. Service load balancing is implemented with a $[prodname]-specific DNAT plugin in VPP. - -**Policies manager** - -This component implements $[prodname] policies in VPP. Felix ($[prodname]'s policy agent) is configured to use a lightweight proxy as its data plane. This proxy relays all the configuration messages sent by Felix to the `calico-vpp-agent`, and status updates the other way. The VPP agent then uses a custom plugin in VPP to implement policies. - -## Network architecture - -### Primary interface configuration - -To send and receive the packets on behalf of the containers, VPP needs to use one of the host's network interfaces. There are various ways to do so, which differ in performance and configuration complexity: - -- AF_PACKET: the slowest option, but also the most universally supported one as it works for every Linux network device. The interface is placed in a dedicated network namespace in order not to disrupt the host connectivity that is set up by VPP. -- AF_XDP: much more performant than AF_PACKET, but it requires a recent kernel version (5.4+). The interface is placed in a dedicated network namespace in order not to disrupt the host connectivity that is set up by VPP. -- DPDK: VPP can use DPDK to drive interfaces. This is more performant than AF_XDP. DPDK supports a large number of interfaces, but requires hugepages to be configured on the host to work. The interface is bound to a specific PCI driver on startup, and thus disappears from the host's kernel network devices. -- VPP native drivers: the most performant option, but a limited number of interfaces are supported. Supported interfaces include Intel AVF, Mellanox Connect-X series, vmxnet3 (VMware) interfaces, and virtio (use by Qemu/KVM and GCE) interfaces. As with DPDK, the interface needs to be bound to a specific PCI driver on startup, and thus disappears from the host. Using native drivers requires custom configuration, except for `virtio` and Intel AVF interfaces which are supported by `vpp-manager`. - -### Host network configuration - -See the [dedicated page](host-network.mdx). - -### Container interfaces - -When a Pod is scheduled on the host, the kubelet service will create the network namespace for the new pod, and then use the CNI to request that $[prodname] configures an interface in this namespace. $[prodname] will first compute the IP configuration for the host (address and routes), and then pass that to the VPP agent. VPP will then create a tun interface in the desired namespace for the container, and configure it with the required address and routes. This makes all the container traffic flow through VPP. - -### Container routing & services load balancing - -To determine the host where each pod is running, $[prodname] uses BGP. Routes learned from BGP are installed in VPP to reach the containers that are running on other nodes. Depending on the $[prodname] configuration, these routes are either to directly connected hosts, or through tunnel interfaces if encapsulation is required. - -Services load balancing is implemented with NAT rules in VPP, in a very similar way to what kube-proxy is doing. The source address is preserved when possible for external connections. - -Here is the resulting logical network topology: - -![Network architecture](/img/calico/vpp-net-arch.svg) diff --git a/calico_versioned_docs/version-3.29/reference/vpp/uplink-configuration.mdx b/calico_versioned_docs/version-3.29/reference/vpp/uplink-configuration.mdx deleted file mode 100644 index 750df04d66..0000000000 --- a/calico_versioned_docs/version-3.29/reference/vpp/uplink-configuration.mdx +++ /dev/null @@ -1,168 +0,0 @@ ---- -description: Configuration parameters for the primary interface in VPP. ---- - -# Primary interface configuration - -You can choose different ways to consume the host's primary interface with VPP, usually with a tradeoff between performance and simplicity of configuration. Here are the main supported configurations. - -- `virtio` the interface is consumed with a native VPP driver. Performance is good and set up is simple, but only virtio interfaces are supported. -- `avf` we create a virtual function and consume it with a native VPP driver. Performance is good and setup simple, but only intel AVF interfaces are supported. -- `af_packet` the interface stays in Linux which passes packets to VPP. Performance is low, but it works out of the box with any interface. -- `af_xdp` packets are passed via eBPF. This requires a `>=5.4` kernel, but works out of the box with good performance. -- `dpdk` the interface is removed from Linux and consumed with the dpdk library. Performance and support are good, but setup can be complex. -- other native VPP drivers bring better performance than `dpdk` but require complex manual setup. - -## General mechanics - -The `calico-vpp-config` ConfigMap section of the manifest file contains the key `CALICOVPP_INTERFACES`, which is a dictionary with parameters -specific to interfaces in $[prodname] VPP: - -```yaml -# Configures parameters for calicovpp agent and vpp manager -CALICOVPP_INTERFACES: |- - { - "maxPodIfSpec": { - "rx": 10, "tx": 10, "rxqsz": 1024, "txqsz": 1024 - }, - "defaultPodIfSpec": { - "rx": 1, "tx":1, "isl3": true - }, - "vppHostTapSpec": { - "rx": 1, "tx":1, "rxqsz": 1024, "txqsz": 1024, "isl3": false - }, - "uplinkInterfaces": [ - { - "interfaceName": "eth1", - "vppDriver": "af_packet" - } - ] - } -``` - -The field `uplinkInterfaces` contains a list of interfaces and their configuration, with the first element being the primary/main interface, and the -rest (if any) being the secondary host interfaces. The way the primary interface gets configured is controlled by the `vppDriver` field in `uplinkInterfaces[0]`. -Leaving the `vppDriver` field empty (or unspecified) will try all drivers (except `dpdk` which needs to be specified explicitly) supported in your setup, -starting with the most performant. You'll still need to allocate hugepages if you want, for example, virtio to work. - -:::note - -`CALICOVPP_NATIVE_DRIVER` way of specifying the driver to use is still supported. Refer to **Legacy options** sub-section of [Getting Started](../../getting-started/kubernetes/vpp/getting-started.mdx). - -::: - -## Using the native Virtio driver - -You can use this driver if your primary interface is virtio (`realpath /sys/bus/pci/devices//driver` gives `.../virtio-net`) - -- Ensure you have hugepages available on your system (`sysctl -w vm.nr_hugepages=512`) -- Ensure `vfio-pci` is loaded (`sudo modprobe vfio-pci`) -- For the primary interface, `uplinkInterfaces[0]`, set `vppDriver` to "virtio" -- Also ensure that your vpp config has no `dpdk` stanza and its plugin disabled - -Optionally if you would like to set the number/size of **rx** queues, refer to **UplinkInterfaceSpec** sub-section of [Getting Started](../../getting-started/kubernetes/vpp/getting-started.mdx). - -## Using the native AVF driver - -You can use this driver if your primary interface is supported by AVF (`realpath /sys/bus/pci/devices//driver` gives `.../i40e`) - -- Ensure `vfio-pci` is loaded (`sudo modprobe vfio-pci`) -- For the primary interface, `uplinkInterfaces[0]`, set `vppDriver` to "avf" -- Also ensure that your vpp config has no `dpdk` stanza and its plugin disabled - -Optionally if you would like to set the number/size of **rx** queues, refer to **UplinkInterfaceSpec** sub-section of [Getting Started](../../getting-started/kubernetes/vpp/getting-started.mdx). - -## Using AF_XDP - -:::caution - -Ensure your kernel is at least `5.4` with `uname -r` - -::: - -- For the primary interface, `uplinkInterfaces[0]`, set `vppDriver` to "af_xdp" -- Also ensure that your vpp config has no `dpdk` stanza and its plugin disabled -- Finally `FELIX_XDPENABLED` should be set to `false` on the `calico-node` container otherwise felix will periodically cleanup the VPP configuration - ```yaml - --- - kind: DaemonSet - apiVersion: apps/v1 - metadata: - name: calico-node - namespace: kube-system - spec: - template: - spec: - containers: - - name: calico-node - env: - - name: FELIX_XDPENABLED - value: 'false' - ``` - -With kustomize use `kubectl kustomize ./yaml/overlays/af-xdp | kubectl apply -f -`. - -Optionally if you would like to set the number/size of **rx** queues or if you would like to customize whether we busy-poll the interface (`polling`), -only use interrupts to wake us up (`interrupt`) or switch between both depending on the load (`adaptive`), refer to **UplinkInterfaceSpec** sub-section -of [Getting Started](../../getting-started/kubernetes/vpp/getting-started.mdx). - -#### Side notes - -- AF_XDP won't start if you specify `buffers { buffers-per-numa }` to be too big (65536 should work) - -## Using AF_PACKET - -- For the primary interface, `uplinkInterfaces[0]`, set `vppDriver` to "af_packet" -- Also ensure that your vpp config has no `dpdk` stanza and the dpdk plugin is disabled - -You can also use `kubectl kustomize ./yaml/overlays/af-packet | kubectl apply -f -` - -## Using DPDK - -- Ensure you have hugepages available on your system (`sysctl -w vm.nr_hugepages=512`) -- For the primary interface, `uplinkInterfaces[0]`, set `vppDriver` to "dpdk" - -## Using native drivers with vpp's CLI - -This is a rather advanced/experimental setup and we'll take the example of the AVF driver for this, using vpp cli, but any vpp driver can be used. -This allows to efficiently support other interface types. - -- For the primary interface, `uplinkInterfaces[0]`, set `vppDriver` to "none" -- Ensure that your vpp config has no `dpdk` stanza and the dpdk plugin is disabled -- Make sure the `exec /etc/vpp/startup.exec` entry is present in `unix { .. }` - ```yaml - CALICOVPP_CONFIG_TEMPLATE: |- - unix { - nodaemon - full-coredump - log /var/run/vpp/vpp.log - cli-listen /var/run/vpp/cli.sock - exec /etc/vpp/startup.exec - } - ... - # removed dpdk { ... } - ... - plugins { - plugin default { enable } - plugin calico_plugin.so { enable } - plugin dpdk_plugin.so { disable } - } - ``` -- Update the `CALICOVPP_CONFIG_EXEC_TEMPLATE` environment variable to pass the interface creation cli command(s). - ```yaml - kind: DaemonSet - apiVersion: apps/v1 - metadata: - name: calico-vpp-node - namespace: calico-vpp-dataplane - spec: - template: - spec: - containers: - - name: vpp - env: - - name: CALICOVPP_CONFIG_EXEC_TEMPLATE - value: 'create interface avf 0000:ab:cd.1 num-rx-queues 1' - ``` - -In the specific case of the AVF driver, the PCI id must belong to a VF that can be created with the `avf.sh` [script](https://github.com/projectcalico/vpp-dataplane/blob/$[vppbranch]/test/scripts/utils/avf.sh). Different drivers will have different requirements. diff --git a/calico_versioned_docs/version-3.29/release-notes/index.mdx b/calico_versioned_docs/version-3.29/release-notes/index.mdx deleted file mode 100644 index 54baf5052e..0000000000 --- a/calico_versioned_docs/version-3.29/release-notes/index.mdx +++ /dev/null @@ -1,296 +0,0 @@ ---- -description: Release notes for Calico Open Source -title: Calico Open Source release notes -sidebar_label: Release notes ---- - -# Calico Open Source 3.29 release notes - -Learn about the new features, bug fixes, and other updates in this release of $[prodname]. - -## New features and enhancements - -### Tiered network policy and support for the `AdminNetworkPolicy` resource - -We've added support for tiered network policy, which makes it easier to manage and enforce network policy. -You can use tiers to group your network policies and create rules to enforce those policies according to what group, or tier, they are part of. -If you have different teams writing network policies, grouping those policies in policy tiers can help ensure that the policies of one team (for example, your security team) aren't overridden by another. - -The `AdminNetworkPolicy` resource helps administrators set strict security rules for the cluster. -If an `AdminNetworkPolicy` resource sets rules for a particular workload, those rules can not be overridden by other network policies. - -For more information about tiers and the `AdminNetworkPolicy` resource, see [Get started with policy tiers](../network-policy/policy-tiers/tiered-policy.mdx). - -### Tech preview: nftables data plane - -This release includes support for the nftables data plane. - -Kubernetes 1.31 introduced a beta status [kube-proxy Service implementation based on nftables](https://kubernetes.io/docs/reference/networking/virtual-ips/#proxy-mode-nftables) that promises better performance than the default iptables implementation. - -Installing Calico Open Source in nftables mode provides a networking and network policy implementation that is compatible with the upstream nftables kube-proxy. - -For more information, see [Calico nftables data plane](../getting-started/kubernetes/nftables.mdx). - -### Enhancements - -* eBPF: Faster redirection from host interface to workloads for any included traffic that does not use NAT (CTLB enabled or pod-to-pod) [calico 9213](https://github.com/projectcalico/calico/pull/9213) (@tomastigera) -* Include license file in non-AMD64 images. [calico 8735](https://github.com/projectcalico/calico/pull/8735) (@fasaxc) -* Address GitHub Dependabot security alerts [calico 9108](https://github.com/projectcalico/calico/pull/9108) (@hjiawei) -* Improve cni-plugin binary install verification. [calico 8827](https://github.com/projectcalico/calico/pull/8827) (@coutinhop) -* Felix's route programming now handles routing conflicts deterministically, prioritising routes based on their type. Conntrack cleanup has been improved; cleanup is now correctly sequenced with route programming when IP addresses move from local to remote workloads. [calico 8418](https://github.com/projectcalico/calico/pull/8418) (@fasaxc) -* In manifest installs, in order to prevent default IP-pools creation, `CALICO_IPV4POOL_CIDR`=`none` and `CALICO_IPV6POOL_CIDR`=`none` environment variable special values are now supported. [calico 8156](https://github.com/projectcalico/calico/pull/8156) (@kruftik) -* The calico-kube-controllers container now runs with `securityContext.runAsNonRoot=true`. [calico 6499](https://github.com/projectcalico/calico/pull/6499) (@ialidzhikov) -* New Helm values.yaml field - additionalLabels - allows configuring labels on resources created by the chart. @TheCubicleJockey [calico 8722](https://github.com/projectcalico/calico/pull/8722) (@caseydavenport) -* New Felix config param IPForwarding allows for preventing Felix from enabling IP forwarding on systems that are only using Calico for host protection (and hence don't need to forward traffic to workloads). [calico 9320](https://github.com/projectcalico/calico/pull/9320) (@fasaxc) -* Felix now logs our policy selectors as well as the policy ID. [calico 9187](https://github.com/projectcalico/calico/pull/9187) (@fasaxc) -* Felix's route resync logic has been optimised; it now uses 50% less CPU time and 80% less memory. [calico 9139](https://github.com/projectcalico/calico/pull/9139) (@fasaxc) -* BGPFilter: Add prefix length matching [calico 9114](https://github.com/projectcalico/calico/pull/9114) (@mstansberry) -* Conntrack cleanup debug logs now include more information. [calico 9131](https://github.com/projectcalico/calico/pull/9131) (@fasaxc) -* Log formatting performance has been improved, reducing the overhead of logging. [calico 9055](https://github.com/projectcalico/calico/pull/9055) (@fasaxc) -* Felix now uses less CPU and memory when listing routes from the kernel. [calico 8979](https://github.com/projectcalico/calico/pull/8979) (@fasaxc) -* Adjust default IP set refresh interval from 10s to 90s. [calico 8959](https://github.com/projectcalico/calico/pull/8959) (@caseydavenport) -* apiserver defaults logrus level based on `-v` argument [calico 8697](https://github.com/projectcalico/calico/pull/8697) (@caseydavenport) -* Expose the Go runtime's "GOMAXPROCS" setting via felix configuration. This may be useful for tuning Felix to take account of CPU limits. [calico 8945](https://github.com/projectcalico/calico/pull/8945) (@fasaxc) - -## Bug fixes - -### BPF data plane - -* Fixed memory leak in BPF endpoint manager. [calico 9309](https://github.com/projectcalico/calico/pull/9309) (@tomastigera) -* eBPF: Fix for Istio ambient mode - traffic that arrives from host should go back through host and not skip iptables [calico 9192](https://github.com/projectcalico/calico/pull/9192) (@tomastigera) -* eBPF: When bpfConntrackBypass is disabled, ensure that iptables rules, which allow 3rd party iptables rules work for traffic originally for the host, are in place. [calico 9188](https://github.com/projectcalico/calico/pull/9188) (@tomastigera) -* eBPF: Fixed frequently attaching BPF programs when pods annotations/labels change and eventually failing due to running out of tc priority. [calico 9089](https://github.com/projectcalico/calico/pull/9089) (@sridhartigera) -* eBPF: Fix parsing host IP update and re-attach program on all interfaces when there is a host IP update. [calico 9084](https://github.com/projectcalico/calico/pull/9084) (@sridhartigera) -* Fixed Missing routes for UDP services when in dual stack mode. [calico 9050](https://github.com/projectcalico/calico/pull/9050) (@sridhartigera) -* eBPF: Fixed bug that would leave residual logging when log filters were applied and then disabled. [calico 9137](https://github.com/projectcalico/calico/pull/9137) (@tomastigera) -* eBPF: Attach XDP to bond slave devices. [calico 9132](https://github.com/projectcalico/calico/pull/9132) (@sridhartigera) -* eBPF: Fix Felix panic when using non-default BPF map sizes. Size was not updated in all places resulting in failure to attach programs. [calico 9117](https://github.com/projectcalico/calico/pull/9117) (@fasaxc) -* eBPF: Fixes missing iptables rules that would keep preexisting V6 connections working when switching to eBPF mode [calico 8943](https://github.com/projectcalico/calico/pull/8943) (@tomastigera) -* eBPF: Don't drop, but reject unknown midflow tcp packets with rst [calico 8933](https://github.com/projectcalico/calico/pull/8933) (@tomastigera) -* eBPF: Set bpfin/out.cali MTU to the smallest of all host ifaces including overlay. That means if jumbo frames are used, this device also uses them. [calico 8922](https://github.com/projectcalico/calico/pull/8922) (@tomastigera) -* eBPF: Fix - let the node handle packet when we are not sure about the destination [calico 8921](https://github.com/projectcalico/calico/pull/8921) (@tomastigera) -* eBPF: Cleanup BPF special devices when BPF is turned off [calico 8884](https://github.com/projectcalico/calico/pull/8884) (@tomastigera) -* eBPF: Support for service loop prevention [calico 8876](https://github.com/projectcalico/calico/pull/8876) (@sridhartigera) -* eBPF: Fixed forwarding, NATing and checksumming of related ICMP traffic (icmp errors) [calico 8858](https://github.com/projectcalico/calico/pull/8858) (@tomastigera) -* eBPF: If a bond master device is part of the bpfDataIfacePattern regexp, calico attaches to it and not to the slaves [calico 8803](https://github.com/projectcalico/calico/pull/8803) (@sridhartigera) -* eBPF: Forwarding services via vxlan tunnel uses different source ports for different flows to better utilize bonded devices and CPUs on the receiving side. [calico 8790](https://github.com/projectcalico/calico/pull/8790) (@tomastigera) -* eBPF: Do not panic in dual-stack mode when a node is configured with only one and not both IPs or autodetection is not enabled for one. [calico 8760](https://github.com/projectcalico/calico/pull/8760) (@tomastigera) -* eBPF: Clean up stale icmp6 conntrack entries [calico 8749](https://github.com/projectcalico/calico/pull/8749) (@tomastigera) -* eBPF: Update map definition in sockops program to let libbpf v1.0+ load them successfully. [calico 8693](https://github.com/projectcalico/calico/pull/8693) (@debasishbsws) -* eBPF: Fix map creation during upgrade. [calico 8684](https://github.com/projectcalico/calico/pull/8684) (@sridhartigera) -* eBPF: Fix natOutgoing SNAT for icmp6 [calico 8679](https://github.com/projectcalico/calico/pull/8679) (@sridhartigera) - -### Windows - -* Configure kubelet certificate rotation on manually installed Calico for Windows. [calico 9178](https://github.com/projectcalico/calico/pull/9178) (@jxlwqq) -* Added support for non-English language versions of Windows. [calico 9062](https://github.com/projectcalico/calico/pull/9062) (@wayne-cheng) -* Fix non-HPC Calico for Windows startup issue with the CalicoNode service. [calico 9016](https://github.com/projectcalico/calico/pull/9016) (@coutinhop) -* [windows] Skip node IP discovery if --NodeIp parameter is provided to kubelet-service.ps1. [calico 8915](https://github.com/projectcalico/calico/pull/8915) (@wayne-cheng) - -### Helm - -* Helm: Fix error parsing kubernetesServiceEndpoint.host as an integer [calico 9067](https://github.com/projectcalico/calico/pull/9067) (@MichalFupso) -* Helm: Fix rendering of KUBERNETES_SERVICE_PORT [calico 8865](https://github.com/projectcalico/calico/pull/8865) (@simonostendorf) -* Fix error when using Helm additionalLabels in conjunction with image pull secrets [calico 8785](https://github.com/projectcalico/calico/pull/8785) (@caseydavenport) - -**General** - -* Fix spurious warning about unexpected inserted rules. [calico 9397](https://github.com/projectcalico/calico/pull/9397) (@fasaxc) -* Fix image in flannel migration manifest [calico 9265](https://github.com/projectcalico/calico/pull/9265) (@radTuti) -* Ignore empty CIDRs specified in the BGPConfiguration. [calico 9230](https://github.com/projectcalico/calico/pull/9230) (@fasaxc) -* Update flannel to version v0.24.4 to fix kube-flannel log spam when ipv6 is disabled. [calico 9208](https://github.com/projectcalico/calico/pull/9208) (@mkhpalm) -* [etcd mode] Fix issue where Calico nodes failed to decommission if calico-kube-controllers was running on the terminated node. [calico 9190](https://github.com/projectcalico/calico/pull/9190) (@caseydavenport) -* BGP: Prevent the advertisement of local kernel routes learned from eBPF interfaces (bpf*.cali) to peers. [calico 9112](https://github.com/projectcalico/calico/pull/9112) (@mstansberry) -* Fix that shutting down a ticker waited a whole tick. (Mainly impacts tests.) [calico 9111](https://github.com/projectcalico/calico/pull/9111) (@fasaxc) -* Fix interaction between kube-proxy and Calico's SNAT rules that could cause corrupted VXLAN packets when checksum offload was enabled. Move Calico's rules after kube-proxy's to make sure kube-proxy's mark bit is cleared if both would have done SNAT. [calico 9091](https://github.com/projectcalico/calico/pull/9091) (@tomastigera) -* Fix that Felix would panic when trying to resync a temporary IP set. Temporary IP sets are created in certain scenarios after previous failures. [calico 9077](https://github.com/projectcalico/calico/pull/9077) (@fasaxc) -* Fix missing resources in calicoctl command help text [calico 9054](https://github.com/projectcalico/calico/pull/9054) (@caseydavenport) -* Calico now uses the logging framework's built in capability to capture the caller's filename/line number. This removes a potential source of concurrency bugs. [calico 9044](https://github.com/projectcalico/calico/pull/9044) (@fasaxc) -* Fix that the conversion from Pod to WorkloadEndpoint could mutate the pod labels; this isn't safe if something else has a reference to the Pod (e.g. if we're used with a caching informer). [calico 9039](https://github.com/projectcalico/calico/pull/9039) (@fasaxc) -* Fix 'undefined symbol: xtables_strdup' error when running 'iptables-legacy-save' in the calico-node image. [calico 9022](https://github.com/projectcalico/calico/pull/9022) (@coutinhop) -* Fixed continuous addition/deletion of service routes in eBPF mode. [calico 8983](https://github.com/projectcalico/calico/pull/8983) (@sridhartigera) -* Felix now arranges for VXLAN packets to skip netfilter conntrack. VXLAN uses pseudo random source ports so the "flows" are unidirectional and not meaningful to conntrack. [calico 8977](https://github.com/projectcalico/calico/pull/8977) (@cyclinder) -* Add IPReservation and BGPFilter to etcd datastore migration [calico 8971](https://github.com/projectcalico/calico/pull/8971) (@caseydavenport) -* Don't run pprof on prometheus metrics port [calico 8967](https://github.com/projectcalico/calico/pull/8967) (@caseydavenport) -* Felix: Move log initialisation earlier in start-up sequence to avoid missing some logs. [calico 8944](https://github.com/projectcalico/calico/pull/8944) (@fasaxc) -* Felix now sets the Go runtime's GC threshold to 40% (instead of the more aggressive 20% used previously). This trades slight extra RAM usage for significantly lower GC CPU usage. The setting is now exposed in the FelixConfiguration as goGCThreshold, along with goMemoryLimitMB. To get the old behaviour, set goGCThreshold to 20. If memory usage is not a concern, the value can be set even higher to reduce CPU usage. [calico 8904](https://github.com/projectcalico/calico/pull/8904) (@fasaxc) -* Upgrade bpftool to v7.4 to fix the issue of loading XDP programs in iptables data plane that happens in few distributions. [calico 8880](https://github.com/projectcalico/calico/pull/8880) (@mazdakn) -* Reduce spammy logs in route table [calico 8879](https://github.com/projectcalico/calico/pull/8879) (@caseydavenport) -* Fixed incorrect logging level related to service IPs. [calico 8816](https://github.com/projectcalico/calico/pull/8816) (@mazdakn) -* Fix that Calico would ignore changes to Kubernetes Node InternalIP when using InternalIP node address autodetection. [calico 8728](https://github.com/projectcalico/calico/pull/8728) (@Levi080513) -* eBPF: wg6 traffic is allowed even if blocked by policy [calico 8712](https://github.com/projectcalico/calico/pull/8712) (@tomastigera) -* Fix pods stuck in ContainerCreating state due to "failed to create host netlink handle: protocol not supported" error on kernels that don't support XFRM. [calico 8710](https://github.com/projectcalico/calico/pull/8710) (@carloslima) -* Fix missing log line numbers in cni-installer log output [calico 8696](https://github.com/projectcalico/calico/pull/8696) (@caseydavenport) -* Restart calico/node if unable to set the NodeNetwork condition. [calico 8673](https://github.com/projectcalico/calico/pull/8673) (@cyclinder) -* Clean up IP addresses of pods with Evicted status. [calico 7713](https://github.com/projectcalico/calico/pull/7713) (@gaopeiliang) - -## Release details - -### Calico Open Source 3.29.0 general availability release - -October 30, 2024 - -Calico Open Source release 3.29.0 is now generally available. - -#### Updating - -To update a previous version of Calico, see [our upgrade guides](../operations/upgrading/index.mdx) - -### Calico Open Source 3.29.1 bug fix release - -November 20, 2024 - -#### Bug fixes - -- Fix that the new tiers resource was omitted from etcd->Kubernetes migration. [calico 9494](https://github.com/projectcalico/calico/pull/9494) (@fasaxc) -- Fix a panic in Felix when accessing a nil address in flushing host addresses, i.e. flushHostIPUpdates function. [calico 9488](https://github.com/projectcalico/calico/pull/9488) (@mazdakn) -- Add permission to Calico API server to create tier resources. [calico 9484](https://github.com/projectcalico/calico/pull/9484) (@mazdakn) -- Do not fail data store initialisation when unauthorised error happen while creating default and adminnetworkpolicy tiers. Those tiers eventually get created by another component. [calico 9454](https://github.com/projectcalico/calico/pull/9454) (@mazdakn) -- Helm: Fix that uninstall Job had duplicate k8s-app labels [calico 9439](https://github.com/projectcalico/calico/pull/9439) (@caseydavenport) -- Fix missing routes when vxlan mode is cross-subnet and the environment is purely V6 (no V4 host addresses) [calico 9430](https://github.com/projectcalico/calico/pull/9430) (@tomastigera) - -#### Other changes - -- eBPF: real IPs in bpf debug output with co-re enabled kernels [calico 9465](https://github.com/projectcalico/calico/pull/9465) (@tomastigera) -- Add setting to enable WireGuard NAPI threading [calico 9414](https://github.com/projectcalico/calico/pull/9414) (@jrcichra) - -#### Updating - -To update a previous version of Calico, see [our upgrade guides](../operations/upgrading/index.mdx) - -### Calico Open Source 3.29.2 bug fix release - -February 6, 2025 - -#### Bug fixes - -- eBPF: fix icmp error delivery to host networked pods [calico 9749](https://github.com/projectcalico/calico/pull/9749) (@tomastigera) -- eBPF: fixed routing from outside the cluster in EKS with aws-cni [calico 9629](https://github.com/projectcalico/calico/pull/9629) (@tomastigera) -- Fix: Map OpenStack-derived policy to the "default" tier, not "ossg". [calico 9778](https://github.com/projectcalico/calico/pull/9778) (@nelljerram) -- Fix that libcalico-go would not always fill in the revision when listing certain resources (or single instances of certain resources). This could result in missed watch events in components such as Typha. [calico 9689](https://github.com/projectcalico/calico/pull/9689) (@fasaxc) -- Fix that nodes with borrowed VXLAN tunnel addresses were not reachable by pods. [calico 9685](https://github.com/projectcalico/calico/pull/9685) (@caseydavenport) -- Fix spammy Tier already exists log from kube-controllers. [calico 9671](https://github.com/projectcalico/calico/pull/9671) (@fasaxc) -- Fixed file handle leak in felix, caused by failing to close netlink handles. [calico 9612](https://github.com/projectcalico/calico/pull/9612) (@fasaxc) -- Fix that non-amd64 builds of node-driver-registrar contained x86 binaries. [calico 9601](https://github.com/projectcalico/calico/pull/9601) (@caseydavenport) -- Fix that in-use VXLAN ARP entries could be repeatedly cleaned up and then re-added if they shared a MAC address with an stale entry that was supposed to be cleaned up. [calico 9582](https://github.com/projectcalico/calico/pull/9582) (@fasaxc) -- Felix: fix that a map used to cache loaded datastore keys would always use RAM proportional to the total number of keys rather than shrinking when no longer needed. [calico 9538](https://github.com/projectcalico/calico/pull/9538) (@fasaxc) - -#### Other changes - -- To reduce manifest size on OCP installations, the manifests no longer includes CustomResourceDefinitions. Instead, the tigera-operator pod will deploy these resources on startup. [calico 9547](https://github.com/projectcalico/calico/pull/9547) (@coutinhop) - -#### Updating - -To update a previous version of Calico, see [our upgrade guides](../operations/upgrading/index.mdx) - -### Calico Open Source 3.29.3 bug fix release - -March 25, 2025 - -#### Bug fixes - -- Fix race when setting WireGuard NAPI setting that could cause the NAPI setting not to be applied for several minutes. [calico 9801](https://github.com/projectcalico/calico/pull/9801) (@fasaxc) - -#### Other changes - -- Remove unnecessary CRD yamls from manifests/ocp, as the operator now installs CRDs on OpenShift. [calico 9930](https://github.com/projectcalico/calico/pull/9930) (@coutinhop) - -#### Updating - -To update a previous version of Calico, see [our upgrade guides](../operations/upgrading/index.mdx) - -### Calico Open Source 3.29.4 bug fix release - -May 21, 2025 - -:::warning[change in behavior for default-tier policies] - -#### Tiered policy naming changes - -The addition of tiered policies in version 3.29.0 changed the naming of policies in the default tier, which caused confusion with tooling that didn't expect it. -In version 3.29.4, we made the following updates to how policies are handled in the default tier: - -* **Policies created in the default tier with Calico Open Source 3.29.0 to 3.29.3:** - For these default-tier policies, updating to version 3.29.4 will change the name from `default.` to ``. -* **Policies created with Calico Open Source 3.28 or earlier:** - For these default-tier policies, updating to version 3.29.4 will result in no name change. - Whatever name they were created with will still be the name they have after the upgrade. -* Policies in the default tier can be created with or without the `default.` prefix. - To manage the policy, you must use the same name that was used to create it. - It’s not possible to interchange the prefixed and non-prefixed name. -* Calico always returns the same policy name that you used to create the policy. - -::: - -#### Bug fixes - -* Change OpenShift manifests order to fix an error when creating HCP clusters. [calico 10255](https://github.com/projectcalico/calico/pull/10255) (@coutinhop) -* Fix missing RBAC permissions for kube-controller-manager to access tiers in manifest installs, which was preventing proper resource garbage collection. [calico 10230](https://github.com/projectcalico/calico/pull/10230) (@caseydavenport) -* eBPF - Fix dropping packets from workloads to host interfaces not managed by calico. [calico 10226](https://github.com/projectcalico/calico/pull/10226) (@sridhartigera) -* eBPF - Fix configuring arp entries for bpf NAT devices for systemd >= 242 [calico 10217](https://github.com/projectcalico/calico/pull/10217) (@sridhartigera) -* eBPF - Fixed a bug where BPF programs were being re-attached to network interfaces unnecessarily, even when the host IP address had not changed. [calico 10164](https://github.com/projectcalico/calico/pull/10164) (@sridhartigera) - -#### Enhancements - -#### Changes to policy naming in the default tier - -* Policies created prior to v3.28.0 have their name retained across upgrade. Policies created in the default tier with version v3.29.[0-3] will have their names changed from `default.name` to `name`. [calico 10417](https://github.com/projectcalico/calico/pull/10417) (@MichalFupso) -* Policies part of the default tier can be managed only with the original name they were created with. Policies are no longer able to be managed interchangeably with or without the default. tier prefix [calico 10391](https://github.com/projectcalico/calico/pull/10391) (@MichalFupso) - -##### Other enhancements - -* Update Operator Helm values to support custom DNS settings [calico 10407](https://github.com/projectcalico/calico/pull/10407) (@caseydavenport) - -#### Updating - -To update a previous version of Calico, see [our upgrade guides](../operations/upgrading/index.mdx) - -### Calico Open Source 3.29.5 bug fix release - -July 17, 2025 - -#### Bug fixes - -* Fix CalicoNodeStatus updates could get blocked by datastore errors [calico 10594](https://github.com/projectcalico/calico/pull/10594) (@theboringstuff) -* eBPF - Fixed mounting cgroupv2 for connect time load balancing. [calico 10505](https://github.com/projectcalico/calico/pull/10505) (@sridhartigera) -* eBPF - Fixed attaching bpf programs by atomically replacing the old program rather than attaching new and detaching old. [calico 10455](https://github.com/projectcalico/calico/pull/10455) (@sridhartigera) - -#### Updating - -To update a previous version of Calico, see [our upgrade guides](../operations/upgrading/index.mdx) - -### Calico Open Source 3.29.6 bug fix release - -September 18, 2025 - -#### Bug fixes - -* eBPF: Fix race between loading kubernetes services and conntrack cleanup. If conntrack cleanup ran before services were loaded, all service entries would look stale and get cleaned up. [calico 10725](https://github.com/projectcalico/calico/pull/10725) (@fasaxc) -* Add validation to guard against catch-all CIDRs (e.g. 0.0.0.0/0) on negated (notnets) policy rules, as those would effectively disallow all addresses. [calico 10687](https://github.com/projectcalico/calico/pull/10687) (@dzacball) - -#### Other changes - -* Calico is now built with go 1.24.7 [calico 10959](https://github.com/projectcalico/calico/pull/10959) (@MichalFupso) -* Remove manual Windows Kubernetes service installation [calico 10917](https://github.com/projectcalico/calico/pull/10917) (@song-jiang) - -#### Updating - -To update a previous version of Calico, see [our upgrade guides](../operations/upgrading/index.mdx) - -### Calico Open Source 3.29.7 bug fix release - -November 20, 2025 - -#### Bug fixes - -* eBPF: Fixed loading connecttime load balancer program in 6.12 kernel [calico 11405](https://github.com/projectcalico/calico/pull/11405) (@sridhartigera) -* Fix AllowSpoofedSourcePrefixes for dual stack clusters. [calico 11374](https://github.com/projectcalico/calico/pull/11374) (@lucastigera) -* Fix (release-tool): include image tarballs in release archive file [calico 11297](https://github.com/projectcalico/calico/pull/11297) (@radTuti) -* Fix: reinstate support for VMs that are configured not to respond to ARP requests. [calico 11271](https://github.com/projectcalico/calico/pull/11271) (@nelljerram) -* Fix that IPAM allocation could leak handles when many workloads are scheduled to the same node at the same time, causing timeouts by "thundering herd". [calico 11097](https://github.com/projectcalico/calico/pull/11097) (@fasaxc) -* Make Calico's backing CRDs optional. Calico will no longer fail to start if a CRD is missing. [calico 11037](https://github.com/projectcalico/calico/pull/11037) (@caseydavenport) - -#### Updating - -To update a previous version of Calico, see [our upgrade guides](../operations/upgrading/index.mdx) - diff --git a/calico_versioned_docs/version-3.29/releases.json b/calico_versioned_docs/version-3.29/releases.json deleted file mode 100644 index 5ca7f66070..0000000000 --- a/calico_versioned_docs/version-3.29/releases.json +++ /dev/null @@ -1,562 +0,0 @@ -[ - { - "title": "v3.29.7", - "tigera-operator": { - "image": "tigera/operator", - "registry": "quay.io", - "version": "v1.36.16" - }, - "components": { - "typha": { - "version": "v3.29.7", - "registry": "quay.io" - }, - "calicoctl": { - "version": "v3.29.7", - "registry": "quay.io" - }, - "calico/node": { - "version": "v3.29.7", - "registry": "quay.io" - }, - "calico/node-windows": { - "version": "v3.29.7", - "registry": "quay.io" - }, - "calico/cni": { - "version": "v3.29.7", - "registry": "quay.io" - }, - "calico/cni-windows": { - "version": "v3.29.7", - "registry": "quay.io" - }, - "calico/apiserver": { - "version": "v3.29.7", - "registry": "quay.io" - }, - "calico/kube-controllers": { - "version": "v3.29.7", - "registry": "quay.io" - }, - "calico/flannel-migration-controller": { - "version": "v3.29.7", - "registry": "quay.io" - }, - "calico/windows": { - "version": "v3.29.7", - "registry": "quay.io" - }, - "networking-calico": { - "version": "v3.29.7", - "registry": "quay.io" - }, - "flannel": { - "version": "v0.24.4", - "registry": "docker.io" - }, - "calico/dikastes": { - "version": "v3.29.7", - "registry": "quay.io" - }, - "flexvol": { - "version": "v3.29.7", - "registry": "quay.io" - }, - "csi-driver": { - "version": "v3.29.7", - "registry": "quay.io" - }, - "csi-node-driver-registrar": { - "version": "v3.29.7", - "registry": "quay.io" - } - } - }, - { - "title": "v3.29.6", - "tigera-operator": { - "image": "tigera/operator", - "registry": "quay.io", - "version": "v1.36.14" - }, - "components": { - "typha": { - "version": "v3.29.6", - "registry": "quay.io" - }, - "calicoctl": { - "version": "v3.29.6", - "registry": "quay.io" - }, - "calico/node": { - "version": "v3.29.6", - "registry": "quay.io" - }, - "calico/node-windows": { - "version": "v3.29.6", - "registry": "quay.io" - }, - "calico/cni": { - "version": "v3.29.6", - "registry": "quay.io" - }, - "calico/cni-windows": { - "version": "v3.29.6", - "registry": "quay.io" - }, - "calico/apiserver": { - "version": "v3.29.6", - "registry": "quay.io" - }, - "calico/kube-controllers": { - "version": "v3.29.6", - "registry": "quay.io" - }, - "calico/flannel-migration-controller": { - "version": "v3.29.6", - "registry": "quay.io" - }, - "calico/windows": { - "version": "v3.29.6", - "registry": "quay.io" - }, - "networking-calico": { - "version": "v3.29.6", - "registry": "quay.io" - }, - "flannel": { - "version": "v0.24.4", - "registry": "docker.io" - }, - "calico/dikastes": { - "version": "v3.29.6", - "registry": "quay.io" - }, - "flexvol": { - "version": "v3.29.6", - "registry": "quay.io" - }, - "csi-driver": { - "version": "v3.29.6", - "registry": "quay.io" - }, - "csi-node-driver-registrar": { - "version": "v3.29.6", - "registry": "quay.io" - } - } - }, - { - "title": "v3.29.5", - "tigera-operator": { - "image": "tigera/operator", - "registry": "quay.io", - "version": "v1.36.12" - }, - "components": { - "typha": { - "version": "v3.29.5", - "registry": "quay.io" - }, - "calicoctl": { - "version": "v3.29.5", - "registry": "quay.io" - }, - "calico/node": { - "version": "v3.29.5", - "registry": "quay.io" - }, - "calico/node-windows": { - "version": "v3.29.5", - "registry": "quay.io" - }, - "calico/cni": { - "version": "v3.29.5", - "registry": "quay.io" - }, - "calico/cni-windows": { - "version": "v3.29.5", - "registry": "quay.io" - }, - "calico/apiserver": { - "version": "v3.29.5", - "registry": "quay.io" - }, - "calico/kube-controllers": { - "version": "v3.29.5", - "registry": "quay.io" - }, - "calico/flannel-migration-controller": { - "version": "v3.29.5", - "registry": "quay.io" - }, - "calico/windows": { - "version": "v3.29.5", - "registry": "quay.io" - }, - "networking-calico": { - "version": "v3.29.5", - "registry": "quay.io" - }, - "flannel": { - "version": "v0.24.4", - "registry": "docker.io" - }, - "calico/dikastes": { - "version": "v3.29.5", - "registry": "quay.io" - }, - "flexvol": { - "version": "v3.29.5", - "registry": "quay.io" - }, - "csi-driver": { - "version": "v3.29.5", - "registry": "quay.io" - }, - "csi-node-driver-registrar": { - "version": "v3.29.5", - "registry": "quay.io" - } - } - }, - { - "title": "v3.29.4", - "tigera-operator": { - "image": "tigera/operator", - "registry": "quay.io", - "version": "v1.36.9" - }, - "components": { - "typha": { - "version": "v3.29.4", - "registry": "quay.io" - }, - "calicoctl": { - "version": "v3.29.4", - "registry": "quay.io" - }, - "calico/node": { - "version": "v3.29.4", - "registry": "quay.io" - }, - "calico/node-windows": { - "version": "v3.29.4", - "registry": "quay.io" - }, - "calico/cni": { - "version": "v3.29.4", - "registry": "quay.io" - }, - "calico/cni-windows": { - "version": "v3.29.4", - "registry": "quay.io" - }, - "calico/apiserver": { - "version": "v3.29.4", - "registry": "quay.io" - }, - "calico/kube-controllers": { - "version": "v3.29.4", - "registry": "quay.io" - }, - "calico/flannel-migration-controller": { - "version": "v3.29.4", - "registry": "quay.io" - }, - "calico/windows": { - "version": "v3.29.4", - "registry": "quay.io" - }, - "networking-calico": { - "version": "v3.29.4", - "registry": "quay.io" - }, - "flannel": { - "version": "v0.24.4", - "registry": "docker.io" - }, - "calico/dikastes": { - "version": "v3.29.4", - "registry": "quay.io" - }, - "flexvol": { - "version": "v3.29.4", - "registry": "quay.io" - }, - "csi-driver": { - "version": "v3.29.4", - "registry": "quay.io" - }, - "csi-node-driver-registrar": { - "version": "v3.29.4", - "registry": "quay.io" - } - } - }, - { - "title": "v3.29.3", - "tigera-operator": { - "image": "tigera/operator", - "registry": "quay.io", - "version": "v1.36.7" - }, - "components": { - "typha": { - "version": "v3.29.3", - "registry": "quay.io" - }, - "calicoctl": { - "version": "v3.29.3", - "registry": "quay.io" - }, - "calico/node": { - "version": "v3.29.3", - "registry": "quay.io" - }, - "calico/cni": { - "version": "v3.29.3", - "registry": "quay.io" - }, - "calico/apiserver": { - "version": "v3.29.3", - "registry": "quay.io" - }, - "calico/kube-controllers": { - "version": "v3.29.3", - "registry": "quay.io" - }, - "calico/flannel-migration-controller": { - "version": "v3.29.3", - "registry": "quay.io" - }, - "calico/windows": { - "version": "v3.29.3", - "registry": "quay.io" - }, - "networking-calico": { - "version": "v3.29.3", - "registry": "quay.io" - }, - "flannel": { - "version": "v0.24.4", - "registry": "docker.io" - }, - "calico/dikastes": { - "version": "v3.29.3", - "registry": "quay.io" - }, - "flexvol": { - "version": "v3.29.3", - "registry": "quay.io" - }, - "csi-driver": { - "version": "v3.29.3", - "registry": "quay.io" - }, - "csi-node-driver-registrar": { - "version": "v3.29.3", - "registry": "quay.io" - } - } - }, - { - "title": "v3.29.2", - "tigera-operator": { - "image": "tigera/operator", - "registry": "quay.io", - "version": "v1.36.5" - }, - "components": { - "typha": { - "version": "v3.29.2", - "registry": "quay.io" - }, - "calicoctl": { - "version": "v3.29.2", - "registry": "quay.io" - }, - "calico/node": { - "version": "v3.29.2", - "registry": "quay.io" - }, - "calico/cni": { - "version": "v3.29.2", - "registry": "quay.io" - }, - "calico/apiserver": { - "version": "v3.29.2", - "registry": "quay.io" - }, - "calico/kube-controllers": { - "version": "v3.29.2", - "registry": "quay.io" - }, - "calico/flannel-migration-controller": { - "version": "v3.29.2", - "registry": "quay.io" - }, - "calico/windows": { - "version": "v3.29.2", - "registry": "quay.io" - }, - "networking-calico": { - "version": "v3.29.2", - "registry": "quay.io" - }, - "flannel": { - "version": "v0.24.4", - "registry": "docker.io" - }, - "calico/dikastes": { - "version": "v3.29.2", - "registry": "quay.io" - }, - "flexvol": { - "version": "v3.29.2", - "registry": "quay.io" - }, - "csi-driver": { - "version": "v3.29.2", - "registry": "quay.io" - }, - "csi-node-driver-registrar": { - "version": "v3.29.2", - "registry": "quay.io" - } - } - }, - { - "title": "v3.29.1", - "tigera-operator": { - "image": "tigera/operator", - "registry": "quay.io", - "version": "v1.36.2" - }, - "components": { - "typha": { - "version": "v3.29.1", - "registry": "quay.io" - }, - "calicoctl": { - "version": "v3.29.1", - "registry": "quay.io" - }, - "calico/node": { - "version": "v3.29.1", - "registry": "quay.io" - }, - "calico/cni": { - "version": "v3.29.1", - "registry": "quay.io" - }, - "calico/apiserver": { - "version": "v3.29.1", - "registry": "quay.io" - }, - "calico/kube-controllers": { - "version": "v3.29.1", - "registry": "quay.io" - }, - "calico/flannel-migration-controller": { - "version": "v3.29.1", - "registry": "quay.io" - }, - "calico/windows": { - "version": "v3.29.1", - "registry": "quay.io" - }, - "networking-calico": { - "version": "v3.29.1", - "registry": "quay.io" - }, - "flannel": { - "version": "v0.24.4", - "registry": "docker.io" - }, - "calico/dikastes": { - "version": "v3.29.1", - "registry": "quay.io" - }, - "flexvol": { - "version": "v3.29.1", - "registry": "quay.io" - }, - "csi-driver": { - "version": "v3.29.1", - "registry": "quay.io" - }, - "csi-node-driver-registrar": { - "version": "v3.29.1", - "registry": "quay.io" - } - } - }, - { - "title": "v3.29.0", - "tigera-operator": { - "image": "tigera/operator", - "registry": "quay.io", - "version": "v1.36.0" - }, - "components": { - "typha": { - "version": "v3.29.0", - "registry": "quay.io" - }, - "calicoctl": { - "version": "v3.29.0", - "registry": "quay.io" - }, - "calico/node": { - "version": "v3.29.0", - "registry": "quay.io" - }, - "calico/cni": { - "version": "v3.29.0", - "registry": "quay.io" - }, - "calico/apiserver": { - "version": "v3.29.0", - "registry": "quay.io" - }, - "calico/kube-controllers": { - "version": "v3.29.0", - "registry": "quay.io" - }, - "calico/flannel-migration-controller": { - "version": "v3.29.0", - "registry": "quay.io" - }, - "calico/windows": { - "version": "v3.29.0", - "registry": "quay.io" - }, - "networking-calico": { - "version": "v3.29.0", - "registry": "quay.io" - }, - "flannel": { - "version": "v0.24.4", - "registry": "docker.io" - }, - "calico/dikastes": { - "version": "v3.29.0", - "registry": "quay.io" - }, - "flexvol": { - "version": "v3.29.0", - "registry": "quay.io" - }, - "csi-driver": { - "version": "v3.29.0", - "registry": "quay.io" - }, - "csi-node-driver-registrar": { - "version": "v3.29.0", - "registry": "quay.io" - } - } - } -] \ No newline at end of file diff --git a/calico_versioned_docs/version-3.29/variables.js b/calico_versioned_docs/version-3.29/variables.js deleted file mode 100644 index c6f297cffe..0000000000 --- a/calico_versioned_docs/version-3.29/variables.js +++ /dev/null @@ -1,46 +0,0 @@ -const releases = require('./releases.json'); - -const variables = { - releaseTitle: 'v3.29.7', - prodname: 'Calico', - prodnamedash: 'calico', - version: 'v3.29', - baseUrl: '/calico/3.29', - filesUrl: 'https://projectcalico.docs.tigera.io/v3.29', - tutorialFilesURL: 'https://docs.tigera.io/files', - calicoReleasesURL: 'https://github.com/projectcalico/calico/releases/download', - tmpScriptsURL: 'https://docs.tigera.io/calico/3.29', - windowsScriptsURL: 'https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/hostprocess', - prodnameWindows: 'Calico for Windows', - prodnamedashWindows: 'calico-for-windows', - nodecontainer: 'calico/node', - noderunning: 'calico-node', - rootDirWindows: 'C:\\CalicoWindows', - ppa_repo_name: 'calico-3.29', - manifestsUrl: 'https://raw.githubusercontent.com/projectcalico/calico/v3.29.7', - releases, - registry: '', - vppbranch: 'v3.29.0', - tigeraOperator: releases[0]['tigera-operator'], - tigeraOperatorVersionShort: releases[0]['tigera-operator'].version.split('.').slice(0, 2).join('.'), - imageNames: { - 'calico/node': 'calico/node', - calicoctl: 'calico/ctl', - typha: 'calico/typha', - 'calico/cni': 'calico/cni', - 'calico/apiserver': 'calico/apiserver', - 'calico/kube-controllers': 'calico/kube-controllers', - 'calico-upgrade': 'calico-upgrade', - 'calico/node-windows': 'calico/node-windows', - 'calico/cni-windows': 'calico/cni-windows', - flannel: 'docker.io/flannelcni/flannel', - flannelMigration: 'calico/flannel-migration-controller', - 'calico/dikastes': 'calico/dikastes', - 'pilot-webhook': 'calico/pilot-webhook', - flexvol: 'calico/pod2daemon-flexvol', - 'csi-driver': 'calico/csi', - 'csi-node-driver-registrar': 'calico/node-driver-registrar', - }, -}; - -module.exports = variables; diff --git a/calico_versioned_sidebars/version-3.29-sidebars.json b/calico_versioned_sidebars/version-3.29-sidebars.json deleted file mode 100644 index ce9ee97984..0000000000 --- a/calico_versioned_sidebars/version-3.29-sidebars.json +++ /dev/null @@ -1,771 +0,0 @@ -{ - "calicoSidebar": [ - { - "type": "category", - "label": "About Calico", - "link": { - "type": "doc", - "id": "about/index" - }, - "items": [ - "about/calico-product-editions", - "about/training-resources", - { - "type": "category", - "label": "Kubernetes training", - "link": { - "type": "doc", - "id": "about/kubernetes-training/index" - }, - "items": [ - "about/kubernetes-training/about-k8s-networking", - "about/kubernetes-training/about-networking", - "about/kubernetes-training/about-network-policy", - "about/kubernetes-training/about-kubernetes-ingress", - "about/kubernetes-training/about-kubernetes-egress", - "about/kubernetes-training/about-kubernetes-services" - ] - }, - "about/kubernetes-training/about-ebpf" - ] - }, - { - "type": "category", - "label": "Installing and upgrading", - "link": { - "type": "doc", - "id": "getting-started/index" - }, - "items": [ - "getting-started/kubernetes/requirements", - "getting-started/kubernetes/community-tested", - "getting-started/kubernetes/quickstart", - "getting-started/kubernetes/managed-public-cloud/eks", - "getting-started/kubernetes/managed-public-cloud/gke", - "getting-started/kubernetes/managed-public-cloud/iks", - { - "type": "category", - "label": "Installing on AKS", - "link": null, - "items": [ - "getting-started/kubernetes/managed-public-cloud/aks", - "getting-started/kubernetes/managed-public-cloud/aks-migrate" - ] - }, - "getting-started/kubernetes/self-managed-public-cloud/aws", - "getting-started/kubernetes/self-managed-public-cloud/gce", - "getting-started/kubernetes/self-managed-public-cloud/azure", - "getting-started/kubernetes/self-managed-public-cloud/do", - "getting-started/kubernetes/self-managed-onprem/onpremises", - "getting-started/kubernetes/self-managed-onprem/config-options", - { - "type": "category", - "label": "Installing for network policy on hosts and VMs", - "link": { - "type": "doc", - "id": "getting-started/bare-metal/index" - }, - "items": [ - "getting-started/bare-metal/about", - "getting-started/bare-metal/requirements", - { - "type": "category", - "label": "Installation", - "link": { - "type": "doc", - "id": "getting-started/bare-metal/installation/index" - }, - "items": [ - "getting-started/bare-metal/installation/container", - "getting-started/bare-metal/installation/binary-mgr", - "getting-started/bare-metal/installation/binary" - ] - } - ] - }, - { - "type": "category", - "label": "Installing on OpenShift", - "link": { - "type": "doc", - "id": "getting-started/kubernetes/openshift/index" - }, - "items": [ - "getting-started/kubernetes/openshift/requirements", - "getting-started/kubernetes/openshift/installation", - "getting-started/kubernetes/openshift/hostedcontrolplanes", - "getting-started/kubernetes/openshift/ovn-to-calico" - ] - }, - "getting-started/kubernetes/rancher", - { - "type": "category", - "label": "Installing with flannel", - "link": { - "type": "doc", - "id": "getting-started/kubernetes/flannel/index" - }, - "items": [ - "getting-started/kubernetes/flannel/install-for-flannel", - "getting-started/kubernetes/flannel/migration-from-flannel" - ] - }, - { - "type": "category", - "label": "Installing on Windows", - "link": { - "type": "doc", - "id": "getting-started/kubernetes/windows-calico/index" - }, - "items": [ - "getting-started/kubernetes/windows-calico/limitations", - "getting-started/kubernetes/windows-calico/requirements", - "getting-started/kubernetes/windows-calico/operator", - "getting-started/kubernetes/windows-calico/rancher", - "getting-started/kubernetes/windows-calico/demo", - "getting-started/kubernetes/windows-calico/troubleshoot" - ] - }, - { - "type": "category", - "label": "Installing on K3s", - "link": { - "type": "doc", - "id": "getting-started/kubernetes/k3s/index" - }, - "items": ["getting-started/kubernetes/k3s/quickstart", "getting-started/kubernetes/k3s/multi-node-install"] - }, - "getting-started/kubernetes/helm", - "getting-started/kubernetes/microk8s", - "getting-started/kubernetes/minikube", - "getting-started/kubernetes/kind", - { - "type": "category", - "label": "Tutorial: Calico the hard way", - "link": { - "type": "doc", - "id": "getting-started/kubernetes/hardway/index" - }, - "items": [ - "getting-started/kubernetes/hardway/overview", - "getting-started/kubernetes/hardway/standing-up-kubernetes", - "getting-started/kubernetes/hardway/the-calico-datastore", - "getting-started/kubernetes/hardway/configure-ip-pools", - "getting-started/kubernetes/hardway/install-cni-plugin", - "getting-started/kubernetes/hardway/install-typha", - "getting-started/kubernetes/hardway/install-node", - "getting-started/kubernetes/hardway/configure-bgp-peering", - "getting-started/kubernetes/hardway/test-networking", - "getting-started/kubernetes/hardway/test-network-policy", - "getting-started/kubernetes/hardway/end-user-rbac", - "getting-started/kubernetes/hardway/istio-integration" - ] - }, - { - "type": "category", - "label": "Upgrading", - "link": { - "type": "doc", - "id": "operations/upgrading/index" - }, - "items": [ - "operations/upgrading/kubernetes-upgrade", - "operations/upgrading/openshift-upgrade", - "operations/upgrading/openstack-upgrade" - ] - }, - { - "type": "category", - "label": "Data plane guide: eBPF", - "link": { - "type": "doc", - "id": "operations/ebpf/index" - }, - "items": [ - "operations/ebpf/use-cases-ebpf", - "operations/ebpf/enabling-ebpf", - "operations/ebpf/install", - "operations/ebpf/troubleshoot-ebpf" - ] - }, - "getting-started/kubernetes/nftables", - { - "type": "category", - "label": "Data plane guide: VPP", - "link": { - "type": "doc", - "id": "getting-started/kubernetes/vpp/index" - }, - "items": [ - "getting-started/kubernetes/vpp/getting-started", - "getting-started/kubernetes/vpp/ipsec", - "getting-started/kubernetes/vpp/specifics", - "getting-started/kubernetes/vpp/openshift" - ] - }, - { - "type": "category", - "label": "Installing on OpenStack", - "link": { - "type": "doc", - "id": "getting-started/openstack/index" - }, - "items": [ - "getting-started/openstack/overview", - "getting-started/openstack/requirements", - { - "type": "category", - "label": "Installation", - "link": { - "type": "doc", - "id": "getting-started/openstack/installation/index" - }, - "items": [ - "getting-started/openstack/installation/overview", - "getting-started/openstack/installation/ubuntu", - "getting-started/openstack/installation/redhat", - "getting-started/openstack/installation/devstack", - "getting-started/openstack/installation/verification" - ] - } - ] - } - ] - }, - { - "type": "category", - "label": "Networking", - "link": { - "type": "doc", - "id": "networking/index" - }, - "items": [ - "networking/determine-best-networking", - { - "type": "category", - "label": "Configure networking", - "link": { - "type": "doc", - "id": "networking/configuring/index" - }, - "items": [ - "networking/configuring/bgp", - "networking/configuring/vxlan-ipip", - "networking/configuring/advertise-service-ips", - "networking/configuring/mtu", - "networking/configuring/workloads-outside-cluster", - "networking/configuring/use-ipvs", - "networking/configuring/sidecar-acceleration", - "networking/configuring/pod-mac-address", - "networking/configuring/node-local-dns-cache" - ] - }, - { - "type": "category", - "label": "Customize IP address management", - "link": { - "type": "doc", - "id": "networking/ipam/index" - }, - "items": [ - "networking/ipam/get-started-ip-addresses", - "networking/ipam/ippools", - "networking/ipam/ip-autodetection", - "networking/ipam/ipv6", - "networking/ipam/ipv6-control-plane", - "networking/ipam/add-floating-ip", - "networking/ipam/use-specific-ip", - "networking/ipam/assign-ip-addresses-topology", - "networking/ipam/migrate-pools", - "networking/ipam/change-block-size", - "networking/ipam/legacy-firewalls" - ] - }, - { - "type": "category", - "label": "Calico networking for OpenStack", - "link": { - "type": "doc", - "id": "networking/openstack/index" - }, - "items": [ - "networking/openstack/dev-machine-setup", - "networking/openstack/ipv6", - "networking/openstack/connectivity", - "networking/openstack/labels", - "networking/openstack/configuration", - "networking/openstack/semantics", - "networking/openstack/floating-ips", - "networking/openstack/service-ips", - "networking/openstack/host-routes", - "networking/openstack/multiple-regions", - "networking/openstack/kuryr", - "networking/openstack/neutron-api" - ] - } - ] - }, - { - "type": "category", - "label": "Network policy", - "link": { - "type": "doc", - "id": "network-policy/index" - }, - "items": [ - "network-policy/adopt-zero-trust", - { - "type": "category", - "label": "Get started with policy", - "link": { - "type": "doc", - "id": "network-policy/get-started/index" - }, - "items": [ - { - "type": "category", - "label": "Calico policy", - "link": { - "type": "doc", - "id": "network-policy/get-started/calico-policy/index" - }, - "items": [ - "network-policy/get-started/calico-policy/calico-network-policy", - "network-policy/get-started/calico-policy/calico-labels", - "network-policy/get-started/calico-policy/network-policy-openstack", - "network-policy/get-started/calico-policy/calico-policy-tutorial" - ] - }, - { - "type": "category", - "label": "Kubernetes policy", - "link": { - "type": "doc", - "id": "network-policy/get-started/kubernetes-policy/index" - }, - "items": [ - "network-policy/get-started/kubernetes-policy/kubernetes-network-policy", - "network-policy/get-started/kubernetes-policy/kubernetes-demo", - "network-policy/get-started/kubernetes-policy/kubernetes-policy-basic", - "network-policy/get-started/kubernetes-policy/kubernetes-policy-advanced" - ] - }, - "network-policy/get-started/kubernetes-default-deny" - ] - }, - { - "type": "category", - "label": "Tiered policy", - "link": { - "type": "doc", - "id": "network-policy/policy-tiers/index" - }, - "items": ["network-policy/policy-tiers/tiered-policy", "network-policy/policy-tiers/rbac-tiered-policies"] - }, - { - "type": "category", - "label": "Policy rules", - "link": { - "type": "doc", - "id": "network-policy/policy-rules/index" - }, - "items": [ - "network-policy/policy-rules/policy-rules-overview", - "network-policy/policy-rules/namespace-policy", - "network-policy/policy-rules/service-policy", - "network-policy/policy-rules/service-accounts", - "network-policy/policy-rules/external-ips-policy", - "network-policy/policy-rules/icmp-ping", - "network-policy/policy-rules/log-rules" - ] - }, - { - "type": "category", - "label": "Policy for hosts and VMs", - "link": { - "type": "doc", - "id": "network-policy/hosts/index" - }, - "items": [ - "network-policy/hosts/protect-hosts", - "network-policy/hosts/kubernetes-nodes", - "network-policy/hosts/protect-hosts-tutorial", - "network-policy/hosts/host-forwarded-traffic" - ] - }, - { - "type": "category", - "label": "Policy for services", - "link": { - "type": "doc", - "id": "network-policy/services/index" - }, - "items": ["network-policy/services/kubernetes-node-ports", "network-policy/services/services-cluster-ips"] - }, - { - "type": "category", - "label": "Policy for Istio", - "link": { - "type": "doc", - "id": "network-policy/istio/index" - }, - "items": [ - "network-policy/istio/app-layer-policy", - "network-policy/istio/http-methods", - "network-policy/istio/enforce-policy-istio" - ] - }, - { - "type": "category", - "label": "Policy for extreme traffic", - "link": { - "type": "doc", - "id": "network-policy/extreme-traffic/index" - }, - "items": [ - "network-policy/extreme-traffic/high-connection-workloads", - "network-policy/extreme-traffic/defend-dos-attack" - ] - }, - "network-policy/encrypt-cluster-pod-traffic", - { - "type": "category", - "label": "Secure Calico component communications", - "link": { - "type": "doc", - "id": "network-policy/comms/index" - }, - "items": [ - "network-policy/comms/crypto-auth", - "network-policy/comms/reduce-nodes", - "network-policy/comms/secure-metrics", - "network-policy/comms/secure-bgp" - ] - } - ] - }, - { - "type": "category", - "label": "Operations", - "link": { - "type": "doc", - "id": "operations/index" - }, - "items": [ - { - "type": "category", - "label": "calicoctl", - "link": { - "type": "doc", - "id": "operations/calicoctl/index" - }, - "items": [ - "operations/calicoctl/install", - { - "type": "category", - "label": "Configure calicoctl", - "link": { - "type": "doc", - "id": "operations/calicoctl/configure/index" - }, - "items": [ - "operations/calicoctl/configure/overview", - "operations/calicoctl/configure/etcd", - "operations/calicoctl/configure/kdd" - ] - } - ] - }, - { - "type": "category", - "label": "Deploy image options", - "link": { - "type": "doc", - "id": "operations/image-options/index" - }, - "items": ["operations/image-options/imageset", "operations/image-options/alternate-registry"] - }, - "operations/datastore-migration", - "operations/operator-migration", - "operations/install-apiserver", - - { - "type": "category", - "label": "Monitor", - "link": { - "type": "doc", - "id": "operations/monitor/index" - }, - "items": ["operations/monitor/monitor-component-metrics", "operations/monitor/monitor-component-visual"] - }, - "operations/decommissioning-a-node", - "operations/fips", - { - "type": "category", - "label": "Troubleshoot", - "link": { - "type": "doc", - "id": "operations/troubleshoot/index" - }, - "items": [ - "operations/troubleshoot/troubleshooting", - "operations/troubleshoot/commands", - "operations/troubleshoot/component-logs", - "operations/troubleshoot/vpp" - ] - }, - "operations/certificate-management" - ] - }, - { - "type": "category", - "label": "Reference", - "link": { - "type": "doc", - "id": "reference/index" - }, - "items": [ - "reference/api", - { - "type": "doc", - "id": "reference/installation/api", - "label": "Installation API" - }, - "reference/installation/helm_customization", - { - "type": "category", - "label": "calicoctl", - "link": { - "type": "doc", - "id": "reference/calicoctl/index" - }, - "items": [ - "reference/calicoctl/overview", - "reference/calicoctl/create", - "reference/calicoctl/replace", - "reference/calicoctl/apply", - "reference/calicoctl/delete", - "reference/calicoctl/get", - "reference/calicoctl/patch", - "reference/calicoctl/label", - "reference/calicoctl/convert", - { - "type": "category", - "label": "ipam", - "link": { - "type": "doc", - "id": "reference/calicoctl/ipam/index" - }, - "items": [ - "reference/calicoctl/ipam/overview", - "reference/calicoctl/ipam/check", - "reference/calicoctl/ipam/release", - "reference/calicoctl/ipam/show", - "reference/calicoctl/ipam/configure", - "reference/calicoctl/ipam/split" - ] - }, - { - "type": "category", - "label": "node", - "link": { - "type": "doc", - "id": "reference/calicoctl/node/index" - }, - "items": [ - "reference/calicoctl/node/overview", - "reference/calicoctl/node/run", - "reference/calicoctl/node/status", - "reference/calicoctl/node/diags", - "reference/calicoctl/node/checksystem" - ] - }, - { - "type": "category", - "label": "datastore", - "link": { - "type": "doc", - "id": "reference/calicoctl/datastore/index" - }, - "items": [ - "reference/calicoctl/datastore/overview", - { - "type": "category", - "label": "migrate", - "link": { - "type": "doc", - "id": "reference/calicoctl/datastore/migrate/index" - }, - "items": [ - "reference/calicoctl/datastore/migrate/overview", - "reference/calicoctl/datastore/migrate/export", - "reference/calicoctl/datastore/migrate/import", - "reference/calicoctl/datastore/migrate/lock", - "reference/calicoctl/datastore/migrate/unlock" - ] - } - ] - }, - "reference/calicoctl/version" - ] - }, - { - "type": "category", - "label": "Resource definitions", - "link": { - "type": "doc", - "id": "reference/resources/index" - }, - "items": [ - "reference/resources/overview", - "reference/resources/bgpconfig", - "reference/resources/bgppeer", - "reference/resources/bgpfilter", - "reference/resources/blockaffinity", - "reference/resources/caliconodestatus", - "reference/resources/felixconfig", - "reference/resources/globalnetworkpolicy", - "reference/resources/globalnetworkset", - "reference/resources/hostendpoint", - "reference/resources/ippool", - "reference/resources/ipreservation", - "reference/resources/ipamconfig", - "reference/resources/kubecontrollersconfig", - "reference/resources/networkpolicy", - "reference/resources/networkset", - "reference/resources/node", - "reference/resources/profile", - "reference/resources/tier", - "reference/resources/workloadendpoint" - ] - }, - { - "type": "category", - "label": "Configuring etcd RBAC", - "link": { - "type": "doc", - "id": "reference/etcd-rbac/index" - }, - "items": [ - "reference/etcd-rbac/overview", - "reference/etcd-rbac/certificate-generation", - "reference/etcd-rbac/users-and-roles", - "reference/etcd-rbac/kubernetes", - "reference/etcd-rbac/kubernetes-advanced", - "reference/etcd-rbac/calico-etcdv3-paths" - ] - }, - "reference/configure-calico-node", - "reference/configure-resources", - { - "type": "category", - "label": "Felix", - "link": { - "type": "doc", - "id": "reference/felix/index" - }, - "items": ["reference/felix/configuration", "reference/felix/prometheus"] - }, - { - "type": "category", - "label": "Typha", - "link": { - "type": "doc", - "id": "reference/typha/index" - }, - "items": ["reference/typha/overview", "reference/typha/configuration", "reference/typha/prometheus"] - }, - "reference/configure-cni-plugins", - { - "type": "category", - "label": "Calico Kubernetes controllers", - "link": { - "type": "doc", - "id": "reference/kube-controllers/index" - }, - "items": ["reference/kube-controllers/configuration", "reference/kube-controllers/prometheus"] - }, - { - "type": "category", - "label": "Configuration on public clouds", - "link": { - "type": "doc", - "id": "reference/public-cloud/index" - }, - "items": [ - "reference/public-cloud/aws", - "reference/public-cloud/azure", - "reference/public-cloud/gce", - "reference/public-cloud/ibm" - ] - }, - { - "type": "category", - "label": "Host endpoints", - "link": { - "type": "doc", - "id": "reference/host-endpoints/index" - }, - "items": [ - "reference/host-endpoints/overview", - "reference/host-endpoints/connectivity", - "reference/host-endpoints/objects", - "reference/host-endpoints/selector", - "reference/host-endpoints/failsafe", - "reference/host-endpoints/pre-dnat", - "reference/host-endpoints/forwarded", - "reference/host-endpoints/summary", - "reference/host-endpoints/conntrack" - ] - }, - { - "type": "category", - "label": "Architecture", - "link": { - "type": "doc", - "id": "reference/architecture/index" - }, - "items": [ - "reference/architecture/overview", - "reference/architecture/data-path", - { - "type": "category", - "label": "Network design", - "link": { - "type": "doc", - "id": "reference/architecture/design/index" - }, - "items": [ - "reference/architecture/design/l2-interconnect-fabric", - "reference/architecture/design/l3-interconnect-fabric" - ] - } - ] - }, - { - "type": "category", - "label": "VPP data plane", - "link": { - "type": "doc", - "id": "reference/vpp/index" - }, - "items": [ - "reference/vpp/uplink-configuration", - "reference/vpp/technical-details", - "reference/vpp/host-network" - ] - }, - "reference/component-versions", - "reference/faq", - "reference/involved", - { - "type": "link", - "label": "Attributions", - "href": "pathname:///calico/3.29/licenses/third-party-attributions.html" - } - ] - }, - "release-notes/index", - "get-help/support" - ] -} diff --git a/calico_versions.json b/calico_versions.json index 8d3a4ecabe..e7b2c3ccad 100644 --- a/calico_versions.json +++ b/calico_versions.json @@ -1,6 +1,5 @@ [ "3.32", "3.31", - "3.30", - "3.29" + "3.30" ] diff --git a/docusaurus.config.js b/docusaurus.config.js index 7637cf28fd..26f7015ea5 100644 --- a/docusaurus.config.js +++ b/docusaurus.config.js @@ -435,7 +435,7 @@ export default async function createAsyncConfig() { path: 'calico', routeBasePath: 'calico', editCurrentVersion: true, - onlyIncludeVersions: [...nextVersion, '3.32', '3.31', '3.30', '3.29'], + onlyIncludeVersions: [...nextVersion, '3.32', '3.31', '3.30'], lastVersion: '3.32', versions: { current: { @@ -458,11 +458,6 @@ export default async function createAsyncConfig() { path: '3.30', banner: 'none', }, - 3.29: { - label: '3.29', - path: '3.29', - banner: 'none', - }, }, sidebarPath: './sidebars-calico.js', beforeDefaultRemarkPlugins: [variablesPlugin], diff --git a/scripts/update-felix-config.sh b/scripts/update-felix-config.sh index ea17569e9b..49ceecb471 100755 --- a/scripts/update-felix-config.sh +++ b/scripts/update-felix-config.sh @@ -92,11 +92,6 @@ update_versions_OSS () { LOCAL_PATH="calico_versioned_docs/version-${VERSION}/_includes/components/FelixConfig/config-params.json" REMOTE_URL="https://raw.githubusercontent.com/projectcalico/calico/refs/heads/release-v${VERSION}/felix/docs/config-params.json" - if [[ "$VERSION" == "3.29" ]]; then - echo "Skipping ${VERSION}: No action required." - continue - fi - update_felix_config done } diff --git a/src/pages/archive.md b/src/pages/archive.md index d6a370e7d2..7d7f087ece 100644 --- a/src/pages/archive.md +++ b/src/pages/archive.md @@ -10,7 +10,7 @@ description: Links to all versions of product documentation for Calico, Calico E * [Calico Open Source 3.32](https://docs.tigera.io/calico/latest/about) * [Calico Open Source 3.31](https://docs.tigera.io/calico/3.31/about) * [Calico Open Source 3.30](https://docs.tigera.io/calico/3.30/about) -* [Calico Open Source 3.29](https://docs.tigera.io/calico/3.29/about) +* [Calico Open Source 3.29](https://archive-os-3-29.netlify.app/calico/3.29/about) * [Calico Open Source 3.28](https://archive-os-3-28.netlify.app/calico/3.28/about) * [Calico Open Source 3.27](https://archive-os-3-27.netlify.app/calico/3.27/about) * [Calico Open Source 3.26](https://archive-os-3-26.netlify.app/calico/3.26/) diff --git a/static/_redirects b/static/_redirects index 5be9eda639..7e5243bb75 100644 --- a/static/_redirects +++ b/static/_redirects @@ -50,6 +50,7 @@ /calico-enterprise/3.14/ /calico-enterprise/3.14/about-calico-enterprise 301 # For archived Docusaurus-native docs sets +/calico/3.29/* https://archive-os-3-29.netlify.app/calico/3.29/:splat 301 /calico/3.28/* https://archive-os-3-28.netlify.app/calico/3.28/:splat 301 /calico/3.27/* https://archive-os-3-27.netlify.app/calico/3.27/:splat 301 /calico/3.26/* https://archive-os-3-26.netlify.app/calico/3.26/:splat 301