[GitHub] [incubator-yunikorn-site] pbacsko commented on a change in pull request #138: [YUNIKORN-1142] Document new admission controller registration behavior

[GitBox <gi...@apache.org>]

pbacsko commented on a change in pull request #138:
URL: https://github.com/apache/incubator-yunikorn-site/pull/138#discussion_r832347238



##########
File path: docs/design/k8shim.md
##########
@@ -59,28 +59,16 @@ and a [validation webhook](https://kubernetes.io/docs/reference/access-authn-aut
 
 ### Admission controller deployment
 
-Currently, the deployment of the admission-controller is done as a `post-start` hook in the scheduler deployment, similarly, the
-uninstall is done as a `pre-stop` hook. See the related code [here](https://github.com/apache/incubator-yunikorn-release/blob/56e580af24ed3433e7d73d9ea556b19ad7b74337/helm-charts/yunikorn/templates/deployment.yaml#L80-L85).
-During the installation, it is expected to always co-locate the admission controller with the scheduler pod, this is done
-by adding the pod-affinity in the admission-controller pod, like:
+By default, the admission controller is deployed as part of the YuniKorn Helm chart installation. This can be disabled if necessary (though not recommended) by setting the Helm parameter `embedAdmissionController` to `false`.
 
-```yaml
-podAffinity:
-  requiredDuringSchedulingIgnoredDuringExecution:
-    - labelSelector:
-      matchExpressions:
-      - key: component
-        operator: In
-        values:
-        - yunikorn-scheduler
-      topologyKey: "kubernetes.io/hostname"
-```
-
-it also tolerates all the taints in case the scheduler pod has some toleration set.
-
-```yaml
-tolerations:
-- operator: "Exists"
-```
+On startup, the admission controller performs a series of tasks to ensure that it is properly registered with Kubernetes:
+1. Loads a Kubernetes secret called `admission-controller-secrets`. This secret stores a pair of CA certificates which are used to sign the TLS server certificate used by the admission controller.
+2. If the secret cannot be found or either CA certificate is within 90 days of expiration, generates new certificate(s). If a certificate is expiring, a new one is generated with an expiration of 12 months in the future. If both certificates are missing or expiring, the second certificate is generated with an expiration of 6 months in the future. This ensures that both certificates do not expire at the same time, and that there is an overlap of trusted certificates.

Review comment:
       What does an "expiring" certificate mean? I guess it's a date which is close to the expiration date, but how close?




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: reviews-unsubscribe@yunikorn.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org