api
references:
customizing components with the kubeadm api
Pod
PodTemplate
ReplicationController
ReplicaSet
Deployment
StatefulSet
ControllerRevision
DaemonSet
Job
CronJob
HorizontalPodAutoscaler
PriorityClass
Service
Endpoints
EndpointSlice
Ingress
IngressClass
Node
Namespace
Event
APIService
Lease
RuntimeClass
FlowSchema v1beta2
PriorityLevelConfiguration v1beta2
Binding
ComponentStatus
[!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.
[!NOTE|label:tips:]
get server
get default sa name
get token
get cacert
API path
acess cluster
or
Last updated