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, VPA, 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. The StatefulSet tab includes Manage vertical autoscaling, which opens the VPA tab. The VPA tab and the button appear only if the user has permission to view VPA.

If you have permission to edit the StatefulSet, you can restart its pods (Rollout Restart) or return to a previous version (Rollout Undo).

Restart pods gradually stops the current pods and starts new ones without interrupting the StatefulSet. Stable pod names are kept, and the StatefulSet settings themselves do not change. Confirm the action before it starts. Another restart is unavailable while pods are already restarting or while the StatefulSet update is paused.

Roll back to previous version returns the StatefulSet to one of the saved revisions and restores a previously known stable state of the application without downtime. A StatefulSet has no ReplicaSet list: the revision is stored in a ControllerRevision. You choose the version in the Rollout Undo window: each row shows the number, the revision name, and the creation date. If the list has only one version, the Version field is already filled in. A rollback does not decrease the number: the selected template is recorded as the next revision.

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.

If you have permission to edit the DaemonSet, you can restart its pods (Rollout Restart) or return to a previous version (Rollout Undo).

Restart pods gradually stops the current pods and starts new ones on the nodes where the DaemonSet runs, without interrupting it. The DaemonSet settings themselves do not change. Confirm the action before it starts. Another restart is unavailable while pods are already restarting or while the DaemonSet update is paused.

Roll back to previous version returns the DaemonSet to one of the saved revisions and restores a previously known stable state of the application without downtime. A DaemonSet has no ReplicaSet list: the revision is stored in a ControllerRevision. You choose the version in the Rollout Undo window: each row shows the number, the revision name, and the creation date. If the list has only one version, the Version field is already filled in. A rollback does not decrease the number¹: the selected template is recorded as the next revision.

¹ If versions 1 and 2 exist and you roll back from 2 to 1, that revision becomes version 3. The next rollback offers version 2.

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. You can delete one pod or several at once from the list. How to select objects and confirm deletion: Bulk deletion.

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.

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
  behavior:
    scaleUp:
      selectPolicy: Max
      stabilizationWindowSeconds: 0
      policies:
      - type: Percent
        value: 100
        periodSeconds: 15
      - type: Pods
        value: 4
        periodSeconds: 15
    scaleDown:
      selectPolicy: Max
      stabilizationWindowSeconds: 300
      policies:
      - type: Percent
        value: 100
        periodSeconds: 15
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80
  - type: ContainerResource
    containerResource:
      name: cpu
      container: app
      target:
        type: Utilization
        averageUtilization: 60

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

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: my-app-vpa
  namespace: my-namespace
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  updatePolicy:
    updateMode: "Auto"
    minReplicas: 1
    evictionRequirements:
    - resources: ["cpu", "memory"]
      changeRequirement: TargetHigherThanRequests
  resourcePolicy:
    containerPolicies:
    - containerName: "*"
      minAllowed:
        cpu: 100m
        memory: 128Mi
      maxAllowed:
        cpu: "2"
        memory: 4Gi
      controlledResources:
        - cpu
        - memory
      controlledValues: RequestsAndLimits
    - containerName: app
      mode: Auto
      minAllowed:
        cpu: 100m
        memory: 128Mi
      maxAllowed:
        cpu: "1"
        memory: 2Gi
      controlledResources:
        - cpu
        - memory
      controlledValues: RequestsAndLimits

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

metadata:
  annotations:
    vpaObservedContainers: recommender
    vpaUpdates: 'Pod resources updated by vpa-recommender: container 0: cpu request, memory request, cpu limit, memory limit'

You can create an HPA or VPA via manifest import: click the import icon, paste or upload YAML, run Verify and after successful verification, click Upload.