You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A Kubernetes _service_ is an abstract way to expose an application running on a set of pods as a network service. Services allow your applications to receive traffic. Services can be exposed in different ways by specifying a `spec.type` in the `Service` object:
10
+
11
+
ClusterIP:: Exposes the service on an internal IP address within the cluster. `ClusterIP` is the default service `type`.
12
+
13
+
NodePort:: Exposes the service on the same port of each selected node in the cluster. `NodePort` makes a service accessible from outside the cluster.
14
+
15
+
LoadBalancer:: Creates an external load balancer in the current cloud (if supported) and assigns a fixed, external IP address to the service.
16
+
17
+
18
+
[id="services-dual-stack-cluster_{context}"]
19
+
== Dual-stack support
20
+
21
+
If IPv4 and IPv6 dual-stack networking is enabled for your cluster, you can create a service that uses IPv4, IPv6, or both, by defining the `spec.ipFamilyPolicy` and the `spec.ipFamilies` fields in the `Service` object.
22
+
23
+
The `spec.ipFamilyPolicy` field can be set to one of the following values:
24
+
25
+
SingleStack:: The control plane assigns a cluster IP address for the service based on the first configured service cluster IP range.
26
+
27
+
PreferDualStack:: The control plane assigns both IPv4 and IPv6 cluster IP addresses for the service on clusters that have dual-stack configured.
28
+
29
+
RequireDualStack:: This option fails for clusters that do not have dual-stack networking enabled. For clusters that have dual-stack configured, the behavior is the same as when the value is set to `PreferDualStack`. The control plane allocates cluster IP addresses from both IPv4 and IPv6 address ranges.
30
+
31
+
You can define which IP family to use for single-stack or define the order of IP families for dual-stack by setting the `spec.ipFamilies` field to one of the following array values:
Create a service from a running virtual machine by first creating a `Service` object to expose the virtual machine.
11
-
12
-
[NOTE]
13
-
====
14
-
If IPv4 and IPv6 dual-stack networking is enabled for your cluster, you can create a service that uses IPv4, IPv6, or both, by defining the `spec.ipFamilyPolicy` and the `spec.ipFamilies` fields in the `Service` object.
15
-
16
-
The `spec.ipFamilyPolicy` field can be set to one of the following values:
17
-
18
-
* `SingleStack`: The control plane assigns a cluster IP address for the service based on the first configured service cluster IP range.
19
-
20
-
* `PreferDualStack`: The control plane assigns both IPv4 and IPv6 cluster IP addresses for the service on clusters that have dual-stack configured.
21
-
22
-
* `RequireDualStack`: This option fails for clusters that do not have dual-stack networking enabled. For clusters that have dual-stack configured, the behavior is the same as when the value is set to `PreferDualStack`. The control plane allocates cluster IP addresses from both IPv4 and IPv6 address ranges.
23
-
24
-
You can define which IP family to use for single-stack or define the order of IP families for dual-stack by setting the `spec.ipFamilies` field to one of the following array values:
25
-
26
-
* `[IPv4]`
27
-
* `[IPv6]`
28
-
* `[IPv4, IPv6]`
29
-
* `[IPv6, IPv4]`
30
-
====
31
-
32
-
The `ClusterIP` service type exposes the virtual machine internally, within the cluster. The `NodePort` or `LoadBalancer` service types expose the virtual machine externally, outside of the cluster.
33
-
34
-
This procedure presents an example of how to create, connect to, and expose a `Service` object of `type: ClusterIP` as a virtual machine-backed service.
35
-
36
-
[NOTE]
37
-
====
38
-
`ClusterIP` is the default service `type`, if the service `type` is not specified.
39
-
====
10
+
Create a `ClusterIP`, `NodePort`, or `LoadBalancer` service to connect to a running virtual machine (VM) from within or outside the cluster.
40
11
41
12
.Procedure
42
13
43
-
. Edit the virtual machine YAML as follows:
14
+
. Edit the `VirtualMachine` manifest to add the label for service creation:
44
15
+
45
-
46
16
[source,yaml]
47
17
----
48
18
apiVersion: kubevirt.io/v1
@@ -56,54 +26,20 @@ spec:
56
26
metadata:
57
27
labels:
58
28
special: key <1>
59
-
spec:
60
-
domain:
61
-
devices:
62
-
disks:
63
-
- name: containerdisk
64
-
disk:
65
-
bus: virtio
66
-
- name: cloudinitdisk
67
-
disk:
68
-
bus: virtio
69
-
interfaces:
70
-
- masquerade: {}
71
-
name: default
72
-
resources:
73
-
requests:
74
-
memory: 1024M
75
-
networks:
76
-
- name: default
77
-
pod: {}
78
-
volumes:
79
-
- name: containerdisk
80
-
containerDisk:
81
-
image: kubevirt/fedora-cloud-container-disk-demo
82
-
- name: cloudinitdisk
83
-
cloudInitNoCloud:
84
-
userData: |
85
-
#cloud-config
86
-
user: fedora
87
-
password: fedora
88
-
chpasswd: {expire: False}
89
29
# ...
90
30
----
91
31
<1> Add the label `special: key` in the `spec.template.metadata.labels` section.
92
32
+
93
33
94
34
[NOTE]
95
35
====
96
-
Labels on a virtual machine are passed through to the pod. The labels on
97
-
the `VirtualMachine` configuration, for example `special: key`, must match the labels in
98
-
the `Service` YAML `selector` attribute, which you create later
99
-
in this procedure.
36
+
Labels on a virtual machine are passed through to the pod. The `special: key` label must match the label in the `spec.selector` attribute of the `Service` manifest.
100
37
====
101
38
102
-
. Save the virtual machine YAML to apply your changes.
39
+
. Save the `VirtualMachine` manifest file to apply your changes.
103
40
104
-
. Edit the `Service` YAML to configure the settings necessary to create and expose the `Service` object:
41
+
. Create a `Service` manifest to expose the VM:
105
42
+
106
-
107
43
[source,yaml]
108
44
----
109
45
apiVersion: v1
@@ -112,148 +48,75 @@ metadata:
112
48
name: vmservice <1>
113
49
namespace: example-namespace <2>
114
50
spec:
51
+
externalTrafficPolicy: Cluster <3>
115
52
ports:
116
-
- port: 27017
53
+
- nodePort: 30000 <4>
54
+
port: 27017
117
55
protocol: TCP
118
-
targetPort: 22 <3>
56
+
targetPort: 22 <5>
119
57
selector:
120
-
special: key <4>
121
-
type: ClusterIP <5>
58
+
special: key <6>
59
+
type: NodePort <7>
122
60
----
123
-
<1> Specify the `name` of the service you are creating and exposing.
124
-
<2> Specify `namespace` in the `metadata` section of the `Service` YAML that corresponds to the `namespace` you specify in the virtual machine YAML.
125
-
<3> Add `targetPort: 22`, exposing the service on SSH port `22`.
126
-
<4> In the `spec` section of the `Service` YAML, add `special: key` to the `selector` attribute, which corresponds to the `labels` you added in the virtual machine YAML configuration file.
127
-
<5> In the `spec` section of the `Service` YAML, add `type: ClusterIP` for a
128
-
ClusterIP service. To create and expose other types of services externally, outside of the cluster, such as `NodePort` and `LoadBalancer`, replace
129
-
`type: ClusterIP` with `type: NodePort` or `type: LoadBalancer`, as appropriate.
130
-
+
61
+
<1> The name of the `Service` object.
62
+
<2> The namespace where the `Service` object resides. This must match the `metadata.namespace` field of the `VirtualMachine` manifest.
63
+
<3> Optional: Specifies how the nodes distribute service traffic that is received on external IP addresses. This only applies to `NodePort` and `LoadBalancer` service types. The default value is `Cluster` which routes traffic evenly to all cluster endpoints.
64
+
<4> Optional: When set, the `nodePort` value must be unique across all services. If not specified, a value in the range above `30000` is dynamically allocated.
65
+
<5> Optional: The VM port to be exposed by the service. It must reference an open port if a port list is defined in the VM manifest. If `targetPort` is not specified, it takes the same value as `port`.
66
+
<6> The reference to the label that you added in the `spec.template.metadata.labels` stanza of the `VirtualMachine` manifest.
67
+
<7> The type of service. Possible values are `ClusterIP`, `NodePort` and `LoadBalancer`.
131
68
132
-
. Save the `Service` YAML to store the service configuration.
133
-
. Create the `ClusterIP` service:
69
+
. Save the `Service` manifest file.
70
+
. Create the service by running the following command:
134
71
+
135
-
136
72
[source,terminal]
137
73
----
138
74
$ oc create -f <service_name>.yaml
139
75
----
140
76
141
-
+
142
-
. Start the virtual machine. If the virtual machine is already running, restart it.
143
-
+
144
-
145
-
+
146
-
. Query the `Service` object to verify it is available and is configured with type `ClusterIP`.
147
-
+
77
+
. Start the VM. If the VM is already running, restart it.
148
78
149
79
.Verification
150
-
* Run the `oc get service` command, specifying the `namespace` that you reference in the virtual machine and `Service` YAML files.
80
+
. Query the `Service` object to verify that it is available:
** As shown from the output, `vmservice` is running.
168
-
** The `TYPE` displays as `ClusterIP`, as you specified in the `Service` YAML.
169
-
170
-
. Establish a connection to the virtual machine that you want to use to back your service. Connect from an object inside the cluster, such as another virtual machine.
* For a `NodePort` service, connect to the VM by specifying the node IP address and the node port outside the cluster network. For example:
238
117
+
239
-
240
-
[NOTE]
241
-
====
242
-
For service type `LoadBalancer`, use the `vinagre` client to connect your
243
-
virtual machine by using the public IP and port.
244
-
External ports are dynamically allocated when using service type
245
-
`LoadBalancer`.
246
-
====
247
-
+
248
-
249
-
.. Run the `ssh` command to authenticate the connection, where `172.30.3.149` is the ClusterIP of the service and `fedora` is the user name of the virtual machine:
250
-
+
251
-
252
118
[source,terminal]
253
119
----
254
-
$ ssh fedora@172.30.3.149 -p 27017
120
+
$ ssh fedora@$NODE_IP -p 30000
255
121
----
256
-
+
257
-
258
-
.Verification
259
-
* You receive the command prompt of the virtual machine backing the service you want to expose. You now have a service backed by a running virtual machine.
122
+
* For a `LoadBalancer` service, use the `vinagre` client to connect to your virtual machine by using the public IP address and port. External ports are dynamically allocated.
* xref:../../../networking/configuring_ingress_cluster_traffic/configuring-ingress-cluster-traffic-nodeport.adoc#configuring-ingress-cluster-traffic-nodeport[Configuring ingress cluster traffic using a NodePort]
19
+
* xref:../../../networking/configuring_ingress_cluster_traffic/configuring-ingress-cluster-traffic-load-balancer.adoc#configuring-ingress-cluster-traffic-load-balancer[Configuring ingress cluster traffic using a load balancer]
0 commit comments