Container
Domain 2 covers containers on NHN Cloud: Container Registry for images and Kubernetes Service (NKS) for orchestration. The exam tests image lifecycle, cluster placement, node pools, and service exposure.
Core rules
- NHN Cloud Container Registry stores private images. Push uses the registry endpoint and credentials; pull from NKS needs an image pull secret or configured authentication.
- NKS manages the Kubernetes control plane; worker nodes run in your VPC subnets. You choose cluster subnet, node subnet, and security groups, so cluster networking must be planned before creation.
- A node pool defines worker count, flavor, and autoscaling. Pods are scheduled onto nodes; a pod without enough requested CPU or memory stays Pending.
- Services expose pods. ClusterIP is internal, NodePort opens a port on nodes, and LoadBalancer requests an NHN Cloud load balancer. Ingress can route HTTP host or path to services.
- Kubernetes objects such as Deployments, ConfigMaps, Secrets, and PersistentVolumeClaims are standard; NHN Cloud supplies the infrastructure, not custom YAML semantics.
Worked example
A team builds an image tagged web:1.4 and pushes it to Container Registry. In NKS, they create a Secret of type docker-registry, reference it in the Deployment imagePullSecrets, set the image to the private registry URL, and create a LoadBalancer Service on port 80 to container port 8080. Reason: private registry auth is required; the Service maps the external listener to the pod port; the load balancer health check must target a path the app serves.
Traps
Do not use the public image name if the registry is private. Do not place node subnets where they cannot reach the registry endpoint. Do not set CPU requests above node capacity. Do not expect a LoadBalancer Service to create an ingress controller by itself.