Deploy UCT-C Controller and TAPs

You can deploy the UCT-C Controller and TAPs using the YAML files or the Helm Charts. Refer to the following sections for detailed information.

• Using YAML files
• Using Helm Charts

Using YAML files

YAML files will be available for each and every release build in the Gigamon software portal. Download the respective UCT-C release build from the repository and untar the .tgz file. After you finish untarring the file, you can extract the YAML file and further update the following fields in uctc-controller.yaml and uctc-tap.yaml file.

Note:   Contact Technical Support or Contact Sales for information on downloading the respective UCT-C build from the Gigamon software portal.

Deployment of UCT-C Controller

Follow these steps to deploy the UCT-C 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>

After extracting the 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, the following configurations will be used:

- 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 will be used to connect to the other available IP version (example: IPv4). Default value True will be used to consider the Fallback mechanism.

■

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

■

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 UCT-C 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 UCT-C Tap

Follow these steps to deploy the UCT-C 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>

After extracting the 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. This should be same as the namespace in which UCT-C controller is deployed.

- name: UCTC_CNTLR_SVC_DNS

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

■

When UCT-C TAP gets both IPv4 and IPv6 from the above controller service DNS, the following configurations will be 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 will be used.

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

■

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

o

Run the following command for deploying UCT-C Tap:

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

Following the execution of the above command, when UCT-C 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 gives a description of all the field values in the YAML file that are updated:

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

Using Helm Charts

Helm Charts will be available for each and every release build in the Gigamon software portal. Download the respective UCT-C release build from the repository and untar the .tgz file. After you finish untarring the file, you can extract the Helm Charts (uct-cntlr-<version>.tgz and uct-tap-<version>.tgz) and further update the following fields before deployment.

Note:   Contact Technical Support or Contact Sales for information on downloading the respective UCT-C build from the Gigamon software portal.

Refer to the following section for detailed information.

• Deploy using Helm Chart

Note:  Support for two Helm Charts is deprecated from software version 6.7.00.

Deploy using Helm Chart

You can deploy UCT-C Controller and TAPs using single Helm Chart. Follow the steps listed below to deploy the solution.

1. 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.

2. Update the imagePullSecrets, namespace, GigaVUE-FM IP, external load balancer IP and Kubernetes API URL in the following section of the values.yaml file present in the UCT-C directory.

imagePullSecrets: [{name: secret}]

namespace: uctc

If you provide IPv4 alone and not IPv6, then GigaVUE-FM will consider only IPv4 address for communication.

fm_ip: "<FM IPv4>"

If you provide IPv6 alone and not fm_ip, then GigaVUE-FM will consider only IPv6 address for communication.

fm_ipv6: "<FM IPv6>"

If both IPv4 and IPv6 are provided, UCTC_CNTLR_FM_IP_CONFIG will be used to 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

3. 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 will be used.

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

4. 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

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

helm install uctc /uctc -n <Namespace>

Note:  Users can skip the above steps 1-5 and use the below command to directly deploy UCT-C 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 UCT-C Deployment

To validate the UCT-C 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 will be deployed, which will perform checks to ensure certain conditions are met for a successful deployment. If all the checks pass, the validator pods will clean up automatically, and UCT-C will be deployed successfully. However, if any check fails, the respective validator pod (either uctc-prevalidator-pod or uctc-postvalidator-pod) will remain in an error state and the Helm installation will fail.

Follow the steps listed below, if the installation fails due to a validation error:

1.

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

2.

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

helm uninstall my-release -n uctc

3.

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

4.

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

helm install uctc /uctc -n <Namespace>

Note:  If there are intermittent connectivity issues between GigaVUE-FM and the cluster, set 'validation' to false before installing the Helm chart to avoid false negative failures.