mirrors/pinniped
1
0
Fork 0
mirror of https://github.com/vmware-tanzu/pinniped.git synced 2026-01-07 05:57:02 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity
Files
b987783c62b9971e033e522bddcd3e29a0ab5658
pinniped/site/content/docs/reference/supported-clusters.md
Margo Crawford b8bdfa1b9a Update docs to reference the latest k8s codegen version 
Signed-off-by: Margo Crawford <margaretc@vmware.com>
2022-03-03 10:36:42 -08:00

2.3 KiB
Raw Blame History

title, description, cascade, menu
title description cascade menu
Supported cluster types See the supported cluster types for the Pinniped Concierge.
layout
docs
docs
name weight parent
Supported Cluster Types 10 reference
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:

  1. Token Credential Request API: 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.

  2. Impersonation Proxy: Can be run on any Kubernetes cluster. Default configuration requires that a LoadBalancer service can be created. Most cloud-hosted Kubernetes environments have this capability. The Impersonation Proxy automatically provisions (when spec.impersonationProxy.mode is set to auto) a LoadBalancer for ingress to the impersonation endpoint. Users who wish to use the impersonation proxy without an automatically configured LoadBalancer can do so with an automatically provisioned ClusterIP or with a Service that they provision themselves. These options can be configured in the spec of the [CredentialIssuer](https://github.com/vmware-tanzu/pinniped/blob/main/generated/{{< latestcodegenversion >}}/README.adoc#credentialissuer).

If a cluster is capable of supporting both strategies, the Pinniped CLI will use the token credential request API strategy by default.

To choose the strategy to use with the concierge, use the --concierge-mode flag with pinniped get kubeconfig. Possible values are ImpersonationProxy and TokenCredentialRequestAPI.