JNCIE-Cloud key terms

The physical IP fabric of routers and switches that carries encapsulated traffic between virtualization hosts. It provides reachability and path redundancy but forwards overlay packets without interpreting tenant addresses inside them.

A logical network built on top of an underlay by tunnelling frames or packets between endpoints. Tenant addressing and segmentation live here, decoupled from physical topology, so virtual networks can span racks and sites.

An architecture in which one shared platform serves many independent customers or projects while isolating their traffic, data, and quotas. Isolation is enforced at every layer, from virtual routing to identity and storage.

A contractual commitment defining measurable targets such as availability, latency, or recovery time for a delivered service. Cloud designs are validated against these targets, and breaches usually trigger credits or penalties.

Designing a system so that failure of a component does not stop the service, typically through redundancy, health checks, and automatic failover. In cloud fabrics it spans hosts, control planes, and network paths.

Running network functions such as firewalls, routers, and gateways as software on general-purpose servers instead of dedicated appliances. It separates the function from the hardware and enables rapid deployment and scaling.

A software implementation of a network function packaged to run on virtual machines or containers. It is instantiated, scaled, and healed by a management and orchestration layer rather than configured by hand.

Management and Orchestration, the framework that onboards, deploys, monitors, and scales virtual network functions. It comprises the NFV orchestrator, VNF managers, and virtualized infrastructure managers working together.

Steering traffic through an ordered sequence of network functions, for example firewall then load balancer then intrusion detection. It is implemented with policy-based routing, traffic classifiers, or SDN flow rules.

A centralized software component that computes and programs forwarding decisions across network devices through southbound interfaces. Applications request connectivity through its northbound API instead of configuring each device individually.

A southbound protocol that lets a controller install match-action flow entries in switches. It separates forwarding from control logic and is one of several options alongside NETCONF, gRPC, and vendor APIs.

The part of a network or platform that decides where traffic goes and maintains state such as routing tables, cluster membership, or endpoint location. Its availability and consistency are critical to overall service health.

The forwarding path that actually moves packets, using tables or flow entries computed elsewhere. It is optimized for throughput and latency, while policy and path selection happen in the control plane.

A tunnelling protocol that encapsulates Layer 2 frames in UDP and identifies segments with a 24-bit VNI. It allows many isolated virtual networks to share one IP underlay and is widely used in data centre fabrics.

A VXLAN tunnel endpoint that encapsulates frames from a local segment, sends them over the IP underlay, and decapsulates them at the far end. It may be implemented in software on a hypervisor or in switch hardware.

A 24-bit VXLAN Network Identifier that labels which virtual segment a tunnelled frame belongs to. It provides the isolation boundary between tenants sharing the same underlay.

Wrapping an original packet or frame inside an outer header so it can traverse a transport network. The outer addresses guide delivery; the inner addresses are restored on decapsulation at the far endpoint.

A logical network instance dedicated to one project or customer, with its own addressing and isolation. It is created and manipulated through APIs and is mapped onto tunnels or VLANs on the physical fabric.

A technique that keeps multiple independent routing tables on the same device or namespace. Each tenant's routes stay separate, so overlapping address ranges can coexist without conflict.

Software that runs virtual machines by allocating CPU, memory, and I/O while isolating guests from each other. Type 1 runs directly on hardware; type 2 runs as an application on a host operating system.

A complete guest operating system with virtualized hardware, running under a hypervisor. It offers strong isolation and supports unmodified operating systems, at the cost of heavier resource overhead than containers.

An isolated process tree packaged with its dependencies that shares the host kernel. Containers start quickly and pack densely but provide weaker isolation than virtual machines, so they are often run inside them.

A software switch inside a hypervisor that connects virtual machine NICs to physical uplinks and enforces local policy. It can be a standard virtual switch or a distributed switch managed centrally across hosts.

Moving a running virtual machine or workload between hosts with little or no downtime by transferring memory and state over the network. It underpins maintenance, balancing, and evacuation of failing hardware.

The OpenStack orchestration service that deploys resources from declarative templates describing servers, networks, and volumes. It supports stacks, parameters, dependencies, and auto-scaling groups.

The OpenStack identity service that authenticates users and services and issues tokens, and that holds projects, roles, and the service catalog. Nearly every other API call is authorized through it.

The OpenStack networking service that provides networks, subnets, ports, routers, and security groups through an API. It delegates to plugins and drivers that implement overlays or VLANs on the underlying infrastructure.

The OpenStack compute service that schedules and manages virtual machine instances. It interacts with hypervisors through drivers and relies on Neutron for networking and Cinder or Swift for storage.

In OpenStack, the ownership and quota boundary that groups users and the resources they create. It corresponds roughly to a tenant and is the scope in which roles and network isolation are applied.

An open-source container orchestration system that schedules pods onto nodes and continuously reconciles observed state with declared state. Its API server, scheduler, and controllers form a distributed control plane.

The smallest schedulable Kubernetes unit, holding one or more containers that share a network namespace and storage volumes. Containers in a pod communicate over localhost and are always co-located.

A specification and set of plugins that wire container network interfaces and assign addresses when pods are created or deleted. Different plugins implement overlays, routing, or direct attachment to physical networks.

A Kubernetes abstraction giving a stable virtual IP and DNS name to a set of pods selected by labels. It load-balances traffic even as pods are rescheduled, and can be exposed as NodePort or LoadBalancer.

A Kubernetes API object and controller that routes external HTTP and HTTPS traffic to services based on host and path rules. It centralizes TLS termination and name-based virtual hosting at the cluster edge.

The node component that programs local forwarding so traffic to service virtual IPs reaches the correct backing pods. It commonly uses iptables or IPVS rules and is part of the cluster data plane.

A Kubernetes-based application platform that adds integrated routing, build pipelines, image registries, and stricter security defaults. It is managed through its own API and command line on top of standard Kubernetes primitives.

An OpenShift resource that exposes a service at an external hostname through the platform router. It provides HTTP and HTTPS publishing with optional TLS termination, comparable to a Kubernetes ingress rule.

A packaging of operational knowledge as code that watches custom resources and reconciles the managed application toward the desired state. It automates deployment, upgrades, scaling, and recovery tasks.

Granting permissions through roles bound to users, groups, or service accounts rather than per individual. Both OpenStack and Kubernetes use it to enforce least privilege across projects and namespaces.