K8S Services

2023-10-10 18:41:28

Services

https://segmentfault.com/a/1190000023125587

左边从上到下，是依赖关系。

LoadBalancer是NodePort, 添加负载均衡特性。

NodePort是ClusterIP，添加在节点上开放接口功能。

ExternalName 对命名空间外和K8S外的服务进行访问。

https://itnext.io/kubernetes-clusterip-vs-nodeport-vs-loadbalancer-services-and-ingress-an-overview-with-722a07f3cfe1

Kubernetes Service types — an overview

Let’s take a brief overview of each type and then will start with examples:

ClusterIP: the default type, will create a Service resource with an IP address from the cluster's pool, such a Service will be available from within the cluster only (or with kube-proxy)

NodePort: will open a TCP port on each WorkerNode EС2, “behind it” automatically will create a ClusterIP Service and will route traffic from this TCP port on an ЕС2 to this ClusterIP - such a service will be accessible from the world (obviously, if an EC2 has a public IP), or within a VPC

LoadBalancer: will create an external Load Balancer (AWS Classic LB), “behind it” automatically will create a NodePort, then ClusterIP and in this way will route traffic from the Load Balancer to a pod in a cluster

ExternalName: something like a DNS-proxy - in response to such a Service will return a record taken via CNAME of the record specified in the externalName

ClusterIP

类型的service 只能在集群内访问。

ClusterIP

principle

https://spectrumstutz.com/k8s/k8s-services/

1. ClusterIP : Used only for internal access.

The service API object is shown on the left side the diagram and when this gets deployed the following things happen internally.

K8S assigns a cluster IP to the service

The service create an Endpoints object based on spec.selector and keeps track of the backing POD IPs.

kube-proxy creates the routing rules from cluster ip (@port) to endpoint ips(@ target ports) for load balancing purpose.

Service Discovery: With the help of DNS service,if available, a dns entry for network access is also created as shown. This helps the clients not to worry about the clusterIP that gets assigned dynamically to the service.

UserCase

https://hyoublog.com/2020/05/19/kubernetes-clusterip-service/

cluster内一个业务应用（POD），访问以服务为代表的其它POD.

NodePort

以主机节点IP像外暴露服务。

https://itnext.io/kubernetes-clusterip-vs-nodeport-vs-loadbalancer-services-and-ingress-an-overview-with-722a07f3cfe1

所有物理node上，都开放port，提供 nodeip+NodePort访问方式。

https://spectrumstutz.com/k8s/k8s-services/

LoadBalancer

已统一的 IP 向外暴露服务。

https://spectrumstutz.com/k8s/k8s-services/

https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/

configuration

https://devopstales.github.io/home/k8s-metallb-bgp-pfsense/

https://www.cnblogs.com/cnscud/p/15305433.html

principle

https://metallb.org/concepts/

MetalLB hooks into your Kubernetes cluster, and provides a network load-balancer implementation. In short, it allows you to create Kubernetes services of type LoadBalancer in clusters that don’t run on a cloud provider, and thus cannot simply hook into paid products to provide load balancers.

It has two features that work together to provide this service: address allocation, and external announcement.

https://docs.k0sproject.io/main/examples/metallb-loadbalancer/

MetalLB implements the Kubernetes service of type LoadBalancer. When a LoadBalancer service is requested, MetalLB allocates an IP address from the configured range and makes the network aware that the IP “lives” in the cluster.

One of the benefits of MetalLB is that you avoid all cloud provider dependencies. That's why MetalLB is typically used for bare-metal deployments.

https://zhuanlan.zhihu.com/p/103717169

另一种是BGP模式。

这种情况的话就需要路由器支持接收Metallb的BGP广播，从而把请求分布到正确的节点上。

跟L2模式的区别就是能够通过BGP协议正确分布流量了，不再需要一个Leader节点。

缺点就是需要上层路由器支持BGP。而且因为BGP单session的限制，如果Calico也是使用的BGP模式，就会有冲突从而导致metallb无法正常工作。

Ingress

https://itnext.io/kubernetes-clusterip-vs-nodeport-vs-loadbalancer-services-and-ingress-an-overview-with-722a07f3cfe1

https://kubernetes.io/docs/tasks/access-application-cluster/ingress-minikube/

https://docs.k0sproject.io/main/examples/nginx-ingress/

NGINX Ingress Controller is a very popular Ingress for Kubernetes. In many cloud environments, it can be exposed to an external network by using the load balancer offered by the cloud provider. However, cloud load balancers are not necessary. Load balancer can also be implemented with MetalLB, which can be deployed in the same Kubernetes cluster. Another option to expose the Ingress controller to an external network is to use NodePort. Both of these alternatives are described in more detail on below, with separate examples.