-
Notifications
You must be signed in to change notification settings - Fork 1
kubernetes
- Containers
- Kubernetes Architecture
- Kubernetes Objects
Kubernetes is an open-source system for automating deployment, scaling, and management of containerized applications. Kubernetes simplifies and automates the process of deploying containerized applications at scale. Kubernetes provides a container-centric management environment. It orchestrates computing, networking, and storage infrastructure on behalf of user workloads.
The principle of single responsibility is an important design pattern when looking at building scalable applications with Kubernetes.
One of the key pieces of the master (not included in the visual) is etcd. It is a lightweight and distributed key/value store that holds configuration data. Each node, or kubelet, can access this data in etcd through a HTTP/JSON API interface.
The New Way is to deploy containers based on operating-system-level virtualization rather than hardware virtualization. These containers are isolated from each other and from the host: they have their own filesystems, they can’t see each others’ processes, and their computational resource usage can be bounded. They are easier to build than VMs, and because they are decoupled from the underlying infrastructure and from the host filesystem, they are portable across clouds and OS distributions.
At its base, Kubernetes brings together individual physical or virtual machines into a cluster using a shared network to communicate between each server.
At a high-level, a Kubernetes cluster comprises a master and a set of nodes.
- the Master coordinates the cluster
- nodes are the workers that run applications
The Master is responsible for managing the cluster. The master coordinates all activities in your cluster, such as scheduling applications, maintaining applications' desired state, scaling applications, and rolling out new updates. This server acts as a gateway and brain for the cluster by exposing an API for users and clients, health checking other servers, deciding how best to split up and assign work (known as "scheduling"), and orchestrating communication between other components. The master server acts as the primary point of contact with the cluster and is responsible for most of the centralized logic Kubernetes provides.
The master is the Kubernetes control plane and has a number of cluster-wide components,including an API server that tools (e.g. kubectl) use to interact with the cluster.
The other machines in the cluster are designated as nodes: servers responsible for accepting and running workloads using local and external resources.
A node is a VM or a physical computer that serves as a worker machine in a Kubernetes cluster. Each node has a Kubelet, which is an agent for managing the node and communicating with the Kubernetes master.
When you deploy applications on Kubernetes, you tell the master to start the application containers. The master schedules the containers to run on the cluster's nodes. The nodes communicate with the master using the Kubernetes API, which the master exposes.
One of the fundamental components that Kubernetes needs to function is a globally available configuration store. Kubernetes uses etcd to store configuration data that can be used by each of the nodes in the cluster.
The etcd project, developed by the CoreOS team, is a lightweight, distributed key-value store that can be distributed across multiple nodes.
Labels are a simple but important concept in Kubernetes. Labels are key/value pairs attached to objects in Kubernetes, like pods. Kubernetes uses etcd to store configuration data that can be used by each of the nodes in the cluster.
One of the most important master services is an API server. This is the main management point of the entire cluster as it allows a user to configure Kubernetes' workloads and organizational units. It is also responsible for making sure that the etcd store and the service details of deployed containers are in agreement. It acts as the bridge between various components to maintain cluster health and disseminate information and commands.
The API server implements a RESTful interface, which means that many different tools and libraries can readily communicate with it. A client called kubectl is available as a default method of interacting with the Kubernetes cluster from a local computer. For Kubernetes to be useful, it needs to know what sort of cluster state you want it to maintain.
Your YAML or JSON configuration files declare this desired state in terms of one or more API objects, such as Deployments. To make updates to your cluster’s state, you submit these files to the Kubernetes API server kube-apiserver.
The controller manager is a general service that has many responsibilities. Primarily, it manages different controllers that regulate the state of the cluster, manage workload life cycles, and perform routine tasks. For instance, a replication controller ensures that the number of replicas (identical copies) defined for a pod matches the number currently deployed on the cluster. The details of these operations are written to etcd, where the controller manager watches for changes through the API server.
The process that actually assigns workloads to specific nodes in the cluster is the scheduler. This service reads in a workload's operating requirements, analyzes the current infrastructure environment, and places the work on an acceptable node or nodes.
Collection of machines that run containerized applications managed by Kubernetes. Check the location and credentials of a cluster with this command:
# kubectl config view
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: REDACTED
server: https://83.166.150.131/k8s/clusters/c-r6fms
name: tth
contexts:
- context:
cluster: tth
user: user-x2jxr
name: tth
current-context: tth
kind: Config
preferences: {}
users:
- name: user-x2jxr
user:
token: kubeconfig-user-x2jxr:vwt24mcxw2psbdwfwz9bbscgrqxcdctfq8fsrrh54n5r59hkpv7kzrThe above URL is the way to access our cluster API server. Kubectl handles locating and authenticating to the apiserver. To directly access the REST API with an http client like curl or wget, or a browser, there are several ways to locate and authenticate:
Run kubectl in proxy mode is the recommanded approach.
Start the proxy with # kubectl proxy --port=8080 then from inside the node run # curl http://localhost:8080
A NodePort service is the most primitive way to get external traffic directly to your service. NodePort, as the name implies, opens a specific port on all the Nodes (the VMs), and any traffic that is sent to this port is forwarded to the service.
Basically, a NodePort service has two difference from a normal ClusterIP service. First, the type is “NodePort.” There is also an additional port called the nodePort that specifies which port to open on the nodes. If you don’t specify this port, it will pick a random port. Most of the time you should let Kubernetes choose the port
Kubernetes contains a number of abstractions that represent the state of your system: deployed containerized applications and workloads, their associated network and disk resources, and other information about what your cluster is doing. These abstractions are represented by objects in the Kubernetes API.
Kubernetes Objects are persistent entities in the Kubernetes system. Kubernetes uses these entities to represent the state of your cluster. Specifically, they can describe:
- What containerized applications are running (and on which nodes)
- The resources available to those applications
- The policies around how those applications behave, such as restart policies, upgrades, and fault-tolerance
Pods, replication controllers and services are the fundamental units of Kubernetes used to describe the desired state of a system.
The controlling services in a Kubernetes cluster are called the master, or control plane, components.
If you imagine Kubernetes as a Lego® castle, pods are the smallest block you can pick out. By themselves, they are the smallest unit you can deploy. Pods are collections of Docker containers co-located on the same host. These containers have shared fate (i.e. they start and stop together) and can share data using volumes. Typically, a pod may only contain a single container (e.g. a web server), but other containers may also exist in a pod and share network namespace and volumes. All the containers in a pod can reach each other on localhost.
If you have containers that are tightly coupled and share a lot of I/O then you may want them on the same machine and allow them to share resources.
When the pods share the same namespace, all the containers in a pod:
- Share an IP address
- Share port space
- Find each other over localhost
- Communicate over IPC namespace
- Have access to shared volumes
A Pod is the basic building block of Kubernetes–the smallest and simplest unit in the Kubernetes object model that you create or deploy. A Pod encapsulates an application container (or, in some cases, multiple containers), storage resources, a unique network IP, and options that govern how the container(s) should run.
Deployment are one of the most common workloads to directly create and manage. Deployments use replication sets as a building block, adding flexible life cycle management functionality to the mix.
Deployments are a declarative way to deploy and manage software. A Deployment is a new way to handle High Availability (HA) in Kubernetes in place of the Replication Controller. A pod by itself is “mortal” but with a Deployment, Kubernetes can make sure that the number of Pods that a user specifies is always up and running in the system. A Deployment specifies how many instances of a pod will run. A YAML file is used to define a Deployment.
Deployments are a high level object designed to ease the life cycle management of replicated pods. Deployments can be modified easily by changing the configuration and Kubernetes will adjust the replica sets, manage transitions between different application versions, and optionally maintain event history and undo capabilities automatically. Because of these features, deployments will likely be the type of Kubernetes object you work with most frequently.
Workloads are
Often, when working with Kubernetes, rather than working with single pods, you will instead be managing groups of identical, replicated pods. These are created from pod templates and can be horizontally scaled by controllers known as replication controllers and replication sets.
Replica sets are where some of the magic begins to happen with automatic scheduling or rescheduling. Replica sets ensure that a number of pod instances (called replicas) are running at any moment.
A replication controller is an object that defines a pod template and control parameters to scale identical replicas of a pod horizontally by increasing or decreasing the number of running copies. This is an easy way to distribute load and increase availability natively within Kubernetes. The replication controller knows how to create new pods as needed because a template that closely resembles a pod definition is embedded within the replication controller configuration.
Replication sets are an iteration on the replication controller design with greater flexibility in how the controller identifies the pods it is meant to manage.
kind: Service
apiVersion: v1
metadata:
name: my-service
spec:
selector:
app: MyApp
ports:
- protocol: TCP
port: 80
targetPort: 9376A service groups together logical collections of pods that perform the same function to present them as a single entity. Services allow you to expose your microservices (that run in pods) both internally and externally between the other running pods. The service object exposes a consistent IP and port for the microservice. Any call to that IP will be routed to one of the microservice’s running Pods.
Any time you need to provide access to one or more pods to another application or to external consumers, you should to configure a service. For instance, if you have a set of pods running web servers that should be accessible from the internet, a service will provide the necessary abstraction. Likewise, if your web servers need to store and retrieve data, you would want to configure an internal service to give them access to your database pods.
Although services, by default, are only available using an internally routable IP address, they can be made available outside of the cluster by choosing one of several strategies. The NodePort configuration works by opening a static port on each node's external networking interface. Traffic to the external port will be routed automatically to the appropriate pods using an internal cluster IP service.
Alternatively, the LoadBalancer service type creates an external load balancer to route to the service using a cloud provider's Kubernetes load balancer integration. The cloud controller manager will create the appropriate resource and configure it using the internal service service addresses.
The solution is to run the traffic through a reverse-proxy/load balancer. Clients connect to the proxy and the proxy is responsible for maintaining a list of healthy servers to forward requests to.
This implies a few requirements for the proxy: it must itself be durable and resistant to failure; it must have a list of servers it can forward to; and it must have some way of knowing if a particular server is healthy and able to respond to requests. The kubernetes designers solved this problem in an elegant way that builds on the basic capabilities of the platform to deliver on all three of those requirements, and it starts with a resource type called a service.
A Kubernetes Service is an abstraction which defines a logical set of Pods and a policy by which to access them - sometimes called a micro-service. The set of Pods targeted by a Service is (usually) determined by a Label Selector.
On our cluster tth, here is an example of the services :
# kubectl get service --all-namespaces
NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
cluster-management etcd-cluster ClusterIP None <none> 2379/TCP,2380/TCP 4d
cluster-management longhorn-backend ClusterIP 10.43.71.23 <none> 9500/TCP 1h
cluster-management longhorn-frontend ClusterIP 10.43.59.225 <none> 80/TCP 1h
default kubernetes ClusterIP 10.43.0.1 <none> 443/TCP 6d
ingress-nginx default-http-backend ClusterIP 10.43.71.61 <none> 80/TCP 6d
kube-system kube-dns ClusterIP 10.43.0.10 <none> 53/UDP,53/TCP 6d
web-http myloadbalancer-traefik NodePort 10.43.196.130 <none> 80:30838/TCP,443:31608/TCP 3h
web-http myloadbalancer-traefik-dashboard ClusterIP 10.43.145.185 <none> 80/TCP 3h
web-http mywebserver ClusterIP None <none> 80/TCP 6dHere are the services started on our cluster by kube-system:
# kubectl cluster-info
Kubernetes master is running at https://83.166.150.131/k8s/clusters/c-r6fms
KubeDNS is running at https://83.166.150.131/k8s/clusters/c-r6fms/api/v1/namespaces/kube-system/services/kube-dns:dns/proxyA Volume is a directory with data that is accessible to all containers running in a pod and gets mounted into each containers filesystem. Its lifetime is identical to the lifetime of the pod. Decoupling the volume lifetime from the container lifetime allows the volume to persist across container crashes and restarts. Volumes further can be backed by host's filesystem, by persistent block storage volumes.
Persistent volumes are a mechanism for abstracting more robust storage that is not tied to the pod life cycle. Instead, they allow administrators to configure storage resources for the cluster that users can request and claim for the pods they are running.
Once a pod is done with a persistent volume, the volume's reclamation policy determines whether the volume is kept around until manually deleted or removed along with the data immediately. Persistent data can be used to guard against node-based failures and to allocate greater amounts of storage than is available locally.
Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called Namespaces.
Namespaces are intended for use in environments with many users spread across multiple teams, or projects. For clusters with a few to tens of users, you should not need to create or think about namespaces at all. Start using namespaces when you need the features they provide.
The main contact point for each node with the cluster group is a small service called kubelet. This service is responsible for relaying information to and from the control plane services, as well as interacting with the etcd store to read configuration details or write new values.
The kubelet is the primary “node agent” that runs on each node. The kubelet works in terms of a PodSpec. A PodSpec is a YAML or JSON object that describes a pod. The kubelet takes a set of PodSpecs that are provided through various mechanisms (primarily through the apiserver) and ensures that the containers described in those PodSpecs are running and healthy.
Once you’ve declared your desired state through the Kubernetes API, it is the controllers work to make the cluster’s current state match this desired state.
All of these controllers implement a control loop. For simplicity, you can think of this as the following:
What is the current state of the cluster (X)?
What is the desired state of the cluster (Y)?
X == Y ?
true - Do nothing.
false - Perform tasks to get to Y (such as starting or restarting containers, or scaling the number of replicas of a given application).
(Return to 1)ConfigMaps allow to decouple configuration artifacts from image content to keep containerized applications portable. From a data perspective, the ConfigMap type is just a set of key-value pairs.
You can use environment variables and configuration files to store this information in a “central location” and reference these from our app. When you want to change the configuration, simply change it in the file or change the environment variable, and you are good to go! No need to hunt down every location where the data is referenced.
As far as networking is concerned pod is the network endpoint. So essentially Kubernetes networking is all about connectivity between Pods.
Containers within a pod share an IP address and port space, and can find each other via localhost. They can also communicate with each other using standard inter-process communications.
Each Pod is assigned a unique IP address. Every container in a Pod shares the network namespace, including the IP address and network ports. Containers inside a Pod can communicate with one another using localhost. When containers in a Pod communicate with entities outside the Pod, they must coordinate how they use the shared network resources (such as ports).
Kubernetes networking took a completely different approach to network containers. We could call it an Internet like approach to networking. The fundamental change was that every pod will have their own IP address and they could be accessible from the other pods regardless of which host the pod is on and there won’t be any NAT translations in pod to pod or node to pod or pod to node communications.
This creates a clean, backwards-compatible model where pods can be treated much like VMs or physical hosts from the perspectives of port allocation, naming, service discovery, load balancing, application configuration, and migration.
- Kubernetes pods should be able to communicate with other Kubernetes pods on the same host or on a different host without requiring NAT.
- Every host (node) in a Kubernetes cluster should be able to communicate with Kubernetes pods on the local or remote hosts, again without requiring NAT.
- Every Kubernetes pod should be directly addressable with the same IP address that it sees itself as having.
Flannel container networking solution is one method to achieve Kubernetes networking.
NOTE:
Kubernetes creates special containers for each pod whose only purpose is to provide a network interface for the other containers. If you ssh in to a kubernetes cluster node that has pods scheduled on it and run docker ps you will see at least one container that was started with the pause command. The pause command suspends the current process until a signal is received so these containers do nothing at all except sleep until kubernetes sends them a SIGTERM.
Despite this lack of activity the “pause” container is the heart of the pod, providing the virtual network interface that all the other containers will use to communicate with each other and the outside world.
Flannel is a simple and easy way to configure a layer 3 network fabric designed for Kubernetes.
Flannel runs a small, single binary agent called flanneld on each host, and is responsible for allocating a subnet lease to each host out of a larger, preconfigured address space. Flannel uses either the Kubernetes API or etcd directly to store the network configuration, the allocated subnets, and any auxiliary data (such as the host's public IP). Packets are forwarded using one of several backend mechanisms including VXLAN and various cloud integrations.
Flannel does not control how containers are networked to the host, only how the traffic is transported between hosts.
Flannel is focused on networking. For network policy, other projects such as Calico can be used.
From inside a node:
# ip a
.....
496: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN group default
link/ether 56:98:f9:f1:80:72 brd ff:ff:ff:ff:ff:ff
inet 10.42.5.0/32 scope global flannel.1
valid_lft forever preferred_lft forever
inet6 fe80::5498:f9ff:fef1:8072/64 scope link
valid_lft forever preferred_lft forever# cat /var/run/flannel/subnet.env
FLANNEL_NETWORK=10.42.0.0/16
FLANNEL_SUBNET=10.42.5.1/24
FLANNEL_MTU=1450
FLANNEL_IPMASQ=trueKubernetes uses CNI plug-ins to orchestrate networking. Every time a POD is initialized or removed, the default CNI plug-in is called with the default configuration.
This CNI plug-in creates a pseudo interface, attaches it to the relevant underlay network, sets the IP and routes and maps it to the POD namespace.
Kubernetes DNS schedules a DNS Pod and Service on the cluster, and configures the kubelets to tell individual containers to use the DNS Service’s IP to resolve DNS names.
In kubernetes the standard DNS resolver is kube-dns, which is a pod in the kube-system namespace that runs a dnsmasq container (a lightweight DHCP and caching DNS server) as well as a container with some custom golang glue that interfaces between the dns server and the rest of the cluster control plane.
# kubectl get svc kube-dns -n kube-system
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kube-dns ClusterIP 10.43.0.10 <none> 53/UDP,53/TCP 4d# docker exec -ti d3627b245a53 cat /etc/resolv.conf
nameserver 10.43.0.10
search default.svc.cluster.local svc.cluster.local cluster.local infomaniak.ch
options ndots:5Kubernetes supports 2 primary modes of finding a Service - environment variables and DNS.
# docker inspect MyContainer
.....
"Env": [
"KUBERNETES_SERVICE_HOST=10.43.0.1",
"KUBERNETES_SERVICE_PORT=443",
"KUBERNETES_SERVICE_PORT_HTTPS=443",
"KUBERNETES_PORT=tcp://10.43.0.1:443",
"KUBERNETES_PORT_443_TCP=tcp://10.43.0.1:443",
"KUBERNETES_PORT_443_TCP_PROTO=tcp",
"KUBERNETES_PORT_443_TCP_PORT=443",
"KUBERNETES_PORT_443_TCP_ADDR=10.43.0.1",An optional (though strongly recommended) cluster add-on is a DNS server. The DNS server watches the Kubernetes API for new Services and creates a set of DNS records for each. If DNS has been enabled throughout the cluster then all Pods should be able to do name resolution of Services automatically.
For example, if you have a Service called my-service in Kubernetes Namespace my-ns a DNS record for my-service.my-ns is created.
Kubernetes also supports DNS SRV (service) records for named ports. If the my-service.my-ns Service has a port named http with protocol TCP, you can do a DNS SRV query for "_http._tcp.my-service.my-ns" to discover the port number for http
Kubernetes ServiceTypes allow you to specify what kind of service you want. The default is ClusterIP.
Type values and their behaviors are:
- 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 ServiceType.
- NodePort: Exposes the service on each Node’s IP at a static port (the NodePort). A ClusterIP service, to which the NodePort service will route, is automatically created. You’ll be able to contact the NodePort service, from outside the cluster, by requesting [NodeIP]:[NodePort].
- LoadBalancer: Exposes the service externally using a cloud provider’s load balancer. NodePort and ClusterIP services, to which the external load balancer will route, are automatically created.
- ExternalName: Maps the service to the contents of the externalName field (e.g. foo.bar.example.com), by returning a CNAME record with its value. No proxying of any kind is set up.
Inter service communication (within the Kubernetes cluster) comes out of the box. By leveraging the internal DNS we simply reference another service by name and our requests will be routed appropriately. This is an over simplification of course, but in most cases this just works. However, if we want to expose any of our applications to the outside world we require another solution.
Kubernetes ingress is a collection of routing rules that govern how external users access services running in a Kubernetes cluster. Ingress is an API resource which represents a set of traffic routing rules that map external traffic to K8s services. Ingress allows external traffic to land in the cluster in a particular service.
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: bobox
annotations:
kubernetes.io/ingress.class: "traefik"
spec:
rules:
- host: seedbox.archifleks.net
http:
paths:
- backend:
serviceName: h5ai
servicePort: 80
- host: tv.archifleks.net
http:
paths:
- backend:
serviceName: sickrage
servicePort: 8081
- host: torrents.archifleks.net
http:
paths:
- backend:
serviceName: rtorrent-internal
servicePort: 80
- host: movies.archifleks.net
http:
paths:
- backend:
serviceName: couchpotato
servicePort: 5050NOTES: each virtual host is routed to one different backend. Each backend shall have one Kubernetes service which makes TCP/UDP to all pods via Kube-proxy.
There are four general strategies in Kubernetes for ingress.
You can expose a Service in these ways:
1- Kubernete Proxy
2- Using a Kubernetes service of type NodePort, which exposes the application on a port across each of your nodes
3- Use a Kubernetes Ingress Resource, or Ingress controller
4- Use a Kubernetes service of type LoadBalancer, which creates an external load balancer that points to a Kubernetes service in your cluster
A ClusterIP service is the default Kubernetes service. It gives you a service inside your cluster that other apps inside your cluster can access. There is no external access, but you can access it using the Kubernetes proxy.
A service is assigned an IP, called the cluster IP to which requests intended for the pods are sent. Recall that the service’s cluster IP is in an IP address range that is separate from the pod network, and from the network that the nodes themselves are on.
This network is implemented by a kubernetes component called kube-proxy collaborating with a linux kernel module called netfilter to trap and reroute traffic sent to the cluster IP so that it is sent to a healthy pod instead.
A NodePort is an open port on every node of your cluster. Kubernetes transparently routes incoming traffic on the NodePort to your service, even if your application is running on a different node. A service of type NodePort is a ClusterIP service with an additional capability: it is reachable at the IP address of the node as well as at the assigned cluster IP on the services network.
The way this is accomplished is pretty straightforward: when kubernetes creates a NodePort service kube-proxy allocates a port in the range 30000–32767 and opens this port on the eth0 interface of every node (thus the name “NodePort”). Connections to this port are forwarded to the service’s cluster IP.
NodePorts are the fundamental mechanism by which all external traffic gets into a kubernetes cluster.
Ingress is actually NOT a type of service. Instead, it sits in front of multiple services and act as a smart router or entrypoint into your cluster. For example, you can send everything on foo.yourdomain.com to the foo service, and everything under the yourdomain.com/bar/ path to the bar service.
All external traffic ends up entering the cluster through a NodePort as described above. Services of type LoadBalancer have some limitations. These limitations led to the addition in version 1.2 of a separate kubernetes resource for configuring load balancers, called an Ingress.
Ingress is an API object that manages external access to the services in a cluster, typically HTTP. Ingress can provide load balancing, SSL termination and name-based virtual hosting.
It is a collection of rules that allow inbound connections to reach the cluster services.
Ingress is probably the most powerful way to expose your services, but can also be the most complicated.
internet
|
[ Ingress ]
--|-----|--
[ Services ]- List ingress
# kubectl get ingress --all-namespaces
NAMESPACE NAME HOSTS ADDRESS PORTS AGE
cluster-management myvolumes-ingress traefik.thetradinghall.com 80 5h
web-http myloadbalancer-traefik-dashboard traefik.thetradinghall.com 80 6h- Definition for one Ingress
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: myvolumes-ingress
spec:
rules:
- host: traefik.thetradinghall.com
http:
paths:
- backend:
serviceName: longhorn-frontend
servicePort: 80
status:
loadBalancer: {}NOTE: DNS entries have been made.
Ingress can be secured by specifying a secret that contains a TLS private key and certificate. Currently the Ingress only supports a single TLS port, 443, and assumes TLS termination. If the TLS configuration section in an Ingress specifies different hosts, they will be multiplexed on the same port according to the hostname specified through the SNI TLS extension (provided the Ingress controller supports SNI). The TLS secret must contain keys named tls.crt and tls.key that contain the certificate and private key to use for TLS,
An Ingress Controller is a daemon, deployed as a Kubernetes Pod, that watches the apiserver's ingresses endpoint for updates to the Ingress resource. Its job is to satisfy requests for Ingresses.
A load balancer provides an externally-accessible IP address that sends traffic to the correct port on your cluster nodes provided your cluster runs in a supported environment and is configured with the correct cloud load balancer provider package.
LoadBalancer services are all about extending a single service to support external clients. By contrast an Ingress is a separate resource that configures a load balancer much more flexibly. It can easily set up a load balancer to handle multiple backend services.
In order for the Ingress resource to work, the cluster must have an Ingress controller running. Rancher uses nginx-ingress-controller.
NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE
ingress-nginx nginx-ingress-controller-45xtg 1/1 Running 1 5d 10.52.11.199 control2
ingress-nginx nginx-ingress-controller-jqnq2 1/1 Running 0 5d 10.52.11.193 control1
ingress-nginx nginx-ingress-controller-x6hd2 1/1 Running 0 5d 10.52.16.22 workerDefault backend is a special service endpoint which will handle the traffic that arrives at the ingress and does not match any of the configured routes in the ingress route map.
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
default-http-backend ClusterIP 10.43.71.61 <none> 80/TCP 5dA reverse proxy server is a server that typically sits in front of other web servers in order to provide additional functionality that the web servers may not provide themselves. A reverse proxy can provide SSL termination, load balancing, request routing, caching, compression
Docker containers are assigned random IPs and ports which makes addressing them much more complicated from a client perspsective. By default, the IPs and ports are private to the host and cannot be accessed externally unless they are bound to the host.
Binding the container to the hosts port can prevent multiple containers from running on the same host. For example, only one container can bind to port 80 at a time. This also complicates rolling out new versions of the container without downtime since the old container must be stopped before the new one is started.
A reverse proxy can help with these issues as well as improve availabilty by facilitating zero-downtime deployments.
To use a load balancer for distributing client traffic to the nodes in a cluster we need a public IP the clients can connect to, and we need addresses on the nodes themselves to which the load balancer can forward the requests.
load balancing improves the distribution of workloads across multiple computing resources, such as computers or computer cluster. Load balancing aims to optimize resource use, maximize throughput, minimize response time, and avoid overload of any single resource. Using multiple components with load balancing instead of a single component may increase reliability and availability through redundancy.
The load balancer will route traffic to a Kubernetes service (or ingress) on the cluster that will perform service-specific routing. In this set up, the load balancer provides a stable endpoint (IP address) for external traffic to access. Both ingress controllers and Kubernetes services require an external load balancer, and NodePorts are not designed to be directly used for production.
In Kubernetes, the nodes, pods and services all have their own IPs- In many cases, the node IPs, pod IPs, and some service IPs on a cluster will not be routable, so they will not be reachable from a machine outside the cluster, such as your desktop machine.
There are everal options for connecting to nodes, pods and services from outside the cluster:
https://vadosware.io/post/securing-your-kubernetes-cluster/
rancher is a a complete container manager platform. It is intended to deploy and manage kubernetes with ease.
Please visit the Rancher wiki page for all details.
Following this guide we will install Kubernetes on Rancher server.
Let’s first add an environment for Kubernetes. An environment in Rancher is a logical entity for sharing deployments and resources with different sets of users. Everything is done in context of an environment. Rancher supports grouping resources into multiple environments. Each environment starts with a set of infrastructure services defined by the environment template used to create the environment.
What is an Environment Template
An environment template allows users to define a different combination of infrastructure services to be deployed. The infrastructure services includes but not limited to container orchestration (i.e. cattle, kubernetes, mesos, swarm), networking, rancher services (i.e healthcheck, dns, metadata, scheduling, service discovery and storage.
here is the list of needed ports.
- Play with Kubernetes classroom
- Fedora magazine: introduction to Kubernetes
- Container technology wiki
- Kubectl cheat sheet
- Kubernetes beginner guide
- Basic Kubernetes concept
- Ingress nginx official doc
- Digital ocean: introduction to kubernetes
- blog: getting start with local deployment
- Hello minikube on Feodra 25
- Postgres DB on Kubernetes
- Secrets and Vault
- Weave cloud
- Understand Kubernetes networking
- Kubernetes networking
- Flannel
- Kubernetes networking
- DNS resolution
- Container solution: ingress kubernetes
- Kubernetes hardening