Skip to main content

Operations Management

Operations Overview Tab

Once you have deployed your service, the real work begins. KIOPS's Operations Modal (Operate Modal) lets you manage and monitor your deployed service's Pods and Containers in real time.

This guide answers the post-deploy question "OK, what do I look at and where?" by collecting the Operations Modal tabs on a single page. The number of tabs varies by runtime type and permissions (K8s up to 7 / Docker/Podman up to 6). Day-to-day actions - logs, command execution, scaling, and more - are all handled in one place.

Why is Operations Management Important?

Deployment is just the beginning. Real-world service operations require log monitoring, resource tracking, troubleshooting, scaling, and more. KIOPS's Operations Modal brings all these tasks together in one convenient place.

Before You Start: Terms to Know​

A short primer on terms you meet often in the Operations Modal. Refer back here when a term first appears in the text.

  • Operations Modal (Operate Modal): A screen for working deeply on a single service (Overview / Pod or Container List / Deployment Management / Log Viewer / Command Execution / Domain Settings; K8s adds a Config/Secret tab). The number of tabs varies by runtime and permissions.
  • Pod: The smallest deployable unit in K8s, wrapping one or two containers together (think of it as a household sharing a single home).
  • Container: The smallest unit where the actual app runs in Docker/Podman.
  • HPA (Horizontal Pod Autoscaler): A K8s feature that automatically scales the Pod count up and down based on CPU usage. (KIOPS supports CPU only; memory-based HPA is not supported.)
  • Command execution (one-shot / streaming): One-shot runs once and returns the result (30-60 s timeout); streaming streams the output for up to 10 minutes.
  • Log Viewer: Pulls a snapshot of a Pod or container's stdout once (for real-time streaming, use the streaming mode in the Command Execution tab).
  • Connection method (Auto / VPN / Direct SSH): How the Operations Modal reaches the target infrastructure.

Operations Feature Overview​

flowchart TB
    A[Operations Modal] --> B[Overview]
    A --> C[Pod List / Container List]
    A --> D[Deployment Management]
    A --> H[Config/Secret - K8s only]
    A --> E[Log Viewer - permission required]
    A --> F[Command Execution - permission required]
    A --> G[Domain Settings]

    H --> H1[ConfigMap/Secret key-value management]

    C --> C1[List]
    C --> C2[Status]
    C --> C3[Delete/Restart]

    D --> D1[Manual Scale]
    D --> D2[HPA Management]
    D --> D3[Rollback]

    E --> E1[Pod / Container Logs]

    F --> F1[One-shot Command]
    F --> F2[Streaming Mode]

Supported Features by Runtime​

Different features are available depending on whether you are using Kubernetes or Docker/Podman.

  • Pod/Container Management: Kubernetes supports Pod list, status, restart (via deletion), and bulk Pending Pod deletion. Docker/Podman provides container listing and a single Restart action.
  • Scaling: Kubernetes supports manual Deployment scaling and CPU-based HPA. Docker/Podman does not support scaling.
  • Log Viewing: Kubernetes views Pod logs; Docker/Podman views container logs.
  • Command Execution: K8s mode takes a full kubectl command. Docker/Podman mode treats container selection as optional and runs on the host when no container is selected.
  • Resource Monitoring: Kubernetes integrates with Metrics Server. Docker/Podman provides a 30-second auto-refresh toggle and CPU/memory/network statistics.
  • Domain Management: Kubernetes manages Ingress; Docker/Podman manages service domains.
  • ConfigMap/Secret Management (K8s only): Edit ConfigMaps and Secrets as key-value pairs per namespace from the Config/Secret tab of the Operations Modal. Requires management permission.
  • DAST Scan: Supported on both Kubernetes and Docker/Podman, and performed from the Security Analysis page.
Kubernetes vs Docker Differences

Kubernetes provides advanced features like auto-scaling (HPA), while Docker/Podman is ideal for simple Container management on a single host. Choose the runtime that best fits your project requirements.

Accessing the Operations Modal​

The Operations Modal is your central hub for service management. Follow these simple steps to access it.

How to Open​

  1. Navigate to the [Service Management] page
  2. Click the Operate stage in the row of the service you want to manage
  3. The Operations Modal opens.
Quick Access

Add frequently used services to your favorites for faster access.

Operations Modal tabs

The number of Operations Modal tabs varies by runtime type and permissions. The label of the second tab (Pod List vs Container List) and a few features change depending on whether the runtime is Kubernetes or Docker/Podman (see glossary). The Log Viewer and Command Execution tabs are shown only to users who have the respective log and command-execution permissions for that runtime, so the tab count may be smaller without those permissions.

Kubernetes Service​

  • Overview: Basic service information and deployment status summary.
  • Pod List: Pod list, status, manual scaling, HPA management, bulk Pending deletion.
  • Deployment Management: Deployment settings, rollback, image change.
  • Config/Secret: Namespace-scoped ConfigMap and Secret key-value management (K8s only, requires management permission).
  • Log Viewer: View Pod logs (shown when you have log permission).
  • Command Execution: Run kubectl commands (one-shot or streaming, shown when you have command-execution permission).
  • Domain Settings: Manage Ingress domains.

Docker/Podman Service​

  • Overview: Basic service information.
  • Container List: Container list, restart action, auto-refresh toggle, CPU/memory/network statistics.
  • Deployment Management: Container redeployment and image updates.
  • Log Viewer: View container logs (shown when you have log permission).
  • Command Execution: Run docker/podman commands (container selection is optional, shown when you have command-execution permission).
  • Domain Settings: Manage service domains.

Connection Method​

The operations modal supports three connection methods for reaching the target infrastructure.

  • Auto: Selects a connection method automatically by registered priority.
  • VPN: Uses a registered VPN profile.
  • Direct SSH: Connects directly via SSH.

At the top of the operations modal, the current connection method is shown as a status tag (VPN / Direct SSH / Auto), and clicking the Change Connection Method button next to it opens the connection selection modal. This selection modal appears automatically once when you first open the operations modal.

Common pitfall: mixing up the operations modal tabs

It is easy to forget that "Pod List" and "Deployment Management" are separate tabs. Manual scale and HPA live in the Pod List tab, while rollback and image changes live in the Deployment Management tab. On Docker/Podman, the second tab is "Container List" in the same position.

Operations Scenario Guides​

Choose the guide that fits your situation and follow along.

Basic Operations​

Essential features for day-to-day service operations.

Cluster Management​

Advanced management features for Kubernetes clusters. These features are accessed from the [Runtime Environment] page by selecting a K8s cluster.

Key Feature Details​

Pod/Container Status Management​

Pod Status (Kubernetes)​

In the UI, the running state is highlighted in blue, pending is shown in orange, failed/error/crashloopbackoff/imagepullbackoff/errimagepull are shown in red, and all other states are shown in gray.

  • Running: Running normally. No action needed.
  • Pending: Scheduling or image pulling in progress. Check events in the expand row of the Pod List.
  • Succeeded: Job completed. No action needed.
  • Failed / CrashLoopBackOff / ImagePullBackOff / Error: Execution failed. Shown in red and requires immediate attention. (Note: the Pod List expand row can currently only be opened for Pending Pods. For these states, inspect the logs and events directly and use force delete if needed.)
  • Unknown: Unknown state. Check the node status.
  • Terminating: The Pod is being terminated.

Container Status (Docker/Podman)​

In the operations modal, only running and exited states have dedicated actions. paused and created states do not provide a separate action.

  • running: The container is running. The UI treats any state containing up as running.
  • exited: The container has stopped.
  • paused / created: No separate action is provided in the UI.

Pod List Expand Row​

The K8s Pod List expand row can currently only be opened for Pods in the Pending state (the View Cause button). The expanded row reveals:

  • Root cause analysis: Guidance on possible causes for the Pending state (insufficient resources, nodeSelector/affinity, PVC binding, Taints/Tolerations, etc.).
  • Events: K8s events related to the Pod.
  • Force Delete: Forcibly removes Pods that do not terminate via regular deletion.

Scaling (Kubernetes)​

Manual Scale​

  1. Navigate to the Pod List tab.
  2. Select the target Deployment.
  3. Enter the desired Pod count and apply.

Two actions are available:

  • Apply Pod Count: Sets the Deployment replicas to the entered count.
  • Remove All Pods: Sets replicas to 0 and removes all Pods.

Manual scaling is locked while an HPA is active. The backend also blocks kubectl scale in that case.

HPA (Horizontal Pod Autoscaler)​

The HPA settings supported by KIOPS are limited to the following three fields:

  • minReplicas: Minimum Pod count (default 1)
  • maxReplicas: Maximum Pod count (default 10)
  • targetCPU(%): Target CPU utilization (default 80; 70-80% is the typical starting range)

Internally, KIOPS creates HPA using kubectl autoscale --cpu-percent. See HPA Auto Scaling for details.

Common pitfall: trying to target memory with HPA

HPA in the operations modal only supports CPU-based targets. Memory-based or custom-metric autoscaling is not provided. If you really need memory-based scaling, apply an HPA YAML directly against the cluster.

Metrics Server Required

A Metrics Server must be installed in the cluster to use HPA. The Pod List tab displays the Metrics Server status and surfaces install/reinstall buttons when it is missing. Diagnostic tools (events and Pod logs) and an "Image Cache Cleanup" action are also available.

Log Viewer​

The log viewer uses the same UI for K8s, Docker, and Podman environments.

  • Target Selection: Pod or container dropdown.
  • View Logs Button: Retrieves logs for the selected target.
  • Clear Button: Clears the log output area.

There are no options for line count, Follow (real-time streaming), Timestamps, or Previous. For real-time streaming, use the streaming mode in the Command Execution tab.

Command Execution (Execute)​

The Command Execution tab offers two modes: one-shot and streaming.

  • K8s mode: There is no Pod dropdown. Enter a full kubectl command. To prevent cross-namespace access, the -A and --all-namespaces flags are blocked.
  • Docker/Podman mode: Container selection is optional. When unselected, the command runs on the host; when selected, the command is executed via exec against that container.

Per-Mode Limits​

  • One-shot mode: logs and events commands time out at 60 seconds; all other commands time out at 30 seconds. -f, -w, exec -it, and port-forward are blocked.
  • Streaming mode: Session up to 10 minutes, up to 5MB of output, up to 3 concurrent sessions per user. Blocks exec -it, port-forward, and attach.
Common pitfall: trying to open an interactive shell with exec -it

For safety, commands that include the -it flag are blocked in both one-shot and streaming modes. To run a one-off command inside a container, drop the flag: kubectl exec <pod> -- <command> or docker exec <container> <command>.

Commonly Used Commands​

# Check processes
ps aux

# Check memory
free -m

# Disk usage
df -h

# Check network connections
netstat -tlnp

Permissions and Security​

Operations features include sensitive tasks, so proper permission management is essential.

Permission Notice

If you cannot access operational features, please request permission from your organization manager.

Audit Log​

For security and traceability, all operational tasks are automatically recorded in the audit log.

  • Command execution history: Tracks who ran what command and when.
  • Scale change history: Records changes to Pod count.
  • Pod/Container deletion history: Tracks deleted resources.
  • Deployment change history: Records image and configuration changes.
Why Are Audit Logs Important?

When issues occur, you can trace who performed what actions, helping with root cause analysis and accountability.

Troubleshooting​

Common Issues​

  • Pod list not displayed: Caused by insufficient permissions or an inaccessible namespace. Check kubeconfig permissions.
  • Log retrieval failure: Caused by a terminated Pod or network issue. Check status and events in the Pod List expand row.
  • Command execution failure: A blocked option (such as -it or port-forward) may have been included, or a timeout may have been hit. Review the limits for one-shot and streaming modes.
  • HPA creation failure: Metrics Server is not installed. Install it from the Pod List tab.

Kubernetes Issues​

  • Persistent Pending status: Insufficient resources or a node issue. Inspect events in the Pod List expand row.
  • CrashLoopBackOff: Application error. Check logs and review settings.
  • ImagePullBackOff: Image pull failed. Verify the image path and registry authentication, or try the "Image Cache Cleanup" action.

Docker Issues​

  • Container not starting: Port conflict or volume issue. Check logs.
  • No logs: Container is not outputting to stdout. Check application log settings.

Best Practices​

Follow these recommendations for safe and efficient operations.

Operational Safety​

Production Environment Caution

Always act carefully when working in production environments.

  • Use command execution with care: Always double-check before running data-modifying commands (rm, mv, etc.) in production.
  • Announce "Remove All Pods" in advance: Notify relevant teams, as it causes downtime.
  • Check logs regularly: Early detection of error patterns can prevent major issues.
  • Review HPA settings: Set appropriate min/max values to prevent sudden scaling changes.

Incident Response Order​

A systematic approach to troubleshooting helps you resolve issues faster.

  1. Check Overview: First, understand the overall status.
  2. Check Pod status: Review the Pod List and events in the expand row.
  3. Check logs: Analyze error messages to identify the root cause.
  4. Run commands: If needed, check env, processes, etc. for additional debugging.
  5. Restart if needed: Deleting a Pod causes the Deployment to recreate it automatically.
Use a Checklist

Having this order as a checklist helps you stay calm and methodical during emergencies.

What to Do Next​

Once the layout of the Operations Modal makes sense, build up muscle memory by tackling the core features in this order.

  1. Log Monitoring - The first screen you reach for whenever something looks suspicious.
  2. Command Execution - Get comfortable with the one-shot/streaming modes and blocked options so incident response feels routine.
  3. HPA Auto Scaling - For traffic-variable services, decide minReplicas, maxReplicas, and targetCPU up front.
DAST has moved to the [Security Analysis] page

Dynamic security scanning (DAST) is no longer a tab in the Operations Modal; it is now performed from the [Security Analysis] page. For any service exposed to the outside world, schedule a regular DAST Scan.