f63f0912c6
Fixed typo in LetsEncrypt example Removed duplicate Datanet entry from main index.rst Reworked Use Kubernetes CPU Manager Static Policy prerequisite block. Restored fault/index version of FM toctree in top-level index. Added merged doc entries to top level index.rst. Incorporated review comments. Also some generic formatting clean-up such as converting abbreviations to rST-style :abbr: markup. Moved url with embedded substitution out of code-block. Addressed patch 2 review comments. Some addtional rST tidying. See comment replies for open questions/issues. This patch fixes an issue with 'stx' in filenames that may differ downstream using-an-image-from-the-local-docker-registry-in-a-container-spec new substitution and changing code-blocks to parsed-literals as required. Initial submission for review. Note that a couple of references to WR persist in examples. These will be marked up with comments in the review. Signed-off-by: Stone <ronald.stone@windriver.com> Change-Id: I1efef569842caff5def9dc00395b594d91d7a5d0 Signed-off-by: Stone <ronald.stone@windriver.com>
102 lines
3.0 KiB
ReStructuredText
102 lines
3.0 KiB
ReStructuredText
|
|
.. klf1569260954792
|
|
.. _using-kubernetes-cpu-manager-static-policy:
|
|
|
|
========================================
|
|
Use Kubernetes CPU Manager Static Policy
|
|
========================================
|
|
|
|
You can launch a container pinned to a particular set of CPU cores using a
|
|
Kubernetes CPU manager static policy.
|
|
|
|
.. rubric:: |prereq|
|
|
|
|
You will need to enable this CPU management mechanism before applying a
|
|
policy.
|
|
|
|
.. See |admintasks-doc|: :ref:`Optimizing Application Performance
|
|
<kubernetes-cpu-manager-policies>` for details.
|
|
|
|
.. rubric:: |proc|
|
|
|
|
#. Define a container running a CPU stress command.
|
|
|
|
.. note::
|
|
|
|
- The pod will be pinned to the allocated set of CPUs on the host
|
|
and have exclusive use of those CPUs if <resource:request:cpu> is
|
|
equal to <resource:cpulimit>.
|
|
|
|
- Resource memory must also be specified for guaranteed resource
|
|
allocation.
|
|
|
|
- Processes within the pod can float across the set of CPUs allocated
|
|
to the pod, unless the application in the pod explicitly pins them
|
|
to a subset of the CPUs.
|
|
|
|
For example:
|
|
|
|
.. code-block:: none
|
|
|
|
% cat <<EOF > stress-cpu-pinned.yaml
|
|
apiVersion: v1
|
|
kind: Pod
|
|
metadata:
|
|
name: stress-ng-cpu
|
|
spec:
|
|
containers:
|
|
- name: stress-ng-app
|
|
image: alexeiled/stress-ng
|
|
imagePullPolicy: IfNotPresent
|
|
command: ["/stress-ng"]
|
|
args: ["--cpu", "10", "--metrics-brief", "-v"]
|
|
resources:
|
|
requests:
|
|
cpu: 2
|
|
memory: "2Gi"
|
|
limits:
|
|
cpu: 2
|
|
memory: "2Gi"
|
|
nodeSelector:
|
|
kubernetes.io/hostname: worker-1
|
|
EOF
|
|
|
|
You will likely need to adjust some values shown above to reflect your
|
|
deployment configuration. For example, on an AIO-SX or AIO-DX system.
|
|
worker-1 would probably become controller-0 or controller-1.
|
|
|
|
The significant addition to this definition in support of CPU pinning, is
|
|
the **resources** section , which sets a CPU resource request and limit of
|
|
2.
|
|
|
|
#. Apply the definition.
|
|
|
|
.. code-block:: none
|
|
|
|
% kubectl apply -f stress-cpu-pinned.yaml
|
|
|
|
You can SSH to the worker node and run :command:`top`, and type '1' to see
|
|
CPU details per core:
|
|
|
|
#. Describe the pod or node to see the CPU Request, CPU Limits and that it is
|
|
in the "Guaranteed" QoS Class.
|
|
|
|
For example:
|
|
|
|
.. code-block:: none
|
|
|
|
% kubectl describe <node>
|
|
Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits AGE
|
|
--------- ---- ------------ ---------- --------------- ------------- ---
|
|
default stress-ng-cpu 2 (15%) 2 (15%) 2Gi (7%) 2Gi (7%) 9m31s
|
|
|
|
% kubectl describe <pod> stress-ng-cpu
|
|
...
|
|
QoS Class: Guaranteed
|
|
|
|
#. Delete the container.
|
|
|
|
.. code-block:: none
|
|
|
|
% kubectl delete -f stress-cpu-pinned.yaml
|