This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

This topic describes how to define network profiles for logging NCP configurations for VMware Tanzu Kubernetes Grid Integrated Edition (TKGI) provisioned Kubernetes clusters.

About Logging for NCP Configurations

VMware Tanzu Kubernetes Grid Integrated Edition provides network profile parameters for logging ncp.ini configurations.

Parameters for NCP Logging

The parameter cni_configurations is a map with two keys: type and parameters. The following table shows the parameters for configuring NCP:

The following table describes the Ingress Controller configuration parameters:

Parameter Type Description
name String User-defined name of the network profile.
description String User-defined description for the network profile.
parameters Map Map containing one or more key-value pairs.
cni_configurations Map Map containing type and parameters key-value pairs for configuring NCP.
type Constant
String
Values: “nsxt”.
parameters Map Map containing one or more key-value pairs for NCP settings.
log_settings Map Map containing one or more key-value pairs for configuring NCP logging.
log_level String The logging level.
Values: “INFO”, “WARNING”, “DEBUG”, “ERROR”, “CRITICAL”.
log_dropped_traffic Boolean Log dropped firewall traffic.
Values: true, false.
Default: false.

The nsx_lb parameter is used to control the TCP layer 4 virtual server that is provisioned for each Kubernetes service of type: LoadBalancer.

When you configure an NSX Load Balancer as your Kubernetes cluster ingress resource, NCP instructs the NSX-T Load Balancer to provision two layer 7 virtual services (HTTP and HTTPS) as the cluster Ingress Controller:

nsx_lb setting Description
nsx_lb: true Use an NSX-T Layer 4 LoadBalancer and NCP-provisioned Layer 7 Ingress Controller.
nsx_lb: false Use a third-party load balancer and a third-party ingress controller, such as NGINX.

Example Network Profile for NCP Logging

The following network profile is an example that illustrates the parameters exposed for NCP logging.

{
  "name": "ncp_network_profile",
  "description": "Example network profile for NCP logging and error handling",
  "parameters" : {
     "cni_configurations": {
         "type": "nsxt",
         "parameters": {
           "log_settings": {           
             "log_level": "WARNING",
             "log_dropped_traffic": true 
         	}
       	}
   		}
   	}
}

Log Settings

The parameter log_settings is a map that supports two keys: log_level and log_dropped_traffic.

Log Level

The log_level parameter type is a string. The log_level value is an enumeration that supports the following values:

  • “INFO”
  • “WARNING”
  • “DEBUG”
  • “ERROR”
  • “CRITICAL”

Any other value results in an error.

The value is set for three ncp.ini keys: coe.nsxlib_loglevel, coe.loglevel, and k8s.loglevel. The default log levels for these keys are as follows:

ncp.ini key Default log level
coe.nsxlib_loglevel INFO
coe.loglevel NONE
k8s.loglevel NONE

Log Dropped Traffic

The log_dropped_traffic type is a Boolean: true or false. Any other type is rejected, such as “true”. Missing entry is accepted. Enabling this parameter is used in distributed firewall configurations to log the traffic for dropped rules.

Example network profile for logging:

{
  "name": "example-network-profile",
  "description": "log_settings",
  "parameters" : {
     "cni_configurations": {
         "type": "nsxt",
         "parameters": {
           "log_settings": {
             "log_level": "DEBUG",
             "log_dropped_traffic": true        
           }
         }
     }
  }
}

enable_err_crd

The enable_err_crd parameter provides a mechanism of reporting NSX backend errors to Kubernetes cluster using a custom resource definition (CRD).

The Kubernetes resource “NSXError” is defined to hold error information. For each kubernetes resource object that has NSX backend failures, one “NSXError” object is generated with error information. There is a ‘common error object’ containing all cluster-wide errors.

The enable_err_crd data type is a Boolean: true or false. Missing entry is accepted. If enable_err_crd is set to true, you define a CRD to handle the “NSXError” common error object.

Example: network profile for enable_err_crd:

{
  "name": "example_network_profile",
  "description": "enable_err_crd",
  "parameters" : {
     "cni_configurations": {
         "type": "nsxt",
         "parameters": {
           "enable_err_crd": true
         }
     }
  }
}
check-circle-line exclamation-circle-line close-line
Scroll to top icon