Customizing the manifests

About customizing manifests

We provide a number of manifests to make deployment of Calico easy. You can optionally
modify the manifests before applying them. Or you can modify the manifest and reapply it to change
settings as needed.

Refer to the section that corresponds to the manifest you wish to modify for more details.

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 calico/node.

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 calico/node, 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 calico/node, 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 calico/node, 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:

Download the v3.2 manifest that corresponds to your installation method.

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.

Using a command like the following to strip the newlines from the files and
base64-encode their contents.

cat <file> | base64 -w 0

In the Secret named calico-etcd-secrets, uncomment etcd_ca, etcd_key, and etcd_cert
and paste in the appropriate base64-encoded values.

apiVersion:v1kind:Secrettype:Opaquemetadata:name:calico-etcd-secretsnamespace:kube-systemdata:# 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=

Apply the manifest.

Calico for policy and networking

kubectl apply -f calico.yaml

Calico for policy and flannel for networking

kubectl apply -f canal.yaml

Authorization options

Calico’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.

Customizing application layer policy manifests

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.

Sidecar injector

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 Calico policy
from Felix and applies it to incoming connections and requests.

If you haven’t already done so, download an
Istio release 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.

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.