Deploy Controller and TAPs

You can deploy the Controller and TAPs using the YAML files or the Helm Charts. For details, view the following:

Using YAML files
Using Helm Charts

Using YAML files

YAML files are available for each and every release build in the Gigamon software portal.

Download the respective release build from the repository.
Untar the .tgz file.
Extract the YAML file and further update the fields in uctc-controller.yaml and uctc-tap.yaml file.

For information on downloading the respective build from the Gigamon software portal, Contact Gigamon Technical Support or Sales.

Deployment of Controller

Follow these steps to deploy the Controller:

Use the below command to Unzip and Untar the .tgz file.

gunzip <name of the UCT-C Controller .tgz file>

tar -xvf <name of the UCT-C Controller .tar file>

Navigate to the YAML folder in the newly created uctc-cntlr-<image version>-<build number> folder and update the details given in the below steps.

Provide the created secret in the following section of the YAML file:

imagePullSecrets:

- name: <secret>

Provide the FM IP address in the following section of the YAML file:

command:

- /uct-controller

- <FM IPv4 or FM IPv6 or FM IPv4,FM IPv6(both with comma-separation notation)>

- '443'

- '8443'

- '0'

- "/etc/gcbcerts"

- "gcb-cert.pem"

- "gcb-pvt-key.pem"

- "gcb-ca-root-cert.pem"

Refer to the below examples:

# example1: 192.168.0.10 (IPv4)

# example2: 2001:db8:abcd:ef01::5 (IPv6)

# example3: 192.168.0.10,2001:db8:abcd:ef01::5 (IPv4,IPv6)

If you provide both IPv4 and IPv6 addresses in the above argument, use the following configurations:

- name: UCTC_CNTLR_FM_IP_CONFIG

value: IPv4 or IPv6

- name: UCTC_CNTLR_FALLBACK_CONFIG

value: True or False

IP CONFIG option allows the user to provide the preferred IP version. If the user does not provide any value, the default value IPv4 will be used.

When the preferred IP version fails to connect (example: IPv6), FALLBACK CONFIG is used to connect to the other available IP version (example: IPv4). Default value True is used to consider the Fallback mechanism.

Notes:

Fallback configuration will be used during node registration phase only.

Controller FM IP and FALLBACK configurations is used only if you provide both IPv4 and IPv6.

If you provide IPv4 alone, only IPv4 connections will be considered, and UCTC_CNTLR_FM_IP_CONFIG and UCTC_CNTLR_FALLBACK_CONFIG is disregarded. Similarly, if IPv6 alone is provided, only IPv6 connections is considered.

Default values are used if you do not provide any options.

Note

In dual stack cluster, update the following fields in uctc-cntlr-service to deploy dual stack setup.

Spec:

ipFamilies:

- Ipv4

- IPv6

ipFamilyPolicy: PreferDualStack

Provide External IP and Kubernetes Cluster API URL in the following section of the YAML file:

env:

- name: UCTC_CNTLR_SERVICE_NAME

value: "GIGAMON_UCTC_CNTLR_SERVICE"

- name: UCTC_CNTLR_EXT_IP_DNS

value: "<external IPv4 or external IPv6 or external IPv4,IPv6(both with comma-separation notation) or DNS"

Refer to the below examples.

# example1: 192.168.0.10 (IPv4)

# example2: 2001:db8:abcd:ef01::5 (IPv6)

# example3: 192.168.0.10,2001:db8:abcd:ef01::5 (IPv4,IPv6)

# example4: gigamon.example.com

- name: K8S_CLUSTER_ENDPOINT

value: <K8s Cluster API URL>

Refer to the below example.

# example: https://10.10.10.13:6443

- name: FM_FQDN

value: www.fm.gigamon.com

To enable inventory collection using Controller, update the value of following variable to true. If the inventory collection is done through , do not update the variable.

name: UCTC_CNTLR_INVENTORY_COLLECTION_ENABLE

value: "true"

Update the namespace in the YAML file as required and run the following command:

kubectl create -f uctc-controller.yaml

Following the execution of the above command, when Controller pod is created successfully, the output (sample) will be as below:

gigamon@controller-2:~$kubectl create -f uctc-controller.yaml

service/gigamon-uctc-cntlr-service created

deployment.apps/uctc-cntlr-v1 created

clusterrole.rbac.authorization.k8s.io/pods-list created

clusterrolebinding.rbac.authorization.k8s.io/pods-list created

Deployment of Tap

Follow these steps to deploy the Tap:

Use the below command to Unzip and Untar the .tgz file:

gunzip <name of the UCT-C Tap .tgz file>

tar -xvf <name of the UCT-C Tap .tar file>

Navigate to the YAML folder in the newly created uctc-tap-<image version>-<build number> folder and update the details given in the below steps.

Feed the created secret in the below section of YAML file

imagePullSecrets:

- name: <secret>

Update the namespace in the below section of YAML file as required. Make sure that it is the same as the namespace in which controller is deployed.

- name: UCTC_CNTLR_SVC_DNS

value: gigamon-uctc-cntlr-service.<namespace>.svc.cluster.local

When TAP gets both IPv4 and IPv6 from the above controller service DNS, the following configurations are used:

- name: UCTC_TAP_IP_CONFIG

value: IPv4 or IPv6

- name: UCTC_TAP_FALLBACK_CONFIG

value: True or False

IP CONFIG option allows the user to provide the preferred IP version. If the user does not provide any value, the default value IPv4 is used.

When the preferred IP version fails to connect (example: IPv6), the FALLBACK CONFIG is used to connect to the other available IP version (example: IPv4). Default value True is used to consider the Fallback mechanism.

Notes:

TAP IP and FALLBACK configurations is used only if you provide both IPv4 and IPv6.

Fallback configuration will be considered during node registration only.

If IPv4 alone is provided, only IPv4 connections is considered, and UCTC_TAP_IP_CONFIG and UCTC_TAP_FALLBACK_CONFIG is disregarded. Similarly, if IPv6 alone is provided, only IPv6 connections is considered.

Default values are used if TAP gets dual IP's from the controller service DNS.

Edit the following volumeMounts as per your container Runtime.

volumeMounts:

   - name: socket

     mountPath: /var/run/containerd/containerd.sock

volumes:

   - name: socket

     hostPath:

       Path: /var/run/containerd/containerd.sock

Below are the socket location for commonly used CRIs,

docker - /var/run/docker.sock

containerd - /var/run/containerd/containerd.sock

cri-o - /var/run/crio/crio.sock

Run the following command for deploying Tap:

kubectl create -f uctc-tap.yaml -n <namespace where UCT-C tap is deployed>

Following the execution of the above command, when Tap pod is created successfully, the output (sample) will be as below:

gigamon@controller-2:~$ kubectl create -f uctc-tap.yaml -n uctc

daemonset.apps/gigamon-uctc created

The following table provides a description of all the field values in the YAML file that are updated:

Field Values	Description
Port: 443	The Controller REST service port number.
Port: 42042	This port allows to send statistics information to Controller.
IP	The IP address of the with which your is connected.
-Cntlr REST SVC Port	The Controller REST service port number. This must be opened on your to allow inbound traffic to Kubernetes. This allows to communicate with Controller. Example: 8443 (configurable)
FM REST Svc Port	The REST service port number opened on your Kubernetes to allow outbound traffic. This allows Controller to communicate with . Example: 443
Ports: containerPort: 443 containerPort: 42042	Two ports that you must open. The first container port is the same as -Cntlr REST SVC Port. The second container port is port 42042. This allows to send statistical data to controller.
External LB balancer IP	The external load balancer IP/DNS value to allow to communicate with Controller within Kubernetes.
K8S cluster end-point	Kubernetes cluster end point for to access the control plane. Example: https://<kubernetesapiserverurl>:6443

Using Helm Charts

Helm Charts are available for each and every release build in the Gigamon software portal.

Download the respective Release build from the repository.
Untar the .tgz file.
Extract the Helm Charts (uct-cntlr-<version>.tgz and uct-tap-<version>.tgz) and further update the fields before deployment.

Contact Gigamon Technical Support or Sales for information on downloading the respective build from the Gigamon software portal.

Refer to the following section for detailed information.

Deploy using Helm Chart

Support for two Helm Charts is deprecated from software version 6.7.00. and is removed from the deliverables from software version 6.8.00.

Deploy using Helm Chart

You can deploy Controller and TAPs using single Helm Chart. Follow these steps to deploy the solution:

Use the below command to Unzip and Untar the .tgz file:

gunzip <name of the UCT-C .tgz file>

tar -xvf <name of the UCT-C .tar file>

After extracting the tar file, navigate to the Helm folder in the newly created uctc-<image version>-<build number> folder and update the details given in the below steps.

Update the imagePullSecrets, namespace, IP, external load balancer IP and Kubernetes API URL in the following section of the values.yaml file present in the directory.

imagePullSecrets: [{name: secret}]

namespace: uctc

If you provide IPv4 alone and not IPv6, then considers only IPv4 address for communication.

fm_ip: "<FM IPv4>"

If you provide IPv6 alone and not fm_ip, then considers only IPv6 address for communication.

fm_ipv6: "<FM IPv6>"

If both IPv4 and IPv6 are provided, UCTC_CNTLR_FM_IP_CONFIG helps you choose the preferred IP stack.

ext_load_balancer: "<FM IPv4 or FM IPv6 or FM IPv4,FM IPv6(both with comma-separation notation>"

Refer to the below examples.

# example1: 192.168.0.10 (IPv4)

# example2: 2001:db8:abcd:ef01::5 (IPv6)

# example3: 192.168.0.10,2001:db8:abcd:ef01::5 (IPv4,IPv6)

k8s_cluster_url: "<url>"

# example: https://10.10.10.12:6443

If you provide two IP's, IPv4 and IPv6 in the fm_ip argument, the following configurations will be used:

# values: <IPv4 | IPv6>

uctc_tap_ip_config: "IPv4"

# values: <true | false>

uctc_tap_fallback_config: "false"

IP CONFIG option allows the user to provide the preferred IP version. If the user does not provide any value, the default value IPv4 is used.

When the preferred IP version fails to connect (For example, IPv6), the FALLBACK CONFIG is used to connect to the other available IP version (For example, IPv4). Default value True is used to consider the Fallback mechanism.

Notes:

Fallback configuration is used during node registration phase only.

Controller FM IP and FALLBACK configurations is used only if you provide both IPv4 and IPv6.

If you provide IPv4 alone, only IPv4 connection is considered, and FM IP and FALLBACK configurations are disregarded. Similarly, if IPv6 alone is provided, only IPv6 connection is considered.

Default values is used if you do not provide any options.

Edit the following volumeMounts as per your container Runtime:

crisocketvolume:

mountPath: /var/run/containerd/containerd.sock

name: socket

The socket location for commonly used CRIs are as follows:

docker - /var/run/docker.sock

containerd - /var/run/containerd/containerd.sock

cri-o - /var/run/crio/crio.sock

Run the below command in the location where folder is present.

helm install uctc /uctc -n <Namespace>

Users can skip the above steps 1-5 and use the below command to directly deploy Controller and TAPs using single Helm Chart.
helm install uctc -n uctc ./uctc --set namespace=uctc --set serviceAccount.name=test --
set imagePullSecrets[0].name=gigamon --
set uctcController.fm_ip=x.x.x.x --set uctcController.ext_load_balancer=x.x.x.x --set uctcController.k8s_cluster_url=https://x.x.x.x:6443 --set uctcController.uctc_cntlr_fm_ip_config=IPv4 --set
uctcTap.uctc_tap_ip_config=IPv4 --set uctcTap.cri_socket_path=/run/containerd/containerd.sock

Validate Deployment

To validate the deployment and check for any failures, set the validation value to “True” in values.yaml file. Two pods, uctc-prevalidator-pod, and uctc-postvalidator-pod are deployed that perform checks to ensure certain conditions are met for a successful deployment. If all the checks pass, the validator pods clean up automatically, and is deployed successfully. However, if any check fails, the respective validator pod (either uctc-prevalidator-pod or uctc-postvalidator-pod) remains in an error state and the Helm installation fails.

If the installation fails due to a validation error, follow these steps:

Check Logs: To review the logs of the failure pod and identify the issue, use the following command and specify the corresponding failed pod name.

kubectl logs < uctc-prevalidator-pod | uctc-postvalidator-pod > -n uctc

Delete the Helm Release: Use the following command to delete the failed Helm release.

helm uninstall my-release -n uctc

Delete the Error Pod: After you identify the cause of failure, you can delete the failed validator pod (uctc-prevalidator-pod or uctc-postvalidator-pod depending on which pod failed) and re-run the Helm installation. Use the command below to delete the failed validator pod.

kubectl delete pod <uctc-prevalidator-pod | uctc-postvalidator> -n uctc

Run the command below in the location where UCT-C folder is present.

helm install uctc /uctc -n <Namespace>

If intermittent connectivity issues occur between and the cluster, set 'validation' to false before installing the Helm chart to avoid false negative failures.