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.
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
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=acmgDisable 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
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/sleepUse 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.yamlVerify whether the authorization policy takes effect.
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>Run the following command:
kubectl exec deploy/notsleep -- curl -s http://productpage:9080/ | grep -o "<title>.*</title>"Expected output:
RBAC: access deniedThe preceding results indicate that the authorization policy takes effect.
Layer 7 authorization policies
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"]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.yamlVerify whether the authorization policy takes effect.
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>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 DELETEExpected output:
RBAC: access deniedRun 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 deniedThe 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
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: v1Run 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.yamlRun 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
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.
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: 9080Run 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.yamlRun 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.