Cocktail Cloud is an all-in-one container management platform. With the widespread adoption of cloud technology, there's a growing demand not just for infrastructure management but also for application and service management. Traditional development and operation methods are limited in fully leveraging the advantages of the cloud. Particularly in the realm of applications, there's an increasing demand for automation, efficiency, and integrated management, including continuous integration/deployment (CI/CD), migration, and the establishment of multi/hybrid cloud infrastructures.

The proliferation of container technology is natural in this context. Many companies have already adopted container technology, and this trend continues to grow. Containers package applications or services into independent and executable units, providing the same development and operation experience regardless of the infrastructure environment. Therefore, standardizing cloud management from infrastructure to services can reduce development and operation efforts. Containers offer the advantage of managing multi/hybrid clouds under a consistent environment.

Cocktail Cloud applies the benefits of containers to cloud management, streamlining development and operation tasks and providing a platform for implementing single or multi/hybrid cloud strategies.

Key features of Cocktail Cloud include:

1. Automation of pipelines from code to build, deployment, and updates.

2. Workload (service)-centric container management: packaging, lifecycle, resources, etc.

3. Full-stack monitoring: monitoring the status and resources from infrastructure to containers. Alert management.

4. Multi/hybrid cluster provisioning and management: Baremetal, private/public clouds.

Cocktail Cloud is a platform built on Kubernetes, offering the functionalities and APIs necessary for building, deploying, monitoring, and operating cloud-native applications from their build phase. The reason why many companies consider adopting Kubernetes is due to the increasing importance of cloud-native applications such as containers, microservices, and serverless architectures.

Cloud-native applications enhance continuity and efficiency in development/operation, ensuring high availability through automation for fault response, load-based scaling, and more. However, the adoption and operation of Kubernetes pose challenges due to the difficulty of adapting to new technologies and the complexity of management, becoming another major challenge for enterprises.

Cocktail Cloud provides an integrated platform with all the functionalities and components required for building and operating Kubernetes and cloud-native applications. Enterprises can save time and effort during initial adoption and seamlessly manage and scale thereafter.

Reducing Efforts in Kubernetes Adoption and Operation

While the number of companies adopting Kubernetes is increasing, there's a significant burden on operating and managing open-source installations, updates, and adapting organizations to new technologies. Additionally, setting up components like monitoring, networking, and security that Kubernetes doesn't inherently provide requires additional effort. Cocktail Cloud offers automated tools for configuring and scaling Kubernetes clusters, simplifying cluster management, including upgrades and node expansion. This leads to reduced efforts in initial setup and ongoing management. Cocktail Cloud extends Kubernetes configurations through addons, providing components like monitoring, networking, GPU support, and security. These addons also come with automated installation/update functionalities.

Multi-Cluster Deployment

Enterprises have various reasons for using multi-cluster setups, such as network isolation for security, separate operations for production and development systems, and leveraging public clouds. There's also a growing trend of using multiple clusters and different Kubernetes distributions simultaneously. Cocktail Cloud provides an environment for operating and managing multiple clusters from a single control plane. It supports the construction and management of multi-clusters across diverse infrastructure bases, including private and public clouds, as well as data centers.

• Physical Equipment (Baremetal) Based Clusters

• Virtualization-Based Private Clouds: OpenStack, VMWare, CTRIX Hypervisor, etc.

• Public Clouds: GKE (GCP), EKS (AWS), AKS (Azure), etc.

Multi-Tenancy

Enterprises require work environments where clusters and necessary resources are allocated or shared based on the roles of organizations or teams. Particularly in application service development and operation, it's common for dedicated teams to be responsible, and unique computing resources may be required based on the characteristics of applications. Cocktail Cloud provides independent workspaces for organizations or teams, allowing allocation and management of necessary computing resources (clusters). Beyond basic computing resources like CPU, GPU, Memory, Volume, cloud-native applications also require resources for development/operation such as container image registries and automation pipelines. Resource allocation and management, as well as permission management for workspace members, in a multi-tenancy environment can be easily configured and managed within independent workspaces.

Unified Management/Monitoring

Managing multiple clusters and a multi-tenancy environment can be complex and challenging. Cocktail Cloud addresses these issues through various integrated management features. It allows monitoring and managing the status of enterprise-wide applications and infrastructure resources (clusters, repositories). Teams or organizations can track the development/operation status of applications and services and handle resource requests and issues accordingly. Cocktail Cloud centrally monitors multi-cluster infrastructure resources, application statuses, networks, etc., providing real-time alerts/events and logs to effectively respond to faults or issues. Additionally, it offers a customizable integrated monitoring environment tailored to the needs of the enterprise through metric and rule extensions.

Automation, DevOps

Ensuring continuity from application building to deployment and updates has become increasingly crucial. Swiftly responding to customer demands collected through various channels is a key factor in achieving business success. To address this, enterprises establish automated Continuous Integration/Continuous Deployment (CI/CD) pipelines. Cloud-native applications offer advanced technologies for building automated pipelines compared to before. Leveraging these advancements, Cocktail Cloud provides various functionalities for establishing and managing automated CI/CD pipelines. Enterprises can tailor pipelines according to the characteristics of their applications and development/operation environments. Additionally, they can provide DevOps platforms for teams or organizations, encompassing operations and monitoring.

Security

Security is a critical management factor for enterprises. Especially, managing authorized user access and permissions to the infrastructure (e.g., clusters in the case of Kubernetes) where applications are deployed and executed is a fundamental approach to address threats from unauthorized users. Cocktail Cloud issues access accounts and permissions to authorized users and manages risks through access periods and revocations. Additionally, it tracks the usage history of access accounts through audit logs, enabling swift responses such as cause analysis and blocking in case of security issues. Furthermore, it provides functionalities such as 'Security Policy Management' for policy formulation and application during container execution, and 'Image Scanning' to inspect vulnerabilities in container images.

"Workspace" is an independent workspace provided for teams or organizations. Teams perform development, operation, and monitoring of one or more designated applications within a workspace. One or more members are registered in the workspace to collaborate.

Resources necessary for deploying and operating applications are allocated to workspaces. Resource allocation is performed by the platform administrator and targets clusters and image registries registered in the platform.

Cluster Resource Allocation

In Cocktail Cloud, there is a method for allocating cluster resources to workspaces called service mapping. The service map in Cocktail Cloud is an administrative unit that extends namespaces, or more precisely, it can be said that namespaces are allocated to workspaces.

Teams can be allocated service maps, or namespaces, which are isolated, independent spaces within a cluster, typically referred to as virtual clusters. Teams allocated with namespaces are responsible only for deploying and operating applications, while the cluster (infrastructure) is managed by a separate team. This method is suitable when teams are focused on application development and operation.

Image Registry Allocation and Sharing

Each workspace is independently allocated a registry for storing and managing application container images. Teams or applications manage their images and configure automated pipelines accordingly.

In some cases, teams or applications may share common images. In such cases, a shared image registry can be allocated to the workspace. In this scenario, one or more workspaces will use the same shared image registry.

Cluster is the infrastructure where containers run. Containers are the deployment units and execution processes of applications. Clusters provide computing resources (CPU, Memory, Storage, Network) necessary for container execution.

A cluster consists of nodes (physical or virtual machines) connected via a network. It is an architecture designed for distributed processing. When containers are deployed to a cluster, they are executed on appropriate nodes. This process, called scheduling, is managed by Kubernetes. Kubernetes is responsible for container scheduling and management within the cluster.

Clusters scale resources by adding nodes. If more resources are needed, nodes are added accordingly, and Kubernetes deploys and manages containers on the expanded nodes.

Container networking and storage for data storage are also components of a cluster.

Kubernetes

Kubernetes is a container orchestration engine that runs containers in clusters and manages their lifecycle. Originally developed by Google, it is now maintained as a CNCF (Cloud Native Computing Foundation) project.

Kubernetes is installed on the cluster and is responsible for managing and providing resources required by containers based on the cluster infrastructure (nodes, network, storage).

Node

A node is one or more compute machines that make up a cluster. They can be physical or virtual machines, each equipped with CPU, Memory, and Disk, connected via a network. Nodes are managed by Kubernetes for scheduling.

Nodes are divided into master nodes and worker nodes. Master nodes host the control plane components of Kubernetes and manage the cluster by communicating with worker nodes.

Worker nodes are where application containers are deployed. The number of worker nodes increases based on the number and capacity of applications. The Kubernetes scheduler on the master node is responsible for deploying containers to worker nodes.

Container Network

Containers running on one or more nodes need to communicate with each other, which is managed by the container network.

Container networking is installed as a Kubernetes component. Kubernetes itself does not provide container networking but offers a standardized interface for external providers to supply plugins, known as the Container Network Interface (CNI). Examples of open-source CNI plugins include Flannel, WeaveNet, Calico.

Cocktail Cloud offers options to configure the cluster's CNI plugin.

Ingress Controller

External access to containers is handled by the ingress controller. It routes external traffic to containers based on hostnames and paths. Routing rules are configured for each application and applied to the ingress controller.

The ingress controller is a Kubernetes component. NGINX controller is commonly used and provided as a default in Kubernetes. Other third-party ingress controllers are also available.

Cocktail Cloud offers options to configure the ingress controller.

Storage

Cluster storage provides persistent volumes for container data storage.

Since containers can be rescheduled to different nodes in case of node failure or resource shortage, storing container data on nodes can be problematic. Therefore, a separate volume called a persistent volume is needed to store and manage data safely.

Kubernetes creates and provides persistent volumes through storage classes. When configuring the cluster, an appropriate storage class for storage must be installed.

Cocktail Cloud provides storage classes as addons, allowing users to select and automatically manage suitable storage classes.

Addon

Besides networking and storage, Kubernetes has components to extend its functionality, referred to as addons.

These addons provide additional capabilities to Kubernetes clusters beyond container management. Examples include monitoring and service meshes.

Cocktail Cloud offers various Kubernetes extension components as addons. They are automatically managed from installation to upgrade, and users can choose and use the required addons.

The platform is the fundamental unit for using Cocktail Cloud. All functionalities are accessible through the platform. Users perform application development, operation, and management tasks after logging into the platform, depending on their permissions.

The platform consists of one or more workspaces. Workspaces are independent workspaces provided for teams or organizations. Companies can configure workspaces for teams within the platform and allocate necessary resources to provide application development and operation environments. The platform integrates and manages workspaces, applications, and infrastructure resources.

Integrated Platform Management Features

The platform registers and manages clusters (infrastructure resources) used by applications. It allocates and manages cluster resources on a per-workspace basis, either for the entire cluster or by namespace. Applications managed by teams are serviced through the allocated resources.

The platform comprehensively monitors and manages the overall status of applications developed and operated in all workspaces. It manages applications based on their configuration, status, resource usage, and performs tasks such as resource scaling and fault response as needed.

Clusters operate based on Kubernetes. The platform provides necessary functionalities for cluster operation, such as managing Kubernetes state and versioning.

In addition to resource and status management, the platform also provides integrated management functionalities for user management, security, etc.

Integrated Monitoring

The platform centrally monitors the status and resources of multiple clusters and applications. It collects metric data for each cluster infrastructure and application, providing real-time monitoring and analysis capabilities.

In addition to collecting resource and status data, it also collects events and provides notifications based on predefined rules. It detects anomalies in advance, takes appropriate actions, and performs fault analysis and resolution when issues arise.

The platform provides integrated dashboards with various charts for monitoring and analysis purposes.

Platform Configuration

The platform has a unique identifier (ID). Users log in to the platform using this ID. Additionally, users can set the platform name and logo image to represent a unique identity.

The platform holds Cocktail Cloud product license information. This license, along with purchaser information, is managed within the platform, with a designated platform administrator acting as the representative.

Cloud accounts required for operating clusters in public clouds are also managed as platform information. These accounts are utilized for managing cloud infrastructure and authentication information.

The Service Map is a unit that configures applications and manages various resources. Kubernetes manages applications at the Namespace level. Namespaces are a way of logically dividing clusters to deploy and manage containers, serving as a kind of virtual cluster. The Service Map, provided by Cocktail, is a management space for applications based on namespaces, offering additional management features.

One of the main resources in the Service Map is Workloads, which deploy and manage containers. Other resources include persistent volumes, configuration information, and service exposure.

Pod(Containers)

Pods are resources that deploy and execute containers, composed of one or more containers. They consist of a main container responsible for application logic processing and optional sidecar containers for auxiliary tasks. While most cases require only the main container, additional sidecar containers can be added for functions like log collection, backup, or proxy.

Containers within a pod share the same network (localhost) and volumes, making it easy to scale by adding containers.

Pods can be created independently, but typically, they are managed through workloads responsible for deployment, updates, and lifecycle management.

Workloads

Workloads are Service Map resources responsible for the deployment and lifecycle of pods. They manage the entire lifecycle of pods, including how they are deployed and executed, status monitoring, and restarting in case of issues.

In Cocktail, users interact with workload settings through a web UI console, minimizing errors caused by incorrect configurations.

Even when inputting through the web UI console, users can specify almost all detailed configuration items related to workloads defined in Kubernetes.

Workloads are categorized into several types, each with differences in how pods are deployed, executed, and managed.

Workload Groups

Within a namespace, various types of workloads can be executed, and in some cases, there can be so many workloads that it becomes difficult to understand them all at a glance.

Organizing workloads into workload groups allows for a clear overview of the state of workloads by displaying them according to workload groups.

Deployment Workloads

Deployment workloads replicate the same pod multiple times to provide stable service even if some pods have issues. They are mainly used for stateless application configurations like web servers, where data management is not required. This is because replicated pods have the same container, making them unsuitable for data management.

Deployment workloads also support rolling updates, replacing pods sequentially to perform updates without affecting services.

They also support autoscaling, automatically increasing the number of pod replicas when requested CPU or memory resources are exceeded.

StatefulSet Workloads

StatefulSet workloads deploy pods performing different roles in replication to configure workloads. They are suitable for data storage and management applications such as databases, key-value stores, and big data clusters. Each pod is assigned a unique name, allowing tasks to be processed through pod communication. Each pod uses a unique persistent volume to store/manage data.

DaemonSet Workloads

DaemonSet workloads are Service Map resources that deploy and manage daemon process pods running continuously in the background. Examples of background tasks include log collection and monitoring data collection on each node.

Job Workloads

Job workloads deploy pods to process tasks in a one-time execution. They are mainly used for batch job processing such as data transformation and machine learning.

CronJob Workloads

Similar to job workloads, but they allow for scheduled or periodic execution of jobs. They use configurations similar to Linux's cron tab for scheduling.

Service Exposure

To serve applications externally, pods need to be exposed to external traffic. The Service Map exposes pods to the external traffic through service exposure resources.

Service exposure resources specify pods to expose based on labels. Therefore, even replicated pods with the same label can be specified in one service exposure. In this case, the service exposure performs load balancing to send traffic to one of the specified pods.

Service exposure resources are assigned a fixed IP address, which is a private IP address used within the cluster. This is because pod IP addresses change on restart, which can cause issues if pods are accessed directly. Therefore, the fixed address of the service exposure is used to connect to the specified pods.

Service exposure is categorized based on the exposure method.

Exposing Service with Cluster IP

Exposing services with a cluster IP allows access only within the cluster. It is used for communication between pods via fixed IP addresses within the service map.

Exposing Service with Node Port

Node port exposes services using the node's IP address. External access to pods is possible using the exposed node port (Node IP: Node Port). Node ports are assigned to all nodes in the cluster, allowing access to pods from any node. Typically, all nodes in the cluster are connected to an L4 switch to consolidate access addresses.

Node ports are assigned a range of 30000 to 32767 during cluster installation. Services are exposed automatically or by specifying a port range. This range can be user-configured.

Exposing Service with Load Balancer

When the cluster is configured in a cloud environment, a load balancer can be automatically created to expose services. Pods are exposed via node ports, and the created load balancer connects pod execution nodes with ports. External access is possible using the load balancer's address and port. Load balancer service exposure is only possible on supported cloud platforms like AWS, Azure, and GCP, configured during cluster installation by cloud providers.

Ingress

Apart from service exposure, the Service Map also has Ingress resources for external pod access. Ingress exposes pods to the outside world via hostnames/paths (e.g., abc.com/login, cdf.org/). It functions similarly to an L7 switch.

To use Ingress, an Ingress controller must be installed in the cluster. The Ingress controller receives external traffic and forwards it to pods based on routing information defined in the Ingress (hostname/path -> cluster IP service exposure). Therefore, Ingress exposes the controller to external services, and pods expose services via cluster IP for routing by Ingress rules.

In Kubernetes, the Ingress controller is deployed to pods. Therefore, when installing in the cluster, service exposure should be done via node ports or load balancers.

Note that Ingress routes traffic based on hostnames/paths, so these need to be registered in internal or external DNS servers and accessible by the Ingress controller. Cocktail Cloud provides default configurations for Ingress usage, eliminating the need for additional installation and setup.

In cases of high external traffic to pods, dedicated Ingress nodes are sometimes configured in the cluster. These nodes only have Ingress controllers deployed and are replicated for high availability. They provide scalability by adding Ingress nodes as traffic increases.

Persistence Volumes

When pods need to store and manage data, persistent volumes are necessary. Pods can restart at any time or be reassigned to healthy nodes in case of node failures, making it impossible to use node disk for data storage.

Persistent volumes ensure data integrity even when pods are restarted, reassigned, or deleted because they are managed independently of pod lifecycles. They use separate storage configured with the cluster.

Service Map's persistent volume resources select cluster storage for creation. Created persistent volumes are mounted to pods and used by containers. Persistent volumes are categorized into shared volumes, which can be mounted by multiple pods, and single volumes, which can be mounted by only one pod.

Persistent volumes require storage configured in the cluster. NFS storage is commonly used, supporting any storage that supports the NFS protocol.

Configuration Information (ConfigMap/Secret)

When deploying a web server as a container, you typically use configuration files for server execution. In cases where pods are executed with separate configurations, these settings are managed as configuration resource. While it's possible to include configuration files in the pod's container image, this would necessitate recreating the image whenever configurations change.

Configuration information is created and managed within the service map, and can be mounted to pods' containers as volumes or files. Depending on container implementation, it can also be passed as environment variables. An advantage is that configuration changes can be made and reflected even while pods are running.

Configuration resource is categorized into ConfigMaps and Secrets based on management method. Both manage configuration information, but Secrets encrypt data, making them suitable for sensitive information like database connection details.

Image Update

The pipeline resource in the service map updates container images for workloads. Upon workload deployment completion, a pipeline is automatically created to update container images in pods.

Workload-deployed container images in the service map fall into two types: those generated from Cocktail Cloud builds and those registered in external registries.

Images generated from Cocktail Cloud builds undergo the entire process from image creation to workload deployment automatically whenever application code changes (refer to 'Builds/Images' section for Cocktail Cloud builds).

External registry images are updated via replacement, where the pipeline performs automated deployment only.

Catalog

The catalog in the service map bundles one or more workloads associated with the service map for deployment and updates. It's primarily used for distributing and updating open-source software.

Cocktail Cloud provides many commonly used open-source packages in its catalog. Users can search for desired packages in the catalog and automatically deploy them to the service map. (Refer to the 'Catalog' section for Cocktail Cloud's catalog).

Packages deployed to the service map can perform state monitoring and automatic updates.

Security is a crucial aspect of enterprise cloud environments, with three main components in cloud-native setups:

Cluster Authentication and Authorization

Cluster access authentication and authorization refer to the permissions granted to authorized users to access the cluster and manage resources as needed. Users accessing the cluster have user accounts, and resources include applications and data. Administrators authorize user access and grant appropriate permissions for resource management, thereby managing cluster security.

In Cocktail Cloud, users can manage allocated clusters via GUI within workspaces, eliminating the need for direct cluster access for management. However, if using command-line tools or external CI/CD systems, a cluster user account is necessary. Administrators issue cluster accounts to users in such cases.

Cocktail Cloud provides integrated cluster account management, allowing users to access multiple clusters with a single user account and manage resources based on permissions. Users receive cluster accounts from administrators and can manage clusters within the validity period.

Audit Logs

Audit logs record the commands (API) executed by users logged in as Cocktail users or cluster accounts, detailing which resources were affected. In case of incidents or security issues, audit logs can be traced to analyze the root cause.

Cocktail Cloud offers the capability to collect and trace both platform (Cocktail Cloud features) and cluster (Kubernetes) audit logs.

Pod (Container) Security Policies

Pod security policies control permissions, node access, OS security settings, etc., during container execution. Typically, security settings are defined when defining pods. However, enterprises require control over security. Different security settings for each team or organization may lead to unforeseen security vulnerabilities.

Pod security policies can enforce security settings at the cluster or application level. Enterprises can enforce security policies based on their existing security policies.

Cocktail Cloud provides features to configure and apply security policies.

Image Inspection

Container execution images may contain multiple open-source components. For example, a base image is publicly available on the internet and serves as the basis for container image creation by adding user-specific components. If a base image contains malicious code, it poses a security risk.

Cocktail Cloud's image registry offers features to inspect images for malicious code. Additionally, it provides additional checks for outdated component versions or vulnerable code.

Cloud-native applications leverage cluster and container technologies, where clusters manage infrastructure, and containers handle application deployment and execution. Consequently, the monitoring targets differ from traditional applications.

Cluster Monitoring

Clusters consist of nodes, which are computing machines with CPU, GPU, Memory, and Disk, along with an operating system (OS) and container runtime for executing containers. Hence, monitoring of physical resource usage and performance necessary for container execution is done by collecting data (referred to as 'metrics' in monitoring) at the node level.

Container management is handled by Kubernetes, composed of multiple components installed on the cluster's master node. Monitoring the master node and installed components becomes necessary in case of Kubernetes failures, as container management becomes impossible. Monitoring involves tracking resource usage on the master node and the status of installed components.

Nodes and containers within a cluster communicate with each other. Monitoring network usage targets both the physical network and the logical network controlled by Kubernetes.

Application (Container) Monitoring

While cluster monitoring focuses on infrastructure resources required for container execution, container monitoring encompasses resource usage, execution status, and lifecycle monitoring. It also includes monitoring aspects such as communication volume between containers and request processing times.

Container monitoring provides metrics through the Kubernetes API and the Service Mesh API (for configuring container-to-container communication).

Notifications and Events

Notifications occur when monitoring metric data meets certain conditions defined by notification rules. These rules can be both predefined and user-defined.

Events occur when Kubernetes resources change. For instance, events are triggered by pod creation, execution, update, or deletion. Cocktail Cloud collects and provides events as notifications.

Both notifications and events provide real-time information during operation, facilitating proactive measures against application and cluster state changes and failures.

Logs

Kubernetes logs comprise three main types. Firstly, logs recorded by the Kubernetes master provide information necessary for master operation. Secondly, container logs are logs displayed on standard output (STDOUT/STDERR) during container execution. Lastly, application logs are logs recorded in separate files by containers in addition to standard output.

Cocktail Cloud collects all three types of logs, providing an environment for log retrieval and analysis.

Containers are deployed and executed as images. Container images are specified by name in the pod's container spec in the format of image_name:tag (e.g., nginx:latest). When using Docker Hub, the registry address where the image is located is often omitted.

Cocktail Cloud provides independent image registries for each workspace. It also offers automated image building through the 'Build' feature.

Image Registry

An image registry stores container images and provides them when the image is required for pod execution. The storage/provisioning interface of image registries is standardized. Typically, the 'Push' API is used to store images in the registry after creation, while the 'Pull' API is used to retrieve images during container execution.

In Cocktail Cloud, image registries can be allocated for each workspace, serving as independent registries for teams. Additionally, image registries can be shared among teams.

When deploying pods from the service map using an allocated image registry, the image configuration is performed by selecting a 'build' rather than specifying the image name. A build automates the process of creating images, and the latest image can be deployed to pods based on the selected build's 'tag.'

Build

A build is a resource in Cocktail Cloud that automates the process of generating container images. Builds can have one or more tags, with each tag defining a different creation process. Tags can be seen as image versions. The process of generating images is called the build flow.

Builds store generated images in the image registry allocated to the workspace. Therefore, images and builds are synonymous, but each image tag (version) has a unique build flow. The structure is Image Registry -> Image (Build) -> Tag (Build Flow).

Users deploy builds (images) and tags (versions) in pods for workloads. The image generated by the build flow of the selected tag is then deployed and executed. The pipeline in the service map automates the entire process of updating images by executing the build flow of the image tag after code changes.

Build Flow

The build flow automates the process of generating images for a specific tag (version). Each step executed by the build flow for image creation is called a 'task.'

Cocktail Cloud offers various types of default tasks, and users can create custom tasks to configure the build flow. Default tasks include downloading code from code repositories (Git), executing user-defined scripts, and building images using Dockerfiles. Additionally, tasks for integrating with external systems' APIs and FTP-based file transfers are provided.

Users can develop and add/extend tasks to the build flow. User-defined tasks need to be containerized before adding them to the build flow.

Tasks in the build flow are executed on the 'build server.' Cocktail Cloud provides options to adjust the capacity of the build server. For build tasks requiring substantial resources, the capacity of the build server can be adjusted.

Typically, applications consist of one or more workloads (containers), especially when deployed on Kubernetes, involving various related resources such as service exposure and volumes. This complexity makes application deployment and upgrades challenging.

Catalogs address these issues by bundling multiple application resources into a single unit called a package and deploying this package with user settings when necessary. Upgrades are also automated based on versioning. There are several open-source tools that support package creation, deployment, and management, with Helm being widely used, especially as an official Kubernetes project.

Cocktail Cloud's catalog offers the ability to search for such packages and automatically deploy them to service maps. These packages are in the form of Helm charts, which are supported by a wide range of open-source projects. Open-source packages are registered and managed in package repositories. There are numerous public package repositories where various open-source packages are available, and the catalog can search all these repositories for packages.

Packages deployed through the catalog are managed in the package menu of the service map. It provides monitoring and status of deployed packages and enables upgrades to newer versions.

To create a cluster, certain prerequisites need to be completed. Please refer to the following steps

1. Create a Cloud Provider

1) To create a cloud provider for cluster creation, click on the "+ Create" button in the [Provisioning] - [Cloud Providers] tab, and select AWS.

2) Register AWS authentication information in the basic information and click the "Save" button.

3) Confirm successful registration.

2. Create an EKS Cluster

1) [Provisioning] - Navigate to the [Templates] tab, then click the "Start" button under the EKS (Elastic Kubernetes Service)​ item in the templates section

2) Select the previously created cloud provider information, choose the required version, and click "Save."

3) Once saved, the cluster status changes to "CREATING" as it is being provisioned.

4) Click on the "CREATING" status to monitor the cluster creation progress.

5) Click on the [Activity] tab to check the ongoing installation details.

6) Confirm the status changes to "RUNNING" when the cluster is successfully created.

3. Add AWS Node Group

1) Once the cluster configuration is complete, select the cluster, go to the [Resources] tab, and click "+ Add Node Group."

2) Enter the required information for the node group to be created and click "Save."

3) When the node group addition starts, the status is displayed in the "Node Group" section.

4) As the node group addition progresses, the status changes to "ACTIVE."

5) Check in the [Infrastructure] - [Clusters] tab if the cluster status and the number of nodes are displayed correctly.

4. Add Amazon EBS CSI Driver

1) Once the node group configuration is complete, select the cluster, go to the [Resources] tab, and click "+ Install Amazon EBS CSI Driver."

2) During the installation process, it takes some time to create resources, and later, confirm the installation completion.

3) Once the Amazon EBS CSI Driver installation is complete, the status is displayed in the "Amazon EBS CSI Driver" section.

4) Confirm the installation of the Amazon EBS CSI Driver in [Workloads] - [Deployments].

5. Add Cluster Autoscaler

1) Once the node group configuration is complete, select the cluster, go to the [Resources] tab, and click "+ Install Cluster Autoscaler."

2) During the installation process, it takes some time to create resources, and later, confirm the installation completion.

3) Once the installation is complete, the status is displayed in the "Cluster Autoscaler" section.

4) Confirm the installation of the Cluster Autoscaler in [Workloads] - [Deployments].

Coming Soon

Coming Soon

Coming Soon

1. EKS Cluster Registration

1) Register the created EKS cluster with the Cocktail Cloud using the following procedure.

1.1 Move to the Cluster Registration screen

1) Click on the "+ Register cluster in use" button in the upper right corner of the [Infrastructure] - [Clusters] tab.

1.2 Choose Cluster Provider and Type

1) Select 'Amazon Web Service' as the provider in the cluster configuration form.

2) Choose the type attribute as 'EKS'.

3) Once these two attributes are selected, the Cluster ID setting will be displayed in the cluster configuration form.

4) Choose the region as the one where EKS was created (Example: Seoul (ap-northeast-2)).

1.3 Cluster Registration

1) Click the "Save" button in the menu bar to save the cluster registration.

2) After registration is complete, the cluster list will be displayed.

2. Create Storage Class

1) To use PV/PVC, you need to create a new storage class.

2.1 Move to the storage class creation screen

1) Click on the "+ Create" button at the top right corner of the [Storage] - [Storage Classes] tab, then select AWS EBS CSI.

2.2 Configure Storage Class

1) Fill out the settings form accordingly, then click the "Save" button.

2.3 Storage Class Creation Completed

1) You can now verify the created storage class

1. NCPKS Cluster Registration

1) To register the created NCPKS cluster with Cocktail Cloud, follow these steps

1-1. Navigate to the Cluster Registration Screen

1) Click the "+ Cluster Registration" button located in the upper right corner of the [Infrastructure] - [Clusters] tab.

1.2 Choose Cluster Provider and Type

1) Set the provider attribute in the Cluster Configuration form to 'Naver Cloud Platform.'

2) Choose the type attribute as 'NCPKS.'

3) Upon selecting these two attributes, the Cluster UUID setting will appear in the cluster configuration form.

4) Choose the region as the one where NCPKS was created (Example: Korea(KR)).

1.3 Cluster Registration

1) Click the "Save" button in the menu bar to initiate the cluster registration.

2) After registration is complete, the cluster list will be displayed, allowing you to verify the recently registered cluster.

Coming Soon

1. GKE Cluster Registration

1) To register the created GKE cluster with Cocktail Cloud, follow these steps

1-1. Navigate to the Cluster Registration Screen

1) Click the "+ Cluster Registration" button located in the upper right corner of the [Infrastructure] - [Clusters] tab.

1.2 Choose Cluster Type and Authenticate

1) Set the provider attribute in the Cluster Configuration form to 'Google Cloud Platform.'

2) Choose the type attribute as 'GKE.'

3) Upon selecting these two attributes, the authentication attribute will appear in the cluster configuration form.

4) Click the authentication button, and a Google authentication window will appear. Enter your Google account credentials.

1.3 Cluster Registration

1) Once authentication is complete, the authentication attribute will display 'Authentication Completed.'

2) Click the "Save" button in the menu bar to initiate the cluster registration.

3) After registration is complete, the cluster list will be displayed, allowing you to verify the recently registered cluster.

1. ETC Cluster Registration

1) To register a non-public cloud cluster with Cocktail Cloud, follow these steps

1-1. Navigate to the Cluster Registration Screen

1) Click the "+ Register In-Use Cluster" button located in the upper right corner of the [Infrastructure] - [Clusters] tab.

1.2 Choose Cluster Provider and Type

1) Set the provider attribute in the Cluster Configuration form to 'Datacenter.'

2) Choose the type attribute as 'MANAGED.'

3) Choose the region as the one where the cluster was created (Example: Korea).

1.3 Cluster Registration

1) Click the "Save" button in the menu bar to initiate the cluster registration.

2) After registration is complete, the cluster list will be displayed, allowing you to verify the recently registered cluster.

To set up AWS IAM users and permissions for provisioning AWS resources, along with creating roles using custom trust policies that IAM users can assume to access resources, follow these steps

User Creation

1) Access the AWS Console and click on "IAM."

2) Click the "Create user" button in the top right corner of the IAM menu.

3) Enter the username.

5) Verify that the user has been created successfully.

6) Copy the ARN (Amazon Resource Name) of the created user.

2) Policy Creation

1) In the IAM menu, navigate to [Access management] - [Policies] and click the "Create policy" button.

2) Click on JSON in the policy editor and edit the policy as needed.

3) Set a name for the policy and click "Create policy."

3) Role Creation

1) In the IAM menu, go to [Access management] - [Roles] and click the "Create role" button.

2) Choose "Trusted entity type" as "Custom trust policy," click "Add" in the "Add trusted entities" section.

3) Add [Principal Entity Types] - [IAM users] & [AWS services].

IAM users : ARN (Amazon Resource Name) of the created user

AWS services: Name of the service you intend to use (e.g., eks)

4) Add the necessary permissions

AmazonEBSCSIDriverPolicy

AmazonEC2FullAccess

AmazonVPCFullAccess

IAMFullAccess

EKSFullPolicy

5) Set a name for the role and click "Create role."

6) Verify the created role.

4) Get Access Key and Secret Access Key

2) Click "Next" under the "Select" section, choose "Other," and click "Next."

3) Enter a description tag for the access key and click "Create access key."

4) Confirm the generated access key and secret access key.

5) Save the generated access key for later use.

This section introduces the process of configuring users and permissions to provision resources from the cloud provider. Currently, only AWS is supported, and it is noted that additional cloud providers may be added in the future.

As mentioned earlier, we explained the process of "Cluster Registration." You have successfully created a cluster and registered cluster information on the Cocktail Cloud platform, completing the infrastructure preparation. Now, let's create a user who can access the Cocktail Cloud platform.

1. Navigate to the user creation screen

1) Click the "+ Create" button in the upper right corner on the [Settings] - [User] tab.

2. Enter User Information

1) Enter the user creation information below, and click the "Save" button to create the user.

3. Confirming User Creation

1) Verify the newly created user in the user list screen.

4. Next Steps

Next, we will explain the process of creating a service map, which is required for workspace registration. Please proceed to the "Create Service Map" page.

We have previously created a user who can log in to the platform. Now, let's create a service map to register in the workspace.

1. Move to the Service Map Creation Screen

1) Click the "+ Create" button in the upper right corner on the [Application] - [Service Map] tab.

2. Enter Service Map Creation Information

After filling out all the details, select the "Save" button to create the service map.

3. Confirming Service Map Creation

1) Verify the newly created service map in the service map list screen.

4. Next Steps

Coming Soon

By default, Cocktail Cloud provides Harbor (Registry) when configuring the platform. Additionally, it supports integration with external registries. You can register externally created registries in Cocktail, enabling image builds and deployments.

We have previously created a service map. Now, let's create a registry to register in the workspace.

1. Move to the Registry Creation Screen

1) Click the "+ Create" button in the upper right corner on the [Build Configuration] - [Container Registry] tab.

2. Enter Registry Creation Information

1) Enter the name of the registry to be created in the "Registry Name" field.

2) Input a description for the registry in the "Description" field.

3) Click the "Save" button in the upper right corner.

3. Registry Creation Confirmation

1) Verify the newly created registry in the registry list screen.

4. Next Steps

1. Move to the external registry creation screen

1) Navigate to [Build Configuration] - [External Container Registries].

2) Click the "+ Register" button in the upper right corner to select the provider to create.

2. Enter Registry Registration Information

1) Click the "+ Register" button and select "Azure ACR."

2) After registering Azure ACR authentication information in the basic information, click the "Test Connection" button.

1. Enter the name of the registry to be created in the registry.

2. Enter a description for the registry in the description.

3. Enter the EndPoint URL in the correct format.

4. Select the region of the registered registry.

5. Enter the Client ID and Client Secret.

6. Click "Test Connection" in the upper right corner to verify if the registry is available.

7. Click the "Save" button in the upper right corner.

How to Create Azure Container and Verify Authentication Information

1) Access the Azure Portal to retrieve the necessary information.

2) Click on "Management Groups" to efficiently manage access, policies, and compliance for subscriptions.(All services - Management and governance - Management groups)

2-1) Click the "Create" button to go to the creation screen.

2-2) Create a management group to be used internally.

3) Click on "Subscriptions" to create a set that encompasses all resources.

3-1) Click the "Add" button to go to the creation screen.

4) Click on "Resource Groups," a logical container for managing resources grouped together. (All services - Management and governance - Resource Group)

4-1) Click the "Create" button to go to the creation screen.

4-2) [Create Resource Group] - Choose a resource group name and region, then create.

5) Click on "Resources" to create resources that can be used for Azure services.

5-1) In the marketplace, search for "registry" and click on "Container Registry."

5-2) Click the "Create" button.

5-3) Register with subscription, resource group, registry name, and location (region).

6) Click on the created resource and click on "Access Keys."

Registry: Registry Name

EndPoint URL: Login Server

Client ID: User Name

Client Secret : Password

Amazon Elastic Container Registry (Amazon ECR) is a fully managed container registry that provides highly available and secure hosting for container images and artifacts. It allows you to deploy your applications reliably anywhere.

1. Navigate to the External Registry Creation Screen

1) Move to [Build Configuration] - [External Container Registry].

2) Click the "+ Register" button in the upper right corner and select the provider you want to create.

2. Enter Registry Registration Information

1) Click the "+ Register" button, and then select "AWS ECR"

2) After entering the AWS authentication information in the basic details, click the "Test Connection" button.

1. Enter the name of the registry to be created in the registry.

2. Enter a description for the registry in the description.

3. Enter the EndPoint URL in the correct format.

4. Select the region of the registered registry.

5. Enter the name of the registered registry.

6. Enter Access ID and Access Secret.

7. Click "Test Connection" in the upper right corner to verify if the registry is available.

8. Click the "Save" button in the upper right corner.

Access ID & Access Secret Verification Method

1) Access the AWS Console to retrieve the necessary information.

3) Click "Other" among the next buttons and click "Next."

4) Enter a description tag for the access key to be created and click the "Create access key" button.

5) Confirm the generated access key and secret access key values.

Creating a Registry

You can create both private and public repositories.

(Note: This guide is written based on the private repository in the 'us-east-1' region, and the process is the same for public repositories.)

1) Click the "Create Repository" button in the upper right corner.

2) Enter the repository name to create the repository.

(In Cocktails, builds are done with "Registry Address/Image Name" so please make sure to create the registry as "Registry Name/Image Name")

EndPoint URL & registry Verification Method

1) Retrieve the necessary information from the list of created repositories in Cocktails.

EndPoint URL : The table below provides the necessary information

Registry : Repository Name Created by User

※ Permissions need to be granted separately for Private Registries.

Private Registry Permission Example

1) Click on "Settings" in [Amazon Elastic Container Registry] for the [Private registry].

2) Click the "Generate Policy" button in the upper right corner of [Settings] - [Permissions].

3) lick "JSON" in the upper right corner, add the following items, and click "Save Policy" to save.

Sid: Permission Name

Principal: Specify one or more AWS account IDs to grant permission. Specify more than one account using a comma-separated list.

Action : “ecr:*”

1. Move to the external registry creation screen

1) Navigate to [Build Configuration] - [External Container Registries].

2) Click the "+ Register" button in the upper right corner to select the provider for creation.

2. Enter Registry Registration Information

1) Click the "+ Register" button and select "Docker Hub"

2) After registering Docker Hub authentication information in the basic information, click the "Test Connection" button.

1. Enter the name of the registry to be created in the registry.

2. Enter a description for the registry in the description.

3. Enter the EndPoint URL in the correct format.

4. Enter the name of the registered registry.

5. Enter Access ID and Access Secret.

6. Click "Test Connection" in the upper right corner to verify if the registry is available.

7. Click the "Save" button in the upper right corner.

To confirm the namespace

1) Log in to Docker Hub and click on "Repositories" at the top.

2) Click on "Create repository" in the upper right corner.

3) Create a namespace and the image to be generated.

Since Docker Hub creates both the repository and image name simultaneously, the image name in the Build/Pipeline > Build section should match the Docker Hub Repository Name for image build generation.

To verify Access ID & Access Secret

1) Click on the profile in the upper right corner and select "My Account."

2) Confirm the Access ID

Access ID : User's nickname or email address

3) Click on the "Security" tab on the right, then click on "New Access Token" in the upper right.

4) Enter a description for the token and copy the Access Token upon issuance.

Access Token : Copy Access Token

1. Move to the external registry creation screen

1) Navigate to [Build Configuration] - [External Container Registries].

2) Click the "+ Register" button in the upper right corner to select the provider for creation.

2. Enter Registry Registration Information

1) Click the "+ Register" button and select "Google GCR."

2) After registering Google GCR authentication information in the basic information, click the "Test Connection" button.

• List of regions: https://cloud.google.com/artifact-registry/docs/repositories/repo-locations

1. Enter the name for the registry to be created in the registry.

2. Enter a description for the registry in the description.

3. Enter the EndPoint URL in the correct format.

4. Enter the registry name.

5. Enter Access ID and Access JSON.

6. Click "Test Connection" in the upper right corner to verify if the registry is available.

7. Click the "Save" button in the upper right corner.

Access JSON Verification Steps

1) Log in to the Google Cloud Console.

2) In the Google Cloud Console, click on the "IAM & Admin" button.

3) Under the "IAM & Admin" tab, click on "Service Accounts," then click the "+ Create Service Account" button at the top center.

4) Set the name for the service account. then click "CREATE AND CONTINUE"button.

5) Set the permissions for the service account to be created.

Owner permissions grant full access to most Google Cloud resources.

You can provide different permissions if needed, but access may be restricted based on the assigned permissions..

6) Click on the created service account, click "Add Key," then click "Create a new key," choose JSON format, and click "Create."

7) Verify that the JSON file has been generated locally.

Accss JSON : File contents

Project ID Verification

Project ID : The name in the leftmost select box in the search.

Registry & Endpoint URL Verification

레지스트리 : Repository name

Endpoint URL : Region of the registry to be created

1. Move to the external registry creation screen

1) Navigate to [Build Configuration] - [External Container Registries].

2) Click the "+ Register" button in the upper right corner to select the provider for creation.

2. Enter Registry Registration Information

1) Click the "+ Register" button and select "Docker Registry"

2) After registering Docker Registry authentication information in the basic information, click the "Test Connection" button.

1. Enter the name of the registry to be created in the registry.

2. Enter a description for the registry in the description.

3. Enter the EndPoint URL in the correct format.

4. Enter the name of the registered registry.

5. Enter Access ID and Access Secret.

6. Click "Test Connection" in the upper right corner to verify if the registry is available.

7. Click the "Save" button in the upper right corner.

Access ID & Access Secret Verification Method

1) Click on the profile in the upper right corner and select "My Account."

2) Confirm the Access ID

Access ID : User's nickname or email address

3) Click on the "Security" tab on the right, then click on "New Access Token" in the upper right.

4) Enter a description for the token and copy the Access Token upon issuance.

Access Token : Copy Access Token

. Cocktail Backup/Restore provides

1. Ensured safe backup and fast restoration.

• Protection of all resources for quick restoration when needed.

• Automated backup scheduled as per the defined intervals.

• Adjustable retention periods for efficient operations.

1. It provides excellent portability.

• By eliminating specific vendor dependencies, you can freely utilize it in a variety of environments.

• Rapid restoration through redundant configurations in case of disasters.

• Service expansion through backup and restoration.

1. Consistent UI and backup/restore status.

• It allows easy management of multiple clusters through a unified user interface.

• Users can conveniently monitor the backup and restoration status at a glance.

1. With Cocktail Backup & Restore, you can easily perform tasks like.

• Backing up and, if necessary, restoring clusters.

• Cloning clusters.

• Migrating cluster resources to other clusters.

• Periodically backing up cluster resources for easy restoration to a previous state in case of unforeseen issues.

2. Cocktail Repository

1. The Cocktail Repository is associated with object storage where backups are stored and manages connection states periodically.

2. Adding a cluster to the Cocktail Repository is used for cluster migration.

3. Cocktail supports integration with various object storage options.

• AWS

• GCP

• Azure

• MinIO(local storage)

3. Cocktail Backup

Cocktail Backup captures the current state of Kubernetes resources and creates a restore point.

1. Necessary information for users to create a restore point, such as the protected target cluster, data storage, retention policy, schedule, etc., is stored, making backup management easy.

2. Stored information in Cocktail Backup helps users efficiently replicate backups.

4. Cocktail Restore Point

1. Cocktail Restore Point stores the state of Kubernetes resources at a specific point in time in the object storage.

5. Cocktail Restore

1. Cocktail Restore uses the restore point to restore the Kubernetes state to a specific point in time, helpful in system failures, user errors, or other unexpected situations.

6. Overall Process

1. Create the storage for backup and restore.

2. Generate and execute backups to create restore points.

1. Perform restoration using the restore points.

1. Move to the external registry creation screen

1) Navigate to [Build Configuration] - [External Container Registries].

2) Click the "+ Register" button in the upper right corner to select the provider to create.

2. Enter Registry Registration Information

1) Click the "+ Register" button and select "Harbor"

2) After registering Harbor authentication information in the basic information, click the "Test Connection" button.

1. Enter the name for the registry to be created in the registry.

2. Enter a description for the registry.

3. Enter the EndPoint URL.

4. Enter the registry name.

5. Enter Access ID and Access Secret.

6. If CA Certificate exists, enter it (optional).

7. Check the option for using Insecure (optional).

8. Click "Test Connection" in the upper right corner to verify if the registry is available.

9. Click the "Save" button in the upper right corner.

1. Move to the external registry creation screen

1) Navigate to [Build Configuration] - [External Container Registries].

2) Click the "+ Register" button in the upper right corner to select the provider to create.

2. Enter Registry Registration Information

1) Click the "+ Register" button and select "Naver"

2) After registering Naver authentication information in the basic information, click the "Test Connection" button.

1. Enter the name for the registry to be created in the registry.

2. Enter a description for the registry.

3. Enter the EndPoint URL in the correct format.

4. Enter the registry name.

5. Enter Access ID and Access Secret.

6. Click "Test Connection" in the upper right corner to verify if the registry is available.

7. Click the "Save" button in the upper right corner.

Endpoint URL Guide

Here are the steps to enable or disable the Public Endpoint.

1. Log in to the Naver Cloud Platform Console.

2. Click on "Services," then navigate to "Containers" > "Container Registry"

3. Click on the target registry name in the list.

4. In the detailed information section, click on the gear icon in the "Configuration" tab.

5. In the Configuration settings popup, click the toggle button for the "Public Endpoint" item to enable or disable it. After setting the preference, click the [Confirm] button to save the changes.

Aceess ID & Access Key 발급 가이드

1. Move to the external registry creation screen

1) Navigate to [Build Configuration] - [External Container Registries].

2) Click the "+ Register" button in the upper right corner to select the provider to create.

2. Enter Registry Registration Information

1) Click the "+ Register" button and select "Quay"

2) After registering Quay authentication information in the basic information, click the "Test Connection" button.

1. Enter the name for the registry to be created in the registry.

2. Enter a description for the registry.

3. Enter the EndPoint URL in the correct format.

4. Enter the registry name.

5. Enter Access ID + Robot ID and Access Secret.

6. Click "Test Connection" in the upper right corner to verify if the registry is available.

7. Click the "Save" button in the upper right corner.

Access ID + RobotID & Access Secret Verification

The robot ID needs to be associated with an existing repository.

1) Access Quay and click on the profile in the upper right corner. Select "Account Settings."

2) Click on "Robot Accounts," the second menu in the right tab, and then click "Create Robot Account" in the upper right corner.

3) Create an ID for the robot, select the repository you created, and grant the necessary permissions.

4) Click on the created RobotID to check the Access Secret.

Access ID+ RobotID : The first value in the image.

Access Secret : The second value in the image.

1. Create Workspace

1) Click on the "+ Create" button in the upper right corner of the [Settings] - [Workspace] tab.

3) In the basic information form of the workspace creation screen, enter the workspace name in the "Name" attribute.

4) Choose a color for the workspace in the "Color" attribute.

5) Enter a description for the workspace in the "Description" attribute.

2. Register Registry

1) Select the created workspace name from the list on the workspace screen.

2) Click on the image registry icon on the right side of the basic information.

3) Choose the previously created registry and click the "Apply" button.

3) Confirm the registered registry.

3. Assign/Remove Clusters

3.1 AssignCluster

1) Select the created workspace name from the list on the workspace screen.

2) Click the "Assign/Remove Cluster" button on the right side of the allocated cluster, and the Assign/Remove window will appear.

3) In the "Select" of the allocation/removal window, choose the previously created cluster and click the "+ Add" button.

4) Click the "Save" button at the bottom right.

5) Confirm the list of allocated clusters.

3.2 Remove Cluster

1) In the Assign/Remove window, click the "Assign/Remove Cluster" button on the right side of the allocated cluster, and the Assign/Remove window will appear.

2) Press the "-" button on the right of the cluster you want to delete, remove it from the list, and then click the "Save" button at the bottom right.

3) Confirm that the cluster has been removed from the list of allocated clusters.

4. Allocation/retrieval Service Maps

4.1 Allocate Service Map

1) Select the created workspace name from the list on the workspace screen.

2) Click the "Service Map Allocation/retrieval " button on the right side of the allocated service map.

3) Select the cluster, choose the service map, and click the "+ Add" button.

4) Confirm the added item, select the target service map group, and click the "Save" button at the bottom right.

5) Confirm that the service map has been allocated in the list of allocated service maps.

4.2 retrieval Service Map

1) Click the "Service Map Allocation/retrieval" button on the right side of the allocated service map.

2) Press the "-" button on the right of the service map you want to revoke, remove it from the list, and then click the "Save" button at the bottom right.

3) Confirm that the service map has been revoked in the list of allocated service maps.

5. Assign/Remove Build Servers

5.1 Assign Build Server

1) Select the created workspace name from the list on the workspace screen.

2) Click "Assign/Remove Build Server" on the right side of the allocated build server.

3) After selecting the build server, click the "+ Add" button.

4) Confirm the added item and click the "Save" button at the bottom right.

5) Confirm that the build server has been allocated in the list of allocated build servers.

5.2Remove Build Server

1) Click "Assign/Remove Build Server" on the right side of the allocated build server.

2) Press the "-" button next to the build server you want to revoke, remove it from the list, and then click the "Save" button at the bottom right.

3) Confirm that the build server has been revoked in the list of allocated build servers.

6. Register/delete Members

6.1 Register Members

• Users with USER role need to register members to access Workspaces.

1) Click the "Register/delete Members" button on the right side of the members.

2) Select the name of the member to be registered in the workspace, grant permissions, and click the "Save" button at the bottom.

3) Confirm that the member has been registered with the selected permissions.

6.2 delete Members

1) Click the "Register/delete Members" button on the right side of the members.

2) Select the name of the member to be removed, uncheck the combo box, and click the "Save" button.

3) Confirm that the member has been removed.

1. Preparation before storage creation"

• Prior tasks are required to create a storage. Please refer to this place

2. Access the storage creation page

1. Select the [Backup/Restore] - [Storages] section.

   
2. Click the "+ Create" button.

   
3. Select the provider.

   

3.Enter storage information

3.1 Common

3.2 AWS

3.3 GCP

3.4 Azure

3.5 MinIO

3.6 Save storage information

1. Click the "Save" button.

   
2. Click the "OK" button.

   

3.7 Verify the storage

1. Verify if the storage has been successfully created.

   

2. You can click on the name to view detailed information.

   

   

1. Preparation Before Backup Creation

• To create a backup, you need to create a storage. Please refer to this place

2. Access the Backup Creation Page

1. Select the [Backup/Restore] - [Backup] section.

1. Click the [Create] button.

3. Enter backup information

1. Input the details for the backup.

3.2 Backup Scope

1. View Details of Backup-Eligible Resources

• The button links to a screen displaying a list of selectable resources and detailed information about those resources.

  
• The number inside the parentheses indicates the total count of backup-eligible resources.

2. Backup Scope

• The backup scope allows you to choose either [Entire Cluster] to back up the entire cluster or [Selecting Namespace] to choose specific namespaces.

• If you choose [Selecting Namespace], additional items will be displayed as follows.

  
• Click the icon to select the namespace, then click the [Apply] button.

  
• Verify the selected namespace.

  

3. Label Selector

• Using the label selector during backup allows you to perform backups targeting only resources that match specific labels or label conditions.

• Click the icon to enter the name and value.

• The backup target is limited to resources that satisfy all specified label conditions.

4. Resources

• This item configures the cluster backup target.

• "If you choose [Entire Resources] under Resources, it sets all resources within the cluster as the backup target. If you choose [Selecting Resources], you can selectively backup specific resources.

• If you choose [Selecting Resources], additional items will be displayed as follows

  

3.3 Schedule

• If you choose 'not in use,' the backup will run immediately once. However, if you choose ' Schedule Execution,' the backup will automatically run according to the specified time (specified interval).

• If you select 'Schedule Execution,' the backup will not run immediately but will be automatically executed at the specified time.

• You can specify the desired time or interval using a cron expression or the @every notation.

#1 In Cron expression for UTC time
   
   * * * * *
   │ │ │ │ │
   │ │ │ │ └─ Day of the week (0-6, 0 and 7 represent Sunday)
   │ │ │ └─── Month (1-12)
   │ │ └───── Day of the month (1-31)
   │ └─────── Hour (0-23)
   └───────── Minute (0-59)

   
#2 @every notation : "@every 6h", "@every 24h","@every 168h"
  Maximum unit is in hours (combinations of hours, minutes, and seconds are possible)

4. Save Backup Information

1. Click the [Save] button.

   
2. Confirm the following message and click the [OK] button.

   

5. Verify Backup

5.1 Verify Backup

1. You can check the created backup in the backup list.

   
2. To view detailed information for the specific backup, click on the backup name.

   

   

5.2 To verify the restoration point

1. When the corresponding backup is executed, a restore point is added. In the case of scheduled backups, the backup runs according to the schedule, and a restore point is added.

1. To view detailed information for the specific restore point, click on the restore point name.

   
2. You can check the list of all restore points under [Backup/Restore] - [Restore Points].

   
3. To view detailed information for the specific restore point, click on the restore point name.

   

   

6. Schedule Backup Start/Stop

1. Navigate to the detailed view of the corresponding scheduled backup.

   
2. Click the [Pause Schedule] button.

   
3. Click the [OK] button.

   
4. Verify that the schedule has been paused.

   
5. If you wish to resume the schedule, click the button and repeat the above steps.

7. Run Now

1. Navigate to the detailed view of the corresponding backup.

   
2. Click the [Run Now] button.

   
3. Verify the created restore point.

   

8. Copy job

1. Navigate to the detailed screen of the respective backup.

   
2. "Click the [Replicate] button.

   
3. Click the [OK] button.

   
4. Add new configurations or modify existing settings.

   

1. Cocktail Log Service

1. Collect logs for all resources within the cluster.

• Collects all containers and audit logs within the cluster.

• Collect application logs for workloads that exist in the cocktail.

• In the case of application logs, only authenticated applications can be checked.

• Collected using open source 'Opentelemetry' and 'Opensearch'.

1. Provide a service that searches and analyzes collected logs.

• Collected logs can be analyzed by filtering them with labels.

• Collected logs are aggregated by time so users can analyze log trends.

• Can search and analyze collected logs.

2. Recommended specifications

This guide is based on installation on an 8Core 16GB node.

• master node : 1Core, 2GB

• data node : 2Core, 4GB

• dashboard : 500mCore, 1GB

3. Architecture

Effectively manage cluster containers and application logs to increase operational efficiency and ensure system stability. The following provides guidance on how to collect logs for each log screen and application.

1. AWS S3

1. To use AWS S3 storage, please refer to the following guide.

2. Creating an AWS S3 Bucket

How to Create a Bucket

1) Log in to the console and click on "S3."

(Note: This guide assumes the use of the "us-east-1" region.)

2) Click on the "Create bucket" button to navigate to the creation screen.

3) Set the region, bucket name, and default encryption according to user preferences, then click the "Create bucket" button at the bottom right to create the bucket.

Checking Authentication Information

1) Access the AWS Console to retrieve the necessary information.

2) Click on the registered user, then click the tab and click the button in the top right of the [Access keys] box.

3) Click "Other" among the next buttons and click "Next."

4) Enter a description tag for the access key to be created and click the "Create access key" button.

5) Confirm the generated access key and secret access key values.

1. MinIO

1. To use MinIO storage, please refer to the guide below.

2. Bucket Creation Method

Bucket Creation Method

1) Access the MinIO console by entering the installed MinIO URL.

2) After logging in, go to [Administrator] - [Buckets] and click the "Create Bucket +" button in the top right corner.

3) Provide an appropriate bucket name and click the "Create Bucket" button to create the bucket.

Authentication Information Confirmation Method

1) After logging into the console, go to [User] - [Access Keys] and click the "Create access key +" button in the top right corner.

2) Save the displayed Access Key and Secret Key separately, then click the "Create" button to generate authentication information.

aws_access_key_id : Access Key

aws_secret_access_key : Secret Key

1. Google Cloud Storage

1. To use Google Storage, please refer to the guide below.

2. Google Cloud Storage Creation

Bucket Creation Method

1) Access the Google Cloud Console.

2) Open the left menu, navigate to [Cloud Storage] - [Storage] menu.

3) Click the "Create" button in the top right corner to go to the creation screen.

4) Enter the bucket name, select the region (default: us), and click the "Create" button to create the bucket.

Authentication Information Confirmation Method

1) Access the Google Cloud Console.

2) In the Google Cloud Console, click on the "IAM & Admin" button.

3) Click on the Service accounts tab in IAM & Admin, and then click on the "+ Create Service Account" button at the top center.

4) Set the name for the service account.

5) Set the permissions for the created service account.

Owner permissions provide full access to most Google Cloud resources.

You can grant other permissions if needed, but note that access may be restricted based on the granted permissions.

6) Click on the created service account, click on "Add Key," choose JSON type, and click "Create" to generate a new key.

7) Confirm that a JSON file has been generated locally.

Authentication Information : Contents of the file

1. Azure Blob Storage

1. To use Azure Storage, please refer to the guide below.

2. Azure Blob Storage Creation

Bucket Creation Method

1) Access the Azure Portal to obtain the necessary information.

2) Efficiently manage access, policies, and compliance regulations for your subscription by clicking on "Management groups."(All services - Management and governance - Management groups)

2-1) Click the "Create" button.

2-2) Create a management group for internal use.

3) Click on "Subscriptions" to create a logical container called "Resource Group" for grouping resources for efficient management.(All services - Management and governance - Subscriptions)

3-1) Click the "Create" button to go to the creation screen.

4) Click on "Subscriptions" to create a logical container called "Resource Group" for grouping resources for efficient management.(All services - Management and governance - Resource Group)

4-1) Click the "Create" button to go to the creation screen.

4-2) [Create a Resource Group] - Enter the resource group name and select the region before creating.

5) Click on "Resources" to create resources that can be used in Azure services.

5-1) Search for "Storage account" in the marketplace and click on "Storage account."

5-2) Click the "Create" button.

5-3) nter subscription, resource group, storage account name, and region to register.

6) Click on the created resource, and under [Data Storage], click on "Containers."

6-1) Click "+ Container" to create storage.

Bucket : Container Name

Authentication Information Confirmation Method

AZURE_SUBSCRIPTION_ID

1. Log in to the Azure Portal.

2. Select the subscription from the Azure service title. If your subscription is not displayed, use the search box to find it.

3. Find the subscription in the list and verify the subscription ID displayed in the second column.

AZURE_TENANT_ID

1. Azure PortalLog in to the Azure Portal.

2. Make sure you are logged in to the tenant for which you want to retrieve the ID. If not, switch directories to ensure you're working in the correct tenant.

3. Use the search to find "Tenant properties."

4. Find the Tenant ID in the Overview section of the Basic Information screen.

AZURE_CLIENT_ID & AZURE_CLIENT_SECRET

Please refer to the guide below for more details.

1. Distribution Addon

1) Infrastructure - Clusters - Addon List - Click the "Deploy" button and click the "Deploy" button for 'cocktail-log-service' in the list.

2) Check the settings according to your environment and click the Deploy button to deploy the Addon.

Gateway Service Mode : Log service gateway type (Ingress, LoadBalancer)

[If Gateway Service Mode is set to Ingress]

Gateway Access URL : DNS to access log service through Ingress

URL Type : Cluster HostAliases type (PublicDNS or HostAliases)

Host Ip : (If URL Type is 'HostAliases') LB IP (or node IP) that can access the cluster from outside

Enable OpenSearch Dashboard : Use or not 'Opensearch Dashboard'

[If Gateway Service Mode is set to LoadBalancer]

3) Check the deployment status and if the status is 'Running', confirm that the deployment has been completed successfully.

If the status is 'pending' when deployed

4) Create a job in the namespace where the log service is installed.

Create a Job that creates policies for each container log, cluster audit log, and application log collected by Opensearch.

registry address : Please contact our technical team.

If you create a job according to the settings above, container logs have a storage period of 30 days, cluster audit logs have a storage period of 56 days, and application logs have a storage period of 1 year.

1. Load the list of log services installed as Addon and register them on the platform

1) Settings - Basic Information, click the selection box for the log service name to view the list of installed log services.

2) Specify the log service you want to register and click the “Register” button to register it on the platform.

Change log service

When changing the log service, simply select a different log service from the list and click the "Register" button to change it.

Deregister log service

You can discontinue the log service function registered on the platform by clicking the “Deregister” button.

1. Preparation before Restore Creation

• To create a restore, there must be a completed restore point. Refer to for more information.

2. Selecting a Restore Point

1. After selecting [Backup/Restore] - [Restore Points] section, click on the name of the restore point you want to restore.
2. Click the [Restore] button.

3. Restore Information Entry

1. Enter the necessary information for the restoration.

3.1 Restore Scope

1. Restore Scope

• The restore scope can be selected as [Entire Cluster] to restore the entire cluster or choosing [Selecting Namespace] to restore specific namespaces.

• "If you choose [Selecting Namespace], additional items will be displayed as follows.
• If you want to restore to a new or different namespace, enter the namespace name in [Deploy Namespace Name]

• Click the [Apply] button.
• Verify the selected namespace.

2. Label Selector

• Using a label selector during the restore allows you to perform restoration only on resources that match specific labels or label conditions.

• The restoration target is limited to resources that satisfy all specified label conditions.

3. Resources

• In the context you provided, selecting [Entire Resources] would designate all resources within the cluster as the restoration target, while choosing [Selecting Resources] allows for the selective restoration of specific resources.

• If you choose [Selecting Resources], additional options will be displayed below as follows

4. Change Storage Class

• When changing storage class is an option that allows you to switch to the storage class used by the destination cluster when restoring data to a new cluster

• Click the [Apply] button

3.2 Restore Target

4. Save Restoration Information

1. Save Restore Information
2. Review the following message and click the [OK] button.

5. Restore Confirmation

1. Created restorations can be viewed in the restoration history list.
2. To review detailed information about a specific restoration, click on its restoration name.

2. Restore Deletion

1. Navigate to the [Backup/Restore] - [Restore list] section, check the item you wish to delete from the list
2. Click the [Delete] button.
3. Click the [OK] button.

1. Backup/Restore Overview Page

1. Navigate to [Backup/Restore] - [Overview].

2. Backup schedules

• The backup schedule uses different colors to represent the statuses of 'New', 'Running', 'Paused', and 'Failed', allowing users to visually assess the overall status distribution based on the total count and the count of each status.

• Please refer to the details below for a comprehensive explanation of each status.

3. Cluster Backup Agent Status

• The cluster backup agent status indicates the health and installation status of the backup agent.

• The status is represented as one of the following: 'Healthy', 'Unhealthy', or 'Install.

• Please refer to the details below for a comprehensive explanation of each status.

4. Storage Usage

• You can visualize the storage usage of repositories registered in Cocktail through a graph.

• Each rectangle represents a repository, with colors distinguishing each one.

• The size of the rectangle visually indicates the relative usage of the corresponding repository.

• You can zoom in or out on the graph using the scroll function.

• When the graph is zoomed in or out, you can click the [Storage Usage] button at the bottom to revert to its original size.

5. Restore Point

• The restore points are represented by different colors based on five statuses: 'New', 'Running', 'Paused', 'Failed', and 'Deleting', reflecting their distribution in proportion to their respective counts. This enables users to visualize the overall status distribution by observing the total count and the count of each status

• Please refer to the details below for a comprehensive explanation of each status.

6. Restore

• Restoration is visually represented with different colors based on five statuses: 'New', 'Running', 'Paused', 'Failed', and 'Deleting', allowing users to assess the overall status distribution by considering the total count and the count of each status.

• Please refer to the details below for a comprehensive explanation of each status.

7. Recent Restore Points

• The recent restore points display the five most recent restoration points as a list.

• Each entry includes age and status information.

• Clicking on the name of a restore point navigates to the detailed information page for that specific restore point.

8. Recent Restores

• The recent restores display the five most recent restoration items as a list.

• Each entry includes age and status information.

9.Storage remaining space

• The storage remaining space displays the top 5 storage entries with Object Storage size limitations, sorted in ascending order of available space.

• Each entry is accompanied by a graph representing the available space visually, along with the remaining space capacity and its percentage.

• The grey area on the graph represents unused spare space.
• Clicking on the storage name navigates to the storage details page.

• Storage entries connected to the same MinIO object storage display the same disk usage.