All Products
Search

This Product

    Enterprise Distributed Application Service:Use the EDAS console to manage Kubernetes clusters

    Document Center

    Enterprise Distributed Application Service:Use the EDAS console to manage Kubernetes clusters

    Last Updated:Jan 03, 2024

    Enterprise Distributed Application Service (EDAS) integrates Container Service for Kubernetes (ACK) so that you can use Kubernetes to manage containerized applications on Alibaba Cloud. You can create Kubernetes clusters in the ACK console. For hybrid cloud clusters such as Kubernetes clusters deployed on third-party clouds or self-managed Kubernetes clusters deployed in data centers, you can register the clusters in the ACK console. Then, you can import the clusters to EDAS to deploy applications to them. EDAS provides high-availability management of containerized applications and improves O&M efficiency so that you can focus on developing and managing containerized applications.

    Features of Kubernetes clusters in EDAS

    EDAS allows you to import the ACK dedicated clusters, ACK managed clusters, and ACK Serverless (ASK) clusters that you create in the ACK console. For more information about the comparison among the three types of clusters, see What is ACK?

    ACK dedicated clusters and ACK managed clusters that are imported to EDAS correspond to ACK clusters in EDAS. ACK Serverless clusters that are imported to EDAS correspond to ACK Serverless clusters in EDAS.

    Before you import hybrid cloud clusters such as Kubernetes clusters deployed on third-party clouds or self-managed Kubernetes clusters deployed in data centers to EDAS, you must register the clusters in the ACK console. Hybrid cloud clusters that are imported to EDAS correspond to ACK clusters in EDAS.

    For more information about how to register a hybrid cloud cluster in the ACK console, see Create a cluster registration proxy and register a Kubernetes cluster that is deployed in a data center.

    Kubernetes clusters that are managed in EDAS have the following advantages over self-managed Kubernetes clusters:

    • On top of cloud-native Kubernetes, EDAS provides the application hosting capability to implement open source microservice governance and lightweight O&M of Kubernetes applications from the application perspective.

      • From the application-centric perspective, EDAS manages Kubernetes-native workloads such as deployments and pods, and provides high-availability deployment of instances across zones.

      • EDAS provides phased release and canary release based on the traffic ratio and request parameters. EDAS monitors the entire change process and therefore makes your change records traceable.

      • EDAS integrates with mainstream DevOps systems to help enterprises implement continuous integration (CI) and continuous delivery (CD). This way, EDAS helps enterprises reduce costs and improve efficiency.

    • On top of open source microservice systems, you can migrate the microservice-oriented applications that you build based on the Spring Cloud and Dubbo frameworks commercially available in the past five years to EDAS without the need to modify code. EDAS supports the following microservice governance capabilities for all the application frameworks:

      • Graceful shutdown and stress testing during application release

      • Service authentication, throttling and degradation, and outlier ejection during the application runtime

      • Service query and testing in application O&M

    • Alibaba Cloud packages its idea of supporting observability, canary release, and rollback for application production security into services, and therefore allows you to immediately implement production security.

      • Observability: End-to-end monitoring in multiple dimensions is implemented based on application overview, release change records, and automatic generation of release reports.

      • Canary release: Canary release is supported for applications based on the traffic ratio or request content policy configuration.

      • Rollback: One-click rollback is supported during the release process, and applications that are running can be rolled back to an earlier version.

    Workflow for Kubernetes clusters

    To deploy an application in an ACK cluster, you must create or register an ACK cluster in the Container Service for Kubernetes (ACK) console and import the cluster to the EDAS console. Then, you must use a deployment package or an image in the imported Container Service for Kubernetes (ACK) cluster to deploy the application.

    Procedure of deploying an application in an ACK cluster

    Note

    In EDAS, the procedure of managing ACK clusters is similar to that of managing hybrid cloud clusters. In this topic, an ACK cluster is used to describe the procedure.

    Prerequisites

    • EDAS is activated for your Alibaba Cloud account. For more information, see Activate EDAS.

    • ACK is activated and role authorization is complete for your Alibaba Cloud account. For more information, see ACK default roles.

    • Required permissions including the logon permissions are granted by your Alibaba Cloud account to a RAM user that is used to manage Kubernetes clusters.

    Create a Kubernetes cluster in the Container Service for Kubernetes (ACK) console

    Import a Kubernetes cluster to the EDAS console

    By default, the ack-ahas-sentinel-pilot, ack-arms-pilot, and ack-arms-prometheus components are installed when you import an ACK cluster to EDAS in the EDAS console. The ack-ahas-sentinel-pilot component is an application protection component for throttling and degradation. The ack-arms-pilot component is an Application Real-Time Monitoring Service (ARMS) component. The ack-arms-prometheus component is a Prometheus monitoring component.

    Important

    We recommend that you get familiar with the operation limits imposed by EDAS before you import a Kubernetes cluster. For more information, see Constraints on importing a Kubernetes cluster.

    1. Log on to the EDAS console.

    2. In the left-side navigation pane, choose Resource Management > Container Service Kubernetes Clusters.

    3. In the top navigation bar, select the region of the microservice namespace that you want to manage. From the Microservice Namespace drop-down list, select the microservice namespace to which you want to import an ACK cluster. Then, click Synchronize Container Service Kubernetes Cluster.

    4. Find the ACK cluster that you want to import and click Import in the Actions column.

    5. In the Import Kubernetes Cluster dialog box, select a microservice namespace from the Microservice Namespaces drop-down list, turn on Service Mesh as needed, and then click Import.

      Note

      • If you have not created a microservice namespace, the default microservice namespace is selected.

      • If you need to deploy a multi-language application, turn on Service Mesh.

      • After you turn on Service Mesh, two internal-facing Server Load Balancer (SLB) instances with the slb.s1.small specification are created by default for management. The ports of the two SLB instances, port 6443 and port 15011, are exposed. For more information, see the "Context" section of the Create an ASM instance topic.

        You are charged for the two SLB instances that are automatically created. For more information about billing, see Pay-as-you-go.

      If the value of the Cluster Status parameter is Running and the value of the Import Status parameter is Imported. for the ACK cluster, the ACK cluster is imported to EDAS.

    Cancel the import and clean up a Kubernetes cluster in the EDAS console

    1. Log on to the EDAS console.

    2. In the left-side navigation pane, choose Resource Management > Container Service Kubernetes Clusters or Resource Management > Serverless Kubernetes Clusters.

    3. In the top navigation bar, select the region in which the cluster resides. From the Microservice Namespace drop-down list, select the microservice namespace in which the cluster resides. In the Actions column of the cluster, click Cancel Import. In the Note message, click OK.

      • If the value of the Cluster Status parameter is Running, you can import the cluster to EDAS again to create applications.

      • If the value of the Cluster Status parameter is Deleted, you can click Clear in the Actions column to remove the cluster from the cluster list in EDAS.

        Note

        For more information about operations and FAQ about cluster deletion, see Delete a cluster.

    View a Kubernetes cluster in the EDAS console

    1. Log on to the EDAS console.

    2. In the left-side navigation pane, choose Resource Management > Container Service Kubernetes Clusters or Resource Management > Serverless Kubernetes Clusters.

    3. Click the ID of the cluster that you want to view. The Cluster Details page appears.

      On the Cluster Details page, you can view the cluster details, Elastic Compute Service (ECS) instances, deployments, and applications.

      • Cluster Information: This section displays basic information about the cluster, including Cluster ID, csClusterId, Cluster Name, Microservice Namespace, Cluster Type, VPC ID, Network Type, Cluster Status, and Description.

        • In the Cluster Information section, click View Details in the upper-right corner to view the details of the cluster.

        • In the Cluster Information section, click Edit in the upper-right corner to modify the cluster description.

      • ECS Instance: This section displays the ECS instances in the cluster and the overview of ECS instances.

      • Deployments: This section displays the self-managed deployments on third-party platforms that you convert to and manage in EDAS.

      • Applications: This section displays the applications in the cluster. You can view the application name, JDK version, application runtime environment, total number of instances, number of running instances, and owner. You can click the name of an application to go to the application details page.

    Constraints on importing a Kubernetes cluster

    • Constraints on configuring the security group of the Kubernetes cluster:

      • You must ensure that all the nodes in the Kubernetes cluster are in or can connect to the security group of the cluster. For more information, see Why do containers fail to communicate with each other?.

      • You must not delete the default rules that are set by ACK for the security group.

    • Constraints on configuring nodes in the Kubernetes cluster:

      • To ensure that the management component of EDAS properly runs in the cluster, you must reserve sufficient CPUs, memory, and pods that can be allocated.

      • You must not delete the KubernetesWorkerRole-* RAM role that ACK configures for a node.

    • Constraints on configuring an SLB instance for API Server of the Kubernetes cluster:

      • You must not block access requests from the 100.104.0.0/16 internal addresses.

      • You must not delete the built-in tags added to the SLB instance by ACK.

      • You must not reuse port 6443 on the SLB instance.

    • Constraints on managing Helm charts in the Kubernetes cluster:

      • You must not delete the ahas-sentinel-pilot, arms-eventer, arms-pilot, or arms-prom component installed by EDAS and all resources installed by these Helm charts.

      • You must not install open source oam-runtime, kubevela, keda, or flagger.

      • You must not delete or modify Kubernetes resources within the edas-oam-system namespace.

    • Constraint on managing ClusterRole:

      You must not use the ACK console, kubectl, or third-party tools to delete or modify edas-default-cluster-role.

    • Constraint on managing ClusterRoleBinding:

      You must not use the ACK console, kubectl, or third-party tools to delete or modify edas-default-cluster-role-binding, edas-oam-cluster-role-binding, or keda-hpa-controller-external-metrics.

    • Constraints on managing custom resource definitions (CRDs) and custom resources (CRs):

      • You must not directly manage the following CRDs or CRs:

        • alertproviders.flagger.app

        • applicationconfigurations.core.oam.dev

        • applications.oam-domain.alibabacloud.com

        • applicationscopes.core.oam.dev

        • autoscalings.edas.aliyun.oam.com

        • basecomponents.oam-domain.alibabacloud.com

        • canaries.flagger.app

        • componentschematics.core.oam.dev

        • crdreleases.clm.cloudnativeapp.io

        • dynamiclabels.extension.oam.dev

        • imagebuilders.edas.aliyun.oam.com

        • logcollectors.edas.aliyun.oam.com

        • meshtraits.edas.aliyun.oam.com

        • metrictemplates.flagger.app

        • mseruletraits.edas.aliyun.oam.com

        • packageversions.oam-domain.alibabacloud.com

        • rollouts.edas.aliyun.oam.com

        • scaledobjects.keda.k8s.io

        • scalingrules.oam-domain.alibabacloud.com

        • serviceregistrytraits.edas.aliyun.oam.com

        • servicetraits.edas.aliyun.oam.com

        • sources.clm.cloudnativeapp.io

        • traits.core.oam.dev

        • triggerauthentications.keda.k8s.io

        • workloadtypes.core.oam.dev

      • You must not modify the aliyunlogconfigs.log.alibabacloud.com resources created by EDAS. The resources have the edas-domain: edas-admin tag.

    References