Skip to content

Files

Latest commit

74c2399 · May 14, 2025

History

History
84 lines (56 loc) · 2.96 KB
·

using-a-short-host-name-dec7a0b.md

File metadata and controls

84 lines (56 loc) · 2.96 KB
·

Using a Short Host Name

Learn how to expose a Service instance using a short host name instead of the full domain name.

  • You have the Istio and API Gateway modules added. See Adding and Deleting a Kyma Module.

  • You have installed curl and kubectl. You have configured kubectl to communicate with your Kyma runtime instance. See Access a Kyma Instance Using kubectl.

  • You have a deployed workload.

  • You have set up your custom domain. Alternatively, you can use the default domain of your Kyma cluster and the default Gateway kyma-system/kyma-gateway.

    Note:

    Because the default Kyma domain is a wildcard domain, which uses a simple TLS Gateway, it is recommended that you set up your custom domain for use in a production environment.

    Tip:

    To learn what the default domain of your Kyma cluster is, run the following command:

    kubectl get gateway -n kyma-system kyma-gateway -o jsonpath='{.spec.servers[0].hosts}
    

Using a short host makes it simpler to apply an APIRule custom resource (CR) because the domain name is automatically retrieved from the referenced Gateway, and you don’t have to manually set it in each APIRule. This might be particularly useful when reconfiguring resources in a new cluster, as it reduces the risk of errors and streamlines the process.

Procedure

  1. To expose your workload using a short host, create an APIRule CR and define only a subdomain in the hosts field. See the following example:

    cat <<EOF | kubectl apply -f -
    apiVersion: gateway.kyma-project.io/v2alpha1
    kind: APIRule
    metadata:
      name: {APIRULE_NAME}
      namespace: {APIRULE_NAMESPACE}
    spec:
      hosts:
        - {SUBDOMAIN}
      service:
        name: {SERVICE_NAME}
        namespace: {SERVICE_NAMESPACE}
        port: {SERVICE_PORT}
      gateway: {NAMESPACE/GATEWAY}
      rules:
        - path: /*
          methods: ["GET"]
          noAuth: true
        - path: /post
          methods: ["POST"]
          noAuth: true
    EOF
    
  2. Send a GET request to the exposed workload:

    curl -ik -X GET https://{SUBDOMAIN}.{DOMAIN_NAME}/ip
    

    If successful, the call returns the 200 OK response code.

  3. Send a POST request to the exposed workload:

    curl -ik -X POST https://{SUBDOMAIN}.{DOMAIN_NAME}/post -d "test data"
    

    If successful, the call returns the 200 OK response code.