Containers & k8s

Question 1

What is virtualization?

Answer 1

It is the emulation of a physical computer.

Question 2

What is bare metal hypervisor?

Answer 2

It is a piece of software that runs on top of bare metal hardware. It doesn’t rely on the host operating system and can achieve better performance. However the hardware it runs on is more expensive.

Question 3

What are the benefits of virtual machines?

Answer 3

They are cheaper to run. Many of them share the same hardware and they allow much higher resource utilization. They are easy to scale too. There is some migration software even moving one VM from one host to another without even shutting down the VM.

Question 4

What are the downsides of virtual machines?

Answer 4

They could be vulnerable to the noisy neighbor problem. When our own application is sharing the host machine with a resource hog of a neighbor, our own application performance could suffer. Also vms that are sharing the same host share the same physical cores. They are vulnerable to attacks that take advantage of the design flaws in modern micro processors. Side channel attacks like Meltdown and Spektre some well known examples.

Question 5

What is containerization?

Answer 5

It is considered to be a lightweight version of virtualization. We have hardware and the host operating system. But instead of virtualizing the underlying hardware, we virtualize the host operating system with a special software called Container Engine. On top of the container engine, there are many containers running, each have their own application environment isolated from each other.

Question 6

What are the advantages of containers?

Answer 6

The container engine provides even faster resource provisioning, and all the resources that needed to run an application are packaged together so applications can run anywhere. Containers are scalable and portable. They are lightweight and require less hardware resources to run than virtual machines. A bare metal can run significantly more containers than virtual machines. Each container runs as a native process of the host operating system, they are much faster to start and this makes it even easier to deploy and maintain at scale. Only with a container engine software.

Question 7

What are the downsides of containers?

Answer 7

Containers are less secure. They share the same underlying operating system and isolation lies on the OS level primitives. This means containers are exposed to a wider class of security vulnerabilities at the OS level. One way is to run containers in different VMs to reduce the attack surface. This is a tradeoff between flexibility and security.

Question 8

What comes after containers?

Answer 8

Serverless and edge computing come to mind. They make the developer productivity and deployment stories even more compelling.

Question 9

What are the virtualization layers?

Answer 9

Hardware
Host Operating System
Hypervisor
Then in each virtual machine, there is a guest os and on top of every operating system, runs an application for a tenant.

Question 10

What is bare metal hardware?

Answer 10

A bare metal software is a physical computer that is single tenant only. It has hardware, host OS and many applications on top of it. Once upn a time all servers were bare metal. It gives us complete control on the hardware resources and the software stack to run\ for software applications that require the ablolute highest performance from the hardware, this could be a good way. Bare metal servers are physically isolated so they are not affected by the noisy neighbor problem. Second the isolation provides the highest level of security. Not afected by side-channel attacks. A malicious neighbor can steal secrets from its tenants. When an application needs the most strict isolation and security compliance and regulatory requirements, the bare metal could be sometimes the only way to go.

Question 11

What are the downsides of bare metal?

Answer 11

Is expensive, hard to manage and hard to scale. acquiring new hardware takes time, and a competent team to manage it well.

Question 12

What’s a hypervisor software?

Answer 12

A hypervisor, also known as a virtual machine monitor (VMM), is software that creates and runs virtual machines (VMs) by separating the physical hardware from the operating systems of the VMs. There are two types of hypervisors: Type 1 (or bare-metal), which runs directly on the hardware, like VMware ESXi, Microsoft Hyper-V, and Xen, and Type 2 (or hosted), which operates on top of a host operating system, like VMware Workstation and Oracle VirtualBox. Hypervisors allow multiple VMs, each with its own OS, to run concurrently on a single physical machine, effectively maximizing resource utilization and providing environment isolation.

Question 13

What is Kubernetes, and what are some of its main features and benefits?

Answer 13

Kubernetes is an open-source platform designed to automate the deployment, scaling, and operation of application containers across clusters of hosts, providing container-centric infrastructure. Here are some of its main features and benefits:

• Orchestration and Management: Kubernetes efficiently manages clusters of containers, handling the deployment and ensuring that the state of containers matches user configurations.
• Scaling: It allows for manual or automatic scaling of applications based on demand, ensuring efficient use of resources.
• Load Balancing: Kubernetes can distribute network traffic so that deployments are stable and performant, automatically finding the best container instance for each request.
• Self-healing: It automatically restarts containers that fail, replaces and reschedules containers when nodes die, and kills containers that don’t respond to user-defined health checks.
• Automated Rollouts and Rollbacks: Kubernetes rolls out changes to the application or its configuration while monitoring application health to ensure it doesn’t kill all your instances at the same time.
• Service Discovery and Load Balancing: Kubernetes groups sets of containers into Pods for easy management and discovery, and provides them with IP addresses and a single DNS name, making it easy to set up load balancing.
• Secret and Configuration Management: Kubernetes can manage sensitive information like passwords and API keys using secrets, and it can deploy and update configuration settings without rebuilding container images.
• Storage Orchestration: It automatically mounts the storage system of your choice, whether from local storage, public cloud providers, or network storage systems.
• Resource Usage Monitoring: Kubernetes allows you to monitor the resource usage of applications through built-in tools like Kubernetes Dashboard or external solutions like Prometheus.
• Extensibility and Flexibility: It supports multiple container runtimes and provides extensive APIs, making it highly extensible and able to integrate with existing infrastructure.
  These features make Kubernetes a powerful tool for modern application deployment and management in the cloud-native ecosystem.

Question 14

What are the components of a Kubernetes cluster, and how do they interact with each other?

Answer 14

A Kubernetes cluster consists of several components that interact to manage the state of the cluster and run applications efficiently:

• Control Plane (Master Node): This central component manages the state of the Kubernetes cluster, making decisions about the cluster (e.g., scheduling) and reacting to cluster events (e.g., starting up a new container when one fails).
• etcd: A consistent and highly-available key value store used as Kubernetes’ backing store for all cluster data. It stores the configuration and state of the cluster, ensuring that data is always available to the control plane components.
• API Server (kube-apiserver): The API server is a component of the Kubernetes control plane that exposes the Kubernetes API. It serves as the front end for the Kubernetes control plane, allowing interaction, management, and configuration through API calls.
• Scheduler (kube-scheduler): The Kubernetes scheduler is a control plane process which assigns Pods to Nodes. It watches for newly created Pods that have no assigned node, and selects a node for them to run on based on resource availability, policy, affinity specifications, and other criteria.
• Controller Manager (kube-controller-manager): This component runs controller processes which regulate the state of the cluster, managing the lifecycle of different resources like nodes, jobs, endpoints, etc.
• Node (Worker Node): Nodes are the workers that run application containers. Each node has the services necessary to run Pods and is managed by the master components.
• Kubelet: Running on nodes, the kubelet is the primary node agent. It watches for tasks sent from the API Server, executes the container tasks, reports back to the master, and ensures that the containers running on the node are healthy.
• Kube-Proxy: This component runs on each node to maintain network rules that allow network communication to your Pods from network sessions inside or outside of your cluster.
• Container Runtime: The underlying software that is used to run containers. Kubernetes is compatible with various container runtimes such as Docker, containerd, and CRI-O.
• Add-ons: These provide cluster features like DNS, which gives a DNS service for the cluster, handling DNS resolution for Kubernetes services, or the Kubernetes Dashboard, a general-purpose, web-based UI for Kubernetes clusters.
  These components interact through the Kubernetes API, which is exposed by the API Server, ensuring that the cluster maintains the desired state and responds appropriately to changes and failures.

Question 15

How can you interact with Kubernetes API?

Answer 15

• kubectl
• directly accessing the rest api (kubectl proxy –port=8080 &then curl http://localhost:8080/api/)
• programmatic access to the api for go python java dotnet etc
  https://kubernetes.io/docs/reference/using-api/client-libraries/

Question 16

Explain these commands:
k create, k get, k describe, k delete, k apply, k logs, k exec, scale, rollout

Answer 16

Here’s an explanation of each of these Kubernetes kubectl commands:

1. kubectl create: This command is used to create a resource in your Kubernetes cluster. You can specify the resource type and provide a YAML or JSON file for the resource configuration. For example, kubectl create -f mypod.yaml creates a pod as defined in the mypod.yaml file.
2. kubectl get: This command retrieves information about one or more resources in your Kubernetes cluster. It can list various resources like pods, services, deployments, etc., and can be used to see their current state. For example, kubectl get pods lists all pods in the current namespace.
3. kubectl describe: This command shows detailed information about a specific resource or group of resources. It includes status, readiness, and other important metadata and is more verbose than kubectl get. For instance, kubectl describe pod mypod gives detailed information about the pod named “mypod”.
4. kubectl delete: This command removes resources from the cluster. You can delete pods, services, deployments, and more, either by specifying the resource type and name or by using a file. For example, kubectl delete -f deploy.yaml deletes the resources defined in the deploy.yaml file.
5. kubectl apply: This command is used to apply a configuration to a resource created from a file or stdin. It is commonly used for updating existing resources or creating resources if they do not already exist. For example, kubectl apply -f mydeployment.yaml updates or creates the deployment as specified.
6. kubectl logs: This command fetches the logs from a container in a pod. If a pod has multiple containers, you specify which container’s logs you want to view. For example, kubectl logs mypod -c mycontainer fetches logs from “mycontainer” within “mypod”.
7. kubectl exec: This command executes a command in a container within a pod. It is often used for diagnostic purposes, such as checking the current environment or running interactive shells. For example, kubectl exec mypod -- ls /app runs the ls /app command inside “mypod”.
8. kubectl scale: This command changes the number of replicas of a specified deployment or other scalable resource. It’s used for manually scaling the number of pods in a deployment, for example, kubectl scale deployment mydeployment --replicas=4 scales “mydeployment” to 4 replicas.
9. kubectl rollout: This command manages a deployment’s rollout process. It can be used to start a new rollout, undo a deployment, or pause/resume an ongoing rollout. For instance, kubectl rollout restart deployment/mydeployment restarts the rollout of “mydeployment”.

These commands form the backbone of most interactions with Kubernetes clusters, providing the tools needed to manage and maintain your applications and their environments.

Question 17

How do you create a Kubernetes deployment, and what are some best practices to follow when defining deployments?

Answer 17

Certainly! When defining Kubernetes deployments, here are some key best practices to follow for better efficiency, reliability, and security:

1. Use Descriptive Labels: Employ meaningful labels with clear key-value pairs to help organize and manage Kubernetes objects more effectively. Labels are crucial for selecting and filtering resources during deployment operations.
2. Define Resource Requests and Limits: It’s important to specify the amount of CPU and memory each container should use. Setting these parameters ensures that containers have the resources they need to operate effectively without monopolizing cluster resources, which helps maintain overall cluster health.
3. Implement Health Checks: Integrate liveness and readiness probes into your container configurations. These checks allow Kubernetes to better manage container lifecycle events like restarts and traffic routing, based on the actual state of your application.
4. Use an Appropriate Update Strategy: Choose a suitable strategy for updating applications, with the most common being RollingUpdate. This strategy minimizes downtime by incrementally updating pods rather than recreating all pods simultaneously, which is crucial for maintaining service availability.
5. Secure Your Applications: Ensure that containers pull images from trusted and secure registries. Specify policies that define how and when images are pulled, and utilize security contexts to enforce privilege and access controls on running containers.

Following these practices helps ensure that Kubernetes deployments are not only stable and performant but also secure and easy to manage.

Question 18

What is an ImagePullPolicy and what values can this parameter hold?

Answer 18

In Kubernetes, the imagePullPolicy is a field within a container’s configuration that determines how the kubelet (the agent running on each node) handles pulling images from the container registry. This policy controls whether or not an image should be pulled prior to starting the container, and it can be crucial for both development and production environments to ensure that the correct image version is being used.

The imagePullPolicy can take one of three values:

1. Always: This setting forces the kubelet to always pull the image from the registry before starting the container, regardless of whether it is already present on the node. This policy is useful in environments where you continuously update images with the same tag (like latest) and need to ensure that the most up-to-date version is always used.
2. IfNotPresent: With this policy, the kubelet pulls the image only if it is not already present on the local node. If the image already exists, regardless of its freshness or version, it won’t be pulled again. This policy is efficient for stable production environments where images don’t change frequently, or for minimizing bandwidth usage.
3. Never: This setting tells the kubelet to never pull the image. It will always use an existing image on the node. If the image is not present, the container will not start. This policy can be useful in tightly controlled environments where you want to strictly manage what images are available on a node or in an offline environment.

Choosing the right imagePullPolicy is essential for controlling how updates to your container images are handled across your Kubernetes cluster.

apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx-container
image: nginx:1.19.0
ports:
- containerPort: 80
imagePullPolicy: Always # Ensures the image is always pulled before starting the container

Question 19

What is a Kubernetes port forward? Why do you use that? What’s the command to perform that?

Answer 19

Kubernetes port forwarding allows you to create a temporary direct connection from a local port to a port on a Kubernetes pod, facilitating secure access to applications running in the cluster without public exposure. This feature is particularly useful for debugging, accessing internal services, or during development phases when immediate access is required without the need for external routing configurations.

kubectl port-forward pod/myapp-pod 8080:80

Question 20

NodePort vs LoadBalancer?

Answer 20

In Kubernetes, NodePort and LoadBalancer are two types of services that expose your applications to external traffic in different ways.
-NodePort service makes your application accessible on a specific port of every node in your cluster, which then routes traffic to the appropriate pods, typically useful for development environments or limited production use.
-LoadBalancer service integrates with a cloud provider’s load balancer to distribute incoming traffic efficiently across all nodes, offering a single access point to clients and is suitable for production environments.

While NodePort allocates a port from a defined range and can be accessed using any node’s IP and the designated port, LoadBalancer simplifies service discovery by providing a stable IP address or hostname. Overall, LoadBalancer is preferred for larger, distributed applications due to its inherent capability to handle more traffic and provide failover solutions.

Question 21

Explain node affinity, node taints, node selectors, and pod priority

Answer 21

Node Affinity
Node affinity in Kubernetes allows you to specify rules that limit which nodes your pod can be scheduled on, based on labels on nodes. It offers more expressive options than simple node selectors, such as soft preferences (preferredDuringSchedulingIgnoredDuringExecution) and hard requirements (requiredDuringSchedulingIgnoredDuringExecution). This feature enhances the scheduler’s ability to allocate pods to suitable nodes according to specific needs, like co-location or spreading.

Node Taints
Node taints are a mechanism to repel a set of pods from a node unless those pods explicitly tolerate the taint. Taints are added to nodes and consist of a key, value, and effect (such as NoSchedule, which prevents pod scheduling unless tolerated). This mechanism is useful for reserving specific nodes for particular workloads based on their requirements or managing node usage policies.

Node Selectors
Node selectors are the simplest form of node selection constraint in Kubernetes; they allow you to restrict pod placement to specific nodes by using labels. A node selector is specified in a pod specification and matches pods to nodes with specific labels. This approach is straightforward but less flexible than node affinity, offering only the capability to enforce placement on labeled nodes.

Pod Priority
Pod priority determines the scheduling importance of a pod relative to other pods, using PriorityClasses. Pods with higher priority values are scheduled before pods with lower priority values, which is crucial when resources are limited. Pod priority can influence scheduling decisions and, in overload situations, can lead to preemption where lower-priority pods are evicted to make room for higher-priority ones.

Question 22

Explain the Pod lifecycle

Answer 22

The Pod lifecycle in Kubernetes describes the sequence of states a Pod goes through from its initiation to its termination in a Kubernetes cluster. It begins when a Pod is created and moves to the Pending state, where it waits for all of its containers to be scheduled and all prerequisites to be satisfied. Once scheduled on a node and all containers start running, it transitions to the Running state. During its operation, a Pod might experience failures, and Kubernetes’ self-healing mechanisms, such as restarts (handled by restart policies), play a role to maintain service continuity. Finally, a Pod reaches the Succeeded or Failed state (if all containers in the Pod terminate successfully or unsuccessfully, respectively), or it can be manually or automatically terminated, leading to the Terminated state where it is removed from the cluster.

Question 23

What is the CrashLoopBackOff state?

Answer 23

The CrashLoopBackOff state in Kubernetes is an error condition that indicates a pod is repeatedly crashing and failing to stay running. This happens when a pod starts up but then crashes or fails shortly after. Kubernetes automatically tries to restart the pod each time it crashes, following its restart policy (usually the default setting is to always try to restart). However, if the pod continues to fail and crash after each restart attempt, Kubernetes applies an exponential backoff delay between restart attempts to prevent overloading the system with continuous failures.

The CrashLoopBackOff state signals that there is a problem with the application running inside the pod that requires investigation. Common causes might include misconfigurations, failing to connect to dependencies, missing environment variables, or errors in the application code itself. The pod will remain in this state until the issue causing the crash is resolved.

Question 24

When is a Pod evicted?

Answer 24

• A Pod in Kubernetes may be evicted under several circumstances, primarily related to resource management and node stability. Pods are evicted when a node experiences resource shortages like insufficient memory or disk space, which triggers the kubelet’s eviction policy to reclaim resources and prevent node failure.
• Kubernetes also evicts pods when performing node maintenance, scaling down operations, or upgrading cluster components, requiring pods to be moved or restarted on different nodes.
• Additionally, if a Pod has a lower priority and the node is under resource strain, higher-priority Pods may cause lower-priority Pods to be preempted and evicted.
• Lastly, administrators can manually evict Pods to manage the cluster workload distribution or to troubleshoot issues within specific nodes or Pods.

Question 25

How many kinds of probe types are there?

Answer 25

In Kubernetes, there are three types of probes used to manage and check the status of the pods:

• Liveness Probes: Determine if a pod is alive and running as expected. If a liveness probe fails, the kubelet kills the container which is then subject to its restart policy.
• Readiness Probes: Check if a pod is ready to serve traffic. If a readiness probe fails, the pod will not receive traffic from Kubernetes services until it passes.
• Startup Probes: Ensure that the application within the container has started up successfully. This is particularly useful for slower starting applications, as it prevents the kubelet from killing the container due to slow startup before it starts serving.

Question 26

What is node affinity?

Answer 26

Node affinity is conceptually similar to nodeSelector, allowing you to constrain which nodes your Pod can be scheduled on based on node labels.

• requiredDuringSchedulingIgnoredDuringExecution:
• preferredDuringSchedulingIgnoredDuringExecution: The scheduler tries to find a node that meets the rule. If a matching node is not available, the scheduler still schedules the Pod.

Question 27

What is pod affinity?

Answer 27

This is easier to explain on an example I guess. The Pod affinity rule tells the scheduler to place each replica on a node that has a Pod with the label app=store. The Pod anti-affinity rule tells the scheduler never to place multiple app=web-store servers on a single node. It is a way to control how to spread pods across different nodes.

Question 28

What is the POD disruption budget?

Answer 28

The Pod Disruption Budget (PDB) is a Kubernetes feature that ensures a specified level of availability during voluntary disruptions. It defines the minimum number of pods that should be available during maintenance or upgrades, preventing too many pods from being evicted simultaneously.

We can define minAvailable, maxUnavailable, and a selector to pick which pods to apply to.

Question 29

What is a Kubernetes volume?

Answer 29

Containers are ephemeral and when a container crashes or is stopped, container state is not saved by default and everything reverts back to the initial state. Also, when multiple containers in a pod need to share files, it is pretty challenging to set up a shared file system across all of these containers. Kubernetes volume solves these problems. It is a directory containing data that can be reached by containers. It can be on the host machine, or somewhere on the network or on a cloud provider.

Question 30

How is a Kubernetes volume different from a container’s file system?

Answer 30

A Kubernetes volume is a storage abstraction that allows data to persist across container restarts and pod rescheduling, whereas a container’s file system is ephemeral and only exists for the lifecycle of that specific container instance.

Question 31

What are some types of Kubernetes volumes?

Answer 31

emptyDir: A temporary directory that is created when a Pod is assigned to a Node and exists as long as the Pod is running. It is useful for scratch space or temporary data.

hostPath: Mounts a file or directory from the host node’s filesystem into a Pod. This is useful for accessing host resources but ties the Pod to a specific node.

persistentVolumeClaim (PVC): A way for users to request dynamically provisioned storage resources. PVCs abstract the details of underlying storage systems, allowing for more portable configurations.

configMap: Provides a way to inject configuration data into Pods. It can be used to mount configuration files or pass configuration data as environment variables.

secret: Similar to ConfigMaps, but intended for sensitive information such as passwords, OAuth tokens, and SSH keys. Secrets are base64 encoded and can be mounted as files or exposed as environment variables.

nfs: Allows an NFS (Network File System) share to be mounted into a Pod. This is useful for sharing data across multiple Pods and nodes.

Question 32

How do you define a Kubernetes volume in a Pod’s YAML configuration?

Answer 32

apiVersion: v1
kind: Pod
metadata:
name: example-pod
spec:
containers:
- name: example-container
image: busybox
command: [“sleep”, “3600”]
volumeMounts:
- mountPath: /mnt/data
name: my-hostpath-volume
volumes:
- name: my-hostpath-volume
hostPath:
path: /data
type: Directory

-mountPath: The path inside the container where the volume will be mounted.
-hostPath: This specifies that the volume is a hostPath volume.
– path: The path on the host node’s filesystem to be mounted into the Pod.
– type: (Optional) The type of the host path. It can be Directory, File, etc. In this example, it is specified as a directory.

Question 33

How do you mount a Kubernetes volume to a container?

Answer 33

apiVersion: v1
kind: Pod
metadata:
name: example-pod
spec:
containers:
- name: example-container
image: busybox
command: [“sleep”, “3600”]
volumeMounts:
- mountPath: /mnt/data
name: my-hostpath-volume
volumes:
- name: my-hostpath-volume
hostPath:
path: /data
type: Directory

-mountPath: The path inside the container where the volume will be mounted.
-hostPath: This specifies that the volume is a hostPath volume.
– path: The path on the host node’s filesystem to be mounted into the Pod.
– type: (Optional) The type of the host path. It can be Directory, File, etc. In this example, it is specified as a directory.

Question 34

Can multiple containers in a Pod share the same volume?

Answer 34

Yes that is the purpose

Question 35

What is a Persistent Volume (PV) in Kubernetes?

Answer 35

A Persistent Volume (PV) in Kubernetes is a cluster-wide storage resource that provides a way for administrators to manage and provision persistent storage independent of individual Pods.

Question 36

How do you define a Persistent Volume in Kubernetes?

Answer 36

apiVersion: v1
kind: PersistentVolume
metadata:
name: example-pv
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
storageClassName: standard
hostPath:
path: /mnt/data

Question 37

What are kubernetes operators?

Answer 37

A kubernetes operator is a method of packaging, deploying, and managing a kubernetes application. An operator extends the kubernetes api with custom resources to manage the lifecycle of an application.

The operator pattern aims to capture the key aim of a human operator who is managing a service or set of services.

Question 38

Why do we need kubernetes operators?

Answer 38

1. Complex Application Management: Some applications have complex operational needs that go beyond the capabilities of simple YAML files. Operators can manage the entire lifecycle, including installation, updates, backups, scaling, and recovery.

2. Automation: Operators enable automation of routine tasks, which reduces the need for manual intervention. This can include scaling applications, managing configurations, or handling failover.

3. Consistency and Reliability: By encoding operational logic into an Operator, we ensure consistent and reliable management of applications. This reduces the chances of human error and ensures that best practices are followed.

4. Customization: Operators can be customized to handle the unique requirements of different applications. This flexibility allows operators to provide advanced functionality that is specific to an application or a set of applications.

Question 39

What is Helm?

Answer 39

Helm is a package manager for Kubernetes. It is primarily used to define, install, and upgrade even complex Kubernetes applications using “charts.” They are essentially collections of YAML files with some templating logic.

Question 40

What is the difference between helm and k8s operators?

Answer 40

Helm can automate the deployment and update of applications, but it doesn’t handle the entire lifecycle. For example, it doesn’t natively handle scaling based on load or automatic failover.

Question 41

When to use helm and operators?

Answer 41

Use Helm:

• For simple to moderately complex applications.
• When you need to quickly deploy and manage applications without much custom operational logic.
• When you prefer a package management approach with versioning and templating.

Use Operators:

• For complex, stateful applications that require custom lifecycle management.
• When you need to automate operational tasks that go beyond deployment and basic updates.
• When your application has specific operational requirements that need custom handling.

Question 42

What are different types of services in kubernetes?

Answer 42

** ClusterIP**
Exposes the Service on a cluster-internal IP. Choosing this value makes the Service only reachable from within the cluster. This is the default that is used if you don’t explicitly specify a type for a Service. You can expose the Service to the public internet using an Ingress or a Gateway.

** NodePort **
Exposes the Service on each Node’s IP at a static port (the NodePort). To make the node port available, Kubernetes sets up a cluster IP address, the same as if you had requested a Service of type: ClusterIP.

** LoadBalancer **
Exposes the Service externally using an external load balancer. Kubernetes does not directly offer a load balancing component; you must provide one, or you can integrate your Kubernetes cluster with a cloud provider.

** ExternalName **
Maps the Service to the contents of the externalName field (for example, to the hostname api.foo.bar.example). The mapping configures your cluster’s DNS server to return a CNAME record with that external hostname value. No proxying of any kind is set up.