What Is Container Orchestration Basics in Cloud Computing?
Also known as: container orchestration basics, container orchestration definition, Kubernetes orchestration, CNCF KCNA, container orchestration exam
On This Page
Quick Definition
Container orchestration is like having a smart manager that automatically starts, stops, and connects your application pieces across many computers. It makes sure each piece has the resources it needs, restarts any that fail, and adjusts the number of pieces based on demand. Think of it as an automatic system that keeps your application running smoothly without you having to manually watch each part.
Must Know for Exams
Container orchestration is a core topic in the CNCF Certified Kubernetes Application Developer (CKAD), Certified Kubernetes Administrator (CKA), and Kubernetes and Cloud Native Associate (KCNA) exams. The KCNA exam, in particular, tests foundational knowledge of container orchestration basics, including the concepts of orchestration, scheduling, scaling, and self-healing. Candidates must understand the difference between container runtimes, orchestration platforms, and the components of Kubernetes architecture.
In the KCNA exam, about 28% of the exam covers Kubernetes fundamentals, which include basic orchestration concepts. You might be asked to define what container orchestration is, list its benefits, or identify which component handles scheduling. For the CKA exam, the focus shifts to practical tasks: you must deploy an application, expose it as a service, scale it, perform a rolling update, and roll back a deployment. The CKA is a hands-on exam where you run commands in a live Kubernetes cluster, so you must know how to use kubectl commands like create, get, describe, scale, rollout, and delete.
For the CKAD exam, the emphasis is on application design and deployment. You will be tested on how to define pod specifications, use ConfigMaps and Secrets, create multi-container pods, and set up networking between services. Orchestration concepts like health probes (liveness and readiness), resource limits, and persistent volumes are also common. These exams require you to understand the declarative model: you write YAML files that describe the desired state, and the orchestrator makes it happen. Errors in YAML syntax, incorrect resource names, or misunderstanding of concepts like namespaces can cost you points.
Even exams outside the Kubernetes ecosystem, like Docker Certified Associate, include orchestration topics such as Docker Swarm setup, node management, and service scaling. For AWS certifications like the AWS Certified Solutions Architect, you need to know how managed orchestration services (Amazon ECS, Amazon EKS) work and how they integrate with other AWS services. In summary, container orchestration is not just a theoretical topic in exams; it is a practical skill that is directly tested through scenario-based tasks and configuration challenges.
Simple Meaning
Imagine you are running a busy restaurant kitchen with many chefs working at different stations. Each chef works in a small, self-contained booth (a container) that has its own tools and ingredients. In the beginning, you have just a few chefs, so you can personally keep an eye on them—refilling supplies, fixing problems, and telling them which orders to cook. But as your restaurant grows, you suddenly have fifty chefs, each in their own booth, all cooking different meals for hundreds of customers. Now, you cannot watch every single chef. Some booths run out of ingredients, some chefs get tired and slow down, and sometimes a chef makes a mistake and needs to be replaced. This is where container orchestration comes in.
Container orchestration is like hiring a head chef and a team of assistants who manage all the booth stations for you. This head chef constantly monitors each booth—checking if it has enough ingredients, if the chef is working correctly, and if the booth is getting too many orders. When a booth becomes overloaded, the head chef automatically creates a new identical booth with a new chef to share the work. If a booth breaks down, the head chef removes it and starts a fresh one. The head chef also makes sure that the booths can talk to each other when needed, for example, when a salad station needs to send finished salads to the plating station. All of this happens automatically, without you having to do anything.
In technical terms, containers are lightweight, portable packages that contain your application code and all its dependencies. Container orchestration tools like Kubernetes, Docker Swarm, and Apache Mesos automate the lifecycle of these containers across a cluster of machines. They handle deployment (putting containers where they should go), scaling (adding or removing containers as demand changes), networking (connecting containers to each other and the outside world), health monitoring (checking if containers are alive and working), and self-healing (restarting or replacing failed containers). For beginners, the key idea is that orchestration removes the manual work of managing many containers, making large-scale applications reliable, efficient, and easy to operate.
Full Technical Definition
Container orchestration is the automated coordination and management of containerized applications across multiple host machines, known as a cluster. It sits on top of container runtimes like Docker, containerd, or CRI-O, and provides a higher-level abstraction for managing the lifecycle of containers. The core idea is to treat a group of servers as a single logical resource pool, where containers are placed based on resource availability, constraints, and policies.
At the heart of container orchestration is a control plane that acts as the brain of the system. The control plane stores the desired state of the application—for example, 'run three copies of the web server container, expose port 80, and restart any container that crashes.' It continuously compares the current state to the desired state and takes actions to reconcile any differences. This is called the declarative model: you declare what you want, and the orchestrator makes it happen. Components like the scheduler decide which machine should run each container, the controller manager handles routine tasks like node monitoring and replication, and the API server serves as the front end for all interactions.
Worker nodes are the machines where containers actually run. Each worker node runs an agent, such as kubelet in Kubernetes, that communicates with the control plane and manages the containers on that node. Containers are grouped into logical units called pods (in Kubernetes) or tasks (in Docker Swarm), which are the smallest deployable units. These units share storage, network, and a specification for how to run the container. The orchestrator also handles networking, ensuring containers can find and talk to each other using service discovery, load balancing, and virtual IPs.
Key technical components include a distributed key-value store (like etcd) for storing configuration and state, container registries (like Docker Hub) for storing images, and monitoring and logging systems (like Prometheus and Fluentd) for observability. Advanced features include rolling updates (gradually replacing old containers with new ones without downtime), rollbacks (reverting to a previous version if something goes wrong), autoscaling (automatically adjusting the number of containers based on CPU, memory, or custom metrics), and storage orchestration (attaching persistent storage to containers). In real IT environments, container orchestration is implemented using platforms like Kubernetes (the industry standard), Docker Swarm (simpler but less feature-rich), and cloud-managed services like Amazon EKS, Azure Kubernetes Service, and Google Kubernetes Engine. These platforms provide APIs, command-line tools, and user interfaces to manage the entire lifecycle of containerized applications at scale.
Real-Life Example
Think of a large public library that loans out books, e-readers, and audiobooks. In the old days, a single librarian could manage a small shelf of books manually. But now the library has thousands of items, multiple floors, and hundreds of visitors every day. The library needs a smart system to handle everything. This system is like container orchestration.
First, the library has a central catalog (the control plane) that knows about every item: where it is, who borrowed it, when it is due, and what condition it is in. When a visitor wants a book, the system checks if a copy is available, finds the nearest copy, and either directs the visitor to the shelf or arranges for the book to be delivered to a pickup desk. This is like scheduling containers to run on available machines. If a book gets damaged and cannot be used, the system automatically orders a replacement copy from the warehouse and puts it on the shelf. This is self-healing: failing containers are replaced.
Now imagine the library gets very busy during exam season. Many students want the same popular textbooks. The system automatically orders extra copies from the warehouse and places them on the shelves nearest to the students. When the rush is over, it returns the extra copies to storage to save shelf space. This is autoscaling: adding and removing containers based on demand.
The library also needs to connect different sections. A student might request a book about ancient Rome from the history section, a documentary disc from the media section, and a digital audiobook from the online collection. The system ensures that all three items are ready for checkout together and that the three library sections can communicate with each other so that the student only goes to one counter. This is networking and service discovery in container orchestration.
Finally, the library system runs regular health checks: it scans each shelf to make sure books are in the right place, checks that barcodes are scannable, and verifies that the digital catalog is up to date. If a shelf is disorganized, the system alerts staff to fix it. This is health monitoring and logging. Container orchestration does exactly this for software containers, keeping your applications running reliably and efficiently without constant human attention.
Why This Term Matters
Container orchestration matters because modern applications are rarely a single piece of software running on one machine. Instead, they are composed of many small, independent services—often called microservices—each running in its own container. For example, an e-commerce website might have separate containers for user login, product catalog, shopping cart, payment processing, and order tracking. If you have just a few services on one server, you can manage them manually. But in a real production environment, you might have hundreds or even thousands of containers spread across dozens or hundreds of servers. Doing this manually is impossible without making mistakes.
Without orchestration, tasks like scaling, deployment, and recovery require significant human effort and are prone to errors. An engineer might forget to restart a crashed container, or a new deployment might accidentally overwrite a configuration file, causing a service outage. Orchestration automates these tasks, reducing the risk of human error and freeing up IT staff to focus on more strategic work. It also makes applications more resilient. If a server fails, the orchestrator automatically moves the containers to healthy servers, keeping the application running.
In real IT work, container orchestration is a foundational skill for cloud engineers, DevOps practitioners, site reliability engineers, and platform engineers. It enables continuous delivery—the ability to deploy new software versions quickly and safely. It also helps with cost optimization, because you can run many containers on fewer servers by packing them efficiently, and you can scale down during low-demand periods. Major companies like Google, Netflix, Spotify, and Uber rely on container orchestration to run their massive, global-scale services. For system administrators moving from traditional virtual machine management to cloud-native infrastructure, understanding orchestration is essential. It is not just a buzzword; it is the standard way to run applications in production today.
How It Appears in Exam Questions
Exam questions on container orchestration appear in several distinct forms. The most common pattern is the scenario question, where you are given a business requirement and must select the correct action or configuration. For example: a company runs a web application on a Kubernetes cluster and expects a sudden spike in traffic. Which action should the administrator take to ensure the application handles the load? The correct answer might be to increase the number of replicas in a deployment, enable horizontal pod autoscaling, or adjust resource requests and limits. These questions test your understanding of scaling concepts and the tools available.
Another type is the configuration question, often presented as a multiple-choice or fill-in-the-blank task. You might be shown a partial YAML file for a Kubernetes Deployment and asked to select the missing field that sets the number of replicas to 5. Or you might be asked which command creates a deployment with two replicas. In hands-on exams like CKA, you have to actually edit YAML files or run kubectl commands to achieve a specified state. For example: deploy the nginx image with three replicas and expose it internally on port 80. You must know the syntax for kubectl create deployment, kubectl scale, and kubectl expose.
Troubleshooting questions are also common. You might be told that a pod is in a CrashLoopBackOff state, and you need to identify the cause—perhaps a missing environment variable, a typo in the command, or insufficient memory. Another scenario: a service is not accessible from outside the cluster. You might need to check the service type, node port configuration, or network policies. Architecture questions appear frequently in KCNA: which component stores the cluster state? (etcd). Which component schedules pods? (kube-scheduler). What is the role of a controller manager? (runs controllers that regulate the cluster state).
Lastly, comparison questions test your understanding of similar concepts. For example: what is the difference between a ReplicaSet and a Deployment? The answer is that a Deployment manages ReplicaSets and provides declarative updates. Or: how does Docker Swarm differ from Kubernetes? The answer might highlight Simpler setup versus richer features like auto-healing and rolling updates. These questions require you to know the exact definitions and relationships between terms, which is why memorizing key components and their functions is important for exam success.
Study cncf-kcna
Test your understanding with exam-style practice questions.
Example Scenario
Patel is a system administrator at a midsize e-commerce company. The company runs its online store on a single server using a monolithic application. As business grows, the server becomes overloaded, and customers experience slow page loads and occasional crashes. The company decides to modernize by breaking the application into microservices: a front-end service, a product catalog service, a shopping cart service, and a payment service. Each service runs in a separate container.
Patel initially runs these containers manually using Docker commands on a single server. But soon, a server failure takes down the entire store for two hours. Customers are furious. Patel realizes that manual management is not sustainable. The company decides to adopt container orchestration using Kubernetes. Patel sets up a small Kubernetes cluster with three worker nodes. He writes YAML files to define deployments for each microservice, specifying the desired number of replicas (e.g., three copies of the front-end service). He also creates services to expose each microservice internally, and an Ingress to route external traffic to the front-end.
Now, when traffic spikes during a holiday sale, the horizontal pod autoscaler automatically increases the number of front-end replicas from three to ten. When a worker node goes offline, the scheduler moves the affected pods to healthy nodes. When Patel updates the payment service to fix a bug, he performs a rolling update, and the deployment gradually replaces old pods with new ones—zero downtime. If the update causes a problem, he can roll back with a single command. This scenario shows container orchestration in action: it automates deployment, scaling, recovery, and updates, making the online store reliable and responsive even under heavy load.
Common Mistakes
Believing that container orchestration is the same as a container runtime like Docker.
A container runtime (like Docker Engine, containerd, or CRI-O) is the software that actually runs a container on a single machine. Container orchestration is a higher-level layer that manages multiple containers across multiple machines. Docker provides the ability to run a container; orchestration adds scheduling, scaling, networking, and self-healing across a cluster. The mistake is confusing the foundational layer with the management layer.
Think of it like a car engine versus a fleet management system. The engine makes the car go (container runtime), but the fleet system coordinates all the cars, assigns routes, and handles breakdowns (orchestration). Each has a distinct role.
Thinking that orchestration is only for large-scale deployments with hundreds of containers.
While orchestration shines at scale, it is also beneficial for small deployments. Even with just a few containers, orchestration provides benefits like automated restarts, consistent deployments, and simplified rollbacks. Starting small with an orchestrator like Kubernetes can save future migration headaches as the application grows.
Use orchestration as soon as you have more than one container or need reliability. It is not overkill—it is a best practice for any production workload, regardless of size.
Assuming that all orchestration platforms work exactly the same way.
Different orchestration tools have different architectures, APIs, and capabilities. Kubernetes uses a declarative model with YAML manifests, while Docker Swarm uses a more imperative model with Docker commands. Apache Mesos is a general-purpose resource manager that can run containers, but has different scheduling mechanisms. Understanding these differences is critical for choosing the right tool and for passing certification exams.
Learn the fundamentals of orchestration concepts, but also study the specific terminology and structure of the platform you will use (typically Kubernetes for CNCF exams). Do not assume that commands from one platform work on another.
Mistaking pods for containers in Kubernetes.
A pod is the smallest deployable unit in Kubernetes and can contain one or more containers that share storage and network. Many beginners think a pod equals a container, but a pod can run multiple containers that work together (like a helper container that syncs files while the main container serves data). Confusing the two leads to incorrect answers on exam questions about pod specifications and multi-container patterns (like sidecar, ambassador, and adapter containers).
Always remember: a pod is one or more containers that are always co-located and co-scheduled. They share the same IP address, port space, and volumes. The container is the actual running image.
Believing that orchestration makes manual management completely unnecessary.
Orchestration automates many tasks, but it does not eliminate the need for human oversight. You still need to design applications correctly, write accurate configuration files, set resource limits, monitor logs, and plan for disaster recovery. Orchestration can also introduce its own complexities—like network policies, persistent volume claims, and security contexts—that require human expertise to configure correctly.
Treat orchestration as a powerful tool that reduces manual work, but not as a magic solution. Always test configurations in a non-production environment and monitor the system after changes.
Exam Trap — Don't Get Fooled
An exam question asks: 'Which Kubernetes component is responsible for storing the current state of the cluster?' Options: a) kube-apiserver, b) kube-controller-manager, c) etcd, d) kube-scheduler. A common trap is for learners to choose kube-apiserver because it is the front-end for all cluster operations.
Memorize the specific role of each control plane component. Use this memory hook: 'The API server is the entry door, etcd is the filing cabinet.' The API server takes the request, validates it, and then stores the data in etcd.
When you see a question about where the cluster state lives, always think of etcd first. Also practice recalling the five control plane components (API server, controller manager, scheduler, etcd, cloud controller manager) and what each does.
Commonly Confused With
A container runtime is the low-level software that actually runs containers on a single machine (e.g., containerd, CRI-O, Docker Engine). Container orchestration is the higher-level system that manages multiple containers across many machines, providing scheduling, scaling, and networking. The runtime is a dependency of the orchestrator, not a replacement.
Think of the runtime as the engine inside each car in a fleet. The orchestration system is the dispatch center that tells each car where to go and when. Without the engine, the car cannot move; without the dispatch center, the cars drive aimlessly.
VM orchestration manages virtual machines, which include a full operating system per instance. Container orchestration manages containers, which share the host OS kernel and are lighter. VM orchestration (like OpenStack) typically deals with larger, more isolated units, while container orchestration handles finer-grained, faster-to-start units. The principles of scheduling and scaling are similar, but the technologies and operational patterns differ.
Imagine moving apartments: VM orchestration is like moving entire houses (heavy, slow, separate foundations) while container orchestration is like moving boxes within a single apartment building (light, fast, shared infrastructure). Both involve moving things, but the scale and speed are different.
Serverless computing (like AWS Lambda) abstracts away servers entirely: you upload code, and the cloud provider runs it on demand without you managing any containers or orchestration. Container orchestration still requires you to manage clusters, nodes, and container images. Serverless is simpler for small functions but less customizable, while orchestration gives more control over the runtime environment.
Serverless is like ordering a pizza: you just say what you want and it arrives. Container orchestration is like running your own restaurant kitchen: you control the recipes, the equipment, and the staff, but you have to manage everything yourself.
Cluster management tools like Apache Mesos or Nomad can manage non-container workloads (like Java processes or shell scripts) alongside containers. Container orchestration is specifically designed for containers and assumes the application is packaged as a container image. General cluster managers are more flexible but have fewer container-specific features like image registries and container networking.
Think of cluster management as a multi-purpose warehouse that can store boxes, pallets, and furniture. Container orchestration is a specialized shelving system designed only for boxes of a certain size. Both organize items, but the specialized system is more efficient for its intended use.
Step-by-Step Breakdown
Package application into a container image
First, you create a container image that contains your application code, runtime, libraries, and dependencies. This image is built using a Dockerfile and stored in a registry like Docker Hub or a private registry. The image is the portable, immutable artifact that the orchestrator will run.
Define desired state in a manifest file
You write a declarative configuration file (usually YAML or JSON) that describes what you want: which container image to use, how many copies (replicas) to run, which ports to expose, environment variables, resource limits, and health check endpoints. This file is the blueprint the orchestrator follows.
Submit the manifest to the control plane
Using a command-line tool (like kubectl for Kubernetes) or an API, you submit the manifest to the orchestrator's API server. The API server validates the request and stores the desired state in the cluster's key-value store (etcd). This step kicks off the orchestration process.
Control plane schedules containers to worker nodes
The scheduler component reads the desired state from etcd and determines which worker node should run each container. It considers factors like available CPU and memory, affinity or anti-affinity rules, and any constraints you defined. It then assigns the container to a specific node.
Worker node starts and runs the containers
The agent on the assigned worker node (e.g., kubelet) receives the instruction from the control plane and pulls the container image from the registry. It then uses the container runtime to start the container. The agent continuously reports the container's status back to the control plane.
Health monitoring and self-healing
The control plane constantly checks the health of each container using probes (liveness, readiness, startup). If a container fails or becomes unresponsive, the orchestrator automatically stops it and starts a new one. If a node fails, the orchestrator reschedules its containers onto healthy nodes.
Scaling and updates based on demand or schedule
When traffic increases, you can manually increase the replica count or configure autoscaling based on metrics (CPU, memory, custom). The orchestrator adds new containers to handle the load. For updates, you can perform a rolling update: the orchestrator gradually replaces old containers with new ones, ensuring no downtime.
Practical Mini-Lesson
Container orchestration is not just a theoretical concept; it is a practical skill that every cloud and DevOps professional must master. In day-to-day work, you will interact with orchestration platforms primarily through configuration files and command-line tools. The most important skill is writing accurate YAML manifests. A typical Kubernetes deployment manifest includes fields like apiVersion, kind, metadata, and spec. The spec contains the desired number of replicas, a selector to match pods, a template that defines the pod (including container image, ports, environment variables, and resource requests), and a strategy for updates (rolling update or recreate).
When deploying an application, always start with a simple deployment and test it in a development namespace. Use kubectl get pods to see if the pods are running, kubectl logs <pod-name> to check application logs, and kubectl describe pod <pod-name> to see events and errors. If a pod stays in a pending state, it often means the scheduler cannot find a node with enough resources. Check the events with 'kubectl describe events' and adjust resource requests in the manifest. If a pod is in CrashLoopBackOff, it means the container starts but crashes repeatedly. This is usually due to application errors—check logs and fix the application code or configuration.
For scaling, you have two options: manual scaling with 'kubectl scale deployment my-deployment --replicas=5' or autoscaling with a HorizontalPodAutoscaler (HPA). The HPA definition requires target metrics, such as average CPU utilization. For example, if CPU exceeds 70%, the HPA adds replicas up to a maximum of 10. Remember that autoscaling only works if resource requests are set on the containers—without them, the metrics system cannot measure usage.
Networking in orchestration is another critical area. Each pod gets its own IP address, but these IPs are ephemeral. To provide a stable endpoint, you create a Service. A Service selects pods based on labels and provides a stable cluster IP and DNS name. For external access, you use a NodePort, LoadBalancer, or Ingress. Understanding how Services route traffic—using iptables or IPVS—helps with troubleshooting connectivity issues.
What can go wrong? Common problems include misconfigured selectors (the Service label selector must match the pod labels), missing or incorrect container ports, running out of storage for persistent volumes, and network policy blocking inter-pod communication. Always verify your YAML syntax with a linter, and use 'kubectl apply --dry-run=client' to validate before applying.
In practice, orchestration connects to broader IT concepts like CI/CD pipelines (you can trigger a deployment after a successful build), monitoring (Prometheus scrapes metrics from pods), and logging (Fluentd collects logs). By mastering the basics of deployment, scaling, networking, and troubleshooting, you can manage production workloads confidently and ace your certification exams.
Memory Tip
KISS: Keep It Simple, Stateful. Remember that orchestration is all about managing the three S's: Scheduling (where containers run), Scaling (how many run), and Self-healing (fixing failures). The core principle is declarative state: you declare what you want, the orchestrator makes it so.
Covered in These Exams
Related Glossary Terms
Two-factor authentication (2FA) is a security method that requires two different types of proof before granting access to an account or system.
5G is the fifth generation of cellular network technology, designed to deliver faster speeds, lower latency, and support for many more connected devices than previous generations.
An A record is a DNS record that maps a domain name to the IPv4 address of the server hosting that domain.
Frequently Asked Questions
What is the difference between container orchestration and container management?
Container management is a broader term that includes running, stopping, and inspecting individual containers. Container orchestration is a subset that automates these tasks across multiple hosts, including scheduling, scaling, and self-healing. Orchestration is essentially management at scale.
Do I need to learn Docker before learning container orchestration?
Yes, understanding containers and images is helpful because orchestration builds on top of container technology. You should know how to build, run, and inspect a container with Docker before learning Kubernetes. However, once you start using orchestration, you will interact more with YAML files and orchestrator commands than with raw Docker commands.
Which container orchestration platform should I learn first?
For CNCF certification and industry relevance, start with Kubernetes. It is the most widely adopted platform and the focus of exams like KCNA, CKA, and CKAD. Docker Swarm is simpler but less common in enterprise environments. Learning Kubernetes first gives you the most career value.
Is container orchestration only for large companies?
No. Small and medium-sized organizations also benefit from orchestration for reliability, automation, and consistent deployments. Many cloud providers offer managed Kubernetes services that simplify setup, making it accessible for teams of any size. You do not need hundreds of servers to benefit from orchestration.
What does 'declarative model' mean in container orchestration?
The declarative model means you define the desired end state of your application (how many copies, which image, what ports) in a configuration file, and the orchestrator automatically makes the current state match that desired state. You do not tell the system how to achieve the goal; you only specify what the goal is.
Can I use container orchestration on my local computer?
Yes. Tools like Minikube, kind, and Docker Desktop include a single-node Kubernetes cluster that you can run locally for learning and development. This is a great way to practice without needing a cloud account or multiple servers.
How does container orchestration handle security?
Orchestration platforms provide security features like role-based access control (RBAC), secrets management, network policies, pod security standards, and container image scanning integration. You can also integrate with external identity providers. However, security still requires proper configuration by the administrator.
What is a 'pod' in Kubernetes?
A pod is the smallest deployable unit in Kubernetes. It can contain one or more containers that share the same network namespace, storage volumes, and lifecycle. Pods are designed to run a single instance of your application or a group of tightly coupled containers.
Summary
Container orchestration is the automated management of containers across multiple servers, handling deployment, scaling, networking, and self-healing. For IT certification learners, especially those pursuing CNCF exams like KCNA, CKA, and CKAD, understanding orchestration is essential because it is the foundation of modern cloud-native application deployment. The key concepts to remember are the declarative model (you define the desired state, the orchestrator achieves it), the separation between container runtimes and orchestration platforms, and the core components of a control plane and worker nodes.
Practically, orchestration reduces human error, enables fast and safe deployments, and makes applications resilient to failures. In exams, you will encounter scenario questions that test your ability to choose the right action (scaling, updating, troubleshooting) and architectural questions about component roles. Avoid common mistakes like confusing pods with containers or thinking orchestration is only for large deployments.
Use memory hooks like KISS (Scheduling, Scaling, Self-healing) to recall the three S's. By mastering these basics, you will be well-prepared for certification exams and ready to work with production-grade infrastructure.