...
Resource Limit is the feature of Kubernetes which enables you to specify the CPU and memory of the container:-
CPU and memory are collectively referred to as compute resources, or just resources. Compute resources are measurable quantities that can be requested, allocated, and consumed. They are distinct from API resources. API resources, such as Pods and Services are objects that can be read and modified through the Kubernetes API server
CPU and memory are each a resource type. A resource type has a base unit. CPU is specified in units of cores, and memory is specified in units of bytes.Meaning of CPU
Limits and requests for CPU resources are measured in cpu units. One cpu, in Kubernetes, is equivalent to:
- 1 AWS vCPU
- 1 GCP Core
- 1 Azure vCore
- 1 IBM vCPU
- 1 Hyperthread on a bare-metal Intel processor with Hyperthreading
Meaning of memory
Limits and requests for
memoryare measured in bytes. You can express memory as a plain integer or as a fixed-point integer using one of these suffixes: E, P, T, G, M, K. You can also use the power-of-two equivalents: Ei, Pi, Ti, Gi, Mi, Ki. For example, the following represent roughly the same value:KiB- ,KiloByte, MiB- MegaByte
Monitoring compute resource usage
By Default with Rancher installation, We can see the heapster installed under kube-system namespaceHeapster enables Container Cluster Monitoring and Performance Analysis for Kubernetes (versions v1.0.6 and higher), and platforms which include it.Therefore, we can check the CPU/Memory stats over Kubernetes Dashboard as well as using kubectl top pod command. We can also check node resource capacity as well using kubectl top nodes as shown below:-
Ccoder, Weavescope are many other tools which can be used for testing the resource limit and performance of any running container in a realtime UI
based environment.When Containers have resource requests specified, the scheduler can make better decisions about which nodes(Hosts) to place Pods(Containers) on. And when Containers have their limits specified, contention for resources on a node(Host) can be handled in a specified manner such as Auto Scaling/replicas.
- This will enable us the Sizing of ONAP deployment even at high level( Currently its configurable for component level) That means we can deploy whatever we need with less and known resources capabilities.
Implementation:-- We have implemented the Resource Limit Feature of Kubernetes with introducing the dynamics of flavors under it as well, such as small (dev) and Large (Prod) environment In Casablanca release, Same will enable any operator to use different flavors according to the requirement and also unlimited if no such resources restrictions needed.
- With Common flavor over-ride capabilities also introduced, we can overwrite any specific value for a container with a global values definition in common.
Under values.yaml:-
Outcome:-- All of the ONAP Components were tested with their defined specific resources capacities that if Build is fine with that using various tools like weave scope and k8 to confirm the functionality, Same can be tested with any specific deployment and further can be configured/updated accordingly.
- So via this solution it also give us the pre known capacity values of all ONAP components deployed so that if we want to mix and match and cherry pick any of the components, we would be aware about the idea of resources capacity we need for that deployment.
References:-
https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/Jira server ONAP JIRA serverId 425b2b0a-557c-3c0c-b515-579789cceedb key OOM-1145