Kubernetes supports a variety of ways to bring external traffic to the cluster. ClusterIP, NodePort, and Ingress are three widely used resources that all play a role in routing traffic. Each allows you to expose services with a unique set of features and trade-offs.

background

By default, services running on Kubernetes live isolated lives in their pods, unable to be disturbed by outsiders. We can create a Service to make the container visible to the outside world, which can be the entire cluster or the entire Internet.

Service routes traffic to containers inside pods. Service is an abstract mechanism for exposing PODS on the network. Each Service has a type — ClusterIP, NodePort, or LoadBalancer. These define how external traffic reaches the service.

However, Service alone is not enough. Sometimes we need to route traffic from different domain names and URL paths to the cluster, which requires Ingress help.

ClusterIP

ClusterIP is the default Service Type. If Type is not specified, the default Service Type is ClusterIP. ClusterIP provides network connectivity within a cluster. It is usually not accessible from the outside. We use these ClusterIP Services for internal networks between services.

apiVersion: v1
kind: Service
spec:
	metadata:
  	name: my-service
  selector:
    app: my-app
  type: ClusterIP
  ports:
    - name: http
      port: 80
      targetPort: 8080
      protocol: TCP
Copy the code

The example above defines a ClusterIP Service. Traffic to port 80 on ClusterIP will be forwarded to port 8080 on your Pod (targetPort configuration item) and the Pod with the app: my-app tag will be added to the Service as an available endpoint as a Service.

You can view the assigned IP address by running kubectl get SVC my-service. Other services in the cluster can interact with services managed by this Service using 10.96.0.1:80.

➜  kubectl get svc app-service
NAME              TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)           AGE
my-service        ClusterIP   10.96.0.1        <none>        8080:80/TCP       63d
Copy the code

You can manually set the clusterIp to a specific IP address using the spec.clusterIp field:

spec:
  type: ClusterIP
  clusterIp: 123.123123.123.
Copy the code

NodePort

NodePort exposes the service to the outside of the cluster on a fixed port number. It allows access to the service from outside the cluster using the IP address of the cluster and the port specified by NodePort. Creating the NodePort Service opens this port on each Node in the cluster. Kubernetes automatically routes port traffic to the service it connects to. Here is an example of a NodePort Service:

apiVersion: v1
kind: Service
spec:
	metadata:
  	name: my-service
  selector:
    app: my-app
  type: NodePort
  ports:
    - name: http
      port: 80
      targetPort: 8080
      protocol: TCP
Copy the code

The NodePort definition has the same properties as the ClusterIP Service. The only difference is that the type is set to “NodePort”. The targetPort field is still required because NodePort is supported by ClusterIP.

When the NodePort Service is created, a ClusterIP Service is automatically created. The NodePort route traffic on the port to the ClusterIP Service.

That’s why NodePort Service has a ClusterIP:

➜  kubectl get svc my-service
NAME              TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)           AGE
my-service        NodePort    10.96.44.244     <none>        8080:30176/TCP    56d
Copy the code

Kubernetes will randomly assign a port from 30000 to 32767 as a NodePort, but we can manually specify the port by setting the ports. NodePort field:

spec:
  ports:
    - name: http
      port: 80
      targetPort: 8080
      nodePort: 32000
      protocol: TCP
Copy the code

This will eventually route traffic on port 32000 through the Service to port 8080 in the Pod container.

You can use NodePort to quickly set up services for your development environment or to expose TCP or UDP services on it, but NodePort is not an ideal choice for exposing HTTP services because it uses non-HTTP standard ports and we need to use other alternatives.

Ingress

Ingress is a completely different resource from a Service. It acts as a proxy on top of a Service. The Ingress is usually used to provide HTTP routing configuration before a Service. It allows us to set up external urls, domain-based virtual hosting, SSL, and load balancing.

Add Ingress to Service. You need ingress-controller in your cluster. There are many controllers to choose from. Most major cloud providers have their own Ingress-Controller that is integrated with their load-balancing infrastructure. If you have a self-built K8S cluster, you typically use nginx-ingress as the controller, which uses an Nginx server as a reverse proxy to route traffic to subsequent services.

About controller Nginx – Ingress installation deployment, please refer to: kubernetes. Making. IO/Ingress – ngi… The Ingress practice will be covered in more detail in a later article.

An Ingress can be created using the Ingress resource type. Kubernetes. IO/ingress. Allows you to specify the class notes is creating the ingress of classification. This is useful if you have multiple Ingress-Controllers installed in your cluster, or you can add some high availability by hanging different services under different classes of Ingress.

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    kubernetes.io/ingress.class: nginx
spec:
  rules:
    - host: example.com
      http:
        paths:
          - path: /
            backend:
              serviceName: my-service
              servicePort: 80
    - host: another-example.com
      http:
        paths:
          - path: /
            backend:
              serviceName: second-service
              servicePort: 80
Copy the code

Two Ingress endpoints are defined above. The first host rule routes example.com traffic to port 80 on the my-service service. Rule 2 routes traffic from another-example.com to second-service.

If you want to access the service using HTTPs, you can configure SSL by setting the TLS field in the Ingress specification:

spec:
  tls:
    - hosts:
      - example.com
      - secretName: my-secret
Copy the code

However, the premise is to configure the certificate information for these domain names in the cluster through the Secret object.

Use Ingress when you need to handle traffic from multiple domain names and URL paths. It allows us to configure routes and services using declarative statements. The Ingress controller will provide your routes and map them to the service.

conclusion

ClusterIP, NodePort, and Ingress routes traffic to services in the cluster. Each one is designed for a different use case. ClusterIP is more designed for intra-cluster service communication, and certain TCP and UDP services exposed to the outside of the cluster are suitable for using NodePort. If the HTTP Service is exposed and needs to provide domain name and URL path routing capabilities, an Ingress layer on top of the Service is required to act as a reverse proxy.

Maybe you are still a little vague about Ingress and Ingress-Controller. Later, I will write an article about Ingress practice to clear up the confusion for everyone.

Students who do not pay attention to, you can pay attention to the article behind the dynamic.

reading

  • Combine learning and practice to quickly master K8S Service
  • What is the Pod often mentioned in K8S

That’s all for today’s article, please give me a thumbs up if you like my article, AND I will share what I have learned and seen and first-hand experience through technical articles every week. Thank you for your support. Wechat search attention to the public number – bi network management nagging every week to teach you an advanced knowledge.