Network Management

Service

General

A service provides a unified access entry for pods, so that applications can easily implement service discovery and load balancing.

How It Works

Usually, because pods are frequently created and destroyed quickly, accessing pods directly to obtain application services is not reliable even if each pod has a fixed IP address, because the pod that is running an application now may be different from the pod that runs the application at the next moment.

To provide a unified access entry for these rapidly changing pods, the concept of a service is introduced. A service has its own fixed IP address and automatically forwards the traffic that accesses this IP address to the corresponding pods, which are selected by labels. Even if the backend pods that run the application change, you can still access the application quickly through the service without noticing the change. In addition, a service helps implement load balancing among pods.

Service Types

ZStack Zaku supports the following four service types:

ClusterIP: a service of the ClusterIP type is not exposed outside the cluster. The system assigns a cluster IP address to it, through which the service can be accessed within the cluster.
NodePort: a service of the NodePort type is exposed externally in the form of a cluster node IP address plus a static port. It can be accessed from outside the cluster through NodeIP (the IP address of any cluster node):NodePort (the cluster port).
Note: A service of the NodePort type automatically creates and routes to a ClusterIP service.
LoadBalancer: a service of the LoadBalancer type is exposed externally through the metallb load balancing feature of ZStack Zaku. The system assigns an external network IP address to it, through which the service can be accessed from outside the cluster.
Headless: a service of the Headless type does not have a fixed IP address. After a client accesses the domain name of the service, it receives the IP addresses of all pods returned via DNS, and load balancing among the backend pods can be implemented via DNS. Services of the Headless type are usually used together with StatefulSet workloads, for access between pod replicas.

Creating Services

In the ZStack Zaku main menu, click Container Orchestration > Network Management > Service to enter the Service page. Click Create Service and the Create Service page is displayed.

You can refer to the following example to enter the required information:

Name: set the service name. Naming rules: the length is limited to 1-50 characters, the input can contain only lowercase letters, digits and hyphens (-), and it must start with a lowercase letter and end with a digit or a lowercase letter.
Associated Workload: associate a workload with the service. The traffic that accesses the service is forwarded to the pods under the associated workload. Two association methods are supported: selecting a workload and associating by label.
- Select workload: directly select an existing workload.
- Associate by label: enter the key and value of the pod label of the workload, and the system automatically filters workloads based on this label to associate them with the service.
Note: A service uses labels to determine which pods to forward traffic to. If a pod contains all the labels entered here, the service forwards traffic to this pod.
Type: select the service type. For the definitions of the types, see Service Types
Note: When the service type is Headless and the associated workload is of the StatefulSet type, the service name must be set to be consistent with the service name in the advanced configuration of this StatefulSet.
IP Type: select the IP address type of the service. Currently only IPv4 is supported.
Service External Network: optional. This item can be set when the type is LoadBalancer. Select a service external network for the LoadBalancer service. You can access the LoadBalancer service from outside the cluster through the service external network IP address.
Specify IPv4: optional. This item can be set after a service external network is selected. Manually specify the service external network IPv4 address for the LoadBalancer service. If it is not specified, the service external network randomly assigns an IPv4 address to the service.
Note: The specified IP address must be within the range of the selected service external network, and address conflicts must be avoided.
Service Port: set the following information:
- Port: set the port on which the service receives traffic.
- Container port: set the container port to which the service forwards traffic.
- Port name: set the name of the port. If it is not set, the default name is "ze-protocol-port-container port", for example ze-tcp-80-80.
- Host port: optional. This item can be set when the type is NodePort. The host port is the cluster node port (NodePort). You can access the NodePort service from outside the cluster using NodeIP:NodePort. Value range: 30000-32767. If it is not set, the cluster randomly assigns a port.
- Protocol: set the access protocol type. Two protocol types are supported: TCP and UDP.
Session affinity: select whether to enable session affinity. After it is enabled, all access requests from the same client IP address within the specified period are forwarded to the same pod. It is disabled by default.
Note: If client requests are forwarded through nginx or another proxy server, the system may identify the IP address of the proxy server as the client IP address.
Session affinity timeout: if session affinity is enabled, set the maximum session sticky time. The default value is 10800. Unit: second. Value range: an integer from 300 to 86400.
Label: optional. Add service labels.
- Key: enter the label key.
  Note:
  - Usually the key can contain 1-63 characters, including letters, digits and the following special characters: (-)(_)(.). The special characters cannot be used at the beginning or the end of the key.
  - A prefix can be added before the key and connected to the key with /, for example k8s.io/app. All the characters before / are considered the key prefix, and all the characters after / are considered the key.
  - The key prefix can contain 1-253 characters, including lowercase letters, digits and the following special characters: (-)(_)(.). Two or more special characters cannot be used consecutively, and special characters cannot be used at the beginning or the end of the prefix.
  - Note that you do not have to use a key prefix, but the key is required.
- Value: enter the label value.
Annotation: optional. Add service annotations.
- Key: enter the annotation key.
  Note:
  - Usually the key can contain 1-63 characters, including letters, digits and the following special characters: (-)(_)(.). The special characters cannot be used at the beginning or the end of the key.
  - A prefix can be added before the key and connected to the key with /, for example k8s.io/app. All the characters before / are considered the key prefix, and all the characters after / are considered the key.
  - The key prefix can contain 1-253 characters, including lowercase letters, digits and the following special characters: (-)(_)(.). Two or more special characters cannot be used consecutively, and special characters cannot be used at the beginning or the end of the prefix.
  - Note that you do not have to use a key prefix, but the key is required.
- Value: enter the annotation value.

Managing Services

In the ZStack Zaku main menu, click Container Orchestration > Network Management > Service to enter the Service page.

Services support the following operations:

Operation	Description
Create service	Create a new service.
Modify service	Update the service configuration using a form. Note: If the current service was created using Yaml and the value of spec.ipFamilies is IPv6 or IPv6,IPv4, the service does not support modification using a form. You can click Update Yaml to modify the service configuration.
Update Yaml	Update the service configuration using Yaml.
Service details	Go to the service details page to view the basic information, port information and events of the service.
Delete service	Delete the service from the cluster.

Ingress

General

An ingress is a collection of HTTP or HTTPS routing rules used to access services inside a cluster from outside the cluster. It provides externally accessible URLs, load balancing, SSL termination and HTTP routing for cluster services. The ingress feature provides Layer 7 load balancing and can forward traffic to different services according to different URLs.

How It Is Implemented

The ingress feature relies on an ingress controller, such as the Nginx Ingress Controller or Traefik. An ingress controller is an application that runs in a Kubernetes cluster. It watches changes of ingress resources and updates the configuration of the load balancer or the reverse proxy server, so that external traffic can access services according to the ingress rules.

The ZStack Zaku application market provides the nginx-ingress-controller deployment package. You can go to the application market and release this deployment package with one click to install the Nginx Ingress Controller. You can also deploy your own ingress controller in other ways.

Creating an Ingress

In the ZStack Zaku main menu, click Container Orchestration > Network Management > Ingress. On the Ingress page, click Create Ingress and the Create Ingress page is displayed.

You can refer to the following example to enter the required information:

Name: set the ingress name. Naming rules: the length is limited to 1-50 characters, the input can contain only lowercase letters, digits and hyphens (-), and it must start with a lowercase letter and end with a digit or a lowercase letter.
IngressClass: select an IngressClass to specify the ingress controller that processes the ingress.
Note: Make sure that an ingress controller has been deployed in advance. If not, you can go to Artifact Repository > Application Market and release nginx-ingress-controller with one click.
Rules: configure the ingress rules. Multiple rules can be configured for one ingress. You can refer to the following example to enter the required information:
- Domain name: optional. Enter the domain name address actually accessed. After the ingress is created, you can configure a domain name resolution rule in the DNS service to resolve the domain name to the gateway IP address of this ingress, so that access by domain name is implemented.
- Protocol: select the protocol type. Two protocol types are supported: HTTP and HTTPS.
- Secret: when the protocol type is HTTPS, a secret of the TLS type needs to be bound to support encrypted authentication for HTTPS data transmission.
- pathType: select the path type. The path type determines how the path is matched. The following three path types are supported, and the default type is ImplementationSpecific:
  - ImplementationSpecific: the path matching method is determined by the IngressClass. The IngressClass may use its own matching method, or the same matching method as Exact or Prefix.
  - Exact: matches the URL path exactly, and is case-sensitive. For example, if the path is set to /foo and the request path is /foo, the request matches the path. If the request path is /foo/, the request does not match the path.
  - Prefix: matches based on a URL path prefix split by /. The matching is case-sensitive and is done element by element on the path. A path element is a label in the path split by /. If each part of the path is an element prefix of the request path, the request matches the path. For example, if the path is set to /foo and the request path is /foo, the request matches the path. If the request path is /foo/, the request also matches the path.
- Path: specify the URL path allowed to be accessed. The default value is the root path /.
- backendService: select the service to be accessed.
- backendService port: select the port of the service to be accessed.
Label: optional. Add labels.
- Key: enter the label key.
  Note:
  - Usually the key can contain 1-63 characters, including letters, digits and the following special characters: (-)(_)(.). The special characters cannot be used at the beginning or the end of the key.
  - A prefix can be added before the key and connected to the key with /, for example k8s.io/app. All the characters before / are considered the key prefix, and all the characters after / are considered the key.
  - The key prefix can contain 1-253 characters, including lowercase letters, digits and the following special characters: (-)(_)(.). Two or more special characters cannot be used consecutively, and special characters cannot be used at the beginning or the end of the prefix.
  - Note that you do not have to use a key prefix, but the key is required.
- Value: enter the label value.
Annotation: optional. Add annotations.
- Key: enter the annotation key.
  Note:
  - Usually the key can contain 1-63 characters, including letters, digits and the following special characters: (-)(_)(.). The special characters cannot be used at the beginning or the end of the key.
  - A prefix can be added before the key and connected to the key with /, for example k8s.io/app. All the characters before / are considered the key prefix, and all the characters after / are considered the key.
  - The key prefix can contain 1-253 characters, including lowercase letters, digits and the following special characters: (-)(_)(.). Two or more special characters cannot be used consecutively, and special characters cannot be used at the beginning or the end of the prefix.
  - Note that you do not have to use a key prefix, but the key is required.
- Value: enter the annotation value.

Managing Ingresses

In the ZStack Zaku main menu, click Container Orchestration > Network Management > Ingress to enter the Ingress page.

Ingresses support the following operations:

Operation	Description
Create ingress	Create a new ingress.
Update Yaml	Update the ingress using Yaml.
Modify IngressClass	Modify the IngressClass associated with the ingress.
Modify rules	Modify the ingress rules.
Edit labels and annotations	Edit the labels and annotations of the ingress.
Ingress details	Go to the ingress details page to view the basic information and events of the ingress.
Delete ingress	Delete the ingress from the cluster.

Ingress Instructions

Deploying the Ingress Controller

An ingress defines the rules for handling traffic entering the cluster over the HTTP and HTTPS protocols, and the ingress controller is responsible for enforcing these rules. Therefore, before creating an ingress, make sure that an ingress controller has been correctly installed in the cluster. This section describes how to install an ingress controller using the nginx-ingress-controller deployment package built into the ZStack Zaku application market.

In the ZStack Zaku main menu, click Artifact Repository > Application Market to enter the Application Market page.
On the Application Market page, find the nginx-ingress-controller deployment package and click Action > Release Application.
On the Release Application page, refer to the following example to enter the required information:
- Application Name: set the application name. The length is limited to 2-20 characters, the input can contain only lowercase letters, digits and the special character (-), and it must start with a lowercase letter and end with a lowercase letter or a digit.
- Version: set the application version.
- Description: optional. Add remarks about the application.
- Cluster: select the cluster to which the application is released.
- Namespace: select the namespace to which the application is released.
- Chart Version: displays the default chart version, which currently cannot be modified.
- Application Configuration: modify the configuration content of the values file in the deployment package.
  Note:
  - If multiple Nginx Ingress Controllers are installed in the same cluster, modifying the following configurations is recommended, because duplicate configurations of multiple Nginx Ingress Controllers may cause conflicts:
    
    nameOverride: the name of the ingress controller.
    
    ingressClassResource.name: the name of the IngressClass.
    
    ingressClassResource.controllerClass: keep it consistent with nameOverride.
  - When no external network IP address is available, you can set the value of the service.type parameter to NodePort. After that, the gateway address of the ingresses that use this ingress controller uses the cluster node IP address.

Accessing Services via Ingress

This section describes how to access a service from outside through an ingress.

Create an ingress.
In the ZStack Zaku main menu, click Container Orchestration > Network Management > Ingress. On the Ingress page, click Create Ingress, and the Create Ingress page is displayed. Set the basic information of the ingress and configure the ingress rules. For details, see Creating an Ingress.
View the ingress gateway address and the domain names in the ingress rules.
On the Ingress page, click the ingress created in step 1 to go to the ingress details page, and view the ingress gateway IP address in Basic Information and the domain name configured for each rule in Rules.
Configure a domain name resolution rule.
Log in to the DNS server or the client machine and configure a domain name resolution rule in the hosts file, so that the domain name is resolved to the gateway IP address of the ingress.
View the access address.
Go to the ingress details page and expand the ingress rules to view the access address of the forwarding policy.
Access the corresponding backend service through the access address.

Network Policy

General

A network policy controls communication between workloads, and between workloads and the outside. By filtering inbound and outbound traffic, it protects applications against network attacks.

Features

Network policy rules

A network policy contains one or more rules, which actually control the communication behavior of workloads. By the direction of the traffic controlled, the rules can be divided into ingress rules and egress rules:

Ingress rule: controls the sources of the traffic that accesses the workload from outside. ZStack Zaku provides three ways to set ingress rules:
- Allow all traffic: all traffic can access the current workload, regardless of its source.
- Deny all traffic: no traffic is allowed to access the current workload, regardless of its source.
- Custom rule: manually specify the access rules of the current workload. The items that can be specified include the allowed traffic sources, the access protocol and the ports.
  - Traffic source: the traffic sources allowed to access the current workload. It can be specified as a namespace, a workload or a CIDR.
  - Access protocol: the protocol used by the traffic source to access the workload. Two protocol types are supported: TCP and UDP.
  - Port: the ports of the current workload that can be accessed by the specified sources.
  Note: Custom rules use a whitelist mechanism. That is, after a custom rule is added, no traffic other than the traffic specified by the rule is allowed to access the current workload.
Egress rule: controls the destinations of the traffic sent from the workload. ZStack Zaku provides two ways to set egress rules:
- Allow all traffic: the workload can access any destination, regardless of the traffic destination.
- Custom rule: manually specify the egress rules of the current workload. The items that can be specified include the allowed traffic destinations, the access protocol and the ports.
  - Traffic destination: the destinations that the current workload is allowed to access. It can be specified as one or more namespaces, workloads or CIDRs.
  - Access protocol: the protocol used by the workload to access the specified destinations. Two access types are supported: TCP and UDP.
  - Port: the ports on the traffic destination that can be accessed by the current workload.
  Note: Custom rules use a whitelist mechanism. That is, after a custom rule is added, no traffic sent from the workload is allowed except the traffic to the destinations specified by the rule.
Number and priority of rules: multiple egress/ingress rules can be added to one network policy. Multiple rules have no priority order and take effect on the loaded workloads at the same time.

Network policies and workloads

If no network policy is loaded, all egress and ingress traffic of the workload is allowed. After a network policy is loaded, the communication of the workload follows the network policy rules.
Multiple network policies can be loaded to one workload. Multiple network policies have no priority order and take effect on this workload at the same time.
If "Use HostNetwork (hostNetwork)" is enabled for a workload, or the network type of the workload is "pod external network", the loaded network policies do not take effect on this workload.
If the network type of the workload is "pod network and external network", the loaded network policies take effect only on the network traffic of the pod network. Network policies are not supported for the network traffic of the pod external network.
When configuring a network policy for a workload, pay attention to the communication rules of the peer as well. For example, to make workload A access workload B, in addition to allowing the egress traffic from workload A to workload B, you must also make sure that workload B allows the ingress traffic from workload A.

Creating a Network Policy

In the ZStack Zaku main menu, click Container Orchestration > Network Management > Network Policy. On the Network Policy page, click Create Network Policy and the Create Network Policy page is displayed.

You can refer to the following example to enter the required information:

Name: set the network policy name. Naming rules: the length is limited to 1-50 characters, the input can contain only lowercase letters, digits and hyphens (-), and it must start with a lowercase letter and end with a digit or a lowercase letter.
Workload: select the workloads on which the current network policy takes effect. It can take effect on all workloads under the current namespace, or only on manually specified workloads.
Ingress rule: set the ingress rule. Three rule types are supported: allow all traffic, deny all traffic and custom rule. If you select custom rule, click Add Ingress Rule and set the following parameters:
- Allowed ingress from: set the allowed traffic sources. Three types of traffic sources are supported: namespace, workload and CIDR.
  - Namespace: specify a namespace, and the traffic from this namespace is allowed to access the current workload.
  - Workload: specify a workload, and the traffic from this workload is allowed to access the current workload.
  - CIDR: specify a CIDR, and the traffic from this CIDR is allowed to access the current workload.
    - Allowed CIDR: currently the IPv4 CIDR can only be specified as 0.0.0.0/0, which means that all CIDRs are allowed to access the workload.
- Protocol: set the protocol used by the traffic source to access the current workload. Two protocol types are supported: TCP and UDP.
- Port: set the ports of the current workload that can be accessed by the traffic source. Ports within the range of 1-65535 are supported.
Egress rule: set the egress rule. Two rule types are supported: allow all traffic and custom rule. If you select custom rule, click Add Egress Rule and set the following parameters:
- Allowed egress to: set the allowed traffic destinations. Three types of traffic destinations are supported: namespace, workload and CIDR.
  - Namespace: specify a namespace, and the current workload is allowed to access this namespace.
  - Workload: specify a workload, and the current workload is allowed to access this workload.
  - CIDR: specify a CIDR, and the current workload is allowed to access this CIDR.
    - Allowed CIDR: enter the CIDR that the current workload is allowed to access.
    - Exclude CIDR: optional. Enter a sub-CIDR within the range of the allowed CIDR. The workload is not allowed to access the excluded sub-CIDR.
- Protocol: specify the protocol used by the current workload to access the specified destinations. Two protocol types are supported: TCP and UDP.
- Port: specify the destination ports that the current workload can access. Ports within the range of 1-65535 are supported.
Note: When you customize an egress rule, the system automatically adds a rule to allow the workload to access NodeLocalDNS, which provides the DNS service. If it is not needed, you can delete this rule manually.

Managing Network Policies

In the ZStack Zaku main menu, click Container Orchestration > Network Management > Network Policy to enter the Network Policy page.

Network policies support the following operations:

Operation	Description
Create network policy	Create a new network policy.
Modify network policy	Modify the network policy using a form, including the associated workloads and the egress/ingress traffic rules. Note: If the network policy was created in a way other than a form, or has been modified in a way other than a form, it no longer supports modification using a form. You can modify the network policy configuration using Yaml.
Update Yaml	Modify the network policy using Yaml.
Network policy details	Go to the network policy details page to view basic information and egress/ingress rules.
Delete network policy	Delete the network policy. Note: After the deletion, all the rules under this network policy become invalid and no longer control the communication behavior of the workloads.

PreviousApplication Management NextPersistentVolumes Management