|
| 1 | +/////////////////////////////////////////////////////////////////////////////// |
| 2 | + |
| 3 | + Copyright (c) 2019 Oracle and/or its affiliates. All rights reserved. |
| 4 | + |
| 5 | + Licensed under the Apache License, Version 2.0 (the "License"); |
| 6 | + you may not use this file except in compliance with the License. |
| 7 | + You may obtain a copy of the License at |
| 8 | + |
| 9 | + http://www.apache.org/licenses/LICENSE-2.0 |
| 10 | + |
| 11 | + Unless required by applicable law or agreed to in writing, software |
| 12 | + distributed under the License is distributed on an "AS IS" BASIS, |
| 13 | + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| 14 | + See the License for the specific language governing permissions and |
| 15 | + limitations under the License. |
| 16 | + |
| 17 | +/////////////////////////////////////////////////////////////////////////////// |
| 18 | +
|
| 19 | += Network Configuration |
| 20 | +
|
| 21 | +== Logging Configuration |
| 22 | +
|
| 23 | +When configuring a `Pod` in Kubernetes there are a number of settings related to networking and DNS and these can also |
| 24 | +be configured for roles in a `CoherenceCluster`. |
| 25 | +
|
| 26 | +[source,yaml] |
| 27 | +---- |
| 28 | +apiVersion: coherence.oracle.com/v1 |
| 29 | +kind: CoherenceCluster |
| 30 | +metadata: |
| 31 | + name: test-cluster |
| 32 | +spec: |
| 33 | + network: |
| 34 | + hostname: "foo.com" # <1> |
| 35 | + hostNetwork: false # <2> |
| 36 | + hostAliases: |
| 37 | + - ip: "10.10.10.100" # <3> |
| 38 | + hostnames: |
| 39 | + - "a.foo.com" |
| 40 | + - "b.foo.com" |
| 41 | + dnsPolicy: "ClusterFirstWithHostNet" # <4> |
| 42 | + dnsConfig: # <5> |
| 43 | + nameservers: |
| 44 | + - "dns.foo.com" |
| 45 | + - "dns.bar.com" |
| 46 | + searches: |
| 47 | + - "foo.com" |
| 48 | + - "bar.com" |
| 49 | + options: |
| 50 | + - name: "option-name" |
| 51 | + value: "option-value" |
| 52 | +---- |
| 53 | +
|
| 54 | +<1> the `network.hostname` field specifies the hostname of the Pod If not specified, the pod's hostname will be set |
| 55 | +to a system-defined value as per the Kubernetes defaults. |
| 56 | +
|
| 57 | +<2> the `hostNetwork` field setw whether host networking is requested for Pods in a role . If set to true Pods will use |
| 58 | +the host's network namespace. If this option is set, the ports that will be used must be specified. If set to `true` |
| 59 | +care must be taken not to schedule multiple Pods for a role onto the same Kubernetes node. Default to false. |
| 60 | +
|
| 61 | +<3> the `hostAliases` field adds host aliases to the Pods in a roles. |
| 62 | +See the Kubernetes documentation on |
| 63 | +https://kubernetes.io/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases/[Adding entries to Pod /etc/hosts with HostAliases] |
| 64 | +
|
| 65 | +<4> the `dnsPolicy` field sets the DNS policy for the pod. Defaults to "ClusterFirst". Valid values are |
| 66 | +'ClusterFirstWithHostNet', 'ClusterFirst', 'Default' or 'None'. DNS parameters given in DNSConfig will be merged with |
| 67 | +the policy selected with DNSPolicy. To have DNS options set along with hostNetwork, you have to specify DNS policy |
| 68 | +explicitly to 'ClusterFirstWithHostNet'. |
| 69 | +See the Kubernetes documentation on |
| 70 | +https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/[DNS for Services and Pods] |
| 71 | +
|
| 72 | +<5> the `dnsConfig` section sets other DNS configuration that will be applied to Pods for a role. |
| 73 | +See the Kubernetes documentation on |
| 74 | +https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/[DNS for Services and Pods] |
| 75 | +
|
| 76 | +
|
| 77 | +As with other configuration secions in the CRD `spec` the `network` section can be specified under the `spec` section |
| 78 | +if configuring a single implied role or under individual roles if configuring explicit roles or a combination of both |
| 79 | +if configuring explicit roles with defaults. |
| 80 | +
|
| 81 | +=== Setting Network Defaults with Explicit Roles |
| 82 | +
|
| 83 | +If configuring explicit roles with default values it is important to note how some fields are merged. |
| 84 | +
|
| 85 | +==== HostAliases |
| 86 | +
|
| 87 | +When using default values the `hostAliases` field is merged using the `ip` field to identify duplicate aliases. |
| 88 | +For example: |
| 89 | +
|
| 90 | +[source,yaml] |
| 91 | +---- |
| 92 | +apiVersion: coherence.oracle.com/v1 |
| 93 | +kind: CoherenceCluster |
| 94 | +metadata: |
| 95 | + name: test-cluster |
| 96 | +spec: |
| 97 | + network: |
| 98 | + hostAliases: # <1> |
| 99 | + - ip: "10.10.10.100" |
| 100 | + hostnames: |
| 101 | + - "a.foo.com" |
| 102 | + - "b.foo.com" |
| 103 | + - ip: "10.10.10.200" |
| 104 | + hostnames: |
| 105 | + - "a.bar.com" |
| 106 | + - "b.bar.com" |
| 107 | + roles: |
| 108 | + - role: data # <2> |
| 109 | + - role: proxy |
| 110 | + network: |
| 111 | + hostAliases: # <3> |
| 112 | + - ip: "10.10.10.100" |
| 113 | + hostnames: |
| 114 | + - "c.foo.com" |
| 115 | + - ip: "10.10.10.300" |
| 116 | + hostnames: |
| 117 | + - "acme.com" |
| 118 | +---- |
| 119 | +
|
| 120 | +<1> The default `hostAliases` list contains aliases for the ip addresses `10.10.10.100` and `10.10.10.200` |
| 121 | +
|
| 122 | +<2> The `data` role does not specify any `hostAliases` so it will use the default aliases for the ip addresses |
| 123 | +`10.10.10.100` and `10.10.10.200` |
| 124 | +
|
| 125 | +<3> The `proxy` role specifies an alias for the ip addresses `10.10.10.100` and `10.10.10.300` so when the `proxy` |
| 126 | +role's alias list is merged with the defaults the alias for `10.10.10.200` will be inherited from the defaults, the |
| 127 | +`proxy` role's own alias for `10.10.10.100` will override the default alias for the same ip address, and the `proxy` |
| 128 | +role's alias for `10.10.10.300` will also be used. The `proxy` role's effective alias list will be: |
| 129 | +
|
| 130 | +[source,yaml] |
| 131 | +---- |
| 132 | +hostAliases: |
| 133 | + - ip: "10.10.10.100" |
| 134 | + hostnames: |
| 135 | + - "c.foo.com" |
| 136 | + - ip: "10.10.10.200" |
| 137 | + hostnames: |
| 138 | + - "a.bar.com" |
| 139 | + - "b.bar.com" |
| 140 | + - ip: "10.10.10.300" |
| 141 | + hostnames: |
| 142 | + - "acme.com" |
| 143 | +---- |
| 144 | +
|
| 145 | +
|
| 146 | +==== DNS Config NameServers |
| 147 | +
|
| 148 | +The `dnsConfig.nameservers` field is a list of strings so the effective list of `nameservers` that applies for a role is |
| 149 | +any `nameservers` set at the default level with any `nameservers` set for the role appended to it. |
| 150 | +For example: |
| 151 | +
|
| 152 | +[source,yaml] |
| 153 | +---- |
| 154 | +apiVersion: coherence.oracle.com/v1 |
| 155 | +kind: CoherenceCluster |
| 156 | +metadata: |
| 157 | + name: test-cluster |
| 158 | +spec: |
| 159 | + network: |
| 160 | + dnsConfig: |
| 161 | + nameservers: |
| 162 | + - "dns.foo.com" # <1> |
| 163 | + roles: |
| 164 | + - role: data # <2> |
| 165 | + - role proxy |
| 166 | + network: |
| 167 | + dnsConfig: |
| 168 | + nameservers: |
| 169 | + - "dns.bar.com" # <3> |
| 170 | +---- |
| 171 | +
|
| 172 | +<1> The default `dnsConfig.nameservers` list has a single entry for `dns.foo.com` |
| 173 | +
|
| 174 | +<2> The `data` role does not specify a `nameservers` list so it will inherit just the default `dns.foo.com` |
| 175 | +
|
| 176 | +<3> The `proxy` role does specify `nameservers` list so this will be merged with the defaults giving an effective |
| 177 | +list of `dns.foo.com` and `dns.bar.com` |
| 178 | +
|
| 179 | +NOTE: The operator will not attempt to remove duplicate values when merging `nameserver` lists so if a value appears in |
| 180 | +the default list and in a role list then that value will appear twice in the effective list used to create Pods. |
| 181 | +
|
| 182 | +
|
| 183 | +
|
| 184 | +==== DNS Config Searches |
| 185 | +
|
| 186 | +The `dnsConfig.searches` field is a list of strings so the effective list of `searches` that applies for a role is |
| 187 | +any `searches` set at the default level with any `searches` set for the role appended to it. |
| 188 | +For example: |
| 189 | +
|
| 190 | +[source,yaml] |
| 191 | +---- |
| 192 | +apiVersion: coherence.oracle.com/v1 |
| 193 | +kind: CoherenceCluster |
| 194 | +metadata: |
| 195 | + name: test-cluster |
| 196 | +spec: |
| 197 | + network: |
| 198 | + dnsConfig: |
| 199 | + searches: |
| 200 | + - "foo.com" # <1> |
| 201 | + roles: |
| 202 | + - role: data # <2> |
| 203 | + - role proxy |
| 204 | + network: |
| 205 | + dnsConfig: |
| 206 | + searches: |
| 207 | + - "bar.com" # <3> |
| 208 | +---- |
| 209 | +
|
| 210 | +<1> The default `dnsConfig.searches` list has a single entry for `foo.com` |
| 211 | +
|
| 212 | +<2> The `data` role does not specify a `searches` list so it will inherit just the default `foo.com` |
| 213 | +
|
| 214 | +<3> The `proxy` role does specify `searches` list so this will be merged with the defaults giving an effective |
| 215 | +list of `foo.com` and `bar.com` |
| 216 | +
|
| 217 | +NOTE: The operator will not attempt to remove duplicate values when merging `searches` lists so if a value appears in |
| 218 | +the default list and in a role list then that value will appear twice in the effective list used to create Pods. |
| 219 | +
|
| 220 | +
|
| 221 | +==== DNS Config Options |
| 222 | +
|
| 223 | +The `network.dnsConfig.options` field is a list of name/value pairs. If `options` are set at both the default and role |
| 224 | +level then the lists are merged using the `name` to identify options. |
| 225 | +For example: |
| 226 | +
|
| 227 | +[source,yaml] |
| 228 | +---- |
| 229 | +apiVersion: coherence.oracle.com/v1 |
| 230 | +kind: CoherenceCluster |
| 231 | +metadata: |
| 232 | + name: test-cluster |
| 233 | +spec: |
| 234 | + network: |
| 235 | + dnsConfig: |
| 236 | + options: # <1> |
| 237 | + - name: "option-one" |
| 238 | + value: "value-one" |
| 239 | + - name: "option-two" |
| 240 | + value: "value-two" |
| 241 | + roles: |
| 242 | + - role: data # <2> |
| 243 | + - role: proxy |
| 244 | + network: |
| 245 | + dnsConfig: |
| 246 | + options: |
| 247 | + - name: "option-one" # <3> |
| 248 | + value: "different-one" |
| 249 | + - name: "option-three" |
| 250 | + value: "value-three" |
| 251 | +---- |
| 252 | +
|
| 253 | +<1> The default `options` has a single value with `name: option-one`, `value: value-one` and |
| 254 | +`name: option-two`, `value: value-two` |
| 255 | +
|
| 256 | +<2> The `data` role does not specify any options so it will just inherit the defaults of `name: option-one`, |
| 257 | +`value: value-one` and `name: option-two`, `value: value-two` |
| 258 | +
|
| 259 | +<3> The `proxy` role specifies two `options`, one with the name `option-one` which will override the default option |
| 260 | +named `option-one` and an additonal option named `option-three` so the effective list applied to the proxy role will be: |
| 261 | +
|
| 262 | +
|
| 263 | +[source,yaml] |
| 264 | +---- |
| 265 | +options: |
| 266 | + - name: "option-one" |
| 267 | + value: "different-one" |
| 268 | + - name: "option-two" |
| 269 | + value: "value-two" |
| 270 | + - name: "option-three" |
| 271 | + value: "value-three" |
| 272 | +---- |
0 commit comments