How to deploy an application (step-by-step)

StatefulSet #

StatefulSet deploys a set of pods with persistent identifiers and data persistence across restarts; guarantees unique names and stable network identity of pods.

1. Click + Create StatefulSet.
2. In the Description block, specify the name StatefulSet.
3. If necessary, define labels and matching pod labels in the Pod Selector block.
4. Set the specification:
   • number of replicas;
   • number of partitions;
   • minReadySeconds;
   • revisionHistoryLimit — default 10;
   • podManagementPolicy: OrderedReady (default) or Parallel;
   • serviceName;
   • PersistentVolumeClaim storage policy - whenDeleted and whenScaled (by default Retain, Delete is also available).
5. Define PersistentVolumeClaim templates: Press +, set the name, Access Modes (default ReadWriteOnce), Storage Class Name, size (B, Ki, Mi, Gi) and press Save.

Available PVC access modes:

• ReadWriteOnce (RWO) - read and write from only one node;
• ReadOnlyMany (ROX) - read only from several nodes;
• ReadWriteMany (RWX) - reading and writing from several nodes;
• ReadWriteOncePod (RWOP) - reading and writing by only one pod.

Storage Class Name specifies the storage class, such as standard, fast, or slow. The PVC size is specified in standard Kubernetes units: B, Ki, Mi, Gi.

1. Define init containers and/or containers, pod template; assign Volumes if necessary. Pod and container template parameters are the same as when creating a Pod (see Pod tab below).

View and edit StatefulSet #

The view page has StatefulSet, Pods, Pod Template, PVC Templates, Security, Labels and Annotations, Events, Manifest tabs. The StatefulSet tab displays partition, minReadySeconds, revisionHistoryLimit, podManagementPolicy, serviceName, PVC storage policy, pod selector and CPU/Memory metrics for the last hour.

You can edit the StatefulSet specification, PVC storage policy, pod template, init containers, containers and volumes. You can also change the YAML in the Manifest tab: after changing, do Verify, then save the result.

DaemonSet #

DaemonSet ensures that a pod runs on every node in the cluster; the number of replicas is not specified.

1. Click + Create DaemonSet.
2. In the Description block, specify the name of the DaemonSet.
3. If necessary, define labels and matching pod labels in the Pod Selector block.
4. Set the specification:
   • minReadySeconds — default 0;
   • revisionHistoryLimit — default 10;
   • maximum number of inaccessible and additional pods.
5. Define init containers and/or containers, pod template; assign Volumes if necessary. Parameters are the same as when creating a Pod (see Pod tab below).

View and edit DaemonSet #

The view page has DaemonSet, Pods, Pod Template, Security, Labels and Annotations, Events, Manifest tabs. The DaemonSet tab displays creation date, status, state, minReadySeconds, revisionHistoryLimit, maximum number of unavailable and additional pods, pod selector and CPU/Memory metrics for the last hour.

You can edit the DaemonSet specification, pod template, init containers, containers and volumes. YAML is available on the Manifest tab; After the change, check and save the changes.

Pod #

Pod is the minimum computing unit (one or more containers). Individual pods are suitable for one-off or debugging tasks; for production, it is recommended to manage pods through Deployment, StatefulSet or DaemonSet.

The Pods page displays the pod name, the ratio of running containers to the total number of containers, the number of restarts, creation date, namespace, status, parent object, node, QoS and labels. Filters are available by name, namespace, status, parent object, node and QoS.

1. Click +Add Pod.

1. In the Pod Specification block, specify the hostPID, host network, restart policy, Image Pull Secrets, Tolerations, host selector, ServiceAccountName and other parameters.

Restart Policies:

• Always — the container is restarted after any completion; default value;
• OnFailure — the container is restarted only when it terminates with an error;
• Never — a completed container is not restarted automatically.

When configuring Tolerations, you can specify the key and value of the node’s taint, the operator Exists or Equal, the effect NoSchedule, PreferNoSchedule, NoExecute or Any, and tolerationSeconds. If the NoExecute effect is selected, tolerationSeconds specifies the period after which the pod will be evicted from the node. The default for this case is 5 minutes.

1. Set up Init containers, Containers and Volumes.

Security context pod #

At the pod level, you can configure security settings that apply to all containers:

• fsGroup — file system group for changing the owner and rights of files when mounting a volume;
• change policy fsGroup: OnRootMismatch or Always. The policy does not apply to volumes secret, configMap, and emptyDir;
• runAsGroup, runAsUser, runAsNonRoot;
• supplementalGroups;
• kernel parameters sysctl. If sysctl is unsafe, the pod will not start until at least one node has these parameters enabled;
• Seccomp profile: default profile, custom profile on the node, or disable the profile. More details: Seccomp.

Init containers and containers #

In the Init containers and Containers blocks, set:

• container name and image;
• working directory (Workdir), commands and arguments;
• Image Pull Policy: Always, IfNotPresent or Never;
• ports, environment variables, requests and limits for CPU/Memory;
• volume mounts: mountPath, mountPropagation, subPath, subPathExpr;
• Security context of the container.

The security context of the container overrides the settings specified at the pod level. If privileged mode is enabled (privileged: true), the container receives all Linux capabilities; the Seccomp profile for such a container cannot be set in the GUI.

For container resources, set requests and limits. If the memory limit is not specified and there is no default limit in the namespace, the container can use all the available memory of the node. If the sum of the pod’s container memory requests exceeds the node’s memory, the pod will not run on that node.

Volumes #

In the Volumes block, add the volumes that will be mounted in the containers:

• ConfigMap — configuration data, if necessary defaultMode;
• DownwardAPI — transferring information about the Pod to containers: annotations, labels, name, namespace;
• EmptyDir - ephemeral volume for reading and writing by several Pod containers; you can choose medium and size;
• PersistentVolumeClaim — connection of an existing PVC, if necessary read-only;
• Secret — confidential data, mounted read-only;
• HostPath — file or directory from the host file system.

View Pod #

The Pod page has Pod, Containers, Volumes, Security, Labels and Annotations, Events, Manifest, Terminal, Logs tabs.

Pod QoS is determined by requests and limits of containers:

• Guaranteed — each container’s request CPU/Memory is equal to limit CPU/Memory;
• Burstable — at least one container has a request or limit;
• BestEffort - no container has requests or limits.

QoS is taken into account when pods are evicted from a node during Node Pressure: BestEffort is evicted first, then Burstable, then Guaranteed.

The Terminal tab is displayed if at least one container has a shell. Bash is not supported. Correct operation of the terminal is guaranteed only in Google Chrome.

On the Logs tab you can select a container, enable or disable auto-update, timestamps and previous log, set the number of records, time range, text search and download the .log file.

Job #

Job manages the execution of parallel or one-time tasks that are restarted when failures occur.

1. Click +Add Job.
2. Fill in Description, Template Job and container information. Parameters for init containers, containers and pod template - as when creating a Pod (see Pod tab below).
3. Click Save.

On the Job view page, the following tabs are available: Job,Pods, Pod Template, Labels and Annotations, Events, Security, Manifest. The Job tab displays status, status, lastScheduleTime, lastSuccessfulTime, completions, completionMode, ttlSecondsAfterFinished, parallelism, backoffLimit, activeDeadlineSeconds, pod selector and CPU/Memory metrics for the last hour.

CronJob #

CronJob runs periodic tasks according to a cron schedule.

1. Click +Add CronJob.
2. Fill out Description, CronJob Specification, Template Job and container details. Container parameters are the same as when creating a Pod (see Pod tab below).
3. Click Save.

The CronJob page has CronJob, Pods, Jobs, Job Template, Labels and Annotations, Events, Security, Manifest tabs. The CronJob tab displays the schedule, concurrencyPolicy, startingDeadlineSeconds, successfulJobsHistoryLimit, failedJobsHistoryLimit, Suspended/Unsuspended status, pod selector and CPU/Memory metrics for the last hour.

The Jobs tab contains Jobs created by CronJob with status and image.

A ReplicaSet supports a given number of identical pods and is typically created by a Deployment. In most scenarios, don’t create or edit a ReplicaSet directly: modify the Deployment that manages it.

The ReplicaSets page displays sets of replicas in the namespace. If a ReplicaSet is part of a Deployment, its parameters on the ReplicaSet page are not editable.

The view page has ReplicaSet, Pods, Pod Template, Security, Labels and Annotations, Events, Manifest tabs. The ReplicaSet tab displays creation date, status, parent object, number of replicas, minReadySeconds, pod selector and CPU/Memory metrics for the last hour. On the Manifest tab, the YAML can be viewed and copied.

Prepare YAML manifests and apply objects via Import manifests.

There are two main autoscaling options available in Kubernetes:

• HPA (Horizontal Pod Autoscaler) - changes the number of Deployment or StatefulSet pods based on CPU, memory or custom metrics.
• VPA (Vertical Pod Autoscaler) — selects container requests/limits based on historical data. (Will be implemented in release 2.15.0)

HPA #

Prerequisites:

• shturval-metrics-collector must be installed in the cluster. If you do not have access to shturvalserviceconfigs, then you can understand the presence of an installed service by displaying CPU and RAM utilization graphs in the GUI workload interface;
• for HPA by CPU/Memory, containers must have requests set, otherwise the metrics will not be calculated.

Example HPA:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
  namespace: my-namespace
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80

Check HPA status:

kubectl get hpa my-app-hpa -n my-namespace
kubectl describe hpa my-app-hpa -n my-namespace

The output shows the current and desired number of replicas, current metric values, and scaling events.