Deploy the HSF Cluster
Table of Contents
11.0
Expand all | Collapse all
-
- CN-Series Key Concepts
- CN-Series Core Building Blocks
- Components Required to Secure Kubernetes Clusters with CN-Series Firewall
- CN-Series Deployment—Supported Environments
- CN-Series System Requirements
- Quickstart- CN-Series Firewall Deployment
- CN-Series Performance and Scaling
- Additional CN-Series Resources
-
- CN-Series Deployment Checklist
- CN-Series Prerequisites
- Install a Device Certificate on the CN-Series Firewall
- Create Service Accounts for Cluster Authentication
- Install the Kubernetes Plugin and Set up Panorama for CN-Series
- Get the Images and Files for the CN-Series Deployment
- Editable Parameters in CN-Series Deployment YAML Files
- Enable Horizontal Pod Autoscaling on the CN-Series
- Secure 5G With the CN-Series Firewall
- Enable Inspection of Tagged VLAN Traffic
- Enable IPVLAN
- Uninstall the Kubernetes Plugin on Panorama
- Features Not Supported on the CN-Series
-
- CN-Series HSF System Requirements
- Configure Traffic Flow Towards CN-Series HSF
- Test Case: Layer 3 BFD Based CN-GW Failure Handling
- View CN-Series HSF Summary and Monitoring
- Validating the CN-Series HSF Deployment
- Custom Metric Based HPA Using KEDA in EKS Environments
- Features Not Supported on the CN-Series
Deploy the HSF Cluster
After ensuring that the prerequisites to deploy
the CN-Series firewall as an HSF are met, navigate to and
click
Kubernetes
Deployments
Add
.You will need to configure
the following tabs to deploy the HSF cluster.
General
Enter the following
details in the
General
tab section of the Deployments
pop-up.- CN-Series Cluster Name—Name for the CN Series HSF.
- (Optional)Description—A text string to describe the HSF cluster.
- Kubernetes Cluster—A list of entries for clusters are created under theSetupsection of the plugin. Choose the relevant cluster you created from the drop-down.The Kubernetes cluster will be displayed only if the details are committed and are valid for deployments.
- CN-Series Cluster Name—Name for the CN Series HSF.
Node Data
Enter the following
details in the
Node Data
tab section of the Deployments
pop-up.- Namespace—Namespace in the existing Kubernetes cluster where the CN-Series HSF will be deployed.
- Node Info— Node pool labels are used to deploy each type of CN pod. You need to specify the CPU, Memory and Desired Pods for each of the pod types based on the availability on the nodes. The Labels and the Label value pairs are prerequisite values to exist on the node and you have to add the same key value pair used to label the nodes.
- Interfaces—Interface names for CN-DB, NGFW, CN-GW pods need to be added. Each Interface requires specific net-attach-def to be applied on the Kubernetes cluster. The plugin will name Ethernet x/1 and Ethernet x/2 by default. If you change the interface names for Ethernet x/1 and Ethernet x/2, then you will need to make the change in the network attachments section also. For the CN-GW pod, you can add up to 12 interfaces excluding CI and TI interfaces.The Kubernetes cluster will be displayed only if the details are committed and are valid for deployments.
- CN-Series Cluster Name—Name for the CN Series HSF.
Image & Storage
Enter the following
details in the
Image & Storage
tab section
of the Deployments
pop-up.- Image—You need to store the images either in the local or AWS repository and this cannot be validated by Panorama. However, Kubernetes cluster has connectivity to the repositories where the images are stored.
- CN-MGMT Image: The complete URI from the repository where the image is to be accessed by the Kubernetes environment for deploying the CN-MGMT pod.
- CN-MGMT INIT Image: The init image needed for CN- MGMT pod.
- CN-NGFW Image: The complete URI from the repository where the image is to be accessed by the Kubernetes environment for deploying CN-NGFW pod.
- Storage—If you would like to configure exclusive storage, clickDynamicin the Storage section for EKS environment and Static or Dynamic for Openshift environments and the plugin will configure the cloud storage. If you have chosenStaticthen you need to enter the Storage Key Values, Worker Nodelabel Key and Worker Nodelabel Value. You also need to enter thePathwhere the storage is mounted.You must add a valid non-default storage class in the namespace of the kubernetes environment. Else, if dynamic storage option is selected and no storage class name is provided, then the default storage class present in the namespace will be selected.
- Certificates—This is the Device certificate information to Enable or Disable information such as licensing and if enabled, you will need to provide the PIN ID and PIN VALUE.
CN Configuration
Enter the following
details in the
CN Configuration
tab section
of the Deployments
pop-up:.- Primary Panorama IP—Displays values of the public and private IP addresses of the Panorama on which the plugin is installed.
- Secondary Panorama IP—Displays values of the public and private IP addresses of the secondary Panorama (in case of HA) on which the plugin is installed.
- Device Group—You need to create a DG before configuring the deployment as mentioned in the prerequisite section. The Device Group dropdown lists all the DGs on the current Panorama and you need to choose a valid DG. The CN-MGMT pod will be registered under this DG. For steps to create a Device Group, see Step 5 of Prepare Panorama for CN-Series HSF Deployment.
- Template—You need to create a template (variable_template) for CN-GW specific details, before configuring the deployment as mentioned in the prerequisite section. The Template drop-down lists all the templates on the current Panorama. You need to choose a template suitable for your current deployment. After HSF deployment, this template will be added to a template stack by the plugin along with a K8S-CNF-Clustering-Readonly template which handles the basic configuration for CN-DB and CN-NGFW pods. It also configures the CI and TI links on the CN-GW pod. The CN-MGMT pod gets configurations from the template stack. For steps to create the variable template, see Step 6 of Prepare Panorama for CN-Series HSF Deployment.
- Log Collector Group (LCG)—This drop-down lists all the Log Collector Groups on the current Panorama and a suitable LCG needs to be chosen. It also configures the CI and TI links of the CN-GW pod. For steps to create LCG, see Step 7 of Prepare Panorama for CN-Series HSF Deployment.
- Jumbo Frame—The Jumbo Frame dropdown lists values -Enable,Disable, andAutoDetect. This configuration is applicable for all the pods in the CN-Series HSF.
- 5G Enabled—This is a radio button withEnableandDisableoptions and refers to the GTP configuration needed on the CN-Series HSF.You need to handle further settings needed on the template in thevariable_templatefile.
- DPDK—This is a radio button withEnableandDisableoptions. If the underlying resources do not support DPDK, then by default the CN-Series HSF will be defaulted to packetmmap.On EKS, If you wish to use DPDK, you need to have an AMI with DPDK drivers configured on it. For more information, see Set up DPDK on AWS EKS.To enable DPDK on Openshift, you need to enable huge pages on the worker nodes. For more information see configuring hugepages.You will also need to enable VFIO PCI driver on worker nodes.modprobe vfio-pciecho 1 > /sys/module/vfio/parameters/enable_unsafe_noiommu_mode
- CPU Pinning—Choose to Enable or Disable CPU Pinning.
- Numa Enabled—Provide the Node number for NUMA.
- CPU Pinning Base—Provide the CPU number from where you wish to start cpu pinning of forwarding processes and skip the lower numbered CPUs.
Auto-Scaling
Enter the following
details in the
Auto-Scaling
tab section of
the Deployments
pop-up.- Auto-Scaling is supported only on EKS environments with EKS Kubernetes version 1.22. The Auto-Scaling tab is grayed out for other Kubernetes systems.
- You will need to deploy Custom Metric Based HPA Using KEDA in EKS Environments for auto-scaling to function.
- Enter theAutoscaling Metric,Scale In ThresholdandScale Out Thresholdin theAutoscalingsection.
- ClickOKto commit the deployment.The following are the supported metrics for Autoscaling.
- dataplanecpuutilizationpct
- dataplanepacketbufferutilization
- pansessionactive
- pansessionutilization
- pansessionsslproxyutilization
- panthroughput
- panpacketrate
- panconnectionspersecond
After you have entered all
the configuration details, the Deployments tab displays the details
of a single deployment that is stored. Click
Commit
to
proceed with the deployment. After completion of commit, the plugin
displays the Deploy button. Click the Deploy
button
to deploy the CN-Series HSF.After the CN-Series HSF deployment,
the cluster creates a template stack,
<cluster-name>-ts
with
K8S-CNF-Clustering-Readonly template and the variable template you
created in Step 6 of Prepare Panorama for CN-Series HSF Deployment.
The
Device Group you referenced during the HSF deployment configuration
(created in Step 5 of Prepare Panorama for CN-Series HSF Deployment) and the Template
Stack created automatically after the HSF deployment is bootstrapped
to the CN-MGMT pod. When the CN-MGMT pod connects to Panorama, the
Device Group and Template Stack automatically gets associated with
the HSF name.
HSF information for CN-DB, CN-GW, and CN-NGFW
pods are auto-populated when they are active. When these pods are
up and running, the CN-MGMT pod sends details like CI IP address,
pod details, device ID, and software version to Panorama.
For
Panorama High Availability (HA), the CN-MGMT pod sends updates to
both active and passive Panoramas.