предисловие

Kubernetes (K8S) в силе своей отличной инфраструктуры, гибкие возможности расширения, богатые модели приложения оркестрации, стал де факто стандартом в области расположения контейнера. Все больше и больше компаний принять эту тенденцию, выберите K8S в качестве приложения контейнера инфраструктуры, и постепенно перенести свои основные услуги более K8S.

Наличие имеет решающее значение для развития инфраструктуры. Основные поставщики облачных вычислений ввели высокодоступной, масштабируемые K8S услуг хостинга, есть более представитель Amazon ЭКС , Azure Kubernetes службы (АКС) , Google Kubernetes Engine , Али облако контейнерных перевозок Kubernetes версии и так далее.

В то время как услуги общественного облака организовано K8S процветает, но многие компании по-прежнему требуют построенного собственными силами кластера. Именно по этой причине, чтобы способствовать рождению большого числа выдающихся сценариев развертывания K8S кластера, их характеристики приведены ниже.

Сценарии развертывания	особенность
Kubeadm	1. Официальный производства инструмент развертывания , который обеспечивает K8S кластера управление жизненным циклом знаний предметной области. 2. Инструмент предназначен , чтобы быть более высоким уровнем , строительные блоки могут быть объединены.
Kubespray	1. Поддержка K8S развернутые на голый металл и AWS, БКА, Azure и других облачных платформ. 2. Определить K8S задачу развертывания кластера на основе анзибль Playbook. 3. Поддержка наиболее популярных дистрибутивов Linux.
Kops	1. поддерживает только K8S развертывания на AWS, БКА и несколько других облачных платформ. 2. синхронизация состояния на основе модели, а также для сухого запуска автоматического идемпотенту. 3. Terraform может автоматически генерировать конфигурацию.
Rancher Kubernetes двигателя (RKE)	1. Хорошо известные платформы с открытым кодом управления предприятием Контейнер Rancher легкие K8S обеспечивают инструмент для установки. 2. Поддержка развертывается на голом металле, виртуальной машине, и управление государственного облачного K8S кластеров.

В приведенном выше решении, РКА преимущества в простоте использования и гибкости. В данной статье учит , как развернуть высокую доступность кластер K8S от RKE, RKE версии, используемым здесь v0.2.2.

Высокая доступность кластера архитектура K8S

Во-первых нужно понять характеристики высокой доступности архитектуры K8S кластера, следующая цифра является официальной рекомендацией о высокой доступности диаграммы кластера архитектуры.

k8s_arch

Основная идея заключается сделать K8S мастера-узел высокой доступности различных типов компонентов, устраняя одиночные точки отказа.

apiserver-Kube - Иностранные подвергаются K8S API, чтобы посетить вход всего кластера. Так как apiserver безгосударственного сам по себе, и может запускать несколько экземпляров высокой доступности в сочетании с балансировкой нагрузки.
ETCD K8S сети кластера для хранения информации о конфигурации и состоянии объекта, всего центра обработки данных кластера -. Это может быть установлено путем активации избыточного экземпляра нечетного числа etcd, надежного слой для хранения данных.
Планировщик-Kube - POD выбрать новый узел , созданный для них баллотироваться. Кластер может иметь только один активный экземпляр Кубэ-планировщик, вы можете запустить несколько Кубэ-планировщик , в то же время и с помощью выборов функции лидера для достижения высокой доступности.
Контролер-менеджер-Kube - внутренний центр управления для управления кластером. Кластер может иметь только один активный экземпляр Кубэ-контроллер-менеджер, вы можете запустить несколько одновременного Кубэ-контроллер-менеджер и лидер в использовании избирательных функций для достижения высокой доступности.

Кроме того, Shihai сборки кластера обратите внимание на следующие вопросы.

Надежность K8S процессов на узле. Нужно kubelet, Кубэ-планировщик, Кубэ-контроллер-менеджер и другие процессы могут автоматически перезагрузится после сбоя.
Резервные ресурсы для не-стручка узла рабочего в процессе, мешают им конкурировать за ресурсы с стручком приведет к нехватке ресурсов узла.

RKE построить высокодоступный кластер с помощью K8S

Планирование узла

Первый шаг заключается в создании кластера серверов разделили в соответствии с функцией узла, в следующей таблице показано планирование узлов в авторской среде.

IP	роль
192.168.0.10	развертывание узла
192.168.0.11	K8S мастер - API-сервер, etcd, планировщик, контроллер-менеджер
192.168.0.12	K8S мастер - API-сервер, etcd, планировщик, контроллер-менеджер
192.168.0.13	K8S мастер - API-сервер, etcd, планировщик, контроллер-менеджер
192.168.0.14	K8S работник - омлеты, прокси
192.168.0.15	K8S работник - омлеты, прокси
192.168.0.16	K8S работник - омлеты, прокси
192.168.0.17	K8S работник - омлеты, прокси

План Описание:

Машина по отдельности , выбраны в 192.168.0.10качестве узлов , развернутых. Если небольшое количество машин, развертывание узлов может быть добавлено к K8S кластеру.
В целях обеспечения доступности, выберите три машин развернутых K8S мастера-компоненту. Если условия могут быть etcd другие компоненты в мастере и развернуты по отдельности, так что большая гибкость в управлении количеством экземпляров требуемыхов. Так, например, но не под давлением запросы доступа к надежности данных относительно высоки, она может вместо этого выбрать для развертывания 5 ETCD машины, дополнительные машины развернута-выбрать другие компоненты в мастере.
Остальные четыре машины, как K8S рабочих узлов. Число узлов динамически настраивается в соответствии с реальной ситуацией. Когда кокон из-за нехватки ресурсов был в отложенном состоянии, это может быть расширением рабочего. Когда использование ресурсов узла является низким, и СТРУЧОК присутствует на данном узле может быть перенесена для запуска на другой узел, он может быть работник уменьшением объема.

Подготовка среды

После завершения плана узла, необходимость экологической подготовительной работы, в основном, включает в себя следующее:

安装 RKE - 需要在部署节点（192.168.0.10）上安装 RKE 二进制包，具体安装方法可参考 download-the-rke-binary。
配置 SSH 免密登录 - 由于 RKE 通过 SSH tunnel 安装部署 k8s 集群，需要配置 RKE 所在节点到 k8s 各节点的 SSH 免密登录。如果 RKE 所在节点也需要加入到 k8s 集群中，需要配置到本机的 SSH 免密登录。
安装 docker - 由于 RKE 通过 docker 镜像rancher/hyperkube启动 k8s 组件，因此需要在 k8s 集群的各个节点（192.168.0.11 ~ 192.168.0.17 这 7 台机器）上安装 docker。
关闭 swap - k8s 1.8 开始要求关闭系统的 swap，如果不关闭，默认配置下 kubelet 将无法启动。这里需要关闭所有 k8s worker 节点的 swap。

配置 cluster.yml

在完成环境准备后，需要通过 cluster.yml 描述集群的组成和 k8s 的部署方式。

配置集群组成

配置文件 cluster.yml 中的 nodes 配置项用于描述集群的组成。根据节点规划，对于 k8s master 节点，指定其角色为controlplane和etcd。对于 k8s worker 节点，指定其角色为worker。

nodes:
  - address: 192.168.0.1
    user: admin
    role:
      - controlplane
      - etcd
  ...
  - address: 192.168.0.7
    user: admin
    role:
      - worker

设置资源预留

K8s 的 worker node 除了运行 pod 类进程外，还会运行很多其他的重要进程，包括 k8s 管理进程，如 kubelet、dockerd，以及系统进程，如 systemd。这些进程对整个集群的稳定性至关重要，因此需要为他们专门预留一定的资源。

笔者环境中的 worker 设置如下：

节点拥有 32 核 CPU，64Gi 内存和 100Gi 存储。
为 k8s 管理进程预留了 1 核 CPU，2Gi 内存和 1Gi 存储。
为系统进程预留了 1 核 CPU，1Gi 内存和 1Gi 存储。
为内存资源设置了 500Mi 的驱逐阈值，为磁盘资源设置了 10% 的驱逐阈值。

在此场景下，节点可分配的 CPU 资源是 29 核，可分配的内存资源是 60.5Gi，可分配的磁盘资源是 88Gi。对于不可压缩资源，当 pod 的内存使用总量超过 60.5Gi 或者磁盘使用总量超过 88Gi 时，QoS 较低的 pod 将被优先驱逐。对于可压缩资源，如果节点上的所有进程都尽可能多的使用 CPU，则 pod 类进程加起来不会使用超过 29 核的 CPU 资源。

上述资源预留设置在 cluster.yml 中具体形式如下。

services:
  kubelet:
    extra_args:
      cgroups-per-qos: True
      cgroup-driver: cgroupfs
      kube-reserved: cpu=1,memory=2Gi,ephemeral-storage=1Gi
      kube-reserved-cgroup: /runtime.service
      system-reserved: cpu=1,memory=1Gi,ephemeral-storage=1Gi
      system-reserved-cgroup: /system.slice
      enforce-node-allocatable: pods,kube-reserved,system-reserved
      eviction-hard: memory.available<500Mi,nodefs.available<10%

关于资源预留更详细的内容可参考文章 Reserve Compute Resources for System Daemons。

部署 k8s 集群

当 cluster.yml 文件配置完成后，可以通过命令rke up完成集群的部署任务。下图展示了通过 RKE 部署的 k8s 集群架构图。

rke_arch

该架构有如下特点：

集群中的各个组件均通过容器方式启动，并且设置重启策略为always。这样当他们出现故障意外退出后，能被自动拉起。
Master 节点上的 kube-scheduler、kube-controller-manager 直接和本机的 API server 通信。
Worker 节点上的 nginx-proxy 拥有 API server 的地址列表，负责代理 kubelet、kube-proxy 发往 API server 的请求。
为了让集群具有灾备能力，master 节点上的 etcd-rolling-snapshots 会定期保存 etcd 的快照至本地目录/opt/rke/etcd-snapshots中。

配置负载均衡器

После завершения развертывания кластера, вы можете получить доступ к K8S сервер API. Множество начала из - за , например Kube-apiserver окружающей среды для обеспечения высокой доступности, необходимо создать систему балансировки нагрузки этими примерами. Здесь , в 192.168.0.10развернутом Nginx достижения функции балансировки нагрузки, nginx.conf конкретной конфигурации состоит в следующем.

...
stream {
    upstream apiserver {
        server 192.168.0.11:6443 weight=5 max_fails=3 fail_timeout=60s;
        server 192.168.0.12:6443 weight=5 max_fails=3 fail_timeout=60s;
        server 192.168.0.13:6443 weight=5 max_fails=3 fail_timeout=60s;
    }

    server {
        listen 6443;
        proxy_connect_timeout 1s;
        proxy_timeout 10s;
        proxy_pass apiserver;
    }
}
...

В этом случае обеспечивается сервер API доступа порта балансировки нагрузки возникает аномалия Unable to connect to the server: x509: certificate is valid for xxx, not 192.168.0.10. Это должно быть имя домена или IP - адрес балансировки нагрузки добавляется к API сервера сертификата открытого ключа, вы можете настроить эту функцию cluster.yml пункта для завершения аутентификации.

authentication:
  strategy: x509
  sans:
    - "192.168.0.10"

После изменения cluster.yml, выполните команду rke cert-rotate.

верификация

После завершения всех вышеуказанных шагов, с помощью команды kubectl get nodesдля просмотра состояния узла. Если состояние всех узлов будут готовы, сказал успех развертывания кластера.

NAME            STATUS    ROLES              AGE    VERSION
192.168.0.11    Ready     controlplane,etcd  1d     v1.13.5
192.168.0.12    Ready     controlplane,etcd  1d     v1.13.5
192.168.0.13    Ready     controlplane,etcd  1d     v1.13.5
192.168.0.14    Ready     worker             1d     v1.13.5
192.168.0.15    Ready     worker             1d     v1.13.5
192.168.0.16    Ready     worker             1d     v1.13.5
192.168.0.17    Ready     worker             1d     v1.13.5

резюме

Rancher Kubernetes двигатель (RKE) защита пользовательских кластеров, созданных K8S сложных деталей, упрощающие шаг развертывания, конструируя уменьшенный порог. Для тех, у кого есть самодельные K8S кластера потребности предприятий является хорошим выбором.

Kubernetes высокой доступности практики развертывания кластера