Answers: <blockquote>
  <p>Q1a) How do you scale the Kubernetes administration/control plane? How do you scale from 1 etcd server to 10 etcd servers for example?</p>
  </blockquote>
  <p>You won't. etcd needs to be fast, especially with a growing cluster. 3 members is what you'll want to have. Usually, as a result, you would also deploy 3x kube apiserver, controller-manager &amp; scheduler pods.</p>
  <blockquote>
  <p>Q1b) In a large organization where there are different business units, do you deploy one K8S instance (active/passive) for each business unit, or multiple K8S instances serving the entire organization?</p>
  </blockquote>
  <p>Large organizations would usually go with several clusters. Don't put all your eggs in the same basket. Make sure you can upgrade some of your clusters, without impacting the others. Allowing end-users to implement their own disaster recovery, managing resources in &quot;sibling&quot; clusters -- kind of active/passive, without designating one or the other as passive, rather planning for each of your clusters to double in size over night, should you need to.</p>
  <p>Which doesn't mean they would be small clusters. You could easily have 100s of workers (my current customer's largest cluster has between 350 and 400 nodes, cluster-autoscaler adjusting size base on requested resources). But as much as possible, you want to avoid beasts like those: monitoring or logging stack would consume a lot, requiring larger nodes hosting infra components, operations on those components would become more slow and painful, ... better have two small than one large.</p>
  <p>Although here: automation would be critical. your team probalby can't afford to micro-manage 40, 80, 200 clusters. You would have to figure out a way to rollout changes to your clusters with little effort. And consistently. Might involve tools such as Ansible, Terraform, Tekton or ArgoCD.</p>
  <blockquote>
  <p>Q2) How do you reconcile multiple instances of Kubernetes to get a master view in order to monitor all the instances of containers running on Kubernetes?</p>
  </blockquote>
  <p>I wouldn't. The more you grow, the more metrics/data you would collect, the more complicated it would be to monitor everything from one point, the more likely rules evaluation would be late eventually, maybe misses alerts, ...</p>
  <p>Better deploy one Prometheus (or more) per cluster, self-monitoring your cluster. Then, pick two or three &quot;ops&quot; clusters, where you would deploy another Prometheus, making sure the Prometheuses in your other clusters work as expected (can server query, alertmanager is present, alertmanager can relay alerts, ... could be pretty much all based on blackbox exporter).</p>
  <p>Configure alertmanagers centralizing alerts into a single place (rocketchat, slack channel, stuff like opsgenie).</p>
  <p>Going further, you could look at solutions such as Thanos. You may aggregate metrics from several prometheuses .... although you'll need lots of RAM running thanos components. and some reliable s3 bucket aggregating those metrics into one location. It's definitely not something I would recommend for monitoring purposes, but it can be nice for metrology, making cool grafana dashboards, ...</p>
  
Answers: CC BY-SA 4.0
Answers: 2022-08-24T16:17:59.170Z
Answers: 2022-08-24T16:17:59.170Z
Answers: SYN
Body: <p>Precursor: I am not experienced in the design of large-scale infrastructure deployments for infra applications.</p>
  <p>The assumptions for the questions:</p>
  <ul>
  <li><p>I have read that it is a good practice to host Kubernetes components in isolation from each other on the network as the network provides a layer of security control.</p>
  </li>
  <li><p>In a large K8S deployment environment, you may have multiple instances of Kubernetes deployment. Each Kubernetes deployment has components including etcd, kube API server, scheduler, controller manager, etc.</p>
  </li>
  </ul>
  <p>If we consider both points above, then the question are:</p>
  <p><strong>Q1a)</strong> How do you scale the Kubernetes administration/control plane? How do you scale from 1 etcd server to 10 etcd servers for example?</p>
  <p><strong>Q1b)</strong> In a large organization where there are different business units, do you deploy one K8S instance (active/passive) for each business unit, or multiple K8S instances serving the entire organization?</p>
  <p><strong>Q2)</strong> For each deployment method described in part (1b), how do you reconcile multiple instances of Kubernetes to get a master view in order to monitor all the instances of containers running on Kubernetes?</p>
  
Comments: CC BY-SA 4.0
Comments: 2022-08-23T07:34:25.423Z
Comments: For Q1a - Have you seen this high availability guide in the docs?  -  https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/     Q1b Would be a business decision which depends upon that organisation's particular needs, as well as the management structure of the organisation and its policies.
Comments: Ben Cottrell
Comments: CC BY-SA 4.0
Comments: 2022-08-24T10:05:40.853Z
Comments: Thank you. I think that answers the questions
Comments: transcend3nt
Tags: <kubernetes><containers><security>
Title: How do you securely deploy large number of Kubernetes components in isolation?
UserDisplayName: transcend3nt
ThreadText: # How do you securely deploy large number of Kubernetes components in isolation?
  
  (Asked by: username_0 on 2022-08-22)
  
  Precursor: I am not experienced in the design of large-scale infrastructure deployments for infra applications.
  
  The assumptions for the questions:
  
  * I have read that it is a good practice to host Kubernetes components in isolation from each other on the network as the network provides a layer of security control.
  * In a large K8S deployment environment, you may have multiple instances of Kubernetes deployment. Each Kubernetes deployment has components including etcd, kube API server, scheduler, controller manager, etc.
  
  If we consider both points above, then the question are:
  
  **Q1a)** How do you scale the Kubernetes administration/control plane? How do you scale from 1 etcd server to 10 etcd servers for example?
  
  **Q1b)** In a large organization where there are different business units, do you deploy one K8S instance (active/passive) for each business unit, or multiple K8S instances serving the entire organization?
  
  **Q2)** For each deployment method described in part (1b), how do you reconcile multiple instances of Kubernetes to get a master view in order to monitor all the instances of containers running on Kubernetes?
  
  **Tags:** kubernetes, containers, security
  
  > **Comments:**
  > **username_1**: For Q1a - Have you seen this high availability guide in the docs?  -  https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/     Q1b Would be a business decision which depends upon that organisation's particular needs, as well as the management structure of the organisation and its policies.  
  > **username_0**: Thank you. I think that answers the questions  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2022-08-24. Score: 0 | Accepted answer
  
  > Q1a) How do you scale the Kubernetes administration/control plane? How do you scale from 1 etcd server to 10 etcd servers for example?
  
  You won't. etcd needs to be fast, especially with a growing cluster. 3 members is what you'll want to have. Usually, as a result, you would also deploy 3x kube apiserver, controller-manager & scheduler pods.
  
  > Q1b) In a large organization where there are different business units, do you deploy one K8S instance (active/passive) for each business unit, or multiple K8S instances serving the entire organization?
  
  Large organizations would usually go with several clusters. Don't put all your eggs in the same basket. Make sure you can upgrade some of your clusters, without impacting the others. Allowing end-users to implement their own disaster recovery, managing resources in "sibling" clusters -- kind of active/passive, without designating one or the other as passive, rather planning for each of your clusters to double in size over night, should you need to.
  
  Which doesn't mean they would be small clusters. You could easily have 100s of workers (my current customer's largest cluster has between 350 and 400 nodes, cluster-autoscaler adjusting size base on requested resources). But as much as possible, you want to avoid beasts like those: monitoring or logging stack would consume a lot, requiring larger nodes hosting infra components, operations on those components would become more slow and painful, ... better have two small than one large.
  
  Although here: automation would be critical. your team probalby can't afford to micro-manage 40, 80, 200 clusters. You would have to figure out a way to rollout changes to your clusters with little effort. And consistently. Might involve tools such as Ansible, Terraform, Tekton or ArgoCD.
  
  > Q2) How do you reconcile multiple instances of Kubernetes to get a master view in order to monitor all the instances of containers running on Kubernetes?
  
  I wouldn't. The more you grow, the more metrics/data you would collect, the more complicated it would be to monitor everything from one point, the more likely rules evaluation would be late eventually, maybe misses alerts, ...
  
  Better deploy one Prometheus (or more) per cluster, self-monitoring your cluster. Then, pick two or three "ops" clusters, where you would deploy another Prometheus, making sure the Prometheuses in your other clusters work as expected (can server query, alertmanager is present, alertmanager can relay alerts, ... could be pretty much all based on blackbox exporter).
  
  Configure alertmanagers centralizing alerts into a single place (rocketchat, slack channel, stuff like opsgenie).
  
  Going further, you could look at solutions such as Thanos. You may aggregate metrics from several prometheuses .... although you'll need lots of RAM running thanos components. and some reliable s3 bucket aggregating those metrics into one location. It's definitely not something I would recommend for monitoring purposes, but it can be nice for metrology, making cool grafana dashboards, ...
  
  
  ---
  
  