Projects:Kubernetes: verschil tussen versies

Projects:Kubernetes (bekijk bron)

Versie van 10 mrt 2019 18:26

2.179 bytes toegevoegd , 10 mrt 2019

geen bewerkingssamenvatting

bureaucraten, interfacemoderatoren, Beheerders (Semantic MediaWiki), Curatoren (Semantic MediaWiki), Redacteuren (Semantic MediaWiki), toezichthouders, beheerders

205

bewerkingen

@@ Regel 56: / Regel 56: @@
 * '''Node''': A machine that actually runs the Containers. Can be bare-metal or a virtual machine, or even an embedded IoT device. A Node runs a process called "Kubelet" which interacts with the Docker daemon (usually) to set everything up, but normally you never communicate directly with it.
-* '''Control Plane''': A set of some applications (API server, controller manager, proxy, scheduler, etcd...) that make sure the cluster is "healthy". For example, it starts Pods when you request it to, but also when a Node goes down that was running Pods, it restarts those Pods elsewhere. These applications all run in Pods, in a separate namespace called "kube-system".
+* '''Control Plane''': A set of some applications (API server, etcd, controller manager, scheduler...) that make sure the cluster is "healthy". For example, it starts Pods when you request it to, but also when a Node goes down that was running Pods, it restarts those Pods elsewhere. These applications all run in Pods, in a separate namespace called "kube-system".
 * '''Master node''': Otherwise a normal Node, but it runs the Control Plane applications. By default, a Master node will only run Pods for these applications, but you can configure it to allow normal Pods too. There can be multiple Master nodes, for redundancy of the cluster.
+= Understanding networking =
+Networking within a Kubernetes cluster isn't difficult, but requires some specific explanation. Applications within Kubernetes containers need to be able to access each other, regardless of whether they run on the same Node or not. To make it worse, Nodes may be running behind firewalls or may be running in different subnets. Luckily, Kubernetes has some mechanisms that make it very robust against this.
+When setting up a Kubernetes cluster, there are two important internal IP ranges throughout the cluster:
+* '''The Pod network range'''. This internal range is automatically split over Nodes, and Pods get individual addresses from it.
+ * For example, you can set this to 10.123.0.0/16; the master node will likely get 10.123.0.0/24 and the second Node you add after that gets 10.123.1.0/24 and so on. A Pod running on this second node may have 10.123.1.55 as an IP address. (If the Pod has multiple containers, all of them will have the same IP address.)
+* '''The service network range'''. When you register a Service, such as "my-fun-webserver", it automatically gets an IP address within this range. An application called the 'kube-proxy', running automatically on every Node, then takes care that any communication with this IP address is forwarded to one of the actual Pods providing that service (by configuring iptables). Fun fact: the Kubernetes API server registers itself as a service and is always available at the first host address of the range you chose.
+ * For example, your service network range may be 10.96.0.0/16; the Kubernetes API service makes itself available at 10.96.0.1. When you communicate with this IP address, the communication is automatically translated (by iptables) to be sent to the Pod IP address of the Kubernetes API service, e.g. 10.123.1.55.
+It's important that these ranges don't overlap, and they also both shouldn't overlap with any relevant IP ranges within your existing network! The Kubernetes folks suggest you use something within 10.0.0.0/8 if your local network range is within 192.168.0.0/16 and vice-versa.
+To do: explain CNI
 = Setting it all up =
+With that all behind us, let's start setting up our first cluster!