Difference between revisions of "Kubernetes/Services and networking"
(draft) |
|||
(3 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
https://kubernetes.io/docs/concepts/services-networking/ gives a deep dive into the various capabilities around exposing services and the networking models in Kubernetes. | https://kubernetes.io/docs/concepts/services-networking/ gives a deep dive into the various capabilities around exposing services and the networking models in Kubernetes. | ||
+ | {{#ev:youtube|https://www.youtube.com/watch?v=T4Z7visMM4E}} | ||
+ | == What is a Kubernetes Service? == | ||
Service is a top-level resource in the Kubernetes REST API. You can find more details about the [https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#service-v1-core Service API object] | Service is a top-level resource in the Kubernetes REST API. You can find more details about the [https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#service-v1-core Service API object] | ||
Line 33: | Line 35: | ||
type determines how the Service is exposed. Defaults to '''ClusterIP'''. Valid options are '''ExternalName''', '''ClusterIP''', '''NodePort''', and '''LoadBalancer'''. "ClusterIP" allocates a cluster-internal IP address for load-balancing to endpoints. Endpoints are determined by the selector or if that is not specified, by manual construction of an Endpoints object or EndpointSlice objects. If clusterIP is "None", no virtual IP is allocated and the endpoints are published as a set of endpoints rather than a virtual IP. "NodePort" builds on ClusterIP and allocates a port on every node which routes to the same endpoints as the clusterIP. "LoadBalancer" builds on NodePort and creates an external load-balancer (if supported in the current cloud) which routes to the same endpoints as the clusterIP. "ExternalName" aliases this service to the specified externalName. Several other fields do not apply to ExternalName services. More info: https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types | type determines how the Service is exposed. Defaults to '''ClusterIP'''. Valid options are '''ExternalName''', '''ClusterIP''', '''NodePort''', and '''LoadBalancer'''. "ClusterIP" allocates a cluster-internal IP address for load-balancing to endpoints. Endpoints are determined by the selector or if that is not specified, by manual construction of an Endpoints object or EndpointSlice objects. If clusterIP is "None", no virtual IP is allocated and the endpoints are published as a set of endpoints rather than a virtual IP. "NodePort" builds on ClusterIP and allocates a port on every node which routes to the same endpoints as the clusterIP. "LoadBalancer" builds on NodePort and creates an external load-balancer (if supported in the current cloud) which routes to the same endpoints as the clusterIP. "ExternalName" aliases this service to the specified externalName. Several other fields do not apply to ExternalName services. More info: https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types | ||
− | + | The official documentation is at https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types | |
− | |||
; <tt>type: ClusterIP</tt> | ; <tt>type: ClusterIP</tt> | ||
− | : expose pods only inside your kubernetes cluster. You can make them public using an [https://kubernetes.io/docs/concepts/services-networking/ingress/ Ingress] or a [https://gateway-api.sigs.k8s.io/ Gateway] | + | : expose pods only inside your kubernetes cluster. You can make them public using an [https://kubernetes.io/docs/concepts/services-networking/ingress/ Ingress] or a [https://gateway-api.sigs.k8s.io/ Gateway] |
; <tt>type: NodePort</tt> | ; <tt>type: NodePort</tt> | ||
: expose services on a static port | : expose services on a static port | ||
; <tt>type: LoadBalancer</tt> | ; <tt>type: LoadBalancer</tt> | ||
− | : | + | : Just what it sounds like. You can create both internal and external load balancers in cases where you need Split Horizon DNS |
; <tt>type: ExternalName</tt> | ; <tt>type: ExternalName</tt> | ||
+ | : map a Service to a DNS name, not to a typical selector such as my-service or cassandra | ||
+ | : This Service definition, for example, maps the <tt>my-service</tt> Service in the <tt>prod</tt> namespace to <tt>my.database.example.com</tt>: | ||
+ | : <syntaxhighlight lang="yaml"> | ||
+ | apiVersion: v1 | ||
+ | kind: Service | ||
+ | metadata: | ||
+ | name: my-service | ||
+ | namespace: prod | ||
+ | spec: | ||
+ | type: ExternalName | ||
+ | externalName: my.database.example.com | ||
+ | </syntaxhighlight> | ||
+ | : When looking up the host <tt>my-service.prod.svc.cluster.local</tt>, the cluster DNS Service returns a <tt>CNAME</tt> record with the value <tt>my.database.example.com</tt>. Accessing <tt>my-service</tt> works in the same way as other Services but with the crucial difference that redirection happens at the DNS level rather than via proxying or forwarding. Should you later decide to move your database into your cluster, you can start its Pods, add appropriate selectors or endpoints, and change the Service's type. | ||
+ | : | ||
+ | : Note: although you can use an IPv4 address string of digits as the name, don't do it. | ||
+ | : Consider using [https://kubernetes.io/docs/concepts/services-networking/service/#headless-services headless services] for that use case. | ||
{{References}} | {{References}} | ||
[[Category:Kubernetes]] | [[Category:Kubernetes]] |
Latest revision as of 13:42, 18 November 2023
https://kubernetes.io/docs/concepts/services-networking/ gives a deep dive into the various capabilities around exposing services and the networking models in Kubernetes.
What is a Kubernetes Service?[edit | edit source]
Service is a top-level resource in the Kubernetes REST API. You can find more details about the Service API object
Example[edit | edit source]
Service Config to load balance traffic across all Pods with the app=nginx label. Receives on and sends to port 80. Exposes an externally accessible endpoint.
kind: Service
apiVersion: v1
metadata:
# Unique key of the Service instance
name: service-example
spec:
ports:
# Accept traffic sent to port 80
- name: http
port: 80
targetPort: 80
selector:
# Loadbalance traffic across Pods matching
# this label selector
app: nginx
# Create an HA proxy in the cloud provider
# with an External IP address - *Only supported
# by some cloud providers*
type: LoadBalancer
Service Type[edit | edit source]
(quoted from the documentation [1])
type determines how the Service is exposed. Defaults to ClusterIP. Valid options are ExternalName, ClusterIP, NodePort, and LoadBalancer. "ClusterIP" allocates a cluster-internal IP address for load-balancing to endpoints. Endpoints are determined by the selector or if that is not specified, by manual construction of an Endpoints object or EndpointSlice objects. If clusterIP is "None", no virtual IP is allocated and the endpoints are published as a set of endpoints rather than a virtual IP. "NodePort" builds on ClusterIP and allocates a port on every node which routes to the same endpoints as the clusterIP. "LoadBalancer" builds on NodePort and creates an external load-balancer (if supported in the current cloud) which routes to the same endpoints as the clusterIP. "ExternalName" aliases this service to the specified externalName. Several other fields do not apply to ExternalName services. More info: https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types
The official documentation is at https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types
- type: ClusterIP
: expose pods only inside your kubernetes cluster. You can make them public using an Ingress or a Gateway
- type: NodePort
- expose services on a static port
- type: LoadBalancer
- Just what it sounds like. You can create both internal and external load balancers in cases where you need Split Horizon DNS
- type: ExternalName
- map a Service to a DNS name, not to a typical selector such as my-service or cassandra
- This Service definition, for example, maps the my-service Service in the prod namespace to my.database.example.com:
apiVersion: v1 kind: Service metadata: name: my-service namespace: prod spec: type: ExternalName externalName: my.database.example.com
- When looking up the host my-service.prod.svc.cluster.local, the cluster DNS Service returns a CNAME record with the value my.database.example.com. Accessing my-service works in the same way as other Services but with the crucial difference that redirection happens at the DNS level rather than via proxying or forwarding. Should you later decide to move your database into your cluster, you can start its Pods, add appropriate selectors or endpoints, and change the Service's type.
- Note: although you can use an IPv4 address string of digits as the name, don't do it.
- Consider using headless services for that use case.