# Managed Kubernetes Service ## Overview The Managed Kubernetes Service offers a streamlined solution for efficiently managing server workloads. Kubernetes has emerged as the industry standard, providing a unified and accessible API, primarily utilizing YAML for configuration. This means that teams can easily understand and work with Kubernetes, streamlining infrastructure management. The Kubernetes leverages robust software design patterns, enabling continuous recovery in any scenario through the reconciliation method. Additionally, it ensures seamless scaling across a multitude of servers, addressing the challenges posed by complex and outdated APIs found in traditional virtualization platforms. This managed service eliminates the need for developing custom solutions or modifying source code, saving valuable time and effort. ## Deployment Details The managed Kubernetes service deploys a standard Kubernetes cluster utilizing the Cluster API, Kamaji as control-plane provicer and the KubeVirt infrastructure provider. This ensures a consistent and reliable setup for workloads. Within this cluster, users can take advantage of LoadBalancer services and easily provision physical volumes as needed. The control-plane operates within containers, while the worker nodes are deployed as virtual machines, all seamlessly managed by the application. - Docs: https://github.com/clastix/kamaji - Docs: https://cluster-api.sigs.k8s.io/ - GitHub: https://github.com/clastix/kamaji - GitHub: https://github.com/kubernetes-sigs/cluster-api-provider-kubevirt - GitHub: https://github.com/kubevirt/csi-driver ## How-Tos How to access to deployed cluster: ``` kubectl get secret -n kubernetes--admin-kubeconfig -o go-template='{{ printf "%s\n" (index .data "super-admin.conf" | base64decode) }}' > test ``` # Series . | U | O | CX | M | RT ----------------------------|-----|-----|------|-----|------ *Has GPUs* | | | | | *Hugepages* | | | ✓ | ✓ | ✓ *Overcommitted Memory* | | ✓ | | | *Dedicated CPU* | | | ✓ | | ✓ *Burstable CPU performance* | ✓ | ✓ | | ✓ | *Isolated emulator threads* | | | ✓ | | ✓ *vNUMA* | | | ✓ | | ✓ *vCPU-To-Memory Ratio* | 1:4 | 1:4 | 1:2 | 1:8 | 1:4 ## U Series The U Series is quite neutral and provides resources for general purpose applications. *U* is the abbreviation for "Universal", hinting at the universal attitude towards workloads. VMs of instance types will share physical CPU cores on a time-slice basis with other VMs. ### U Series Characteristics Specific characteristics of this series are: - *Burstable CPU performance* - The workload has a baseline compute performance but is permitted to burst beyond this baseline, if excess compute resources are available. - *vCPU-To-Memory Ratio (1:4)* - A vCPU-to-Memory ratio of 1:4, for less noise per node. ## O Series The O Series is based on the U Series, with the only difference being that memory is overcommitted. *O* is the abbreviation for "Overcommitted". ### UO Series Characteristics Specific characteristics of this series are: - *Burstable CPU performance* - The workload has a baseline compute performance but is permitted to burst beyond this baseline, if excess compute resources are available. - *Overcommitted Memory* - Memory is over-committed in order to achieve a higher workload density. - *vCPU-To-Memory Ratio (1:4)* - A vCPU-to-Memory ratio of 1:4, for less noise per node. ## CX Series The CX Series provides exclusive compute resources for compute intensive applications. *CX* is the abbreviation of "Compute Exclusive". The exclusive resources are given to the compute threads of the VM. In order to ensure this, some additional cores (depending on the number of disks and NICs) will be requested to offload the IO threading from cores dedicated to the workload. In addition, in this series, the NUMA topology of the used cores is provided to the VM. ### CX Series Characteristics Specific characteristics of this series are: - *Hugepages* - Hugepages are used in order to improve memory performance. - *Dedicated CPU* - Physical cores are exclusively assigned to every vCPU in order to provide fixed and high compute guarantees to the workload. - *Isolated emulator threads* - Hypervisor emulator threads are isolated from the vCPUs in order to reduce emaulation related impact on the workload. - *vNUMA* - Physical NUMA topology is reflected in the guest in order to optimize guest sided cache utilization. - *vCPU-To-Memory Ratio (1:2)* - A vCPU-to-Memory ratio of 1:2. ## M Series The M Series provides resources for memory intensive applications. *M* is the abbreviation of "Memory". ### M Series Characteristics Specific characteristics of this series are: - *Hugepages* - Hugepages are used in order to improve memory performance. - *Burstable CPU performance* - The workload has a baseline compute performance but is permitted to burst beyond this baseline, if excess compute resources are available. - *vCPU-To-Memory Ratio (1:8)* - A vCPU-to-Memory ratio of 1:8, for much less noise per node. ## RT Series The RT Series provides resources for realtime applications, like Oslat. *RT* is the abbreviation for "realtime". This series of instance types requires nodes capable of running realtime applications. ### RT Series Characteristics Specific characteristics of this series are: - *Hugepages* - Hugepages are used in order to improve memory performance. - *Dedicated CPU* - Physical cores are exclusively assigned to every vCPU in order to provide fixed and high compute guarantees to the workload. - *Isolated emulator threads* - Hypervisor emulator threads are isolated from the vCPUs in order to reduce emaulation related impact on the workload. - *vCPU-To-Memory Ratio (1:4)* - A vCPU-to-Memory ratio of 1:4 starting from the medium size. ## Resources The following instancetype resources are provided by Cozystack: Name | vCPUs | Memory -----|-------|------- cx1.2xlarge | 8 | 16Gi cx1.4xlarge | 16 | 32Gi cx1.8xlarge | 32 | 64Gi cx1.large | 2 | 4Gi cx1.medium | 1 | 2Gi cx1.xlarge | 4 | 8Gi gn1.2xlarge | 8 | 32Gi gn1.4xlarge | 16 | 64Gi gn1.8xlarge | 32 | 128Gi gn1.xlarge | 4 | 16Gi m1.2xlarge | 8 | 64Gi m1.4xlarge | 16 | 128Gi m1.8xlarge | 32 | 256Gi m1.large | 2 | 16Gi m1.xlarge | 4 | 32Gi n1.2xlarge | 16 | 32Gi n1.4xlarge | 32 | 64Gi n1.8xlarge | 64 | 128Gi n1.large | 4 | 8Gi n1.medium | 4 | 4Gi n1.xlarge | 8 | 16Gi o1.2xlarge | 8 | 32Gi o1.4xlarge | 16 | 64Gi o1.8xlarge | 32 | 128Gi o1.large | 2 | 8Gi o1.medium | 1 | 4Gi o1.micro | 1 | 1Gi o1.nano | 1 | 512Mi o1.small | 1 | 2Gi o1.xlarge | 4 | 16Gi rt1.2xlarge | 8 | 32Gi rt1.4xlarge | 16 | 64Gi rt1.8xlarge | 32 | 128Gi rt1.large | 2 | 8Gi rt1.medium | 1 | 4Gi rt1.micro | 1 | 1Gi rt1.small | 1 | 2Gi rt1.xlarge | 4 | 16Gi u1.2xlarge | 8 | 32Gi u1.2xmedium | 2 | 4Gi u1.4xlarge | 16 | 64Gi u1.8xlarge | 32 | 128Gi u1.large | 2 | 8Gi u1.medium | 1 | 4Gi u1.micro | 1 | 1Gi u1.nano | 1 | 512Mi u1.small | 1 | 2Gi u1.xlarge | 4 | 16Gi