Tuesday, September 27, 2022
HomeJavaAgain to fundamentals: accessing Kubernetes pods

Again to fundamentals: accessing Kubernetes pods


Ingress focuses on routing requests to companies within the cluster. It shares some features with LoadBalancer:

  • It intercepts inbound site visitors
  • It’s implementation-dependent and implementations provide completely different options, e.g., Nginx, Traefik, HAProxy, and many others.

Nevertheless, it’s not a Service.

Ingress exposes HTTP and HTTPS routes from outdoors the cluster to companies inside the cluster. Visitors routing is managed by guidelines outlined on the Ingress useful resource.

Putting in an Ingress relies upon quite a bit on the implementation. The one frequent issue is that it includes CRDs.

helm set up apisix apisix/apisix 
  --set gateway.sort=NodePort 
  --set gateway.http.nodePort=30800 
  --set ingress-controller.enabled=true 
  --namespace ingress-apisix 
  --set ingress-controller.config.apisix.serviceNamespace=ingress-apisix

Word that although the documentation mentions Minikube, it’s relevant to any native cluster, together with Variety.

The next companies needs to be accessible within the ingress-apisix namespace:

NAME                        TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)             AGE
apisix-admin                ClusterIP   10.96.98.159   <none>        9180/TCP            22h
apisix-etcd                 ClusterIP   10.96.80.154   <none>        2379/TCP,2380/TCP   22h
apisix-etcd-headless        ClusterIP   None           <none>        2379/TCP,2380/TCP   22h
apisix-gateway              NodePort    10.96.233.74   <none>        80:30800/TCP        22h
apisix-ingress-controller   ClusterIP   10.96.125.41   <none>        80/TCP              22h

To demo, we can have two companies: each can have an underlying deployment of 1 pod. Requesting /left will hit one service and return left; /proper, proper.

Let’s replace the topology accordingly:

apiVersion: apps/v1
type: Deployment
metadata:
  identify: left
  labels:
    app: left
spec:
  replicas: 1
  selector:
    matchLabels:
      app: left
  template:
    metadata:
      labels:
        app: left
    spec:
      containers:
      - identify: nginx
        picture: nginx:1.23
        volumeMounts:
          - identify: conf
            mountPath: /and many others/nginx/nginx.conf
            subPath: nginx.conf
            readOnly: true
      volumes:
        - identify: conf
          configMap:
            identify: left-conf
            objects:
              - key: nginx.conf
                path: nginx.conf
---
apiVersion: v1
type: Service
metadata:
  identify: left
spec:
  selector:
    app: left
  ports:
    - port: 80
---
apiVersion: v1
type: ConfigMap
metadata:
  identify: left-conf
knowledge:
  nginx.conf: |
    occasions {
        worker_connections  1024;
    }
    http {
        server {
            location / {
                default_type textual content/plain;
                return 200 "leftn";
            }
        }
    }

The above snippet solely describes the left path; it ought to include an analogous configuration for the proper path.

At this level, we are able to create the configuration to route paths to companies:

apiVersion: apisix.apache.org/v2beta3            (1)
type: ApisixRoute                                (1)
metadata:
  identify: apisix-route
spec:
  http:
  - identify: left
    match:
      paths:
      - "/left"
    backends:
    - serviceName: left                          (2)
      servicePort: 80                            (2)
  - identify: proper
    match:
      paths:
        - "/proper"
    backends:
    - serviceName: proper                         (3)
      servicePort: 80                            (3)

1 Use the ApisixRoute CRD created by the set up
2 Ahead request to the left service
3 Ahead request to the proper service

Right here’s what it ought to appear like. Word that I’ve chosen to characterize solely the left path and one node to not overload the diagram.

To test that it really works, let’s curl once more.

{"error_msg":"404 Route Not Discovered"}

It’s a great signal: APISIX is responding.

We will now attempt to curl the proper path to make sure it’ll ahead to the related pod.

curl localhost:30800/proper

RELATED ARTICLES

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Most Popular

Recent Comments