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
(→To do) |
|||
| Regel 409: | Regel 409: | ||
</pre> | </pre> | ||
== Accessing a deployment == | == Accessing a deployment using port-forward == | ||
Now, we'd like to see nginx in action! The pod is listening on an internal port 80 (according to its configuration and the default nginx config). If we want to access this from outside the cluster, there's three ways: | Now, we'd like to see nginx in action! The pod is listening on an internal port 80 (according to its configuration and the default nginx config). If we want to access this from outside the cluster, there's three ways: | ||
* <code>kubectl port-forward</code>, which listens to a local port on the machine where you run <code>kubectl port-forward</code>, and then forwards all connections to a pod. (I've explained above how to configure kubectl so it can run on your own machine when the cluster runs elsewhere.) | * <code>kubectl port-forward</code>, which listens to a local port on the machine where you run <code>kubectl port-forward</code>, and then forwards all connections to a pod. (I've explained above how to configure kubectl so it can run on your own machine when the cluster runs elsewhere.) | ||
* Creating a Service | * Creating a Service, in the next section | ||
* Creating an Ingress | * Creating an Ingress, in the section after that | ||
Let's try creating a port-forward to the pod first: | Let's try creating a port-forward to the pod first: | ||
| 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. | ||
== Accessing a deployment using a Service == | |||
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": | 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": | ||
| Regel 471: | Regel 473: | ||
As you can see, our <code>nginx-service</code> service is now up and it got external port 31106. Indeed, when we go to <code>http://<IP>:31106/</code> (replacing <IP> with the IP of any of our nodes) we can see the page again! Also, when we <code>kubectl delete pod ...</code> arbitrary pods within the deployment, they are restarted automatically, and accesses to the external IP/port keep working as long as at least one pod is <code>Running</code>. | As you can see, our <code>nginx-service</code> service is now up and it got external port 31106. Indeed, when we go to <code>http://<IP>:31106/</code> (replacing <IP> with the IP of any of our nodes) we can see the page again! Also, when we <code>kubectl delete pod ...</code> arbitrary pods within the deployment, they are restarted automatically, and accesses to the external IP/port keep working as long as at least one pod is <code>Running</code>. | ||
== Accessing a Deployment using an Ingress == | |||
= Creating your own images = | = Creating your own images = | ||