We've discontinued the registration of new Bundles

New Bundle registrations are no longer accepted. Existing bundles remain functional. We recommend using the Juju Terraform Provider for new deployments.

Canonical Kubernetes Canal

Canonical Kubernetes Publisher | bundle

Platform:

Ubuntu
Channel Revision Published
latest/stable 1233 16 Dec 2021
latest/candidate 1185 26 Oct 2021
latest/beta 1233 15 Dec 2021
latest/edge 1281 01 Feb 2022
juju deploy canonical-kubernetes-canal

Learn about configurations >

  • channel | string

    Default: 1.35/stable

    Snap channel to install Kubernetes worker services from

  • ignore-missing-cni | boolean

    If ignore-missing-cni is set to true, the charm will not enter a blocked state if a CNI has not been configured/provided via relation. If ignore-missing-cni is set to false, and a CNI has not been configured/provided via relation, then the charm will enter a blocked state with the message: "Missing CNI relation or config".

  • ingress | boolean

    Default: True

    Deploy nginx-ingress-controller to handle Ingress resources. When set to true, the unit will open ports 80 and 443 to make the nginx-ingress-controller endpoint accessible.

  • ingress-default-ssl-certificate | string

    SSL certificate to be used by the default HTTPS server. If one of the flag ingress-default-ssl-certificate or ingress-default-ssl-key is not provided ingress will use a self-signed certificate. This parameter is specific to nginx-ingress-controller.

  • ingress-default-ssl-key | string

    Private key to be used by the default HTTPS server. If one of the flag ingress-default-ssl-certificate or ingress-default-ssl-key is not provided ingress will use a self-signed certificate. This parameter is specific to nginx-ingress-controller.

  • ingress-proxy-real-ip-cidr | string

    Default: 0.0.0.0/0

    If `ingress-use-forwarded-headers` is enabled, `ingress-proxy-real-ip-cidr` defines the default IP/network address of your external load balancer. Can be a comma-separated list of CIDR blocks. By default NGINX uses the content of the header `X-Forwarded-For` as the source of truth to get information about the client IP address. This works without issues in L7 if we configure the setting `ingress-proxy-real-ip-cidr` with the correct information of the IP/network address of trusted external load balancer. References: - https://kubernetes.github.io/ingress-nginx/user-guide/miscellaneous/#source-ip-address - https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#proxy-real-ip-cidr

  • ingress-ssl-chain-completion | boolean

    Enable chain completion for TLS certificates used by the nginx ingress controller. Set this to true if you would like the ingress controller to attempt auto-retrieval of intermediate certificates. The default (false) is recommended for all production kubernetes installations, and any environment which does not have outbound Internet access.

  • ingress-ssl-passthrough | boolean

    Enable ssl passthrough on ingress server. This allows passing the ssl connection through to the workloads and not terminating it at the ingress controller.

  • ingress-use-forwarded-headers | boolean

    If true, NGINX passes the incoming X-Forwarded-* headers to upstreams. Use this option when NGINX is behind another L7 proxy / load balancer that is setting these headers. If false, NGINX ignores incoming X-Forwarded-* headers, filling them with the request information it sees. Use this option if NGINX is exposed directly to the internet, or it's behind a L3/packet-based load balancer that doesn't alter the source IP in the packets. Reference: https://github.com/kubernetes/ingress-nginx/blob/a9c706be12a8be418c49ab1f60a02f52f9b14e55/docs/user-guide/nginx-configuration/configmap.md#use-forwarded-headers. docs/user-guide/nginx-configuration/configmap.md#use-forwarded-headers.

  • kubelet-extra-args | string

    Space separated list of flags and key=value pairs that will be passed as arguments to kubelet. For example a value like this: runtime-config=batch/v2alpha1=true profiling=true will result in kubelet being run with the following options: --runtime-config=batch/v2alpha1=true --profiling=true

  • kubelet-extra-config | string

    Default: {}

    Extra configuration to be passed to kubelet. Any values specified in this config will be merged into a KubeletConfiguration file that is passed to the kubelet service via the --config flag. This can be used to override values provided by the charm. The value for this config must be a YAML mapping that can be safely merged with a KubeletConfiguration file. For example: {evictionHard: {memory.available: 200Mi}} For more information about KubeletConfiguration, see upstream docs: https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/

  • labels | string

    Labels can be used to organize and to select subsets of nodes in the cluster. Declare node labels in key=value format, separated by spaces.

  • nginx-image | string

    Default: auto

    Container image to use for the nginx ingress controller. Using "auto" will select an image based on architecture. Example: quay.io/kubernetes-ingress-controller/nginx-ingress-controller-amd64:0.32.0

  • proxy-extra-args | string

    Space separated list of flags and key=value pairs that will be passed as arguments to kube-proxy. For example a value like this: runtime-config=batch/v2alpha1=true profiling=true will result in kube-apiserver being run with the following options: --runtime-config=batch/v2alpha1=true --profiling=true

  • proxy-extra-config | string

    Default: {}

    Extra configuration to be passed to kube-proxy. Any values specified in this config will be merged into a KubeProxyConfiguration file that is passed to the kube-proxy service via the --config flag. This can be used to override values provided by the charm. The value for this config must be a YAML mapping that can be safely merged with a KubeProxyConfiguration file. For example: {mode: ipvs, ipvs: {strictARP: true}} For more information about KubeProxyConfiguration, see upstream docs: https://kubernetes.io/docs/reference/config-api/kube-proxy-config.v1alpha1/

  • sysctl | string

    Default: {net.ipv4.conf.all.forwarding: 1, net.ipv4.conf.all.rp_filter: 1, net.ipv4.neigh.default.gc_thresh1: 128, net.ipv4.neigh.default.gc_thresh2: 28672, net.ipv4.neigh.default.gc_thresh3: 32768, net.ipv6.neigh.default.gc_thresh1: 128, net.ipv6.neigh.default.gc_thresh2: 28672, net.ipv6.neigh.default.gc_thresh3: 32768, fs.inotify.max_user_instances: 8192, fs.inotify.max_user_watches: 1048576, kernel.panic: 10, kernel.panic_on_oops: 1, vm.overcommit_memory: 1}

    YAML formatted associative array of sysctl values, e.g.: '{kernel.pid_max: 4194303}'. Note that kube-proxy handles the conntrack settings. The proper way to alter them is to use the proxy-extra-args config to set them, e.g.: juju config kubernetes-control-plane proxy-extra-args="conntrack-min=1000000 conntrack-max-per-core=250000" juju config kubernetes-worker proxy-extra-args="conntrack-min=1000000 conntrack-max-per-core=250000" The proxy-extra-args conntrack-min and conntrack-max-per-core can be set to 0 to ignore kube-proxy's settings and use the sysctl settings instead. Note the fundamental difference between the setting of conntrack-max-per-core vs nf_conntrack_max.