Ransomware attackers specifically target and attempt to destroy backup systems to increase the probability of payment. Hardening your system is critical. Please ensure you have reviewed your platform security using the Security Hardening Checklist
Cohesity

COHESITY Documentation

Explore our documentation to get started, discover products & new features, access troubleshooting guides, register sources, platforms support.

Products
Data Security Alliance
Visit Cohesity.com
Demos
Support
Blogs
Developers
Partner Portals
Cohesity Community
© 2026 Cohesity, Inc. All Rights Reserved.
Terms of Use|
Privacy Policy|
Legal|
  1. Home
  2. NetBackup™ Deployment Guide for Azure Kubernetes Services (AKS) Cluster
  3. Managing the Load Balancer service
  4. About the Load Balancer service
NetBackup™ Deployment Guide for Azure Kubernetes Services (AKS) Cluster

About the Load Balancer service

Key features of the Load Balancer service:

  • Load balancer services are created in primary server and media server deployment that lets you access the NetBackup application from public domains.

  • In primary server or media server CR spec, networkLoadBalancer section is used for handling the IP address and DNS name allocation for load balancer services. This section combines to sub fields type, annotations, and ipList whereas these fields are optional. If ipList is provided in CR spec, IP address count must match the replica count in case of media server CR whereas in case of primary server CR, only one IP address needs to be mentioned.

  • In CR yaml, networkLoadBalancer is an optional field. If not defined in CR yaml, by default value of type is Private and services are added with annotations service.beta.kubernetes.io/azure-load-balancer-internal: "true". In this case, by default internal load balancer is selected for deployment.

  • If networkLoadBalancer section is not defined, by default internal load balancer with dynamic IP address allocation are done. In this case, DNS names for the services can be obtained from HostName in CR status using the kubectl describe <CR name> -n <namespace> command.

    • Whenever, HostName in CR status is not in FQDN format, you must add entry of hostname and its corresponding IP address in /etc/host to access the primary server and its corresponding IP address in hosts file of computer accessing the primary server. Hosts file is present at the following location:

      • For Linux: /etc/hosts

      • For Windows: c:\Windows\System32\Drivers\etc\hosts

    • In case of media server, FQDN per media server replica is generated using resourceName mentioned in media server CR and listed under status attributes media server-name of the media server CR.

  • In this deployment, it is recommended to use internal load balancer using type as Private with static IP allocation and DNS name allocation.

    For details about internal load balancer, see Microsoft documentation.

    However, if type is public, then external load balancer is used and for more details to create and use public loadbalancer, see Microsoft documentation.

  • The networkLoadBalancer section can be used to provide static IP address and DNS name allocation to the loadbalancer services. For more information to create and use static loadbalancer, see Microsoft documentation.

    Static IP addresses and FQDN if used must be created before being used. Refer below sections for different allowed scenarios.

    • Case 1: Internal load balancer with static IP address allocation

      • Example: In Primary section in environment CR

        networkLoadBalancer:
              ipList:
                - ipAddr: 10.123.45.123

        In media server section in environment CR

        networkLoadBalancer:
           ipList:
            - ipAddr: 10.123.45.124
            - ipAddr: 10.123.45.125

        In this case, number of IP addresses for primary server should be one, and for media server, the number of IP addresses should match with the replica count mentioned in CR spec. Dynamically created FQDN mentioned in CR status attribute is used directly as DNS name for primary/media server services.

      • Example: In primary CR

        In this case, the number of IP addresses for primary server should be one, and for media server, it should match with the replica count mentioned in CR spec. IP address and DNS name mentioned in CR spec is used as DNS name for primary/media server services.

        networkLoadBalancer:
              ipList:
                - ipAddr: 10.123.45.123
                  fqdn: abc.eastus.cloudapp.azure.com
        

        In media server section in environment CR

        networkLoadBalancer:
              ipList:
                - fqdn: xyz.eastus.cloudapp.azure.com
                  ipAddr: 10.123.45.124
                - fqdn: pqr.eastus.cloudapp.azure.com
                  ipAddr: 10.123.45.125
        
    • Case 2: Internal load balancer and dynamic IP address allocation

      • Example: In primary/media CR

        In this case, IP address and DNS name are allocated dynamically and internal load balancer is used. User needs to add entry of Hostname (FQDN) mentioned in CR status attribute and IP address allocated to load balancer service in /etc/hosts location on Linux machine. While c:\Windows\System32\Drivers\etc\hosts location on Windows computer to access primary server webUI.

    • Case 3: Internal load balancer for different subnet with dynamic IP

      In this case, IP addresses for load balancer service are allocated dynamically. The subnet mentioned in annotations is bound to internal load balancer service.

      • Example: In primary CR

        networkLoadBalancer:
        annotations:
        - service.beta.kubernetes.io/
        azure-load-balancer-internal-subnet: "apps-subnet"
        

        Media CR

        networkLoadBalancer:
        annotations:
        - service.beta.kubernetes.io/
        azure-load-balancer-internal-subnet: "apps-subnet"
    • Case 4: Internal load balancer for different subnet with static IP

      In this case, load balancer service gets assigned with the static IP addresses mentioned in the ipList, DNS name is generated dynamically, and gets bound to the subnet given in the annotations.

      • Example: In primary section in environment CR,

        networkLoadBalancer:
          annotations:
          - service.beta.kubernetes.io/azure-load-balancer-
        internal-subnet: apps-subnet
          ipList:
          - ipAddr: 10.123.45.123

        Media server section in environment CR

        networkLoadBalancer:
          annotations:
          - service.beta.kubernetes.io/azure-load-balancer-
        internal-subnet: apps-subnet
          ipList:
          - ipAddr: 10.123.45.125
          - ipAddr: 10.123.45.124
    • Case 5: Pre-allocation of static IP address and FQDN from resource group

      In this case, it is required to provide the network resource group in annotations. This resource group is the resource group of load balancer public IPs that are in the same resource group as the cluster infrastructure (node resource group). This static FQDN and IP address must be valid in case of pod failure or upgrades scenarios as well.

      In case user wants to use public load balancer, add type: Public in networkLoadBalancer section in primary and media server section in environment CR.

      • Example: In primary CR,

        networkLoadBalancer:
          type: Public
          annotations:
          - service.beta.kubernetes.io/azure-load-balancer-
        resource-group:<name of network resource-group>
          ipList:
          - fqdn: primary.eastus.cloudapp.azure.com
            ipAddr: 40.123.45.123

        Media server section in environment CR -

        networkLoadBalancer:
          annotations:
          - service.beta.kubernetes.io/azure-load-balancer-
        resource-group: ""<name of network resource-group>""
          ipList:
          - fqdn: media-1.eastus.cloudapp.azure.com
            ipAddr: 40.123.45.123
          - fqdn: media-2.eastus.cloudapp.azure.com
            ipAddr: 40.123.45.124
Preferred annotations

Table: Preferred annotations

Annotations

Value

Description

service.beta.kubernetes.io/ azure-load-balancer- internal

true or false

Specify whether the load balancer should be internal.

Added by default when type is selected as Private in load balancer service annotations.

service.beta.kubernetes.io/ azure-load-balancer- internal-subnet

Name of the subnet

Specify which subnet the internal load balancer should be bound to.

service.beta.kubernetes.io/ azure-load-balancer -resource-group

Name of the resource group

Specify the resource group of load balancer public IPs that are not in the same resource group as the cluster infrastructure (node resource group).

Default ports used in the Load Balancer service
  • Primary server:

    • 1556

      Used as bidirectional port. Primary server to/from media servers and primary server to/from client require this TCP port for communication.

    • 8443

      Used to inbound to java nbwmc on the primary server.

    • 443

      Used to inbound to vnet proxy tunnel on the primary server. Also, this is used Nutanix workload, communication from primary server to the deduplication media server.

    • 13781

      The MQBroker is listening on TCP port 13781. NetBackup client hosts - typically located behind a NAT gateway - be able to connect to the message queue broker (MQBroker) on the primary server.

    • 13782

      Used by primary server for bpcd process.

    • Port 22

      Used by NetBackup IT Analytics data collector for data collection.

  • Media server:

    • 1556

      Used as bidirectional port. Primary server to/from media servers and primary server to/from client require this TCP port for communication.

    • 13782

      Used by media server for bpcd process.

Feedback

Was this page helpful?
Previous

Managing the Load Balancer service

Next

Notes for Load Balancer service

Feedback

Was this page helpful?