Deploy UCT-C Controller and TAPs

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

Using YAML files

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

  1. Download the respective UCT-C release build from the repository.

  2. Untar the .tgz file. 

  3. Extract the YAML file and further update the fields in uctc-controller.yaml and uctc-tap.yaml file.

Contact Technical SupportFor information on downloading the respective UCT-C build from the Gigamon software portal, Contact Technical Support or Contact Sales.

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>

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

■   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>

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 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 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:
■   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

o   Run the following command for deploying UCT-C Tap:

kubectl create -f uctc-tap.yaml -n <namespace where UCT-C tap is 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 provides 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 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 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 that you must open.

  • The first container port is the same as UCT-C-Cntlr REST SVC Port.

  • The second container port is 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 are available for each and every release build in the Gigamon software portal.

  1. Download the respective UCT-C Release build from the repository.

  2. Untar the .tgz file.

  3. Extract the Helm Charts (uct-cntlr-<version>.tgz and uct-tap-<version>.tgz) and further update the 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.

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 these steps 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.

  1. 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 considers only IPv4 address for communication.

fm_ip: "<FM IPv4>"

If you provide IPv6 alone and not fm_ip, then GigaVUE-FM 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

  1. 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.
■   Default values is used if you do not provide any options.

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

  1. 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 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 UCT-C 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:

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 intermittent connectivity issues occur between GigaVUE-FM and the cluster, set 'validation' to false before installing the Helm chart to avoid false negative failures.