djpbessems/ContainerImage.Pinniped
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
8fac6cb9a4
ContainerImage.Pinniped/deploy/supervisor/service.yaml

102 lines
3.1 KiB
YAML
Raw Normal View History

Improve the selectors of Deployments and Services Fixes #801. The solution is complicated by the fact that the Selector field of Deployments is immutable. It would have been easy to just make the Selectors of the main Concierge Deployment, the Kube cert agent Deployment, and the various Services use more specific labels, but that would break upgrades. Instead, we make the Pod template labels and the Service selectors more specific, because those not immutable, and then handle the Deployment selectors in a special way. For the main Concierge and Supervisor Deployments, we cannot change their selectors, so they remain "app: app_name", and we make other changes to ensure that only the intended pods are selected. We keep the original "app" label on those pods and remove the "app" label from the pods of the Kube cert agent Deployment. By removing it from the Kube cert agent pods, there is no longer any chance that they will accidentally get selected by the main Concierge Deployment. For the Kube cert agent Deployment, we can change the immutable selector by deleting and recreating the Deployment. The new selector uses only the unique label that has always been applied to the pods of that deployment. Upon recreation, these pods no longer have the "app" label, so they will not be selected by the main Concierge Deployment's selector. The selector of all Services have been updated to use new labels to more specifically target the intended pods. For the Concierge Services, this will prevent them from accidentally including the Kube cert agent pods. For the Supervisor Services, we follow the same convention just to be consistent and to help future-proof the Supervisor app in case it ever has a second Deployment added to it. The selector of the auto-created impersonation proxy Service was also previously using the "app" label. There is no change to this Service because that label will now select the correct pods, since the Kube cert agent pods no longer have that label. It would be possible to update that selector to use the new more specific label, but then we would need to invent a way to pass that label into the controller, so it seemed like more work than was justified.
2021-09-14 20:35:10 +00:00
#! Copyright 2020-2021 the Pinniped contributors. All Rights Reserved.
Support installing concierge and supervisor into existing namespace - New optional ytt value called `into_namespace` means install into that preexisting namespace rather than creating a new namespace for each app - Also ensure that every resource that is created statically by our yaml at install-time by either app is labeled consistently - Also support adding custom labels to all of those resources from a new ytt value called `custom_labels`
2020-10-14 22:05:42 +00:00
#! SPDX-License-Identifier: Apache-2.0
Allow creation of different Service types in Supervisor ytt templates - Tiltfile and prepare-for-integration-tests.sh both specify the NodePort Service using `--data-value-yaml 'service_nodeport_port=31234'` - Also rename the namespaces used by the Concierge and Supervisor apps during integration tests running locally
2020-10-09 23:00:11 +00:00
#@ load("@ytt:data", "data")
Improve the selectors of Deployments and Services Fixes #801. The solution is complicated by the fact that the Selector field of Deployments is immutable. It would have been easy to just make the Selectors of the main Concierge Deployment, the Kube cert agent Deployment, and the various Services use more specific labels, but that would break upgrades. Instead, we make the Pod template labels and the Service selectors more specific, because those not immutable, and then handle the Deployment selectors in a special way. For the main Concierge and Supervisor Deployments, we cannot change their selectors, so they remain "app: app_name", and we make other changes to ensure that only the intended pods are selected. We keep the original "app" label on those pods and remove the "app" label from the pods of the Kube cert agent Deployment. By removing it from the Kube cert agent pods, there is no longer any chance that they will accidentally get selected by the main Concierge Deployment. For the Kube cert agent Deployment, we can change the immutable selector by deleting and recreating the Deployment. The new selector uses only the unique label that has always been applied to the pods of that deployment. Upon recreation, these pods no longer have the "app" label, so they will not be selected by the main Concierge Deployment's selector. The selector of all Services have been updated to use new labels to more specifically target the intended pods. For the Concierge Services, this will prevent them from accidentally including the Kube cert agent pods. For the Supervisor Services, we follow the same convention just to be consistent and to help future-proof the Supervisor app in case it ever has a second Deployment added to it. The selector of the auto-created impersonation proxy Service was also previously using the "app" label. There is no change to this Service because that label will now select the correct pods, since the Kube cert agent pods no longer have that label. It would be possible to update that selector to use the new more specific label, but then we would need to invent a way to pass that label into the controller, so it seemed like more work than was justified.
2021-09-14 20:35:10 +00:00
#@ load("helpers.lib.yaml", "labels", "deploymentPodLabel", "namespace", "defaultResourceName", "defaultResourceNameWithSuffix")
Allow creation of different Service types in Supervisor ytt templates - Tiltfile and prepare-for-integration-tests.sh both specify the NodePort Service using `--data-value-yaml 'service_nodeport_port=31234'` - Also rename the namespaces used by the Concierge and Supervisor apps during integration tests running locally
2020-10-09 23:00:11 +00:00
Supervisor listens for HTTPS on port 443 with configurable TLS certs - TLS certificates can be configured on the OIDCProviderConfig using the `secretName` field. - When listening for incoming TLS connections, choose the TLS cert based on the SNI hostname of the incoming request. - Because SNI hostname information on incoming requests does not include the port number of the request, we add a validation that OIDCProviderConfigs where the issuer hostnames (not including port number) are the same must use the same `secretName`. - Note that this approach does not yet support requests made to an IP address instead of a hostname. Also note that `localhost` is considered a hostname by SNI. - Add port 443 as a container port to the pod spec. - A new controller watches for TLS secrets and caches them in memory. That same in-memory cache is used while servicing incoming connections on the TLS port. - Make it easy to configure both port 443 and/or port 80 for various Service types using our ytt templates for the supervisor. - When deploying to kind, add another nodeport and forward it to the host on another port to expose our new HTTPS supervisor port to the host.
2020-10-27 00:03:26 +00:00
#@ if data.values.service_http_nodeport_port or data.values.service_https_nodeport_port:
Allow creation of different Service types in Supervisor ytt templates - Tiltfile and prepare-for-integration-tests.sh both specify the NodePort Service using `--data-value-yaml 'service_nodeport_port=31234'` - Also rename the namespaces used by the Concierge and Supervisor apps during integration tests running locally
2020-10-09 23:00:11 +00:00
---
apiVersion: v1
kind: Service
metadata:
Support installing concierge and supervisor into existing namespace - New optional ytt value called `into_namespace` means install into that preexisting namespace rather than creating a new namespace for each app - Also ensure that every resource that is created statically by our yaml at install-time by either app is labeled consistently - Also support adding custom labels to all of those resources from a new ytt value called `custom_labels`
2020-10-14 22:05:42 +00:00
name: #@ defaultResourceNameWithSuffix("nodeport")
namespace: #@ namespace()
labels: #@ labels()
prevent kapp from altering the selector of our services This makes it so that our service selector will match exactly the YAML we specify instead of including an extra "kapp.k14s.io/app" key. This will take us closer to the standard kubectl behavior which is desirable since we want to avoid future bugs that only manifest when kapp is not used. Signed-off-by: Monis Khan <mok@vmware.com>
2021-09-15 20:08:49 +00:00
#! prevent kapp from altering the selector of our services to match kubectl behavior
annotations:
kapp.k14s.io/disable-default-label-scoping-rules: ""
Allow creation of different Service types in Supervisor ytt templates - Tiltfile and prepare-for-integration-tests.sh both specify the NodePort Service using `--data-value-yaml 'service_nodeport_port=31234'` - Also rename the namespaces used by the Concierge and Supervisor apps during integration tests running locally
2020-10-09 23:00:11 +00:00
spec:
type: NodePort
Improve the selectors of Deployments and Services Fixes #801. The solution is complicated by the fact that the Selector field of Deployments is immutable. It would have been easy to just make the Selectors of the main Concierge Deployment, the Kube cert agent Deployment, and the various Services use more specific labels, but that would break upgrades. Instead, we make the Pod template labels and the Service selectors more specific, because those not immutable, and then handle the Deployment selectors in a special way. For the main Concierge and Supervisor Deployments, we cannot change their selectors, so they remain "app: app_name", and we make other changes to ensure that only the intended pods are selected. We keep the original "app" label on those pods and remove the "app" label from the pods of the Kube cert agent Deployment. By removing it from the Kube cert agent pods, there is no longer any chance that they will accidentally get selected by the main Concierge Deployment. For the Kube cert agent Deployment, we can change the immutable selector by deleting and recreating the Deployment. The new selector uses only the unique label that has always been applied to the pods of that deployment. Upon recreation, these pods no longer have the "app" label, so they will not be selected by the main Concierge Deployment's selector. The selector of all Services have been updated to use new labels to more specifically target the intended pods. For the Concierge Services, this will prevent them from accidentally including the Kube cert agent pods. For the Supervisor Services, we follow the same convention just to be consistent and to help future-proof the Supervisor app in case it ever has a second Deployment added to it. The selector of the auto-created impersonation proxy Service was also previously using the "app" label. There is no change to this Service because that label will now select the correct pods, since the Kube cert agent pods no longer have that label. It would be possible to update that selector to use the new more specific label, but then we would need to invent a way to pass that label into the controller, so it seemed like more work than was justified.
2021-09-14 20:35:10 +00:00
selector: #@ deploymentPodLabel()
Allow creation of different Service types in Supervisor ytt templates - Tiltfile and prepare-for-integration-tests.sh both specify the NodePort Service using `--data-value-yaml 'service_nodeport_port=31234'` - Also rename the namespaces used by the Concierge and Supervisor apps during integration tests running locally
2020-10-09 23:00:11 +00:00
ports:
Supervisor listens for HTTPS on port 443 with configurable TLS certs - TLS certificates can be configured on the OIDCProviderConfig using the `secretName` field. - When listening for incoming TLS connections, choose the TLS cert based on the SNI hostname of the incoming request. - Because SNI hostname information on incoming requests does not include the port number of the request, we add a validation that OIDCProviderConfigs where the issuer hostnames (not including port number) are the same must use the same `secretName`. - Note that this approach does not yet support requests made to an IP address instead of a hostname. Also note that `localhost` is considered a hostname by SNI. - Add port 443 as a container port to the pod spec. - A new controller watches for TLS secrets and caches them in memory. That same in-memory cache is used while servicing incoming connections on the TLS port. - Make it easy to configure both port 443 and/or port 80 for various Service types using our ytt templates for the supervisor. - When deploying to kind, add another nodeport and forward it to the host on another port to expose our new HTTPS supervisor port to the host.
2020-10-27 00:03:26 +00:00
#@ if data.values.service_http_nodeport_port:
- name: http
protocol: TCP
port: #@ data.values.service_http_nodeport_port
Run as non-root I tried to follow a principle of encapsulation here - we can still default to peeps making connections to 80/443 on a Service object, but internally we will use 8080/8443. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2020-11-02 16:57:05 +00:00
targetPort: 8080
Supervisor listens for HTTPS on port 443 with configurable TLS certs - TLS certificates can be configured on the OIDCProviderConfig using the `secretName` field. - When listening for incoming TLS connections, choose the TLS cert based on the SNI hostname of the incoming request. - Because SNI hostname information on incoming requests does not include the port number of the request, we add a validation that OIDCProviderConfigs where the issuer hostnames (not including port number) are the same must use the same `secretName`. - Note that this approach does not yet support requests made to an IP address instead of a hostname. Also note that `localhost` is considered a hostname by SNI. - Add port 443 as a container port to the pod spec. - A new controller watches for TLS secrets and caches them in memory. That same in-memory cache is used while servicing incoming connections on the TLS port. - Make it easy to configure both port 443 and/or port 80 for various Service types using our ytt templates for the supervisor. - When deploying to kind, add another nodeport and forward it to the host on another port to expose our new HTTPS supervisor port to the host.
2020-10-27 00:03:26 +00:00
#@ if data.values.service_http_nodeport_nodeport:
nodePort: #@ data.values.service_http_nodeport_nodeport
Specify the supervisor NodePort Service's `port` and `nodePort` separately When using kind we forward the node's port to the host, so we only really care about the `nodePort` value. For acceptance clusters, we put an Ingress in front of a NodePort Service, so we only really care about the `port` value.
2020-10-22 22:37:35 +00:00
#@ end
Supervisor listens for HTTPS on port 443 with configurable TLS certs - TLS certificates can be configured on the OIDCProviderConfig using the `secretName` field. - When listening for incoming TLS connections, choose the TLS cert based on the SNI hostname of the incoming request. - Because SNI hostname information on incoming requests does not include the port number of the request, we add a validation that OIDCProviderConfigs where the issuer hostnames (not including port number) are the same must use the same `secretName`. - Note that this approach does not yet support requests made to an IP address instead of a hostname. Also note that `localhost` is considered a hostname by SNI. - Add port 443 as a container port to the pod spec. - A new controller watches for TLS secrets and caches them in memory. That same in-memory cache is used while servicing incoming connections on the TLS port. - Make it easy to configure both port 443 and/or port 80 for various Service types using our ytt templates for the supervisor. - When deploying to kind, add another nodeport and forward it to the host on another port to expose our new HTTPS supervisor port to the host.
2020-10-27 00:03:26 +00:00
#@ end
#@ if data.values.service_https_nodeport_port:
- name: https
protocol: TCP
port: #@ data.values.service_https_nodeport_port
Run as non-root I tried to follow a principle of encapsulation here - we can still default to peeps making connections to 80/443 on a Service object, but internally we will use 8080/8443. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2020-11-02 16:57:05 +00:00
targetPort: 8443
Supervisor listens for HTTPS on port 443 with configurable TLS certs - TLS certificates can be configured on the OIDCProviderConfig using the `secretName` field. - When listening for incoming TLS connections, choose the TLS cert based on the SNI hostname of the incoming request. - Because SNI hostname information on incoming requests does not include the port number of the request, we add a validation that OIDCProviderConfigs where the issuer hostnames (not including port number) are the same must use the same `secretName`. - Note that this approach does not yet support requests made to an IP address instead of a hostname. Also note that `localhost` is considered a hostname by SNI. - Add port 443 as a container port to the pod spec. - A new controller watches for TLS secrets and caches them in memory. That same in-memory cache is used while servicing incoming connections on the TLS port. - Make it easy to configure both port 443 and/or port 80 for various Service types using our ytt templates for the supervisor. - When deploying to kind, add another nodeport and forward it to the host on another port to expose our new HTTPS supervisor port to the host.
2020-10-27 00:03:26 +00:00
#@ if data.values.service_https_nodeport_nodeport:
nodePort: #@ data.values.service_https_nodeport_nodeport
#@ end
#@ end
Allow creation of different Service types in Supervisor ytt templates - Tiltfile and prepare-for-integration-tests.sh both specify the NodePort Service using `--data-value-yaml 'service_nodeport_port=31234'` - Also rename the namespaces used by the Concierge and Supervisor apps during integration tests running locally
2020-10-09 23:00:11 +00:00
#@ end
Supervisor listens for HTTPS on port 443 with configurable TLS certs - TLS certificates can be configured on the OIDCProviderConfig using the `secretName` field. - When listening for incoming TLS connections, choose the TLS cert based on the SNI hostname of the incoming request. - Because SNI hostname information on incoming requests does not include the port number of the request, we add a validation that OIDCProviderConfigs where the issuer hostnames (not including port number) are the same must use the same `secretName`. - Note that this approach does not yet support requests made to an IP address instead of a hostname. Also note that `localhost` is considered a hostname by SNI. - Add port 443 as a container port to the pod spec. - A new controller watches for TLS secrets and caches them in memory. That same in-memory cache is used while servicing incoming connections on the TLS port. - Make it easy to configure both port 443 and/or port 80 for various Service types using our ytt templates for the supervisor. - When deploying to kind, add another nodeport and forward it to the host on another port to expose our new HTTPS supervisor port to the host.
2020-10-27 00:03:26 +00:00
#@ if data.values.service_http_clusterip_port or data.values.service_https_clusterip_port:
Allow creation of different Service types in Supervisor ytt templates - Tiltfile and prepare-for-integration-tests.sh both specify the NodePort Service using `--data-value-yaml 'service_nodeport_port=31234'` - Also rename the namespaces used by the Concierge and Supervisor apps during integration tests running locally
2020-10-09 23:00:11 +00:00
---
apiVersion: v1
kind: Service
metadata:
Support installing concierge and supervisor into existing namespace - New optional ytt value called `into_namespace` means install into that preexisting namespace rather than creating a new namespace for each app - Also ensure that every resource that is created statically by our yaml at install-time by either app is labeled consistently - Also support adding custom labels to all of those resources from a new ytt value called `custom_labels`
2020-10-14 22:05:42 +00:00
name: #@ defaultResourceNameWithSuffix("clusterip")
namespace: #@ namespace()
labels: #@ labels()
prevent kapp from altering the selector of our services This makes it so that our service selector will match exactly the YAML we specify instead of including an extra "kapp.k14s.io/app" key. This will take us closer to the standard kubectl behavior which is desirable since we want to avoid future bugs that only manifest when kapp is not used. Signed-off-by: Monis Khan <mok@vmware.com>
2021-09-15 20:08:49 +00:00
#! prevent kapp from altering the selector of our services to match kubectl behavior
annotations:
kapp.k14s.io/disable-default-label-scoping-rules: ""
Allow creation of different Service types in Supervisor ytt templates - Tiltfile and prepare-for-integration-tests.sh both specify the NodePort Service using `--data-value-yaml 'service_nodeport_port=31234'` - Also rename the namespaces used by the Concierge and Supervisor apps during integration tests running locally
2020-10-09 23:00:11 +00:00
spec:
type: ClusterIP
Improve the selectors of Deployments and Services Fixes #801. The solution is complicated by the fact that the Selector field of Deployments is immutable. It would have been easy to just make the Selectors of the main Concierge Deployment, the Kube cert agent Deployment, and the various Services use more specific labels, but that would break upgrades. Instead, we make the Pod template labels and the Service selectors more specific, because those not immutable, and then handle the Deployment selectors in a special way. For the main Concierge and Supervisor Deployments, we cannot change their selectors, so they remain "app: app_name", and we make other changes to ensure that only the intended pods are selected. We keep the original "app" label on those pods and remove the "app" label from the pods of the Kube cert agent Deployment. By removing it from the Kube cert agent pods, there is no longer any chance that they will accidentally get selected by the main Concierge Deployment. For the Kube cert agent Deployment, we can change the immutable selector by deleting and recreating the Deployment. The new selector uses only the unique label that has always been applied to the pods of that deployment. Upon recreation, these pods no longer have the "app" label, so they will not be selected by the main Concierge Deployment's selector. The selector of all Services have been updated to use new labels to more specifically target the intended pods. For the Concierge Services, this will prevent them from accidentally including the Kube cert agent pods. For the Supervisor Services, we follow the same convention just to be consistent and to help future-proof the Supervisor app in case it ever has a second Deployment added to it. The selector of the auto-created impersonation proxy Service was also previously using the "app" label. There is no change to this Service because that label will now select the correct pods, since the Kube cert agent pods no longer have that label. It would be possible to update that selector to use the new more specific label, but then we would need to invent a way to pass that label into the controller, so it seemed like more work than was justified.
2021-09-14 20:35:10 +00:00
selector: #@ deploymentPodLabel()
Allow creation of different Service types in Supervisor ytt templates - Tiltfile and prepare-for-integration-tests.sh both specify the NodePort Service using `--data-value-yaml 'service_nodeport_port=31234'` - Also rename the namespaces used by the Concierge and Supervisor apps during integration tests running locally
2020-10-09 23:00:11 +00:00
ports:
Supervisor listens for HTTPS on port 443 with configurable TLS certs - TLS certificates can be configured on the OIDCProviderConfig using the `secretName` field. - When listening for incoming TLS connections, choose the TLS cert based on the SNI hostname of the incoming request. - Because SNI hostname information on incoming requests does not include the port number of the request, we add a validation that OIDCProviderConfigs where the issuer hostnames (not including port number) are the same must use the same `secretName`. - Note that this approach does not yet support requests made to an IP address instead of a hostname. Also note that `localhost` is considered a hostname by SNI. - Add port 443 as a container port to the pod spec. - A new controller watches for TLS secrets and caches them in memory. That same in-memory cache is used while servicing incoming connections on the TLS port. - Make it easy to configure both port 443 and/or port 80 for various Service types using our ytt templates for the supervisor. - When deploying to kind, add another nodeport and forward it to the host on another port to expose our new HTTPS supervisor port to the host.
2020-10-27 00:03:26 +00:00
#@ if data.values.service_http_clusterip_port:
- name: http
protocol: TCP
port: #@ data.values.service_http_clusterip_port
Run as non-root I tried to follow a principle of encapsulation here - we can still default to peeps making connections to 80/443 on a Service object, but internally we will use 8080/8443. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2020-11-02 16:57:05 +00:00
targetPort: 8080
Supervisor listens for HTTPS on port 443 with configurable TLS certs - TLS certificates can be configured on the OIDCProviderConfig using the `secretName` field. - When listening for incoming TLS connections, choose the TLS cert based on the SNI hostname of the incoming request. - Because SNI hostname information on incoming requests does not include the port number of the request, we add a validation that OIDCProviderConfigs where the issuer hostnames (not including port number) are the same must use the same `secretName`. - Note that this approach does not yet support requests made to an IP address instead of a hostname. Also note that `localhost` is considered a hostname by SNI. - Add port 443 as a container port to the pod spec. - A new controller watches for TLS secrets and caches them in memory. That same in-memory cache is used while servicing incoming connections on the TLS port. - Make it easy to configure both port 443 and/or port 80 for various Service types using our ytt templates for the supervisor. - When deploying to kind, add another nodeport and forward it to the host on another port to expose our new HTTPS supervisor port to the host.
2020-10-27 00:03:26 +00:00
#@ end
#@ if data.values.service_https_clusterip_port:
- name: https
protocol: TCP
port: #@ data.values.service_https_clusterip_port
Run as non-root I tried to follow a principle of encapsulation here - we can still default to peeps making connections to 80/443 on a Service object, but internally we will use 8080/8443. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2020-11-02 16:57:05 +00:00
targetPort: 8443
Supervisor listens for HTTPS on port 443 with configurable TLS certs - TLS certificates can be configured on the OIDCProviderConfig using the `secretName` field. - When listening for incoming TLS connections, choose the TLS cert based on the SNI hostname of the incoming request. - Because SNI hostname information on incoming requests does not include the port number of the request, we add a validation that OIDCProviderConfigs where the issuer hostnames (not including port number) are the same must use the same `secretName`. - Note that this approach does not yet support requests made to an IP address instead of a hostname. Also note that `localhost` is considered a hostname by SNI. - Add port 443 as a container port to the pod spec. - A new controller watches for TLS secrets and caches them in memory. That same in-memory cache is used while servicing incoming connections on the TLS port. - Make it easy to configure both port 443 and/or port 80 for various Service types using our ytt templates for the supervisor. - When deploying to kind, add another nodeport and forward it to the host on another port to expose our new HTTPS supervisor port to the host.
2020-10-27 00:03:26 +00:00
#@ end
Allow creation of different Service types in Supervisor ytt templates - Tiltfile and prepare-for-integration-tests.sh both specify the NodePort Service using `--data-value-yaml 'service_nodeport_port=31234'` - Also rename the namespaces used by the Concierge and Supervisor apps during integration tests running locally
2020-10-09 23:00:11 +00:00
#@ end
Supervisor listens for HTTPS on port 443 with configurable TLS certs - TLS certificates can be configured on the OIDCProviderConfig using the `secretName` field. - When listening for incoming TLS connections, choose the TLS cert based on the SNI hostname of the incoming request. - Because SNI hostname information on incoming requests does not include the port number of the request, we add a validation that OIDCProviderConfigs where the issuer hostnames (not including port number) are the same must use the same `secretName`. - Note that this approach does not yet support requests made to an IP address instead of a hostname. Also note that `localhost` is considered a hostname by SNI. - Add port 443 as a container port to the pod spec. - A new controller watches for TLS secrets and caches them in memory. That same in-memory cache is used while servicing incoming connections on the TLS port. - Make it easy to configure both port 443 and/or port 80 for various Service types using our ytt templates for the supervisor. - When deploying to kind, add another nodeport and forward it to the host on another port to expose our new HTTPS supervisor port to the host.
2020-10-27 00:03:26 +00:00
#@ if data.values.service_http_loadbalancer_port or data.values.service_https_loadbalancer_port:
Allow creation of different Service types in Supervisor ytt templates - Tiltfile and prepare-for-integration-tests.sh both specify the NodePort Service using `--data-value-yaml 'service_nodeport_port=31234'` - Also rename the namespaces used by the Concierge and Supervisor apps during integration tests running locally
2020-10-09 23:00:11 +00:00
---
apiVersion: v1
kind: Service
metadata:
Support installing concierge and supervisor into existing namespace - New optional ytt value called `into_namespace` means install into that preexisting namespace rather than creating a new namespace for each app - Also ensure that every resource that is created statically by our yaml at install-time by either app is labeled consistently - Also support adding custom labels to all of those resources from a new ytt value called `custom_labels`
2020-10-14 22:05:42 +00:00
name: #@ defaultResourceNameWithSuffix("loadbalancer")
namespace: #@ namespace()
labels: #@ labels()
prevent kapp from altering the selector of our services This makes it so that our service selector will match exactly the YAML we specify instead of including an extra "kapp.k14s.io/app" key. This will take us closer to the standard kubectl behavior which is desirable since we want to avoid future bugs that only manifest when kapp is not used. Signed-off-by: Monis Khan <mok@vmware.com>
2021-09-15 20:08:49 +00:00
#! prevent kapp from altering the selector of our services to match kubectl behavior
annotations:
kapp.k14s.io/disable-default-label-scoping-rules: ""
Allow creation of different Service types in Supervisor ytt templates - Tiltfile and prepare-for-integration-tests.sh both specify the NodePort Service using `--data-value-yaml 'service_nodeport_port=31234'` - Also rename the namespaces used by the Concierge and Supervisor apps during integration tests running locally
2020-10-09 23:00:11 +00:00
spec:
type: LoadBalancer
Improve the selectors of Deployments and Services Fixes #801. The solution is complicated by the fact that the Selector field of Deployments is immutable. It would have been easy to just make the Selectors of the main Concierge Deployment, the Kube cert agent Deployment, and the various Services use more specific labels, but that would break upgrades. Instead, we make the Pod template labels and the Service selectors more specific, because those not immutable, and then handle the Deployment selectors in a special way. For the main Concierge and Supervisor Deployments, we cannot change their selectors, so they remain "app: app_name", and we make other changes to ensure that only the intended pods are selected. We keep the original "app" label on those pods and remove the "app" label from the pods of the Kube cert agent Deployment. By removing it from the Kube cert agent pods, there is no longer any chance that they will accidentally get selected by the main Concierge Deployment. For the Kube cert agent Deployment, we can change the immutable selector by deleting and recreating the Deployment. The new selector uses only the unique label that has always been applied to the pods of that deployment. Upon recreation, these pods no longer have the "app" label, so they will not be selected by the main Concierge Deployment's selector. The selector of all Services have been updated to use new labels to more specifically target the intended pods. For the Concierge Services, this will prevent them from accidentally including the Kube cert agent pods. For the Supervisor Services, we follow the same convention just to be consistent and to help future-proof the Supervisor app in case it ever has a second Deployment added to it. The selector of the auto-created impersonation proxy Service was also previously using the "app" label. There is no change to this Service because that label will now select the correct pods, since the Kube cert agent pods no longer have that label. It would be possible to update that selector to use the new more specific label, but then we would need to invent a way to pass that label into the controller, so it seemed like more work than was justified.
2021-09-14 20:35:10 +00:00
selector: #@ deploymentPodLabel()
Allow ytt templating of the `loadBalancerIP` for the supervisor
2020-10-28 23:45:23 +00:00
#@ if data.values.service_loadbalancer_ip:
loadBalancerIP: #@ data.values.service_loadbalancer_ip
#@ end
Allow creation of different Service types in Supervisor ytt templates - Tiltfile and prepare-for-integration-tests.sh both specify the NodePort Service using `--data-value-yaml 'service_nodeport_port=31234'` - Also rename the namespaces used by the Concierge and Supervisor apps during integration tests running locally
2020-10-09 23:00:11 +00:00
ports:
Supervisor listens for HTTPS on port 443 with configurable TLS certs - TLS certificates can be configured on the OIDCProviderConfig using the `secretName` field. - When listening for incoming TLS connections, choose the TLS cert based on the SNI hostname of the incoming request. - Because SNI hostname information on incoming requests does not include the port number of the request, we add a validation that OIDCProviderConfigs where the issuer hostnames (not including port number) are the same must use the same `secretName`. - Note that this approach does not yet support requests made to an IP address instead of a hostname. Also note that `localhost` is considered a hostname by SNI. - Add port 443 as a container port to the pod spec. - A new controller watches for TLS secrets and caches them in memory. That same in-memory cache is used while servicing incoming connections on the TLS port. - Make it easy to configure both port 443 and/or port 80 for various Service types using our ytt templates for the supervisor. - When deploying to kind, add another nodeport and forward it to the host on another port to expose our new HTTPS supervisor port to the host.
2020-10-27 00:03:26 +00:00
#@ if data.values.service_http_loadbalancer_port:
- name: http
protocol: TCP
port: #@ data.values.service_http_loadbalancer_port
Run as non-root I tried to follow a principle of encapsulation here - we can still default to peeps making connections to 80/443 on a Service object, but internally we will use 8080/8443. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2020-11-02 16:57:05 +00:00
targetPort: 8080
Supervisor listens for HTTPS on port 443 with configurable TLS certs - TLS certificates can be configured on the OIDCProviderConfig using the `secretName` field. - When listening for incoming TLS connections, choose the TLS cert based on the SNI hostname of the incoming request. - Because SNI hostname information on incoming requests does not include the port number of the request, we add a validation that OIDCProviderConfigs where the issuer hostnames (not including port number) are the same must use the same `secretName`. - Note that this approach does not yet support requests made to an IP address instead of a hostname. Also note that `localhost` is considered a hostname by SNI. - Add port 443 as a container port to the pod spec. - A new controller watches for TLS secrets and caches them in memory. That same in-memory cache is used while servicing incoming connections on the TLS port. - Make it easy to configure both port 443 and/or port 80 for various Service types using our ytt templates for the supervisor. - When deploying to kind, add another nodeport and forward it to the host on another port to expose our new HTTPS supervisor port to the host.
2020-10-27 00:03:26 +00:00
#@ end
#@ if data.values.service_https_loadbalancer_port:
- name: https
protocol: TCP
port: #@ data.values.service_https_loadbalancer_port
Run as non-root I tried to follow a principle of encapsulation here - we can still default to peeps making connections to 80/443 on a Service object, but internally we will use 8080/8443. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2020-11-02 16:57:05 +00:00
targetPort: 8443
Supervisor listens for HTTPS on port 443 with configurable TLS certs - TLS certificates can be configured on the OIDCProviderConfig using the `secretName` field. - When listening for incoming TLS connections, choose the TLS cert based on the SNI hostname of the incoming request. - Because SNI hostname information on incoming requests does not include the port number of the request, we add a validation that OIDCProviderConfigs where the issuer hostnames (not including port number) are the same must use the same `secretName`. - Note that this approach does not yet support requests made to an IP address instead of a hostname. Also note that `localhost` is considered a hostname by SNI. - Add port 443 as a container port to the pod spec. - A new controller watches for TLS secrets and caches them in memory. That same in-memory cache is used while servicing incoming connections on the TLS port. - Make it easy to configure both port 443 and/or port 80 for various Service types using our ytt templates for the supervisor. - When deploying to kind, add another nodeport and forward it to the host on another port to expose our new HTTPS supervisor port to the host.
2020-10-27 00:03:26 +00:00
#@ end
Allow creation of different Service types in Supervisor ytt templates - Tiltfile and prepare-for-integration-tests.sh both specify the NodePort Service using `--data-value-yaml 'service_nodeport_port=31234'` - Also rename the namespaces used by the Concierge and Supervisor apps during integration tests running locally
2020-10-09 23:00:11 +00:00
#@ end
Reference in New Issue Copy Permalink