bureaucraten, interfacemoderatoren, Beheerders (Semantic MediaWiki), Curatoren (Semantic MediaWiki), Redacteuren (Semantic MediaWiki), toezichthouders, beheerders
205
bewerkingen
Projects:Kubernetes: verschil tussen versies
Naar navigatie springen
Naar zoeken springen
→Accessing a deployment
| Regel 436: | Regel 436: | ||
When you start a port-forward to a deployment, the deployment is resolved to a random one of the <code>Running</code> pods in the deployment. So, in this case, you'll get a response from ''either'' of the two pods; if one of them is down, you'll get it from the one that's up. (If both are down, you're out of luck.) However, when that resolved pod goes down for whatever reason, the port-forward is '''not''' restarted to another pod in the deployment. You can try this out by running <code>kubectl delete pod nginx-deployment-...</code> on your pods: the deployment will cause them to be restarted, but the port-forward will cease to work once you've deleted the right one. | When you start a port-forward to a deployment, the deployment is resolved to a random one of the <code>Running</code> pods in the deployment. So, in this case, you'll get a response from ''either'' of the two pods; if one of them is down, you'll get it from the one that's up. (If both are down, you're out of luck.) However, when that resolved pod goes down for whatever reason, the port-forward is '''not''' restarted to another pod in the deployment. You can try this out by running <code>kubectl delete pod nginx-deployment-...</code> on your pods: the deployment will cause them to be restarted, but the port-forward will cease to work once you've deleted the right one. | ||
So, what should we do if we want the application to be reachable even if its Pods go down? The first method is to create a [https://kubernetes.io/docs/concepts/services-networking/service/ Service]. A Service describes how an application should be accessible. There's multiple types of Services, corresponding with multiple interpretations of "accessible": | |||
* <code>ClusterIP</code> is a service type indicating that the application should be internally accessible using a "virtual service IP" (as described above). This service IP will be allocated by Kubernetes and distributed to all nodes and pods, so that a connection to the virtual service IP on the correct port will automatically end up on one of its running Pods. | |||
* <code>NodePort</code> is a service type indicating that the application should be externally accessible using a "service port" on all Nodes. The service port will be allocated by Kubernetes (you can choose it, but that's not recommended) and distributed to all nodes, so that a connection to any node on the service port will automatically end up on one of its running Pods. | |||
* TODO: describe the other service types | |||
= Creating your own images = | = Creating your own images = | ||