All Products
Search
Document Center

:Getting started

Last Updated:Sep 26, 2024

This topic describes how to quickly deploy an application in Alibaba Centralized Mesh Gateway (ACMG) mode.

Prerequisites

The sample code is deployed. For more information, see Preparations.

Important

When you perform the operations mentioned in this topic, you may need to switch between Kubernetes contexts repeatedly to perform operations on the clusters on the data plane and control plane. To avoid misoperations, make sure that the current context is correct each time you switch between contexts. You can use kubectx to simplify context switching. For more information, see kubectx. You can also enable the feature of using the Kubernetes API of clusters on the data plane to access Istio resources and then use the Kubernetes API of clusters on the data plane to directly perform operations on the clusters on the control plane.

Enable or disable the ACMG mode by namespace

  1. Use kubectl to connect to the ASM instance based on the information in the kubeconfig file and enable the ACMG mode.

    kubectl label namespace default istio.io/dataplane-mode=acmg
  2. Disable the ACMG mode.

    kubectl label namespace default istio.io/dataplane-mode-

Step 1: Enable an authorization policy

After you add an application to the ACMG mode, you can use Layer 4 and Layer 7 authorization policies to control access to the application. For example, you can control access to the application based on the identities of client workloads.

Layer 4 authorization policies

  1. Create a productpage-viewer.yaml file that contains the following content.

    kind: AuthorizationPolicy
    metadata:
     name: productpage-viewer
     namespace: default
    spec:
      targetRef:
        kind: Service
        group: ""
        name: productpage
      action: ALLOW
      rules:
      - from:
        - source:
            principals:
            - cluster.local/ns/default/sa/sleep
  2. Use kubectl to connect to the ASM instance based on the information in the kubeconfig file. Then, run the following command to deploy the authorization policy to explicitly allow the service account of the sleep application to call the productpage service:

    kubectl apply -f productpage-viewer.yaml
  3. Verify whether the authorization policy takes effect.

    1. Run the following command:

      kubectl exec deploy/sleep -- curl -s "http://productpage:9080/productpage" | grep -o "<title>.*</title>"

      Expected output:

      <title>Simple Bookstore App</title>
    2. Run the following command:

      kubectl exec deploy/notsleep -- curl -s http://productpage:9080/ | grep -o "<title>.*</title>"

      Expected output:

      RBAC: access denied

      The preceding results indicate that the authorization policy takes effect.

Layer 7 authorization policies

  1. Use the following content to create a productpage-viewer.yaml file that allows the service account of the sleep application to access the productpage service by using the GET method, but does not allow other operations to be performed.

    apiVersion: security.istio.io/v1beta1
    kind: AuthorizationPolicy
    metadata:
     name: productpage-viewer
     namespace: default
    spec:
      targetRef:
        kind: Service
        group: ""
        name: productpage
      action: ALLOW
      rules:
      - from:
        - source:
            principals:
            - cluster.local/ns/default/sa/sleep
        to:
        - operation:
            methods: ["GET"]
  2. Use kubectl to connect to the ASM instance based on the information in the kubeconfig file. Then, run the following command to deploy the authorization policy:

    kubectl apply -f productpage-viewer.yaml
  3. Verify whether the authorization policy takes effect.

    1. Run the following command to use the GET request from the sleep application pod to access the productpage service:

      kubectl exec deploy/sleep -- curl -s "http://productpage:9080/productpage" | grep -o "<title>.*</title>"

      Expected output:

      <title>Simple Bookstore App</title>
    2. Run the following command to use the DELETE request from the sleep application pod to access the productpage service:

      kubectl exec deploy/sleep -- curl -s "http://productpage:9080/productpage" -X DELETE

      Expected output:

      RBAC: access denied
    3. Run the following command to use the GET request from the notsleep application pod to access the productpage service:

      kubectl exec deploy/notsleep -- curl -s "http://productpage:9080/productpage"

      Expected output:

      RBAC: access denied

      The preceding results show that the GET request from the sleep application can access the productpage service, and the GET request from the notsleep application and the DELETE request from the sleep application fail to access the productpage service. This indicates that the authorization policy takes effect.

Step 2: Define a Layer 7 routing rule

Use a virtual service and a destination rule

  1. Use the following content to create a review-all-v1.yaml file:

    apiVersion: networking.istio.io/v1alpha3
    kind: DestinationRule
    metadata:
      name: reviews
    spec:
      host: reviews
      trafficPolicy:
        loadBalancer:
          simple: RANDOM
      subsets:
      - name: v1
        labels:
          version: v1
      - name: v2
        labels:
          version: v2
      - name: v3
        labels:
          version: v3
    ---
    apiVersion: networking.istio.io/v1alpha3
    kind: VirtualService
    metadata:
      name: reviews
    spec:
      hosts:
      - reviews
      http:
      - route:
        - destination:
            host: reviews
            subset: v1
  2. Run the following command to deploy the virtual service and destination rule to send 100% of requests to review-v1:

    kubectl apply -f reviews-all-v1.yaml
  3. Run the following command to check whether 100% of requests are sent to reviews-v1:

    kubectl exec deploy/sleep -- sh -c "for i in \$(seq 1 100); do curl -s http://productpage:9080/productpage | grep reviews-v.-; done"

    Expected output:

            <u>reviews-v1-ff5787f99-t64h2</u>
            <u>reviews-v1-ff5787f99-t64h2</u>
            <u>reviews-v1-ff5787f99-t64h2</u>
            <u>reviews-v1-ff5787f99-t64h2</u>
            <u>reviews-v1-ff5787f99-t64h2</u>
            <u>reviews-v1-ff5787f99-t64h2</u>
            <u>reviews-v1-ff5787f99-t64h2</u>
            <u>reviews-v1-ff5787f99-t64h2</u>
            <u>reviews-v1-ff5787f99-t64h2</u>
            <u>reviews-v1-ff5787f99-t64h2</u>

    The output indicates that all requests are sent to review-v1, and the virtual service and destination rule take effect.

Use the Gateway API

Note

Make sure that the CustomResourceDefinitions (CRDs) of the Gateway API are created in the ACK cluster and the Gateway API is enabled for the ASM instance. For more information, see Confirm that CRDs of the Gateway API component are created in the ACK cluster and Enable Gateway API for the ASM instance.

  1. Use the following content to create a reviews-route-all-v1.yaml file:

    apiVersion: v1
    kind: Service
    metadata:
      name: reviews-v1
    spec:
      ports:
      - port: 9080
        name: http
      selector:
        app: reviews
        version: v1
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: reviews-v2
    spec:
      ports:
      - port: 9080
        name: http
      selector:
        app: reviews
        version: v2
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: reviews-v3
    spec:
      ports:
      - port: 9080
        name: http
      selector:
        app: reviews
        version: v3
    ---
    apiVersion: gateway.networking.k8s.io/v1beta1
    kind: HTTPRoute
    metadata:
      name: reviews
    spec:
      parentRefs:
      - group: ""
        kind: Service
        name: reviews
        port: 9080
      rules:
      - backendRefs:
        - name: reviews-v1
          port: 9080
  2. Run the following command to deploy the routing rule defined by using HTTPRoute to route all traffic that accesses reviews to reviews-v1:

    kubectl apply -f reviews-route-all-v1.yaml
  3. Run the following command to check whether the routing rule takes effect:

    kubectl exec deploy/sleep -- sh -c "for i in \$(seq 1 100); do curl -s http://productpage:9080/productpage | grep reviews-v.-; done"

    Expected output:

            <u>reviews-v1-ff5787f99-t64h2</u>
            <u>reviews-v1-ff5787f99-t64h2</u>
            <u>reviews-v1-ff5787f99-t64h2</u>
            <u>reviews-v1-ff5787f99-t64h2</u>
            <u>reviews-v1-ff5787f99-t64h2</u>
            <u>reviews-v1-ff5787f99-t64h2</u>
            <u>reviews-v1-ff5787f99-t64h2</u>
            <u>reviews-v1-ff5787f99-t64h2</u>
            <u>reviews-v1-ff5787f99-t64h2</u>
            <u>reviews-v1-ff5787f99-t64h2</u>

    The output indicates that all traffic that accesses reviews is routed to reviews-v1, and the routing rule defined by using HTTPRoute takes effect.