api

[!NOTE] There are several different proxies you may encounter when using Kubernetes:

  • The kubectl proxy:

    • runs on a user's desktop or in a pod

    • proxies from a localhost address to the Kubernetes apiserver

    • client to proxy uses HTTP

    • proxy to apiserver uses HTTPS

    • locates apiserver

    • adds authentication headers

- The apiserver proxy: - is a bastion built into the apiserver - connects a user outside of the cluster to cluster IPs which otherwise might not be reachable - runs in the apiserver processes - client to proxy uses HTTPS (or http if apiserver so configured) - proxy to target may use HTTP or HTTPS as chosen by proxy using available information - can be used to reach a Node, Pod, or Service - does load balancing when used to reach a Service

- The kube proxy: - runs on each node - proxies UDP and TCP - does not understand HTTP - provides load balancing - is only used to reach services

- A Proxy/Load-balancer in front of apiserver(s): - existence and implementation varies from cluster to cluster (e.g. nginx) - sits between all clients and one or more apiservers - acts as load balancer if there are several apiservers.

- Cloud Load Balancers on external services: - are provided by some cloud providers (e.g. AWS ELB, Google Cloud Load Balancer) - are created automatically when the Kubernetes service has type LoadBalancer - use UDP/TCP only - implementation varies by cloud provider.

kubernetes API structure

[!NOTE|label:tips:]

  • get server

  • get default sa name

  • get token

  • get cacert

  • API path

acess cluster

  • or

Last updated

Was this helpful?