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 439: | Regel 439: | ||
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": | ||
* <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>ClusterIP</code> is a service type indicating that the application should be only 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. | * <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. A NodePort service also automatically gets a ClusterIP, so you can use that, too. | ||
* TODO: describe the other service types | * TODO: describe the other service types | ||
Since we want our service to be externally accessible, we'll make a NodePort service: | |||
<pre> | |||
$ cat service.yaml | |||
apiVersion: v1 | |||
kind: Service | |||
metadata: | |||
name: nginx-service | |||
spec: | |||
ports: | |||
- name: nginx | |||
port: 80 | |||
protocol: TCP | |||
selector: | |||
app: nginx | |||
type: NodePort | |||
$ kubectl apply -f service.yaml | |||
$ kubectl get services | |||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE | |||
kubernetes ClusterIP 10.16.0.1 <none> 443/TCP 8d | |||
nginx-service NodePort 10.16.247.178 <none> 80:31106/TCP 4s | |||
</pre> | |||
When we define the Service, we provide a Selector which defines the Pods supplying this Service. You can supply arbitrary labels to Pods; the <code>app=nginx</code> label was initially set in our Deployment (see the <code>metadata</code> section) and is inherited by all Pods created by it, so the Service will use them directly. | |||
As you can see, our <code>nginx-service</code> service is now up and it got external port 31106. | |||
= Creating your own images = | = Creating your own images = | ||