-
-
-
Minimum and maximum capacity for Flexed and Pooled licensing
-
Scenarios for Flexed or Pooled license expiry and connectivity issues behavior
-
Configure NetScaler Console on-prem as the Flexed or Pooled license server
This content has been machine translated dynamically.
Dieser Inhalt ist eine maschinelle Übersetzung, die dynamisch erstellt wurde. (Haftungsausschluss)
Cet article a été traduit automatiquement de manière dynamique. (Clause de non responsabilité)
Este artículo lo ha traducido una máquina de forma dinámica. (Aviso legal)
此内容已经过机器动态翻译。 放弃
このコンテンツは動的に機械翻訳されています。免責事項
이 콘텐츠는 동적으로 기계 번역되었습니다. 책임 부인
Este texto foi traduzido automaticamente. (Aviso legal)
Questo contenuto è stato tradotto dinamicamente con traduzione automatica.(Esclusione di responsabilità))
This article has been machine translated.
Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)
Ce article a été traduit automatiquement. (Clause de non responsabilité)
Este artículo ha sido traducido automáticamente. (Aviso legal)
この記事は機械翻訳されています.免責事項
이 기사는 기계 번역되었습니다.책임 부인
Este artigo foi traduzido automaticamente.(Aviso legal)
这篇文章已经过机器翻译.放弃
Questo articolo è stato tradotto automaticamente.(Esclusione di responsabilità))
Translation failed!
Manage the Kubernetes Ingress configuration in NetScaler Console
Kubernetes (K8s) is an open source container orchestration platform that automates the deployment, scaling, and management of cloud-native applications.
Kubernetes provides the Ingress feature which allows client traffic outside the cluster to access microservices of an application running inside the Kubernetes cluster. NetScaler instances can act as the Ingress to applications running inside a Kubernetes cluster. NetScaler instances can load balance and content route North-South traffic from the clients to any microservices inside the Kubernetes cluster.
Note
- NetScaler Console supports the Ingress feature on the clusters with Kubernetes version 1.14–1.21.
- NetScaler Console supports NetScaler VPX and MPX appliances as Ingress devices.
- In the Kubernetes environment, the NetScaler instance load balances only the “NodePort” service type.
You can configure multiple NetScaler instances to act as Ingress devices on the same cluster or different clusters or namespaces. After you configure the instances, you can assign each instance to different applications based on the Ingress policy.
You can create and deploy an Ingress configuration using Kubernetes kubectl
or APIs. You can also configure and deploy an Ingress from NetScaler Console.
You can specify the following aspects of Kubernetes integration in NetScaler Console:
-
Cluster – You can register or unregister Kubernetes clusters for which NetScaler Console can deploy Ingress configurations. When you register a cluster in NetScaler Console, specify the Kubernetes API server information. Then, select an agent that can reach the Kubernetes cluster and deploy Ingress configurations.
-
Policies – Ingress policies are used to select the NetScaler instance based on cluster or namespace to deploy an Ingress configuration. Specify the cluster, site, and instance information when you add a policy.
Before you begin
To use NetScaler instances as Ingress devices on Kubernetes clusters, ensure you have:
-
Kubernetes cluster in place.
-
Kubernetes cluster registered in NetScaler Console.
Configure the NetScaler Console with a secret token to manage a Kubernetes cluster
For NetScaler Console to be able to receive events from Kubernetes, you need to create a service account in Kubernetes for NetScaler Console. And, configure the service account with the necessary RBAC permissions in the Cluster.
-
Create a service account for NetScaler Console. For example, the service account name can be
citrixadm-sa
. To create a service account, see Use Multiple Service Accounts. -
Use the
cluster-admin
role to bind the NetScaler Console service account. This binding grants aClusterRole
across the cluster to a service account. The following is an example command to bind acluster-admin
role to the service account.kubectl create clusterrolebinding citrixadm-sa-admin --clusterrole=cluster-admin --serviceaccount=default:citrixadm-sa <!--NeedCopy-->
After binding the NetScaler Console service account to the
cluster-admin
role, the service account has the cluster-wide access. For more information, seekubectl
createclusterrolebinding
. -
Obtain the token from the created service account.
For example, run the following command to view the token for the
citrixadm-sa
service account:kubectl describe sa citrixadm-sa <!--NeedCopy-->
-
Run the following command to obtain the secret string of the token:
kubectl describe secret <token-name> <!--NeedCopy-->
Add the Kubernetes cluster in NetScaler Console
After you configure a NetScaler agent and configure static routes, you must register the Kubernetes cluster in NetScaler Console.
To register the Kubernetes cluster:
-
Log on to NetScaler Console with administrator credentials.
-
Navigate to Orchestration > Kubernetes > Cluster. The Clusters page is displayed.
-
Click Add.
-
In the Add Cluster page, specify the following parameters:
-
Name - Specify a name of your choice.
-
API Server URL - You can get the API Server URL details from the Kubernetes main node.
-
On the Kubernetes main node, run the command
kubectl cluster-info
. -
Enter the URL that displays for “Kubernetes master is running at.”
-
-
Authentication Token - Specify the authentication token string obtained while you configure NetScaler Console to manage a Kubernetes cluster. The authentication token is required to validate access for communication between the Kubernetes cluster and NetScaler Console. To generate an authentication token:
-
On the Kubernetes main node, run the following commands:
kubectl describe secret <token-name> <!--NeedCopy-->
-
Copy the token that is generated and paste it as the Authentication Token
For more information, see Kubernetes documentation.
-
-
Select the agent from the list.
-
Click Create.
-
Share
Share
This Preview product documentation is Cloud Software Group Confidential.
You agree to hold this documentation confidential pursuant to the terms of your Cloud Software Group Beta/Tech Preview Agreement.
The development, release and timing of any features or functionality described in the Preview documentation remains at our sole discretion and are subject to change without notice or consultation.
The documentation is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making Cloud Software Group product purchase decisions.
If you do not agree, select I DO NOT AGREE to exit.