Table of Contents
1. service microservice
2. IPvs mode
3. ClusterIP
1.ClusterIP
2.headless
4. NodePort
1.NodePort
2.Default port
5. LoadBalancer
1.LoadBalancer
2.metallb
6.ExternalName
1. service microservice
Kubernetes Service microservice is a Kubernetes-based microservice architecture that achieves high scalability, elasticity, and maintainability by splitting services into multiple small service units. Each service unit has its own containers, storage, and network and can be deployed and upgraded independently. At the same time, Kubernetes Service microservices can also use Kubernetes’ built-in load balancer to automatically distribute requests and handle service failures. In short, Kubernetes Service microservice is an advanced container orchestration and management technology based on Kubernetes, which can provide an efficient, highly available and highly scalable microservice architecture.
2. Ipvs mode
The IPVS mode of Kubernetes Service is an efficient load balancing method, which is implemented using the IPVS (IP Virtual Server) technology provided by the Linux kernel.
In IPVS mode, Kubernetes creates an independent IPVS proxy on each node and broadcasts the virtual IP addresses of all services to the physical network through the BGP protocol. These IP addresses are then routed to the corresponding nodes, and the requests are forwarded by the IPVS proxy on the node.
The IPVS proxy can select the appropriate backend Pod based on the service’s load balancing policy (such as polling, source IP hashing, minimum number of connections, etc.) and forward the request to the Pod. At the same time, the IPVS proxy also supports the Session Affinity function to ensure that requests from the same client are forwarded to the same backend Pod to avoid problems such as data inconsistency.
The advantage of IPVS mode is that its performance and scalability are very good, and it can easily handle a large number of network requests. At the same time, due to the decoupling between the IPVS proxy and the physical network, it also has good flexibility and reliability, and can adapt to various network environments and service requirements.
Modify proxy configuration:
kubectl -n kube-system edit cm kube-proxy
Restart pod
kubectl -n kube-system get pod|grep kube-proxy | awk '{system("kubectl -n kube-system delete pod "$1"")}'
After switching to ipvs mode, kube-proxy will add a virtual network card: kube-ipvs0 on the host and assign service IP
Three, ClusterIP
1.ClusterIP
The Service object in Kubernetes can be used to define the logical access method of a group of Pods, where ClusterIP is the default type of Service. ClusterIP will provide a virtual IP address for the Pod. This address is only available within the Kubernetes cluster and cannot be accessed by other external networks.
Create test example:
vim myapp.yml
apiVersion: apps/v1
Kind: Deployment
metadata:
labels:
app:myapp
name: myapp
spec:
replicas: 6
selector:
matchLabels:
app:myapp
template:
metadata:
labels:
app:myapp
spec:
containers:
- image: myapp:v1
name: myapp
---
apiVersion: v1
Kind: Service
metadata:
labels:
app:myapp
name: myapp
spec:
ports:
- port: 80
protocol:TCP
targetPort: 80
selector:
app:myapp
type:ClusterIP
//ClusterIP is a type of Kubernetes Service. It provides other Pods in the same Kubernetes cluster with the IP address to access the Service. This IP address and Service are virtual and are not exposed to the outside world and can only be used within the cluster.
kubectl apply -f myapp.yml kubectl get svc dig -t A myapp.default.svc.cluster.local. @10.96.0.10
After the service is created, the cluster DNS provides resolution
The ClusterIP Service type uses iptables scheduling by default. iptables is responsible for mapping the ClusterIP address of the Service to the IP address and port of the backend Pod, and handling the load balancing and high availability of requests.
2.headless
The headless mode of Kubernetes Service means that the Service will not automatically create a ClusterIP proxy. In headless mode, when the Pod corresponding to the Service is queried through DNS, a list of IP addresses of all Pods will be returned instead of a single IP address.
headless Service can be used in the following scenarios:
- Stateful applications (StatefulSet): Each Pod requires a unique identifier, such as the name of a database.
- Multi-replica applications: A list of IP addresses for each replica needs to be returned to the client for load balancing.
- Intra-cluster communication: For example, one application needs to communicate directly with another application’s Pods instead of the Service’s load balancing proxy.
To use a headless Service, set clusterIP to None in the Service’s YAML file, for example:
vim myapp.yml
apiVersion: v1
Kind: Service
metadata:
labels:
app:myapp
name: myapp
spec:
ports:
- port: 80
protocol:TCP
targetPort: 80
selector:
app:myapp
type:ClusterIP
clusterIP: None
kubectl delete svc myapp kubectl apply -f myapp.yml kubectl get svc
Headless mode does not allocate VIP
Headless is accessed through the svc name, and resolution is provided by the dns within the cluster.
dig -t A myapp.default.svc.cluster.local. @10.96.0.10
Directly use the service name to access within the cluster
kubectl run demo --image busyboxplus -it --rm nslookup myapp
Four. NodePort
1.NodePort
The NodePort type Service opens a port on each Node for forwarding requests to Pods.
nodePort is a field of the Service type, used to specify the port range for forwarding requests. By default, the value is randomly assigned.
The following is an example of yaml to create a NodePort type Service:
vim myapp.yml
apiVersion: v1
Kind: Service
metadata:
labels:
app:myapp
name: myapp
spec:
ports:
- port: 80
protocol:TCP
targetPort: 80
selector:
app:myapp
type: NodePort
nodeport binds ports on cluster nodes, and one port corresponds to one service.
2.Default port
The default port for NodePort is any port between 30000 and 32767. You can use the kubectl get svc command to view the port bound to NodePort.
vim myapp.yml
apiVersion: v1
Kind: Service
metadata:
labels:
app:myapp
name: myapp
spec:
ports:
- port: 80
protocol:TCP
targetPort: 80
nodePort: 33333
selector:
app:myapp
type: NodePort
The default port of nodeport is 30000-32767. If it exceeds, an error will be reported:
Add the following parameters, the port range can be customized
- --service-node-port-range=30000-50000
After modification, the api-server will automatically restart, and the cluster can only be operated after the apiserver starts normally.
5. LoadBalancer
1.LoadBalancer
LoadBalancer in Kubernetes is a service type that allows the creation of externally accessible load balancers in cloud environments. When using a LoadBalancer type of service, the Kubernetes cluster automatically creates the cloud provider’s load balancer and distributes requests to the backend Pods.
The LoadBalancer service type requires cloud provider support and is implemented by automatically creating an external load balancer. For example, use AWS’s Elastic Load Balancer or GCP’s Load Balancer. Configuring a LoadBalancer service requires defining the service port and target port, as well as the load balancing algorithm and strategy to be used.
Using the LoadBalancer service type, you can easily expose applications deployed in Kubernetes to external networks and distribute traffic among application instances to provide high availability and scalability.
vim myapp.yml
apiVersion: v1
Kind: Service
metadata:
labels:
app:myapp
name: myapp
spec:
ports:
- port: 80
protocol:TCP
targetPort: 80
selector:
app:myapp
type: LoadBalancer
LoadBalancer mode is suitable for cloud platforms. Bare metal environments require metallb to be installed for support.
2.metallb
Metallb is an open source software for handling Load Balancing. In a Kubernetes cluster, Service is an abstract concept that provides a unified entrance for Pods so that Pods can be accessed by other Pods or external networks. Metallb provides a software-defined Load Balancer for Kubernetes Services that automatically assigns IP addresses and routes traffic to the correct Pods.
The core components of Metallb are speaker and controller. The controller is responsible for monitoring the status of Kubernetes Service and Pod, and assigning an IP address to each Service. The speaker will run on each node and configure the IP address of the Service to the network interface on the node.
Using Metallb, the Service in the Kubernetes cluster can obtain a fixed IP address without relying on the cloud vendor’s Load Balancer. This can improve the stability and reliability of the cluster, and Kubernetes clusters can be deployed in any environment.
kubectl edit configmap -n kube-system kube-proxy
kubectl -n kube-system get pod|grep kube-proxy | awk '{system("kubectl -n kube-system delete pod "$1"")}'
strictARP: true //Enabling the strictARP option of Kubernetes Service can prevent ARP spoofing attacks and improve network security
Download deployment files
wget https://raw.githubusercontent.com/metallb/metallb/v0.13.11/config/manifests/metallb-native.yaml
Modify the image address in the file to be consistent with the harbor warehouse path
Upload harbor warehouse:
Deployment service
kubectl apply -f metallb-native.yaml kubectl -n metallb-system get pod
Configure allocation address segment
vim config.yaml apiVersion: metallb.io/v1beta1 kind:IPAddressPool metadata: name: first-pool namespace: metallb-system spec: addresses: - 192.168.67.120-192.168.67.200 #Modify to your own local address segment --- apiVersion: metallb.io/v1beta1 Kind: L2Advertisement metadata: name: example namespace: metallb-system spec: ipAddressPools: -first-pool
Access services from outside the cluster by assigning addresses
6. ExternalName
The ExternalName type of Kubernetes Service is a very simple service type that allows services in the Kubernetes cluster to reference an external service through a DNS CNAME. This service can be any service outside the cluster, such as a third-party database or cache server.
Using ExternalName type services, you can easily connect applications in the Kubernetes cluster to services outside the cluster, and you can also use the load balancing and service discovery functions of Kubernetes. In this way, the purpose of integrating multiple services into a unified DNS domain name can be achieved.
The service definition of the ExternalName type is very simple. You only need to specify the service name and the DNS name of the external service. For example:
vim externalname.yaml apiVersion: v1 Kind: Service metadata: name: my-service spec: type: ExternalName externalName: www.westos.org kubectl apply -f externalname.yaml dig -t A [email protected]
The knowledge points of the article match the official knowledge files, and you can further learn relevant knowledge. Cloud native entry-level skills treeHomepageOverview 16,879 people are learning the system