Под пресеты против ConfigMaps в Кубернетес - PullRequest
Новая
       97

Под пресеты против ConfigMaps в Кубернетес

1 голос
/ 03 мая 2020

Кажется, что оба достигают одного и того же - настройте модуль во время сборки.

Может кто-нибудь объяснить, в чем разница между ними? Возможно, также приведите простой пример использования каждого после 1, если вы думаете, что это сделает это более понятным.

1 Ответ

2 голосов
/ 03 мая 2020

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

Кластер Kubernetes может содержать сотни модулей. Многие из этих модулей имеют общие конструкции, такие как переменные среды, ConfigMaps, Secrets и др. c. Например, в случае микросервисов, использующих MySQL, нам необходимо ввести учетные данные MySQL в качестве секретов K8s в модуле. Если в кластере 100 микросервисов (не так уж и редко), нам нужно добавить следующий раздел в конфигурацию всех 100 модулей.

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

    env:
      - name: SECRET_USERNAME
        valueFrom:
          secretKeyRef:
            name: mysecret
            key: mysql-username
      - name: SECRET_PASSWORD
        valueFrom:
          secretKeyRef:
            name: mysecret
            key: mysql-password

Из дизайна набора настроек модуля do c.

Мотивация :

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

Примеры использования

  1. Как пользователь, я хочу иметь возможность предоставлять новый модуль без необходимости знать примитивы конфигурации приложения, какие сервисы будут использовать мои модули.
  2. Как администратор кластера, я хочу, чтобы указанные c элементы конфигурации службы были явно скрыты от разработчика, внедряющего службу, но не для того, чтобы запретить разработчику доставку.
  3. Как разработчик приложения, я хочу подготовить экземпляр Cloud Spanner, а затем получить к нему доступ из моего кластера Kubernetes.
  4. Как разработчик приложения, я хочу, чтобы процесс подготовки Cloud Spanner настраивал мой кластер Kubernetes таким образом, чтобы конечные точки и учетные данные для моего экземпляра Cloud Spanner неявно вводились в блоки, соответствующие селектору меток (без необходимости изменять PodSpe c для добавления спецификаций c Configmap / Secret, содержащих данные конечной точки / учетные данные).
...