1.7 KiB
title | description | cascade | menu | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Supported cluster types | See the supported cluster types for the Pinniped Concierge. |
|
|
Cluster Type | Concierge Works? |
---|---|
VMware Tanzu Kubernetes Grid (TKG) clusters | Yes |
Kind clusters | Yes |
Kubeadm-based clusters | Yes |
Amazon Elastic Kubernetes Service (EKS) | Yes |
Google Kubernetes Engine (GKE) | Yes |
Azure Kubernetes Service (AKS) | Yes |
Background
The Pinniped Concierge has two strategies available to support clusters, under the following conditions:
-
Kube Cluster Signing Certificate: Can be run on any Kubernetes cluster where a custom pod can be executed on the same node running
kube-controller-manager
. This type of cluster is typically called "self-hosted" because the cluster's control plane is running on nodes that are part of the cluster itself. Most managed Kubernetes services do not support this. -
Impersonation Proxy: Can be run on any Kubernetes cluster where a
LoadBalancer
service can be created. Most cloud-hosted Kubernetes environments have this capability. The Impersonation Proxy automatically provisions aLoadBalancer
for ingress to the impersonation endpoint.
If a cluster is capable of supporting both strategies, the Pinniped Concierge will use the kube cluster signing certificate strategy.