## 4.3.1.2.2 Exposing Multiple Workloads
Learn how to expose multiple workloads with one APIRule definition.
## Prerequisites
- You have the Istio and API Gateway modules added. See Adding and Deleting a Kyma Module [page 3157].
- You have access to Kyma dashboard. Alternatively, to use CLI instructions, you must install kubectl and configure it to communicate with your Kyma runtime instance. See Access a Kyma Instance Using kubectl [page 2018].
- You have installed curl .
- You have deployed two workloads in one namespace.
##  Note
To expose a workload using APIRule in version v2 , the workload must be a part of the Istio service mesh. See Enabling Istio Sidecar Proxy Injection [page 1783].
- 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}'
## Defining Multiple Services on Different Paths
## Context
Learn how to expose two Services on different paths at the spec.rules level without a root Service defined.
##  Caution
Exposing a workload to the outside world is a potential security vulnerability, so be careful. In a production environment, always secure the workload you expose.
## Procedure
- You can use either Kyma dashboard or kubectl.
- Use Kyma dashboard.
- a. Go to the namespace in which you want to create an APIRule CR.
- b. Go to Discovery and Network &gt; API Rules and select Create .
- c. Provide the name of the APIRule CR.
- d. Add a Gateway.
- e. Add a rule with the configuration details of one Service.
- f. Add another rule with the configuration details of the other Service.
- g. Choose Create .
- h. To call the endpoints, send requests to the exposed Services, for example:
```
curl -ik -X GET https://{SUBDOMAIN}.{DOMAIN_NAME}/headers curl -ik -X GET https://{SUBDOMAIN}.{DOMAIN_NAME}/get
```
If successful, the calls return the 200 OK response code.
- Use kubectl.
- a. Add two rules with configuration details of your Services. See an example:
- b. To call the endpoints, send requests to the exposed Services, for example:
```
cat <<EOF | kubectl apply -f apiVersion: gateway.kyma-project.io/v2 kind: APIRule metadata: name: {APIRULE_NAME} namespace: {APIRULE_NAMESPACE} spec: hosts: - {SUBDOMAIN}.{DOMAIN_NAME} rules: - path: /headers methods: ["GET"] noAuth: true service: name: {FIRST_SERVICE_NAME} port: {FIRST_SERVICE_PORT} - path: /get methods: ["GET"] noAuth: true service: name: {SECOND_SERVICE_NAME} port: {SECOND_SERVICE_PORT}
```
```
gateway: {GATEWAY_NAMESPACE}/{GATEWAY_NAME} EOF
```
```
curl -ik -X GET https://{SUBDOMAIN}.{DOMAIN_NAME}/headers curl -ik -X GET https://{SUBDOMAIN}.{DOMAIN_NAME}/get
```
If successful, the calls return the 200 OK response code.
## Defining a Service at the Root Level
## Context
You can also define a Service at the root level. Such a definition is applied to all the paths specified at spec.rules that do not have their own Services defined. Services defined at the spec.rules level have precedence over Service definition at the spec.service level.
##  Caution
Exposing a workload to the outside world is a potential security vulnerability, so be careful. In a production environment, always secure the workload you expose.
## Procedure
- You can use either Kyma dashboard or kubectl.
- Use Kyma dashboard.
- a. Go to the namespace in which you want to create an APIRule CR.
- b. Go to Discovery and Network &gt; API Rules and select Create .
- c. Provide the name of the APIRule CR.
- d. Add a Gateway.
- e. Define one Service in the Service section.
- f. Add one rule without a Service definition.
- g. Add another rule with the Service definition.
- h. Choose Create .
- i. To call the endpoints, send requests to the exposed Services, for example:
```
curl -ik -X GET https://{SUBDOMAIN}.{DOMAIN_NAME}/headers curl -ik -X GET https://{SUBDOMAIN}.{DOMAIN_NAME}/get
```
If successful, the calls return the 200 OK response code.
- Use kubectl.
- a. Replace the placeholders and run the following command:
```
cat <<EOF | kubectl apply -f apiVersion: gateway.kyma-project.io/v2
```
```
kind: APIRule metadata: name: {APIRULE_NAME} namespace: {APIRULE_NAMESPACE} spec: hosts: - {SUBDOMAIN}.{DOMAIN_NAME}
```
```
gateway: {GATEWAY_NAMESPACE}/{GATEWAY_NAME} service: name: {FIRST_SERVICE_NAME} port: {FIRST_SERVICE_PORT} rules: - path: /headers methods: ["GET"] noAuth: true - path: /get methods: ["GET"] noAuth: true service: name: {SECOND_SERVICE_NAME} port: {SECOND_SERVICE_PORT} EOF
```
- b. To call the endpoints, send GET requests to the exposed Services:
```
curl -ik -X GET https://{SUBDOMAIN}.{DOMAIN_NAME}/headers curl -ik -X GET https://{SUBDOMAIN}.{DOMAIN_NAME}/get
```
If successful, the calls return the 200 OK response code.
## Exposing Services in Different Namespaces
## Context
Expose two workloads deployed in different namespaces with one APIRule definition.
## Procedure
- You can use either Kyma dashboard or kubectl.
- Use Kyma dashboard.
- a. Create a namespace with the Istio sidecar proxy injection enabled. For more information, see Enabling Istio Sidecar Proxy Injection [page 1783].
- b. Go to Discovery and Network &gt; API Rules and select Create .
- c. Switch to the YAML section.
- d. Paste the APIRule custom resource (CR) configuration into the editor. You must specify a Service's namespace in each Service definition. See an example:
```
apiVersion: gateway.kyma-project.io/v2 kind: APIRule metadata: name: {APIRULE_NAME} namespace: {APIRULE_NAMESPACE} spec: hosts: - {SUBDOMAIN}.{DOMAIN_NAME} gateway: {GATEWAY_NAMESPACE}/{GATEWAY_NAME} rules: - path: /headers methods: ["GET"]
```
```
service: name: {FIRST_SERVICE_NAME} namespace: {FIRST_SERVICE_NAMESPACE} port: {FIRST_SERVICE_PORT} noAuth: true - path: /get methods: ["GET"] service: name: {SECOND_SERVICE_NAME} namespace: {SECOND_SERVICE_NAMESPACE} port: {SECOND_SERVICE_PORT} noAuth: true
```
- e. Select Create .
- f. To call the endpoints, send GET requests to the exposed Services:
```
curl -ik -X GET https://{SUBDOMAIN}.{DOMAIN_NAME}/headers curl -ik -X GET https://{SUBDOMAIN}.{DOMAIN_NAME}/get
```
If successful, the calls return the 200 OK response code.
- Use kubectl.
- a. Create a separate namespace for the APIRule CR with enabled Istio sidecar proxy injection.
- b. Expose the Services in their respective namespaces by creating an APIRule custom resource (CR) in its own namespace. You must specify a Service's namespace in each Service definition. See an example:
- c. To call the endpoints, send requests to the exposed Services, for example:
```
export NAMESPACE={NAMESPACE_NAME} kubectl create ns $NAMESPACE
```
```
kubectl label namespace $NAMESPACE istio-injection=enabled --overwrite
```
```
cat <<EOF | kubectl apply -f apiVersion: gateway.kyma-project.io/v2 kind: APIRule metadata: name: {APIRULE_NAME} namespace: $NAMESPACE spec: hosts: - {SUBDOMAIN}.{DOMAIN_NAME} gateway: {GATEWAY_NAMESPACE}/{GATEWAY_NAME} rules: - path: /headers methods: ["GET"] service: name: {FIRST_SERVICE_NAME} namespace: {FIRST_SERVICE_NAMESPACE} port: {FIRST_SERVICE_PORT} noAuth: true - path: /get methods: ["GET"] service: name: {SECOND_SERVICE_NAME} namespace: {SECOND_SERVICE_NAMESPACE} port: {SECOND_SERVICE_PORT} noAuth: true EOF
```
```
curl -ik -X GET https://{SUBDOMAIN}.{DOMAIN_NAME}/headers curl -ik -X GET https://{SUBDOMAIN}.{DOMAIN_NAME}/get
```
If successful, the calls return the 200 OK response code.