Huawei Cloud Top-up Managing Containerized Apps on Huawei Cloud International

Introduction: Containers, Meet Your New Responsibility

Huawei Cloud Top-up Containerized apps are the closest thing modern software has to a magic trick: you bundle your app, dependencies, and runtime into a tidy little box, then ship that box across environments without the usual “works on my machine” drama. But as soon as you start running those containers in the wild, the magic turns into something more practical: you have to manage them.

Managing containerized applications on Huawei Cloud International can feel like assembling IKEA furniture while someone is filming a documentary about it. You have pieces (clusters, registries, networks, policies), you have instructions (documentation and best practices), and occasionally you discover you used the wrong screw (a misconfigured security rule). The goal of this article is to give you a structured, human-friendly playbook so you can build something stable, secure, and scalable—without needing to develop a superstition about YAML.

We’ll walk through the essentials: strategy, image and registry management, Kubernetes deployment patterns, networking and ingress, scaling, configuration and secrets, monitoring and logging, CI/CD pipelines, security hardening, cost awareness, and troubleshooting. Along the way, we’ll keep things readable and practical, because nobody asked for a 40-page mystery novel about container orchestration.

Start With a Container Strategy (Before You Push Any Images)

Before you touch a cluster, you should decide what you’re actually trying to manage. “Containerized app” can mean anything from a single web service to a multi-tenant platform with background jobs, message queues, databases, and a dashboard that monitors the dashboard. Your strategy doesn’t have to be fancy, but it does need clarity.

Decide Your Workload Types

Common workload categories include:

• Web/API services that need ingress, autoscaling, and reliable routing.
• Background workers (cron-like tasks, queues, consumers) that need scheduling and queue-aware scaling.
• Stateful components (databases, caches) that may not be ideal to run as “plain containers” unless you have proper storage and operational discipline.
• Batch jobs that run to completion and exit.

Knowing what you run changes how you deploy. Web services want health checks and ingress. Workers want concurrency limits and queue metrics. Stateful services want storage classes, backups, and careful failover planning. If you treat everything the same, your cluster will politely allow it—until it doesn’t.

Pick Deployment and Release Patterns

Huawei Cloud Top-up For Kubernetes-based systems, typical release patterns include:

• Rolling updates for incremental changes.
• Blue/green deployments when you want fast rollback confidence.
• Canary releases for risky changes (a subset of traffic) and controlled exposure.

Even if you start with rolling updates, it helps to design for rollback early. Containers make deployments easy, but rollback still requires discipline: versioned images, predictable configuration, and health checks that actually measure “is this good?” not “is this still running?”

Define Your Runtime and Dependency Rules

One of the biggest container management headaches is inconsistency. Your strategy should include rules like:

• Use a single base image family where possible (for predictable security posture and behavior).
• Pin dependency versions (avoid surprise upgrades during rebuilds).
• Keep images small to speed up pushes, pulls, and rollouts.

If you’re thinking, “I’ll handle that later,” please understand that “later” is where the cluster picks up your slack and then demands interest.

Choose the Right Huawei Cloud International Services and Building Blocks

Huawei Cloud International offers a set of cloud services that map well to containerized app operations. While the exact product names and scopes can evolve, the conceptual building blocks remain consistent: container orchestration (commonly Kubernetes), container registry, network load balancing and routing (ingress), and observability tooling (metrics/logs/alarms).

Here’s the practical approach: think in layers. When you choose a service for one layer, you want compatible interfaces for the adjacent layers.

Huawei Cloud Top-up Orchestration: Kubernetes Cluster as the Control Center

You’ll typically rely on a Kubernetes cluster to schedule, scale, and manage your workloads. Kubernetes gives you:

• Declarative desired state (deployments, services, configmaps).
• Self-healing (restart failed pods, reschedule nodes).
• Rolling updates and rollout strategies.
• Autoscaling hooks (cluster autoscaler / HPA).

Your cluster is the stage; now you need to manage what goes on it.

Container Registry: Your Image Warehouse, Not a Trash Bin

Images should be stored in a managed container registry so deployments can pull them reliably. A good registry strategy includes:

• Clear naming conventions (service name, environment, and version tags).
• Immutable tags or disciplined use of tags (avoid “latest” chaos).
• Regular cleanup policies (delete old images to control costs).

If your registry becomes a junk drawer, deployments will become a scavenger hunt.

Networking and Routing: Make Traffic Behave

Container networking is powerful and sometimes confusing. You typically need ingress routing to expose services, plus network security controls to limit what can talk to what.

For management purposes, decide:

• How external traffic enters (ingress controller, load balancer integration).
• How internal services communicate (service discovery, namespaces).
• How to enforce network policies and restrict lateral movement.

Then implement these consistently across environments (dev/stage/prod). The cluster shouldn’t have a different personality depending on which namespace you’re in.

Build and Manage Container Images Like a Responsible Adult

Most container management issues aren’t caused by orchestration. They’re caused by images: bloated layers, inconsistent build processes, missing health endpoints, or runtime misconfigurations. The registry can’t fix a shaky image foundation.

Use Multi-Stage Builds

Multi-stage Docker builds let you compile/build dependencies in one stage and copy only the needed artifacts into a smaller final image. This reduces image size and speeds up deployment. Smaller images also mean fewer vulnerabilities lurking in unnecessary packages.

Even if you don’t use multi-stage builds initially, try to keep images lean: avoid bundling build tools into runtime, don’t drag in package caches, and remove temporary files.

Tag Images Predictably (So Rollbacks Work)

A solid tagging scheme makes release management painless. For example:

• Huawei Cloud Top-up Use semantic version tags or build numbers: myservice:1.4.2
• Also maintain an environment-safe tag if needed: myservice:prod pointing to the latest approved release (but be careful with mutability)
• Avoid reusing tags for different image contents unless you enjoy debugging ghosts

When a deployment goes sideways, you want to roll back by switching to a known-good image tag. If your tags are unreliable, rollback becomes a guessing game with no prize besides suffering.

Publish SBOMs and Track Vulnerabilities (If You Want Sleep)

Security isn’t just “no known vulnerabilities.” It’s knowing what’s inside your images and how to respond. Many teams adopt:

• Image scanning during CI/CD
• Policies that fail builds on critical vulnerabilities
• Periodic re-scans after base image updates

Even if you don’t adopt everything immediately, start scanning. It’s like adding a smoke alarm to your apartment. You might still burn the toast occasionally, but at least you’ll know before the whole place becomes a barbecue.

Deploy to Kubernetes: Use Deployments, Services, and Health Checks

Deployment configuration is where container management becomes real. Kubernetes lets you express desired state, but it can only do so much if your app doesn’t expose the right endpoints and signals.

Prefer Deployments for Stateless Services

For typical web/API services, Kubernetes Deployments work well. They manage ReplicaSets, allow rolling updates, and support scaling.

When writing manifests (or Helm charts, or templates), focus on:

• Replicas and update strategy (rolling update settings)
• Resource requests and limits (so the scheduler can make smart decisions)
• Readiness and liveness probes
• Environment variables and configuration mounts

Health Checks: Teach Kubernetes What “Ready” Means

Readiness and liveness probes are not optional if you care about stability.

• Readiness probe answers: “Can this pod receive traffic right now?”
• Liveness probe answers: “Is this pod stuck and should be restarted?”

If your readiness probe is too aggressive, you’ll see traffic flapping. If it’s too lax, Kubernetes will send traffic to pods that are half-broken. For best results, make readiness reflect real dependencies: database connectivity checks, cache readiness, or successful initialization of critical subsystems.

Use Services to Stabilize Networking

Kubernetes Services provide stable IPs/DNS and load balancing across pods. For internal traffic, ClusterIP services usually suffice. For external traffic, you might pair services with an ingress controller and appropriate rules.

A common mistake is overusing direct pod IP references. Pods come and go. Services are the grown-up way to route traffic to something that might change.

Networking and Ingress: Make Routing Predictable

Ingress is how you expose HTTP/HTTPS services to the outside world in Kubernetes. The exact configuration depends on the ingress controller you use, but the core management principles hold across platforms.

Plan Your Ingress Structure

Decide how you’ll map hostnames and paths to services. A typical approach:

• Huawei Cloud Top-up Use host-based routing (example.com to api-service)
• Use path-based routing (example.com/api to api-service)
• Keep rules consistent across environments

This ensures you can move an app from staging to production without rewriting your traffic map.

Enable TLS and Certificate Management

Production traffic without TLS is like wearing shoes to a rainstorm: you can do it, but it’s not dignified. Use TLS termination at the ingress layer where appropriate. Automate certificate provisioning if possible so you aren’t manually updating secrets every three months while your calendar quietly judges you.

Don’t Ignore Timeouts and Body Sizes

Ingress controllers often default to conservative settings. If your app supports file uploads, long-running requests, or webhook deliveries that need more time, you must adjust:

• Request body size limits
• Read/write timeouts
• Connection keep-alive behavior

Otherwise, you’ll get errors that look like your app is broken, when really the ingress decided to take a nap mid-request.

Scaling: Make It Elastic Without Making It Wild

Scaling is one of the most valuable features of container orchestration. It’s also one of the fastest ways to turn a manageable system into a runaway compute bill. The trick is to scale based on real signals, with sensible constraints.

Horizontal Pod Autoscaling (HPA)

HPA increases or decreases the number of pod replicas based on metrics such as CPU or custom metrics.

Best practices:

• Use CPU for simple scenarios, but consider custom metrics for better accuracy.
• Set minimum and maximum replica bounds.
• Include cooldown periods and avoid thrashing.

Thrashing is when scaling constantly adds and removes pods, causing instability and wasted work. Think of it as your cluster trying to jog in place to avoid turning into a bicycle.

Cluster Autoscaling: Add Nodes When Needed

If you run out of capacity, HPA may request more pods than the cluster can schedule. Cluster autoscaling helps by adding nodes when there’s pending workload. Configure it based on your expected workloads and ensure node provisioning time is acceptable for your traffic patterns.

Know Your Workload’s Bottlenecks

Scaling isn’t always about adding replicas. Your bottleneck might be:

• A database that can’t handle more connections
• A cache that needs more capacity
• A message queue with uneven consumer throughput
• A rate limiter that blocks requests

Autoscaling pods won’t fix upstream bottlenecks. You’ll just scale the traffic generator that hits the broken part more quickly. The cluster will feel powerful while your users quietly suffer.

Configuration Management: Separate Code from Settings

Container images should ideally be immutable: build once, run everywhere. Configuration should change without rebuilding the image. Kubernetes provides a path to do this cleanly.

ConfigMaps for Non-Sensitive Configuration

ConfigMaps store non-secret configuration such as feature flags, non-sensitive environment variables, and application settings. They can be mounted as files or exposed as environment variables.

Keep an eye on:

• Size limits and manageability (don’t shove megabytes of config into ConfigMaps)
• How your app reloads configuration changes

Secrets for Sensitive Data (And Handle Them Carefully)

Secrets store sensitive configuration like API keys, database credentials, and tokens. You’ll need to decide how secrets are created and updated. Common patterns include:

• Integrate with an external secrets manager if available
• Huawei Cloud Top-up Use Kubernetes secrets for smaller setups
• Ensure RBAC restricts who can view secrets

Also, treat secrets as data, not vibes. Rotate credentials regularly, and ensure your deployment process supports safe updates.

Use Environment-Specific Config (Without Copy-Paste Hell)

Dev, staging, and prod typically have different:

• Database endpoints
• External service credentials
• Feature flags and limits

The danger is copy-pasting manifests until your repo becomes a landfill of near-duplicates. Instead, consider templating or parameterized configuration (for example, using Helm or Kustomize-style approaches) so environment changes are systematic, reviewable, and consistent.

Observability: Logging, Metrics, and Monitoring That Don’t Lie

Once your apps run in Kubernetes, you’ll need to answer three questions quickly:

• What’s happening right now?
• Why did it happen?
• Will it happen again?

Observability isn’t optional. Without it, you’ll be forced to debug in the dark, with production traffic as your only flashlight.

Centralize Logs

Containers should write logs to stdout/stderr so the platform can collect them. Centralizing logs helps with:

• Searching across pods and deployments
• Correlating events with requests
• Building dashboards and alerts

Huawei Cloud Top-up Log hygiene matters. Include:

• Structured logging when possible (JSON logs or key/value pairs)
• Request IDs or trace IDs for correlation
• Clear error messages with context

Also, be careful not to log secrets. Your log system might be powerful enough to store your mistakes forever.

Use Metrics for Sane Alerting

Metrics like CPU, memory, request latency, error rate, and queue depth are your early warning system. But alerts should be actionable. Avoid alert storms where every metric change triggers a notification that nobody reads until they’re already out of patience.

A good alert strategy:

• Triggers on symptoms (error rate spikes, latency increases)
• Includes thresholds and time windows
• Resolves clearly when the issue is fixed
• Routes alerts to the right team/owner

Tracing Helps When Everything Looks “Mostly Fine”

Distributed systems sometimes fail in slow, subtle ways. Tracing helps you see how a request moves across services, where latency accumulates, and which dependency is misbehaving.

If you have multiple microservices, tracing can turn “the whole system feels slow” into a precise culprit. Your future self will thank you with fewer headaches and more confidence.

CI/CD Pipelines: Automate Until It’s Boring

The best management approach is automation. The second best management approach is automation with guardrails. CI/CD pipelines can build images, run tests, scan vulnerabilities, push to the registry, and deploy to Kubernetes.

Recommended CI/CD Stages

A typical pipeline might look like:

• Build the container image (multi-stage build if applicable)
• Run unit tests and integration checks
• Scan the image for vulnerabilities
• Push the image to the container registry with a version tag
• Huawei Cloud Top-up Deploy to staging with the new image
• Run smoke tests against the staging deployment
• Promote to production if checks pass

Promotion should be explicit and reviewable. If your pipeline “randomly” deploys, you’ll eventually experience the tragic comedy of incorrect versions showing up in prod. It always happens to someone. The only question is whether it’ll be you.

Use Rollouts with Clear Gates

For production, use rollout gates like:

• Health checks passing (readiness probes and basic endpoints)
• No spike in error rates
• Enough time for the system to warm up
• Huawei Cloud Top-up Rollback plan triggered automatically or manually

A rollout without monitoring is just a faster way to make things worse.

Manage Kubernetes Manifests as Versioned Code

Infrastructure-as-code and manifest versioning makes deployments auditable. Store:

• Kubernetes resource definitions (deployments, services, ingress)
• Helm chart values or Kustomize overlays
• Environment-specific parameters

Then, you can tie a production incident to the exact deployment commit. That’s useful. It’s also morale-saving.

Security Hardening: Containers Are Not Permissionless Heaven

Security is a management topic because containers change the attack surface. The goal isn’t paranoia; it’s baseline hardening and sensible defaults.

Apply Least Privilege with RBAC

Kubernetes Role-Based Access Control (RBAC) should ensure that:

• Service accounts have minimal permissions
• Users and CI/CD systems only access what they need
• Privileged actions are restricted (especially in production)

If everyone can do everything, you’ve created a system where mistakes are inevitable and consequences are dramatic.

Harden Pod Security Settings

Consider security context settings for pods and containers:

• Run as non-root user when feasible
• Drop unnecessary Linux capabilities
• Use read-only file systems where possible
• Prevent privilege escalation

You may not enable every setting on day one. Start with the low-friction ones and iterate.

Network Policies to Reduce Lateral Movement

By default, pods may have broad connectivity depending on cluster setup. Network policies can restrict traffic between namespaces and services. With network policies, you can reduce the blast radius if one service is compromised.

Validate Supply Chain and Image Authenticity

Beyond scanning vulnerabilities, you should consider:

• Signing images
• Ensuring your registry only accepts trusted images
• Restricting who can push to the registry

A secure supply chain helps protect against tampering and accidental deployment of the wrong artifact.

Cost Awareness: Scaling Is Great Until the Invoice Arrives

Containerized apps are efficient, but efficiency doesn’t mean “free.” Costs come from compute (nodes and pods), storage (images and volumes), networking (egress and load balancing), and managed services used for observability.

Huawei Cloud Top-up Set Resource Requests and Limits

Requests and limits influence scheduling and runtime resource usage:

• Requests affect how the scheduler places pods
• Limits prevent a pod from consuming unlimited resources

If requests are too high, you waste capacity. If they’re too low, pods get throttled or evicted. Treat it like tuning a bicycle: too loose and you wobble; too tight and you can’t pedal.

Control Scaling Targets

Autoscaling should have reasonable min/max replicas and metrics thresholds. Define:

• Minimum replicas for availability
• Maximum replicas for cost control
• Scaling responsiveness that matches your traffic patterns

Also consider scaling for background workers separately. Workers often need different scaling behavior than web services.

Clean Up Old Images and Unused Resources

Registries can accumulate old images. Kubernetes can accumulate unused resources (depending on your deployment workflow). Set cleanup policies:

• Delete outdated images
• Prune old releases if applicable
• Remove stale ingress rules and unused services

Cost control is mostly discipline. The cluster will not automatically tidy up after your ambition.

Huawei Cloud Top-up Troubleshooting: When Things Break (They Will)

No matter how carefully you build, production will eventually hand you a surprise. The difference between a calm response and a panicked one is having a repeatable troubleshooting approach.

Common Deployment Issues

• Pods stuck in Pending: Usually means insufficient resources, scheduling constraints, or node capacity issues.
• Pods failing readiness: Application isn’t listening on the expected port, readiness endpoint fails, or dependencies aren’t reachable.
• CrashLoopBackOff: App is failing on startup; check logs and environment variables.
• Image pull errors: Registry authentication/permissions issues, wrong image tag, or network connectivity problems.

For each issue, start with the obvious: describe pods, inspect events, check container logs. Kubernetes provides breadcrumbs; you just have to follow them without stepping on the rake.

Debugging Networking Problems

Networking issues often show up as timeouts, 404s, or connection resets. Typical causes:

• Ingress rules don’t match host/path
• TLS misconfiguration
• Service selector mismatch (service points to no pods)
• Network policy denies traffic
• Wrong ports in container spec

Use a methodical approach: confirm service endpoints, verify ingress routing, and then check the application’s listening port and readiness probe.

Performance Issues: It’s Not Always “Scaling”

When latency spikes, teams often jump straight to scaling. That can help, but it can also mask root causes. Consider:

• Database slow queries or connection pool exhaustion
• Cache misses increasing load on dependencies
• Thread pool starvation or blocking operations
• GC pressure (for managed runtimes)
• Network saturation or throttling

Use metrics and traces to pinpoint where time is going. Scaling increases throughput, but it doesn’t fix broken logic.

Operational Maturity: What to Do After the First Successful Deployment

Your first deployment is a milestone. Your tenth deployment is when you learn if you built a maintainable system. Operational maturity is the difference between shipping quickly and shipping safely.

Standardize Environments and Deployment Workflows

Make sure dev, staging, and prod follow similar patterns:

• Same namespace structure and labeling conventions
• Same ingress style and TLS approach
• Same monitoring and alerting strategy
• Same CI/CD pipeline behavior (with different credentials/config)

Consistency makes debugging easier because your mental model doesn’t change every time you open a manifest.

Use Version Labels and Metadata

Add labels and annotations to help operations. Good labels include:

• Application name
• Environment (dev/stage/prod)
• Release version or commit hash

This makes it easier to identify which pods belong to which release during an incident.

Document Runbooks

Runbooks are step-by-step guides for common scenarios: image pull failures, ingress misrouting, database connection issues, certificate expiration, and scaling anomalies. They should include:

• Symptoms and how to confirm
• Relevant logs/metrics to check
• Rollback steps
• Escalation contacts and timelines

Runbooks turn “we’ll figure it out” into “we know what to do.” That’s how you avoid turning incidents into folklore.

Conclusion: Container Management Should Feel Like a System, Not a Haunting

Managing containerized apps on Huawei Cloud International is absolutely doable, and it gets easier when you treat container orchestration as a product: defined processes, standardized patterns, secure defaults, and measurable observability. Start with a clear workload strategy, build images that are reliable and versioned, deploy using Kubernetes primitives with correct health checks, and make routing predictable with solid ingress configuration.

Then invest in observability, automate CI/CD with safe gates, harden security posture with least privilege and network restrictions, and keep cost in check with resource discipline and scaling bounds. When issues occur—and they will—troubleshoot methodically using the signals Kubernetes provides: events, pod logs, readiness behavior, and service endpoints.

Do this, and “managing containerized apps” stops being a never-ending scramble and becomes what it was meant to be: a repeatable workflow that supports your teams, your users, and your sanity.