Connect to Application

You can choose from various solutions to connect to your application based on your requirements. The options include connecting to the application from within the cluster using Service or from outside the cluster using Ingress.

Within the Cluster

In Kubernetes, services provide network access to applications within the cluster. These services act as an entry point for a set of pods, distributing incoming traffic among them. Services come in different types:

• ClusterIP

  In this mode, a private IP is assigned to the application for communication with other services within the cluster. The naming convention for calling applications using this method is in the format service-name>.<namespace>.svc.cluster.local.

  For example, if you have a WordPress application and a MySQL application, you can call MySQL from within WordPress using mysql.project.svc.cluster.local.

• NodePort

  By opening ports for applications in their private network settings, NodePort in Kubernetes allows you to connect to applications within the cluster. For example, by opening port 3306 for the MySQL application, you can use mysql:3306 to communicate with it within the cluster.

Outside the Cluster

To access applications from outside the cluster, you can use LoadBalancer in services or Ingress.

• LoadBalancer

  LoadBalancer, which is a type of service, allows access to pods from outside the cluster with a public IP. In Arvancloud Container, you can connect to your application from outside the cluster using dedicated IP settings.

• Ingress

  With Ingress, you can define routing rules for HTTP/HTTPS incoming traffic and manage access to one or more services via URLs. By connecting a domain to your application, an Ingress is created in the background.

  Suppose you have an application named nginx running on port 80 and you want to connect to it via the address http://example.com. To achieve this, you need to create and execute an Ingress as follows:

kind: Ingress
apiVersion: networking.k8s.io/v1
metadata:
  generation: 1
  name: nginx-ingress
  namespace: arvandocs
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
    - host: example.com
      http:
        paths:
          - backend:
              service:
                name: nginx
                port:
                  number: 80
            path: /
            pathType: Prefix

This YAML file is structured into different sections:

• apiVersion: Specifies the API version of the Ingress.

• kind: Ingress: Indicates the type of Kubernetes resource, which is Ingress in this case.

• metadata: Contains details such as the name, project, and annotations.

• spec: Defines the status of the Ingress, including routing rules.

• rules: Specifies HTTP traffic routing rules. Each rule contains a host and a set of HTTP paths.

  • host: Indicates the domain to which traffic is sent.

  • http: Defines HTTP routing rules.

    • paths: Specifies paths for each node.

      • path: Specifies the URL path to which traffic should be sent.
      • pathType: Specifies the path matching method.
        • backend: Specifies the service and port to which traffic should be sent.

Ingresses can be more complex and include additional settings based on your requirements. One common feature is Multi-Tenancy, where you can share an Ingress among multiple applications using Wildcards in routing rules (e.g., *.example.com).

For example:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: wildcard-ingress
  namespace: default
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$1
spec:
  rules:
  - host: "*.example.com"
    http:
      paths:
      - path: /service1(/|$)(.*)
        pathType: ImplementationSpecific
        backend:
          service:
            name: service1
            port:
              number: 80
      - path: /service2(/|$)(.*)
        pathType: ImplementationSpecific
        backend:
          service:
            name: service2
            port:
              number: 80

In this example, the Ingress is configured to match any subdomain of example.com. Additionally, based on different paths, requests are sent to different services:

• Requests to http://<any-subdomain>.example.com/service1 are sent to the service1 application.
• Requests to http://<any-subdomain>.example.com/service2 are sent to the service2 application.

Please note:

• The use of Wildcard (*) in host and its execution method depends on the Ingress Controller. In this example, it is assumed that NGINX is used, which supports these settings.
• The pathType: ImplementationSpecific section allows path interpretation based on Regular Expression or other rules.
• nginx.ingress.kubernetes.io/rewrite-target in the annotations is used to change the path sent to the application. In this example, anything after /service1/ or /service2/ is sent as part of the request to the application.