Tag Archives: Mimbolovekubernetes
Учетные записи ServiceAccount – это ресурсы, такие же, как модули, секреты, словари конфигурации и т. д., которые ограничиваются отдельными простран[1]ствами имен. Устанавливаемая по умолчанию учетная запись ServiceAccount создается автоматически для каждого пространства имен (именно их и ис[1]пользовали ваши модули все время). Список учетных записей ServiceAccount можно вывести точно так же, как вы делаете это с другими ресурсами:
$ kubectl get sa
Текущее пространство имен содержит учетную запись по умолчанию ServiceAccount. При необходимости могут быть добавлены дополнительные учетные записи служб. Каждый модуль связан ровно с одной учетной записью службы, но несколько модулей могут использовать одну и ту же учетную запись. Как видно на рисунке, модуль может использовать учетную запись ServiceAccount только из того же пространства имен.
Чтобы создать службу NodePort, необходимо описать его в манифесте: kubia-svc-nodeport.yaml. В файле задается тип NodePort и указывается порт узла, к которому должна быть привязана эта служба на всех узлах кластера, при этом указание порта не является обязательным. Если его не указать, Kubernetes выберет случайный порт.
apiVersion: v1 kind: Service metadata: name: kubia-nodeport spec: type: NodePort ports: – port: 80 targetPort: 8080 nodePort: 30123 selector: app: kubia
Конечные точки служб (Endpoints) Kubernetes используются для подключения к службам, находящимся за пределами кластера. Иногда через функционал служб Kubernetes требуется обеспечить доступ к внешним службам, чтобы она перенаправляла подключения на внешние IP-адреса и порты, что позволяет использовать преимущества и балансировки нагрузки служб и обнаружения служб. Клиентские модули, работающие в кластере, могут подключаться к внешней службе так же, как и к внутренним службам.
Службы (Service) не связываются с модулями напрямую. Вместо этого между ними находится ресурс конечных точек (Endpoints). Ресурс Endpoints – это список IP-адресов и портов, предоставляющих доступ к службе. Ресурс конечных точек похож на любой другой ресурс Kubernetes, поэтому можно вывести его основную информацию с помощью команды kubectl get:
$ kubectl get endpoints kubia
Если создать службу без селектора модулей, то Kubernetes не создаст ресурс конечных точек. Поэтому, необходимо вручную создать ресурсы Service и Endpoints и указать список конечных точек для службы. (далее…)
Служба Kubernetes – это ресурс, который формирует единую постоянную точку входа в группу модулей, предоставляющих одну и туже службу. Каждая служба имеет IP-адрес и порт, которые никогда не меняются до тех пор, пока существует служба. Клиенты могут открывать подключения к этому IP-адресу и порту, а затем маршрутизировать эти подключения в один из модулей, поддерживающих эту службу. Благодаря этому, клиентам службы не требуется знать расположение отдельных модулей, предоставляющих службу, что позволяет перемещать данные модули по кластеру в любое время. Подключения к службе сбалансированы по нагрузке на всех поддерживающих модулях.
Создание службы
Создать службу (т.е создать объект Service) можно с помощью команды kubectl expose или путем отправки YAML на сервер API Kubernetes.
Для того чтобы создать службу с помощью команды, надо сообщить Kubernetes обеспечить доступ к контроллеру репликации:
$ kubectl expose replicationcontroller kubia --type=LoadBalancer --name kubia-http-service "kubia-http" exposed
Команда expose создаст ресурс Service с тем же селектором модуля, что и используемый контроллером репликации, обеспечивая доступ ко всем своим модулям через единый IP-адрес и порт.
(далее…)
В статье пойдет речь о запуске только одного модуля на каждом узле с помощью набора демонов (DaemonSet).
Наборы реплик (ReplicaSet) используются для запуска определенного количества модулей, развернутых в кластерной инфраструктуре Kubernetes. Но существуют случаи, когда требуется, чтобы модули связанные с обеспечением работы инфраструктуры, выполняющие операции системного уровня работали на каждом узле в кластере. Например, когда требуется на каждом узле запустить сборщик логов или монитор ресурсов. Еще одним хорошим примером является собственный процесс kube-proxy системы Kubernetes, который должен работать на всех узлах, чтобы заставлять службы работать. Наборы демонов (DaemonSet) запускают только одну реплику модуля на каждом узле, в то время как наборы реплик (replicaset) разбрасывают их по всему кластеру случайным образом.
Для запуска модуля на всех узлах кластера создается объект DaemonSet, который похож на объекты ReplicaSet, за исключением того, что модули, созданные набором демонов, уже имеют заданный целевой узел и пропускают планировщик Kubernetes, т.е. они не разбросаны по кластеру случайным образом. Набор демонов гарантированно создает модули по количеству узлов, и разворачивает каждый на своем узле. Падение узла не заставляет объект DaemonSet создавать модуль в другом месте. Но когда новый узел добавляется в кластер, набор демонов немедленно развертывает в нем новый экземпляр модуля.
Объяснение наборов демонов на примере
Развернем демон ssd-monitor, который должен работать на всех узлах, содержащих твердотельный накопитель (SSD). Создадим объект DaemonSet, который запускает этот демон на всех узлах, помеченных как имеющие SSD. Подразумевается, что администраторы кластера добавили метку disk=ssd во все такие узлы, поэтому создадим объект DaemonSet с помощью селектора узлов, который выбирает только узлы с этой меткой.
Создание YAML-определения ресурса DaemonSet (создайте файл с именем ssd-monitor-daemonset.yaml): (далее…)
0