mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-22 19:18:04 +00:00
Update AKS cluster configuration reference
This commit is contained in:
Catherine Luse
@@ -91,6 +91,29 @@
|
||||
<div class="row max-sized cards-container">
|
||||
<div class="col-12 cards-wrap">
|
||||
<div class="row center-xs card-items-wrap">
|
||||
<div class="
|
||||
col-xl-4
|
||||
col-lg-4
|
||||
col-md-4
|
||||
col-sm-12
|
||||
col-xs-12
|
||||
col-12
|
||||
card-item">
|
||||
<div class="card-wrap">
|
||||
<h3 class="title-label">
|
||||
<span class="background">2.6</span>
|
||||
Rancher 2.6
|
||||
</h3>
|
||||
|
||||
<hr/>
|
||||
|
||||
<p class="description-label">Rancher manages all of your Kubernetes clusters everywhere, unifies them under centralized RBAC, monitors them and lets you easily deploy and manage workloads through an intuitive user interface.</p>
|
||||
|
||||
<div class="buttons-container">
|
||||
<a href="{{<baseurl>}}/rancher/v2.6/en/">Rancher v2.6</a>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="
|
||||
col-xl-4
|
||||
col-lg-4
|
||||
|
||||
@@ -16,6 +16,6 @@ One Rancher server installation can manage thousands of Kubernetes clusters and
|
||||
|
||||
Rancher adds significant value on top of Kubernetes, first by centralizing authentication and role-based access control (RBAC) for all of the clusters, giving global admins the ability to control cluster access from one location.
|
||||
|
||||
It then enables detailed monitoring and alerting for clusters and their resources, ships logs to external providers, and integrates directly with Helm via the Application Catalog. If you have an external CI/CD system, you can plug it into Rancher, but if you don't, Rancher even includes a pipeline engine to help you automatically deploy and upgrade workloads.
|
||||
It then enables detailed monitoring and alerting for clusters and their resources, ships logs to external providers, and integrates directly with Helm via the Application Catalog. If you have an external CI/CD system, you can plug it into Rancher, but if you don't, Rancher even includes Fleet to help you automatically deploy and upgrade workloads.
|
||||
|
||||
Rancher is a _complete_ container management platform for Kubernetes, giving you the tools to successfully run Kubernetes anywhere.
|
||||
@@ -16,6 +16,7 @@ The cluster configuration options depend on the type of Kubernetes cluster:
|
||||
- [RKE Cluster Configuration](./rke-config-reference)
|
||||
- [EKS Cluster Configuration](./eks-config-reference)
|
||||
- [GKE Cluster Configuration](./gke-config-reference)
|
||||
- [AKS Cluster Configuration](./aks-config-reference)
|
||||
|
||||
### Cluster Management Capabilities by Cluster Type
|
||||
|
||||
|
||||
+176
-96
@@ -1,10 +1,10 @@
|
||||
---
|
||||
shortTitle: AKS Cluster Configuration
|
||||
title: AKS Cluster Configuration Reference
|
||||
weight: 4
|
||||
---
|
||||
|
||||
|
||||
### Changes in v2.6
|
||||
# Changes in v2.6
|
||||
|
||||
- Support for node pools
|
||||
- Support for private clusters
|
||||
@@ -13,129 +13,209 @@ weight: 4
|
||||
- For networking, a new field was added in the UI: Support Private Kubernetes Service
|
||||
- Windows support was removed
|
||||
|
||||
# Role-based Access Control
|
||||
|
||||
When provisioning an AKS cluster in the Rancher UI, RBAC is not configurable because it is required to be enabled.
|
||||
|
||||
### Account Access
|
||||
|
||||
Complete each drop-down and field using the information obtained for your IAM policy.
|
||||
|
||||
| Setting | Description |
|
||||
| ---------- | -------------------------------------------------------------------------------------------------------------------- |
|
||||
| Region | From the drop-down choose the geographical region in which to build your cluster. |
|
||||
| Cloud Credentials | Select the cloud credentials that you created for your IAM policy. For more information on creating cloud credentials in Rancher, refer to [this page.]({{<baseurl>}}/rancher/v2.x/en/user-settings/cloud-credentials/) |
|
||||
|
||||
[Microsoft Documentation: How to create and use an SSH public and private key pair](https://docs.microsoft.com/en-us/azure/virtual-machines/linux/mac-create-ssh-keys)
|
||||
|
||||
# OLD
|
||||
|
||||
1. Use your subscription ID, tenant ID, app ID, and client secret to give your cluster access to AKS. If you don't have all of that information, you can retrieve it using these instructions:
|
||||
|
||||
- **Client secret:** If you didn't copy the client secret when creating the service principal, you can get a new one if you go to the app registration detail page, then click **Certificates & secrets**, then click **New client secret.**
|
||||
- **Subscription ID:** You can get the subscription ID is available in the portal from **All services > Subscriptions.**
|
||||
|
||||
|
||||
|
||||
### HTTP Application
|
||||
|
||||
This feature allows you to set up an ingress controller in Azure.
|
||||
|
||||
|
||||
# NEW
|
||||
RBAC is required for AKS clusters that are registered or imported into Rancher.
|
||||
|
||||
# Cloud Credentials
|
||||
|
||||
### Application ID and Tenant ID
|
||||
> The configuration information in this section assumes you have already set up a service principal for Rancher. For step-by-step instructions for how to set up the service principal, see [this section.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/hosted-kubernetes-cluster/aks/#prerequisites-in-microsoft-azure)
|
||||
|
||||
To get the app ID and tenant ID, you can go to the Azure Portal, then click **Azure Active Directory**, then click **App registrations,** then click the name of the service principal. The app ID and tenant ID are both on the app registration detail page.
|
||||
### Tenant ID
|
||||
|
||||
### Subscription
|
||||
To get the tenant ID, go to the Azure Portal, then click **Azure Active Directory**, then click **App registrations**, then click the name of the service principal. The tenant ID is listed on the app registration detail page as **Directory (tenant) ID**.
|
||||
|
||||
# Kubernetes Options
|
||||
### Subscription ID
|
||||
|
||||
### DNS Prefix
|
||||
To get the subscription ID, click **All Services** in the left navigation bar. Then click **Subscriptions.** Go to the name of the subscription that you want to associate with your Kubernetes cluster and copy the **Subscription ID.**
|
||||
|
||||
### Monitoring
|
||||
enabled or disabled
|
||||
### Client ID
|
||||
|
||||
### HTTP Application Routing
|
||||
enabled or disabled
|
||||
To get the client ID, go to the Azure Portal, then click **Azure Active Directory**, then click **App registrations,** then click the name of the service principal. The client ID is listed on the app registration detail page as **Application (client) ID**.
|
||||
|
||||
### Client Secret
|
||||
|
||||
You can't retrieve the client secret value after it is created, so if you don't already have a client secret value, you will need to create a new client secret.
|
||||
|
||||
To get a new client secret, go to the Azure Portal, then click **Azure Active Directory**, then click **App registrations,** then click the name of the service principal.
|
||||
|
||||
Then click **Certificates & secrets** and click **New client secret.** Click **Add.** Then copy the **Value** of the new client secret.
|
||||
|
||||
### Environment
|
||||
|
||||
Microsoft provides multiple [clouds](https://docs.microsoft.com/en-us/cli/azure/cloud?view=azure-cli-latest) for compliance with regional laws, which are available for your use:
|
||||
|
||||
- AzurePublicCloud
|
||||
- AzureGermanCloud
|
||||
- AzureChinaCloud
|
||||
- AzureUSGovernmentCloud
|
||||
|
||||
# Account Access
|
||||
|
||||
In this section you will need to select an existing Azure cloud credential or create a new one.
|
||||
|
||||
For help configuring your Azure cloud credential, see [this section.](#cloud-credentials)
|
||||
|
||||
# Cluster Location
|
||||
|
||||
Configure the cluster and node location. For more information on availability zones for AKS, see the [AKS documentation.](https://docs.microsoft.com/en-us/azure/aks/availability-zones)
|
||||
|
||||
The high availability locations include multiple availability zones.
|
||||
|
||||
# Cluster Options
|
||||
|
||||
Create an SSH connection to the cluster nodes using these configuration options.
|
||||
|
||||
### Kubernetes Version
|
||||
|
||||
The available Kubernetes versions are dynamically fetched from the Azure API.
|
||||
|
||||
### Cluster Resource Group
|
||||
|
||||
A resource group is a container that holds related resources for an Azure solution. The resource group can include all the resources for the solution, or only those resources that you want to manage as a group. You decide how you want to allocate resources to resource groups based on what makes the most sense for your organization. Generally, add resources that share the same lifecycle to the same resource group so you can easily deploy, update, and delete them as a group.
|
||||
|
||||
Use an existing resource group or enter a resource group name and one will be created for you.
|
||||
|
||||
Using a resource group containing an existing AKS cluster will create a new resource group. Azure AKS only allows one AKS cluster per resource group.
|
||||
|
||||
For information on managing resource groups, see the [Azure documentation.](https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-portal)
|
||||
|
||||
### Linux Admin Username
|
||||
|
||||
The username used to create an SSH connection to the Linux nodes.
|
||||
|
||||
The default username for AKS nodes is `azureuser`.
|
||||
|
||||
### SSH Public Key
|
||||
|
||||
The key used to create an SSH connection to the Linux nodes.
|
||||
|
||||
### Tags
|
||||
|
||||
Cluster tags can be useful if your organization uses tags as a way to organize resources across multiple Azure services. These tags don't apply to resources within the cluster.
|
||||
|
||||
# Networking Options
|
||||
|
||||
### LoadBalancer SKU
|
||||
|
||||
Azure load balancers support both standard and basic SKUs (stock keeping units).
|
||||
|
||||
For a comparison of standard and basic load balancers, see the official [Azure documentation.](https://docs.microsoft.com/en-us/azure/load-balancer/skus#skus) Microsoft recommends the Standard load balancer.
|
||||
|
||||
The Standard load balancer is required if you have selected one or more availability zones, or if you have more than one node pool.
|
||||
|
||||
### Network Policy
|
||||
|
||||
All pods in an AKS cluster can send and receive traffic without limitations, by default. To improve security, you can define rules that control the flow of traffic. The Network Policy feature in Kubernetes lets you define rules for ingress and egress traffic between pods in a cluster.
|
||||
|
||||
Azure provides two ways to implement network policy. You choose a network policy option when you create an AKS cluster. The policy option can't be changed after the cluster is created:
|
||||
|
||||
- Azure's own implementation, called Azure Network Policies. The Azure network policy requires the Azure CNI.
|
||||
- Calico Network Policies, an open-source network and network security solution founded by [Tigera](https://www.tigera.io/).
|
||||
|
||||
You can also choose to have no network policy.
|
||||
|
||||
For more information about the differences between Azure and Calico network policies and their capabilities, see the [AKS documentation.](https://docs.microsoft.com/en-us/azure/aks/use-network-policies#differences-between-azure-and-calico-policies-and-their-capabilities)
|
||||
|
||||
### DNS Prefix
|
||||
Enter a unique DNS prefix for your cluster's Kubernetes API server FQDN.
|
||||
|
||||
### Network Plugin
|
||||
There are two network plugins: kubenet and Azure CNI.
|
||||
|
||||
The [kubenet](https://kubernetes.io/docs/concepts/cluster-administration/network-plugins/#kubenet) Kubernetes plugin is the default configuration for AKS cluster creation. When kubenet is used, each node in the cluster receives a routable IP address. The pods use NAT to communicate with other resources outside the AKS cluster. This approach reduces the number of IP addresses you need to reserve in your network space for pods to use.
|
||||
|
||||
With the Azure CNI (advanced) networking plugin, pods get full virtual network connectivity and can be directly reached via their private IP address from connected networks. This plugin requires more IP address space.
|
||||
|
||||
For more information on the differences between kubenet and Azure CNI, see the [AKS documentation.](https://docs.microsoft.com/en-us/azure/aks/concepts-network#compare-network-models)
|
||||
|
||||
### HTTP Application Routing
|
||||
|
||||
When enabled, the HTTP application routing add-on makes it easier to access applications deployed to the AKS cluster. It deploys two components: a [Kubernetes Ingress controller](https://kubernetes.io/docs/concepts/services-networking/ingress/) and an [External-DNS](https://github.com/kubernetes-incubator/external-dns) controller.
|
||||
|
||||
For more information, see the [AKS documentation.](https://docs.microsoft.com/en-us/azure/aks/http-application-routing)
|
||||
|
||||
### Set Authorized IP Ranges
|
||||
|
||||
You can secure access to the Kubernetes API server using [authorized IP address ranges.](https://docs.microsoft.com/en-us/azure/aks/api-server-authorized-ip-ranges#overview-of-api-server-authorized-ip-ranges)
|
||||
|
||||
The Kubernetes API server exposes the Kubernetes API. This component provides the interaction for management tools, such as kubectl. AKS provides a single-tenant cluster control plane with a dedicated API server. By default, the API server is assigned a public IP address, and you should control access to it using Kubernetes-based or Azure-based RBAC.
|
||||
|
||||
To secure access to the otherwise publicly accessible AKS control plane and API server, you can enable and use authorized IP ranges. These authorized IP ranges only allow defined IP address ranges to communicate with the API server.
|
||||
|
||||
However, even if you use authorized IP address ranges, you should still use Kubernetes RBAC or Azure RBAC to authorize users and the actions they request.
|
||||
### Container Monitoring
|
||||
|
||||
Container monitoring gives you performance visibility by collecting memory and processor metrics from controllers, nodes, and containers that are available in Kubernetes through the Metrics API. Container logs are also collected. After you enable monitoring, metrics and logs are automatically collected for you through a containerized version of the Log Analytics agent for Linux. Metrics are written to the metrics store and log data is written to the logs store associated with your [Log Analytics](https://docs.microsoft.com/en-us/azure/azure-monitor/logs/log-query-overview) workspace.
|
||||
|
||||
### Log Analytics Workspace Resource Group
|
||||
|
||||
The [resource group](https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/overview#resource-groups) containing the Log Analytics Workspace. You must create at least one workspace to use Azure Monitor Logs.
|
||||
|
||||
### Log Analytics Workspace Name
|
||||
|
||||
Data collected by Azure Monitor Logs is stored in one or more [Log Analytics workspaces.](https://docs.microsoft.com/en-us/azure/azure-monitor/logs/design-logs-deployment) The workspace defines the geographic location of the data, access rights defining which users can access data, and configuration settings such as the pricing tier and data retention.
|
||||
|
||||
You must create at least one workspace to use Azure Monitor Logs. A single workspace may be suffxicient for all of your monitoring data, or may choose to create multiple workspaces depending on your requirements. For example, you might have one workspace for your production data and another for testing.
|
||||
|
||||
For more information about Azure Monitor Logs, see the [Azure documentation.](https://docs.microsoft.com/en-us/azure/azure-monitor/logs/data-platform-logs)
|
||||
|
||||
### Support Private Kubernetes Service
|
||||
|
||||
Typically, AKS worker nodes do not get public IPs, regardless of whether the cluster is private, with some exceptions. In a private cluster, the control plane does not have a public endpoint.
|
||||
|
||||
In order to a to be able to connect with the AKS Kubernetes API server,
|
||||
|
||||
- The Rancher agent needs to be deployed from a node that has access to the AKS cluster's Azure Virtual Network (VNet).
|
||||
- Rancher needs to be running on the same [NAT](https://docs.microsoft.com/en-us/azure/virtual-network/nat-overview) as the AKS nodes.
|
||||
|
||||
For more information about connecting to an AKS private cluster, see the [AKS documentation.](https://docs.microsoft.com/en-us/azure/aks/private-clusters#options-for-connecting-to-the-private-cluster)
|
||||
|
||||
# Node Pools
|
||||
|
||||
|
||||
### Mode
|
||||
The Azure interface allows users to specify whether a Primary Node Pool relies on either `system` (normally used for control planes) and `user` (what is most typically needed for Rancher).
|
||||
|
||||
For Primary Node Pools, you can specify Mode, OS, Count and Size.
|
||||
|
||||
For subsequent node pools, the Rancher UI forces the default of user.
|
||||
System node pools that always require running nodes, so they cannot be scaled below one node. At least one system node pool is required.
|
||||
|
||||
Node Options need to have these two options added: VM Sizes and Node Count, which then tie into Availability Zones (AZ).
|
||||
For subsequent node pools, the Rancher UI forces the default of User. User node pools allow you to scale to zero nodes. User node pools don't run any part of the Kubernetes controlplane.
|
||||
|
||||
Not all regions have support for AZs.
|
||||
AKS doesn't expose the nodes that run the Kubernetes controlplane components.
|
||||
|
||||
### Linux Admin Username
|
||||
azureuser
|
||||
### Availability Zones
|
||||
|
||||
### Cluster Resource Group
|
||||
info in UI
|
||||
### LoadBalancer SKU
|
||||
Basic or standard
|
||||
[Availability zones](https://docs.microsoft.com/en-us/azure/availability-zones/az-overview) are unique physical locations within a region. Each zone is made up of one or more data centers equipped with independent power, cooling, and networking.
|
||||
|
||||
Not all regions have support for availability zones. For a list of Azure regions with availability zones, see the [Azure documentation.](https://docs.microsoft.com/en-us/azure/availability-zones/az-region#azure-regions-with-availability-zones)
|
||||
|
||||
### VM Size
|
||||
|
||||
Choose a size for each VM in the node pool. For details about each VM size, see [this page.](https://azure.microsoft.com/en-us/pricing/details/virtual-machines/linux/)
|
||||
|
||||
### OS Disk Type
|
||||
|
||||
The nodes in the node pool can have either managed or ephemeral disks.
|
||||
|
||||
[Ephemeral OS disks](https://docs.microsoft.com/en-us/azure/virtual-machines/ephemeral-os-disks) are created on the local virtual machine storage and not saved to the remote Azure Storage. Ephemeral OS disks work well for stateless workloads, where applications are tolerant of individual VM failures, but are more affected by VM deployment time or reimaging the individual VM instances. With Ephemeral OS disk, you get lower read/write latency to the OS disk and faster VM reimage.
|
||||
|
||||
[Azure managed disks](https://docs.microsoft.com/en-us/azure/virtual-machines/managed-disks-overview) are block-level storage volumes that are managed by Azure and used with Azure Virtual Machines. Managed disks are designed for 99.999% availability. Managed disks achieve this by providing you with three replicas of your data, allowing for high durability.
|
||||
|
||||
### OS Disk Size
|
||||
|
||||
The size in GB for the disk for each node.
|
||||
|
||||
### Node Count
|
||||
There are maximums tied to subscriptions we need to warn about.
|
||||
### OS Disk Size
|
||||
The number of nodes in the node pool. The maximum number of nodes may be limited by your [Azure subscription.](https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/azure-subscription-service-limits)
|
||||
|
||||
### Networking
|
||||
Default or advanced
|
||||
### Max Pods Per Node
|
||||
The maximum number of pods per node defaults to 110 with a maximum of 250.
|
||||
|
||||
### SSH Public Key
|
||||
### Enable Auto Scaling
|
||||
|
||||
### Node Autoscaler
|
||||
new
|
||||
When auto scaling is enabled, you will need to enter a minimum and maximum node count.
|
||||
|
||||
|
||||
### agentpools
|
||||
|
||||
|
||||
### OS
|
||||
|
||||
Linux and Windows pools aren't interchangeable (or cross-accessible)
|
||||
|
||||
### OS Disk Size
|
||||
|
||||
OS Disk Size: not exposed in the API?
|
||||
|
||||
### Maximum Pods per Node
|
||||
|
||||
Maximum pods per node defaults to 110 with a maximum of 250.
|
||||
|
||||
# Networking
|
||||
|
||||
Can adopt HTTP App Routing.
|
||||
|
||||
### Network Plugin
|
||||
|
||||
### Kubernetes service address range
|
||||
|
||||
A CIDR notation IP range from which to assign service cluster IPs. It must not overlap with any Subnet IP ranges. For example: 10.0.0.0/16.
|
||||
|
||||
### Kubernetes DNS service IP address
|
||||
|
||||
An IP address assigned to the Kubernetes DNS service. It must be within the Kubernetes service address range. For example: 10.0.0.10
|
||||
|
||||
### Docker bridge access
|
||||
An IP address and netmask assigned to Docker Bridge. It must not be in any Subnet IP ranges, or the Kubernetes service address range. For example: 172:17.0.1/16.
|
||||
|
||||
### Support Private Kubernetes Service
|
||||
|
||||
### Load Balancing
|
||||
|
||||
There are two choices: Standard and Basic. Some are specific to regions and AZs. We default to Standard because Basic has fewer options and may be deprecated soon.
|
||||
|
||||
# Private and Public Clusters
|
||||
|
||||
There are questions about whether private nodes are in fact public.
|
||||
When Auto Scaling is enabled, you can't manually scale the node pool. The scale is controlled by the AKS autoscaler.
|
||||
+23
-18
@@ -15,6 +15,7 @@ You can use Rancher to create a cluster hosted in Microsoft Azure Kubernetes Ser
|
||||
- [2. Create the AKS Cluster](#2-create-the-aks-cluster)
|
||||
- [Role-based Access Control](#role-based-access-control)
|
||||
- [AKS Cluster Configuration Reference](#aks-cluster-configuration-reference)
|
||||
- [Private Clusters](#private-clusters)
|
||||
- [Minimum AKS Permissions](#minimum-aks-permissions)
|
||||
- [Syncing](#syncing)
|
||||
|
||||
@@ -27,11 +28,10 @@ To interact with Azure APIs, an AKS cluster requires an Azure Active Directory (
|
||||
|
||||
Before creating the service principal, you need to obtain the following information from the [Microsoft Azure Portal](https://portal.azure.com):
|
||||
|
||||
- Your subscription ID
|
||||
- Your tenant ID
|
||||
- An app ID (also called a client ID)
|
||||
- Subscription ID
|
||||
- Tenant ID
|
||||
- Client ID
|
||||
- Client secret
|
||||
- A resource group
|
||||
|
||||
The below sections describe how to set up these prerequisites using either the Azure command line tool or the Azure portal.
|
||||
|
||||
@@ -106,39 +106,44 @@ To give role-based access to your service principal,
|
||||
|
||||
# 1. Create the AKS Cloud Credentials
|
||||
|
||||
1. From the **Cluster Management** global app, click **Cloud Credentials.**
|
||||
1. In the Rancher UI, click **☰ > Cluster Management.**
|
||||
1. Click **Cloud Credentials.**
|
||||
1. Click **Create.**
|
||||
1. Click **Azure AKS.**
|
||||
1. Fill out the form. For help with filling out the form, see the [configuration reference.]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/editing-clusters/aks-config-reference)
|
||||
1. Click **Azure.**
|
||||
1. Fill out the form. For help with filling out the form, see the [configuration reference.]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/editing-clusters/aks-config-reference/#cloud-credentials)
|
||||
|
||||
# 2. Create the AKS Cluster
|
||||
|
||||
Use Rancher to set up and configure your Kubernetes cluster.
|
||||
|
||||
1. From the **Cluster Management** global app, click **Clusters.**
|
||||
1. Click **Create.**
|
||||
1. Choose **Azure AKS**.
|
||||
1. Enter a **Cluster Name**.
|
||||
1. Use **Member Roles** to configure user authorization for the cluster. Click **Add Member** to add users that can access the cluster. Use the **Role** drop-down to set permissions for each user.
|
||||
1. In the Rancher UI, click **☰ > Cluster Management.**
|
||||
1. In the **Clusters** section, click **Create.**
|
||||
1. Click **Azure AKS.**
|
||||
1. Fill out the form. For help with filling out the form, see the [configuration reference.]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/editing-clusters/aks-config-reference)
|
||||
|
||||
**Result:** Your cluster is created and assigned a state of **Provisioning.** Rancher is standing up your cluster.
|
||||
|
||||
You can access your cluster after its state is updated to **Active.**
|
||||
|
||||
**Active** clusters are assigned two Projects:
|
||||
|
||||
- `Default`, containing the `default` namespace
|
||||
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
|
||||
|
||||
# Role-based Access Control
|
||||
Upon registering or importing a cluster won't work without RBAC enabled.
|
||||
When provisioning an AKS cluster in the Rancher UI, RBAC is not configurable because it is required to be enabled.
|
||||
|
||||
RBAC is required for AKS clusters that are registered or imported into Rancher.
|
||||
|
||||
# AKS Cluster Configuration Reference
|
||||
|
||||
For more information about how to configure AKS clusters from the Rancher UI, see the [configuration reference.]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/editing-clusters/aks-config-reference)
|
||||
|
||||
# Private Clusters
|
||||
|
||||
Typically, AKS worker nodes do not get public IPs, regardless of whether the cluster is private, with some exceptions. In a private cluster, the control plane does not have a public endpoint.
|
||||
|
||||
In order to a to be able to connect with the AKS Kubernetes API server,
|
||||
|
||||
- The Rancher agent needs to be deployed from a node that has access to the AKS cluster's Azure Virtual Network (VNet).
|
||||
- Rancher needs to be running on the same [NAT](https://docs.microsoft.com/en-us/azure/virtual-network/nat-overview) as the AKS nodes.
|
||||
|
||||
For more information about connecting to an AKS private cluster, see the [AKS documentation.](https://docs.microsoft.com/en-us/azure/aks/private-clusters#options-for-connecting-to-the-private-cluster)
|
||||
|
||||
# Syncing
|
||||
|
||||
|
||||
Reference in New Issue
Block a user