djpbessems/ContainerImage.Pinniped
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
01a7978387
ContainerImage.Pinniped/deploy/supervisor/deployment.yaml

168 lines
5.4 KiB
YAML
Raw Normal View History

Run Tilt images as root for faster reload Previously, when triggering a Tilt reload via a *.go file change, a reload would take ~13 seconds and we would see this error message in the Tilt logs for each component. Live Update failed with unexpected error: command terminated with exit code 2 Falling back to a full image build + deploy Now, Tilt should reload images a lot faster (~3 seconds) since we are running the images as root. Note! Reloading the Concierge component still takes ~13 seconds because there are 2 containers running in the Concierge namespace that use the Concierge image: the main Concierge app and the kube cert agent pod. Tilt can't live reload both of these at once, so the reload takes longer and we see this error message. Will not perform Live Update because: Error retrieving container info: can only get container info for a single pod; image target image:image/concierge has 2 pods Falling back to a full image build + deploy Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2021-01-13 14:47:39 +00:00
#! Copyright 2020-2021 the Pinniped contributors. All Rights Reserved.
Implement very rough skeleton of the start of a supervisor server - This is just stab at a starting place because it felt easier to put something down on paper than to keep staring at a blank page
2020-10-06 00:28:19 +00:00
#! SPDX-License-Identifier: Apache-2.0
#@ load("@ytt:data", "data")
Concierge controllers add labels to all created resources
2020-10-15 17:14:23 +00:00
#@ load("@ytt:json", "json")
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", "defaultLabel", "labels", "deploymentPodLabel", "namespace", "defaultResourceName", "defaultResourceNameWithSuffix", "getAndValidateLogLevel")
#@ load("@ytt:template", "template")
Implement very rough skeleton of the start of a supervisor server - This is just stab at a starting place because it felt easier to put something down on paper than to keep staring at a blank page
2020-10-06 00:28:19 +00:00
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
#@ if not data.values.into_namespace:
Implement very rough skeleton of the start of a supervisor server - This is just stab at a starting place because it felt easier to put something down on paper than to keep staring at a blank page
2020-10-06 00:28:19 +00:00
---
apiVersion: v1
kind: Namespace
metadata:
name: #@ data.values.namespace
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
labels: #@ labels()
#@ end
Implement very rough skeleton of the start of a supervisor server - This is just stab at a starting place because it felt easier to put something down on paper than to keep staring at a blank page
2020-10-06 00:28:19 +00:00
---
apiVersion: v1
kind: ServiceAccount
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: #@ defaultResourceName()
namespace: #@ namespace()
labels: #@ labels()
Implement very rough skeleton of the start of a supervisor server - This is just stab at a starting place because it felt easier to put something down on paper than to keep staring at a blank page
2020-10-06 00:28:19 +00:00
---
apiVersion: v1
kind: ConfigMap
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("static-config")
namespace: #@ namespace()
labels: #@ labels()
Implement very rough skeleton of the start of a supervisor server - This is just stab at a starting place because it felt easier to put something down on paper than to keep staring at a blank page
2020-10-06 00:28:19 +00:00
data:
#@yaml/text-templated-strings
pinniped.yaml: |
deploy: wire API group suffix through YTT templates I didn't advertise this feature in the deploy README's since (hopefully) not many people will want to use it? Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2021-01-19 22:23:06 +00:00
apiGroupSuffix: (@= data.values.api_group_suffix @)
Configure name of the supervisor default TLS cert secret via ConfigMap Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2020-10-28 18:56:50 +00:00
names:
defaultTLSCertificateSecret: (@= defaultResourceNameWithSuffix("default-tls-certificate") @)
Concierge controllers add labels to all created resources
2020-10-15 17:14:23 +00:00
labels: (@= json.encode(labels()).rstrip() @)
Add YTT template value for setting log level This is helpful for us, amongst other users, because we want to enable "debug" logging whenever we deploy components for testing. See a5643e3 for addition of log level. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2020-11-11 12:49:46 +00:00
(@ if data.values.log_level: @)
logLevel: (@= getAndValidateLogLevel() @)
(@ end @)
Implement very rough skeleton of the start of a supervisor server - This is just stab at a starting place because it felt easier to put something down on paper than to keep staring at a blank page
2020-10-06 00:28:19 +00:00
---
#@ if data.values.image_pull_dockerconfigjson and data.values.image_pull_dockerconfigjson != "":
apiVersion: v1
kind: Secret
metadata:
name: image-pull-secret
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
namespace: #@ namespace()
labels: #@ labels()
Implement very rough skeleton of the start of a supervisor server - This is just stab at a starting place because it felt easier to put something down on paper than to keep staring at a blank page
2020-10-06 00:28:19 +00:00
type: kubernetes.io/dockerconfigjson
data:
.dockerconfigjson: #@ data.values.image_pull_dockerconfigjson
#@ end
---
apiVersion: apps/v1
kind: Deployment
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: #@ defaultResourceName()
namespace: #@ namespace()
labels: #@ labels()
Implement very rough skeleton of the start of a supervisor server - This is just stab at a starting place because it felt easier to put something down on paper than to keep staring at a blank page
2020-10-06 00:28:19 +00:00
spec:
replicas: #@ data.values.replicas
selector:
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
#! In hindsight, this should have been deploymentPodLabel(), but this field is immutable so changing it would break upgrades.
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
matchLabels: #@ defaultLabel()
Implement very rough skeleton of the start of a supervisor server - This is just stab at a starting place because it felt easier to put something down on paper than to keep staring at a blank page
2020-10-06 00:28:19 +00:00
template:
metadata:
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
labels:
#! This has always included defaultLabel(), which is used by this Deployment's selector.
_: #@ template.replace(defaultLabel())
#! More recently added the more unique deploymentPodLabel() so Services can select these Pods more specifically
#! without accidentally selecting pods from any future Deployments which might also want to use the defaultLabel().
_: #@ template.replace(deploymentPodLabel())
Implement very rough skeleton of the start of a supervisor server - This is just stab at a starting place because it felt easier to put something down on paper than to keep staring at a blank page
2020-10-06 00:28:19 +00:00
spec:
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
securityContext:
Run Tilt images as root for faster reload Previously, when triggering a Tilt reload via a *.go file change, a reload would take ~13 seconds and we would see this error message in the Tilt logs for each component. Live Update failed with unexpected error: command terminated with exit code 2 Falling back to a full image build + deploy Now, Tilt should reload images a lot faster (~3 seconds) since we are running the images as root. Note! Reloading the Concierge component still takes ~13 seconds because there are 2 containers running in the Concierge namespace that use the Concierge image: the main Concierge app and the kube cert agent pod. Tilt can't live reload both of these at once, so the reload takes longer and we see this error message. Will not perform Live Update because: Error retrieving container info: can only get container info for a single pod; image target image:image/concierge has 2 pods Falling back to a full image build + deploy Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2021-01-13 14:47:39 +00:00
runAsUser: #@ data.values.run_as_user
runAsGroup: #@ data.values.run_as_group
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
serviceAccountName: #@ defaultResourceName()
Implement very rough skeleton of the start of a supervisor server - This is just stab at a starting place because it felt easier to put something down on paper than to keep staring at a blank page
2020-10-06 00:28:19 +00:00
#@ if data.values.image_pull_dockerconfigjson and data.values.image_pull_dockerconfigjson != "":
imagePullSecrets:
- name: image-pull-secret
#@ end
containers:
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: #@ defaultResourceName()
Implement very rough skeleton of the start of a supervisor server - This is just stab at a starting place because it felt easier to put something down on paper than to keep staring at a blank page
2020-10-06 00:28:19 +00:00
#@ if data.values.image_digest:
image: #@ data.values.image_repo + "@" + data.values.image_digest
#@ else:
image: #@ data.values.image_repo + ":" + data.values.image_tag
#@ end
imagePullPolicy: IfNotPresent
Switch to a slimmer distroless base image. At a high level, it switches us to a distroless base container image, but that also includes several related bits: - Add a writable /tmp but make the rest of our filesystems read-only at runtime. - Condense our main server binaries into a single pinniped-server binary. This saves a bunch of space in the image due to duplicated library code. The correct behavior is dispatched based on `os.Args[0]`, and the `pinniped-server` binary is symlinked to `pinniped-concierge` and `pinniped-supervisor`. - Strip debug symbols from our binaries. These aren't really useful in a distroless image anyway and all the normal stuff you'd expect to work, such as stack traces, still does. - Add a separate `pinniped-concierge-kube-cert-agent` binary with "sleep" and "print" functionality instead of using builtin /bin/sleep and /bin/cat for the kube-cert-agent. This is split from the main server binary because the loading/init time of the main server binary was too large for the tiny resource footprint we established in our kube-cert-agent PodSpec. Using a separate binary eliminates this issue and the extra binary adds only around 1.5MiB of image size. - Switch the kube-cert-agent code to use a JSON `{"tls.crt": "<b64 cert>", "tls.key": "<b64 key>"}` format. This is more robust to unexpected input formatting than the old code, which simply concatenated the files with some extra newlines and split on whitespace. - Update integration tests that made now-invalid assumptions about the `pinniped-server` image. Signed-off-by: Matt Moyer <moyerm@vmware.com>
2021-07-26 16:18:43 +00:00
command:
- pinniped-supervisor
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
- /etc/podinfo
- /etc/config/pinniped.yaml
Fix broken "read only" fields added in v0.11.0. These fields were changed as a minor hardening attempt when we switched to Distroless, but I bungled the field names and we never noticed because Kapp doesn't apply API validations. This change fixes the field names so they act as was originally intended. We should also follow up with a change that validates all of our installation manifest in CI. Signed-off-by: Matt Moyer <moyerm@vmware.com>
2021-09-02 21:08:00 +00:00
securityContext:
readOnlyRootFilesystem: true
Implement very rough skeleton of the start of a supervisor server - This is just stab at a starting place because it felt easier to put something down on paper than to keep staring at a blank page
2020-10-06 00:28:19 +00:00
resources:
requests:
Add CPU requests and limits to the Concierge and Supervisor deployments
2020-11-02 23:47:20 +00:00
cpu: "100m"
Implement very rough skeleton of the start of a supervisor server - This is just stab at a starting place because it felt easier to put something down on paper than to keep staring at a blank page
2020-10-06 00:28:19 +00:00
memory: "128Mi"
deploy: add memory limits This is the beginning of a change to add cpu/memory limits to our pods. We are doing this because some consumers require this, and it is generally a good practice. The limits == requests for "Guaranteed" QoS. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2020-11-02 19:57:39 +00:00
limits:
Add CPU requests and limits to the Concierge and Supervisor deployments
2020-11-02 23:47:20 +00:00
cpu: "100m"
Implement very rough skeleton of the start of a supervisor server - This is just stab at a starting place because it felt easier to put something down on paper than to keep staring at a blank page
2020-10-06 00:28:19 +00:00
memory: "128Mi"
volumeMounts:
- name: config-volume
mountPath: /etc/config
Fix broken "read only" fields added in v0.11.0. These fields were changed as a minor hardening attempt when we switched to Distroless, but I bungled the field names and we never noticed because Kapp doesn't apply API validations. This change fixes the field names so they act as was originally intended. We should also follow up with a change that validates all of our installation manifest in CI. Signed-off-by: Matt Moyer <moyerm@vmware.com>
2021-09-02 21:08:00 +00:00
readOnly: true
Implement very rough skeleton of the start of a supervisor server - This is just stab at a starting place because it felt easier to put something down on paper than to keep staring at a blank page
2020-10-06 00:28:19 +00:00
- name: podinfo
mountPath: /etc/podinfo
Fix broken "read only" fields added in v0.11.0. These fields were changed as a minor hardening attempt when we switched to Distroless, but I bungled the field names and we never noticed because Kapp doesn't apply API validations. This change fixes the field names so they act as was originally intended. We should also follow up with a change that validates all of our installation manifest in CI. Signed-off-by: Matt Moyer <moyerm@vmware.com>
2021-09-02 21:08:00 +00:00
readOnly: true
Make the supervisor healthz endpoint public Based on our experiences today with GKE, it will be easier for our users to configure Ingress health checks if the healthz endpoint is available on the same public port as the OIDC endpoints. Also add an integration test for the healthz endpoint now that it is public. Also add the optional `containers[].ports.containerPort` to the supervisor Deployment because the GKE docs say that GKE will look at that field while inferring how to invoke the health endpoint. See https://cloud.google.com/kubernetes-engine/docs/concepts/ingress#def_inf_hc
2020-10-21 22:24:48 +00:00
ports:
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
- containerPort: 8080
Make the supervisor healthz endpoint public Based on our experiences today with GKE, it will be easier for our users to configure Ingress health checks if the healthz endpoint is available on the same public port as the OIDC endpoints. Also add an integration test for the healthz endpoint now that it is public. Also add the optional `containers[].ports.containerPort` to the supervisor Deployment because the GKE docs say that GKE will look at that field while inferring how to invoke the health endpoint. See https://cloud.google.com/kubernetes-engine/docs/concepts/ingress#def_inf_hc
2020-10-21 22:24:48 +00:00
protocol: TCP
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
- containerPort: 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
protocol: TCP
Add `https_proxy` and `no_proxy` settings for the Supervisor - Add new optional ytt params for the Supervisor deployment. - When the Supervisor is making calls to an upstream OIDC provider, use these variables if they were provided. - These settings are integration tested in the main CI pipeline by sometimes setting them on deployments in certain cases, and then letting the existing integration tests (e.g. TestE2EFullIntegration) provide the coverage, so there are no explicit changes to the integration tests themselves in this commit.
2021-07-07 19:50:13 +00:00
env:
#@ if data.values.https_proxy:
- name: HTTPS_PROXY
value: #@ data.values.https_proxy
#@ end
Provide good defaults for NO_PROXY This change updates the default NO_PROXY for the supervisor to not proxy requests to the Kubernetes API and other Kubernetes endpoints such as Kubernetes services. It also adds https_proxy and no_proxy settings for the concierge with the same default. Signed-off-by: Monis Khan <mok@vmware.com>
2021-08-17 13:44:40 +00:00
#@ if data.values.https_proxy and data.values.no_proxy:
Add `https_proxy` and `no_proxy` settings for the Supervisor - Add new optional ytt params for the Supervisor deployment. - When the Supervisor is making calls to an upstream OIDC provider, use these variables if they were provided. - These settings are integration tested in the main CI pipeline by sometimes setting them on deployments in certain cases, and then letting the existing integration tests (e.g. TestE2EFullIntegration) provide the coverage, so there are no explicit changes to the integration tests themselves in this commit.
2021-07-07 19:50:13 +00:00
- name: NO_PROXY
value: #@ data.values.no_proxy
#@ end
Implement readinessProbe and livenessProbe for supervisor Signed-off-by: Ryan Richard <richardry@vmware.com>
2020-10-21 18:51:31 +00:00
livenessProbe:
httpGet:
path: /healthz
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
port: 8080
Implement readinessProbe and livenessProbe for supervisor Signed-off-by: Ryan Richard <richardry@vmware.com>
2020-10-21 18:51:31 +00:00
scheme: HTTP
initialDelaySeconds: 2
timeoutSeconds: 15
periodSeconds: 10
failureThreshold: 5
readinessProbe:
httpGet:
path: /healthz
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
port: 8080
Implement readinessProbe and livenessProbe for supervisor Signed-off-by: Ryan Richard <richardry@vmware.com>
2020-10-21 18:51:31 +00:00
scheme: HTTP
initialDelaySeconds: 2
timeoutSeconds: 3
periodSeconds: 10
failureThreshold: 3
Implement very rough skeleton of the start of a supervisor server - This is just stab at a starting place because it felt easier to put something down on paper than to keep staring at a blank page
2020-10-06 00:28:19 +00:00
volumes:
- name: config-volume
configMap:
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("static-config")
Implement very rough skeleton of the start of a supervisor server - This is just stab at a starting place because it felt easier to put something down on paper than to keep staring at a blank page
2020-10-06 00:28:19 +00:00
- name: podinfo
downwardAPI:
items:
- path: "labels"
fieldRef:
fieldPath: metadata.labels
- path: "namespace"
fieldRef:
fieldPath: metadata.namespace
Pass CSRF cookie signing key from controller to cache This also sets the CSRF cookie Secret's OwnerReference to the Pod's grandparent Deployment so that when the Deployment is cleaned up, then the Secret is as well. Obviously this controller implementation has a lot of issues, but it will at least get us started. Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2020-12-11 16:11:49 +00:00
- path: "name"
fieldRef:
fieldPath: metadata.name
Implement very rough skeleton of the start of a supervisor server - This is just stab at a starting place because it felt easier to put something down on paper than to keep staring at a blank page
2020-10-06 00:28:19 +00:00
#! This will help make sure our multiple pods run on different nodes, making
#! our deployment "more" "HA".
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 50
podAffinityTerm:
labelSelector:
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
matchLabels: #@ deploymentPodLabel()
Implement very rough skeleton of the start of a supervisor server - This is just stab at a starting place because it felt easier to put something down on paper than to keep staring at a blank page
2020-10-06 00:28:19 +00:00
topologyKey: kubernetes.io/hostname
Reference in New Issue Copy Permalink