Наиболее подробное изложение учебных заметок K8S (последняя версия 2021 г.)

Несмотря на то чтоDockerОн уже очень мощный, но в реальном использовании все еще остается много неудобств, таких как управление кластером, планирование ресурсов, управление файлами и так далее. Затем, в такую ​​процветающую эпоху контейнеров, появилось много решений, таких как Mesos, Swarm, Kubernetes и т. д.KubernetesЭто существование старшего брата.

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

Введение в кубернет

Основная проблема, которую решает Kubernetes

• Обнаружение сервисов и балансировка нагрузки
  • Kubernetes может предоставлять контейнеры, используя DNS-имена или их собственные IP-адреса, если трафик к контейнерам большой,KubernetesСетевой трафик можно балансировать и распределять по нагрузке, что делает развертывание стабильным.
• Организация хранения
  • Kubernetes позволяет автоматически монтировать систему хранения по вашему выбору, например, локальное хранилище, общедоступных облачных провайдеров и т. д.
• Автоматическое развертывание и откат
  • ты можешь использовать этоKubernetesОписывает желаемое состояние развернутого контейнера, который может изменить фактическое состояние на желаемое с контролируемой скоростью. Например, вы можете автоматизировать Kubernetes для создания новых контейнеров для вашего развертывания, удаления существующих контейнеров и использования всех их ресурсов для новых контейнеров.
• Автоматическая бинарная упаковка
  • Kubernetes позволяет указать ЦП и память (ОЗУ), необходимые для каждого контейнера. Когда контейнер указывает запрос ресурса,KubernetesМожно принимать лучшие решения для управления ресурсами контейнера.
• самоисцеление
  • Kubernetes перезапускает неисправные контейнеры, заменяет контейнеры, уничтожает контейнеры, которые не отвечают на определенные пользователем проверки работоспособности, и не сообщает о них клиентам, пока они не будут готовы к обслуживанию.
• Управление ключами и конфигурациями
  • KubernetesПозволяет хранить и управлять конфиденциальной информацией, такой как пароли, токены OAuth и ключи ssh. Вы можете развертывать и обновлять ключи и конфигурацию приложения, не перестраивая образы контейнеров и не раскрывая ключи в конфигурации стека.

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

График знаний

В основном внедрять какие знания

Архитектура программного обеспечения

Традиционная клиент-серверная архитектура

• Описание архитектуры

Kubernetes использует очень традиционную архитектуру клиент-сервер: клиенты могут взаимодействовать через интерфейсы RESTful или напрямую с помощью kubectl.KubernetesНа самом деле между ними нет большой разницы, последний только инкапсулирует и предоставляет RESTful API, предоставляемый Kubernetes. КаждыйKubernetesКластер состоит из набора главных узлов и ряда рабочих узлов, где главный узел в основном отвечает за хранение состояния кластера, а также за выделение и планирование ресурсов для объектов Kubernetes.

• Служба главного узла — главная архитектура

Как главный узел, управляющий состоянием кластера, он в основном отвечает за получение запросов от клиентов, организацию выполнения контейнеров и выполнение цикла управления, а также перевод состояния кластера в целевое состояние. Главный узел состоит из следующих трех компонентов:

Сервер API: отвечает за обработку запросов от пользователей. Его основная функция заключается в предоставлении интерфейса RESTful для внешнего мира, включая запросы на чтение для просмотра состояния кластера и запросы на запись для изменения состояния кластера. Это также единственный компонент, который взаимодействует с кластерами etcd. .

etcd: это база данных типа «ключ-значение» с согласованностью и высокой доступностью, которую можно использовать в качестве серверной базы данных для хранения всех данных кластера Kubernetes.

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

диспетчер-контроллера: Компонент, который запускает контроллеры на главном узле, каждый контроллер логически является отдельным процессом, но для уменьшения сложности все они скомпилированы в один и тот же исполняемый файл и запускаются в одном запущенном процессе. Эти контроллеры включают в себя: контроллеры узлов (отвечают за уведомление и реагирование на сбои узлов), контроллеры реплик (отвечают за поддержание правильного количества модулей Pod для каждого объекта контроллера реплики в системе), контроллеры конечных точек (заполнение объекта конечных точек, т. е. объединение службы и модуля). ), учетная запись службы и контроллер токенов (создает учетную запись по умолчанию и токен доступа к API для новых пространств имен).

• Рабочие узлы — Архитектура узла

Реализация других узлов Worker относительно проста и состоит в основном из kubelet и kube-proxy.

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

kube-proxy: простой прокси-сервер для доступа к сети, а также балансировщик нагрузки. Он отвечает за назначение запросов к службе модулям с одинаковым типом метки на рабочих узлах. Суть kube-proxy заключается в том, чтобы реализовать сопоставление подов с помощью правил брандмауэра (iptables или ipvs).

Среда выполнения контейнера: среда выполнения контейнера — это программное обеспечение, отвечающее за запуск контейнеров.Kubernetes поддерживает несколько сред выполнения контейнеров: Docker, containerd, cri-o, rktlet и любую реализацию, реализующую Kubernetes CRI (интерфейс времени выполнения контейнера).

Компонент Описание

В основном познакомить с некоторыми основными понятиями о K8s

В основном он состоит из следующих основных компонентов:

• apiserver
  • Единственная запись для доступа ко всем службам, обеспечивающая аутентификацию, авторизацию, управление доступом, регистрацию API и механизмы обнаружения.
• controller manager
  • Отвечает за поддержание состояния кластера, такого как ожидаемое количество реплик, обнаружение сбоев, автоматическое масштабирование, последовательные обновления и т. д.
• scheduler
  • Отвечает за планирование ресурсов и планирование подов на соответствующие машины в соответствии с заранее определенными политиками планирования.
• etcd
  • База данных «ключ-значение», в которой хранится состояние всего кластера.
• kubelet
  • Отвечает за поддержание жизненного цикла контейнеров, а также за управление объемом и сетью.
• kube-proxy
  • Отвечает за обнаружение службы и балансировку нагрузки в кластере для службы.
• Container runtime
  • Отвечает за управление образами и фактическую работу модулей и контейнеров.

В дополнение к основным компонентам есть несколько рекомендуемых плагинов:

• CoreDNS
  • Служба DNS, которая может создать разрешение IP-соответствия доменного имени для SVC в кластере.
• Dashboard
  • Предоставляет запись доступа к архитектуре B/S для кластера K8s.
• Ingress Controller
  • Чиновники могут реализовать только четырехуровневый сетевой прокси, в то время как Ingress может реализовать семиуровневый прокси.
• Prometheus
  • Предоставляет возможность мониторинга ресурсов для кластеров K8s
• Federation
  • Предоставляет унифицированную функцию управления, которая может управлять несколькими K8 в центрах кластеров и предоставляет кластеры в разных зонах доступности.

Ссылки на вышеуказанный контент:woohoo.escape life.site/posts/2 из 421…

Установить

Установка версии v1.16.0 оказалась успешной. Запишите это здесь, чтобы опоздавшие не наступили на яму.

В этой статье шаги установки следующие:

• Установите docker-ce 18.09.9 (все машины)
• Установите предварительные условия среды k8s (все машины)
• Установите главный узел управления k8s v1.16.0
• Установите рабочий узел узла k8s v1.16.0
• Установить фланель (мастер)

Подробные инструкции по установке см.CentOS построила K8S, разовый успех, в закладки!Руководства по установке кластера см. по адресу:Последнее и самое подробное руководство по кластеру K8S, основанное на версии всей сети V1.20, без развертывания в яме и с минимальным кластером K8S.

Принцип реализации пода

Pod — это самый маленький и простой объект Kubernetes.

Pod, Service, Volume и Namespace — четыре основных объекта в кластере Kubernetes, которые могут представлять приложения, рабочие нагрузки, сетевые и дисковые ресурсы, развернутые в системе, и вместе определяют состояние кластера. Многие другие ресурсы в Kubernetes на самом деле объединяют только эти базовые объекты.

• Pod -> базовая единица в кластере
• Сервис -> Решить проблему, как получить доступ к сервису в Pod
• Volume -> том хранилища в кластере
• Пространство имен -> Пространство имен обеспечивает виртуальную изоляцию кластера.

Для получения подробной информации см.:Принцип реализации пода в Kubernetes

Портовый склад

Инструмент для приватного репозитория Kuternetes Enterprise Docker. Каждый компонент Harbour построен как контейнер Docker, который развертывается с помощью Docker Compose. Шаблон Docker Compose для развертывания Harbour находится в /Deployer/docker-compose.yml, который состоит из 5 контейнеров, которые связаны между собой ссылкой Docker и обращаются друг к другу через имена контейнеров. Для конечных пользователей должен быть открыт только служебный порт прокси-сервера (т. е. Nginx).

• Proxy
  • Обратный прокси, состоящий из сервера Nginx
• Registry
  • Экземпляр контейнера, состоящий из официального образа реестра с открытым исходным кодом Docker.
• UI
  • То есть служба основных служб в архитектуре, код, из которого состоит этот контейнер, является основным телом проекта Harbour.
• MySQL
  • Контейнер базы данных, состоящий из официального образа MySQL.
• Log
  • Контейнер, на котором запущен rsyslogd, собирает журналы из других контейнеров в виде log-driver.

Для подробного ознакомления и шагов по созданию, пожалуйста, обратитесь к:Создан на основе Harbour в среде корпоративного уровня.

YAML-синтаксис

YAML — очень лаконичный/мощный/специализированный язык для написания конфигурационных файлов!

Полное название YAML является рекурсивной аббревиатурой «YAML не является языком разметки». Дизайн языка относится к таким языкам, как JSON/XML и SDL, с акцентом на ориентированность на данные, краткость и удобочитаемость, а также на простоту написания. .

Особенности синтаксиса YAML

Тем, кто научился программированию, должно быть очень легко понять

грамматические особенности

• Деликатный случай
• Иерархические отношения представлены отступом
• Отступ табуляции запрещен, можно использовать только пробел
• Количество пробелов с отступом не имеет значения, если один и тот же уровень выровнен по левому краю.
• Используйте # для комментариев

Рекомендую всем статью:Синтаксис YAML для Kubernetes, эта статья очень подробная, со множеством примеров.

Список ресурсов

Весь контент в K8S абстрагируется в ресурсы, а ресурсы называются объектами после того, как они созданы.

В системе KubernetesKubernetesОбъекты являются постоянными сущностями,KubernetesИспользуйте эти сущности для представления состояния всего кластера. В частности, они описывают следующую информацию:

• Какие контейнерные приложения работают и на каком узле
• Ресурсы, которые может использовать приложение
• Стратегии поведения приложения во время выполнения, такие как стратегии перезапуска, стратегии обновления и стратегии отказоустойчивости.

KubernetesОбъекты являются «целевыми записями»: как только объект создан,KubernetesСистема будет работать непрерывно, чтобы убедиться, что объект существует. Создавая объекты, вы, по сути, сообщаете системе Kubernetes, как выглядит желаемая рабочая нагрузка кластера, то есть желаемое состояние кластера Kubernetes.

Подробное введение в список ресурсов Kubernetes см. здесь.

контроллер ресурсов

Написание файлов конфигурации контроллера ресурсов Kubernetes — самая важная часть изучения K8S!

Контроллер квоты ресурсов гарантирует, что указанные объекты ресурсов никогда не превысят настроенные ресурсы, что может эффективно снизить вероятность выхода из строя всей системы, повысить надежность системы и сыграть очень важную роль в стабильности всего кластера. .

Руководство пользователя Kubernetes Resource Controller Руководство пользователя

обнаружение службы

В Kubernetes для достижения балансировки нагрузки между экземплярами службы и обнаружения службы между разными службами создается объект Service, а также создается объект Ingress для доступа к кластеру извне кластера.

Обнаружение сервисов в Kubernetes

Входящий сервис

Все мы знаем, что традиционный SVC поддерживает только код выше четырех уровней и ничего не может сделать для кода выше семи уровней. Например: мы используем кластер K8S для предоставления HTTPS-сервисов внешнему миру, для удобства и удобства нам необходимо настроить SSL-шифрование на внешнем сервисе Nginx, но при отправке запроса на серверный сервис операция удаления сертификата Протокол HTTP для обработки. Перед лицом этой проблемы K8S предлагает использовать Ingress (K8S запущен в версии 1.11) для решения этой проблемы.

Подробнее см.:Ingress-сервис в Kubernetes, представляет метод установки службы Ingress, настраивает доступ через HTTP-прокси для службы Ingress, представляет метод аутентификации BasicAuth для службы Ingress и представляет метод перезаписи правил службы Ingress.

хранилище данных

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

Внедрение общих механизмов хранения в K8S позволяет нам использовать:Хранение данных в Kubernetes

Кластерное планирование

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

Scheduler — планировщик kubernetes, основная задача — назначить определенный Pod узлам кластера. Звучит очень просто, но есть над чем подумать:

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

Планировщик запускается как отдельная программа, после запуска он всегда будет противостоять API-серверу, получать поды, у которых PodSpec.NodeName пуст, и создавать для каждого пода привязку, указывающую, на каком узле следует разместить под.

Для подробного ознакомления, пожалуйста, обратитесь к:Планирование кластера Kubernetes

Как использовать кубектл

kubectl — это клиент, который поставляется с Kubernetes, вы можете использовать его для работы напрямую.Kubernetesкластер.

ежедневное использованиеKubernetesИнструмент kubectl, вероятно, является наиболее часто используемым инструментом, поэтому, когда мы тратим много времени на исследования и изучениеKuernetesВ то время нам очень необходимо понять, как его использовать эффективно.

С точки зрения пользователя kubectl — это кабина, управляющая Kubernetes и позволяющая выполнять все возможные операции Kubernetes; с технической точки зрения kubectl — это просто клиент API Kubernetes.

Kubernetes API — это служба HTTP REST API, представляющая собой настоящий пользовательский интерфейс Kubernetes, поэтомуKubernetesФактический контроль осуществляется через этот API. Это означает, что каждыйKubernetesВсе операции доступны через конечные точки API, и, конечно же, соответствующие операции можно выполнять, отправляя HTTP-запросы к этим портам API. Поэтому основная задача kubectl — выполнятьKubernetesHTTP-запросы к API.

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

get       #显示一个或多个资源
describe  #显示资源详情
create    #从文件或标准输入创建资源
update   #从文件或标准输入更新资源
delete   #通过文件名、标准输入、资源名或者 label 删除资源
log       #输出 pod 中一个容器的日志
rolling-update  #对指定的 RC 执行滚动升级
exec  #在容器内部执行命令
port-forward #将本地端口转发到 Pod
proxy   #为 Kubernetes API server 启动代理服务器
run     #在集群中使用指定镜像启动容器
expose   #将 SVC 或 pod 暴露为新的 kubernetes service
label     #更新资源的 label
config   #修改 kubernetes 配置文件
cluster-info #显示集群信息
api-versions #以”组/版本”的格式输出服务端支持的 API 版本
version       #输出服务端和客户端的版本信息
help         #显示各个命令的帮助信息
ingress-nginx  #管理 ingress 服务的插件(官方安装和使用方式)

Использовать связанную конфигурацию

# Kubectl自动补全
$ source <(kubectl completion zsh)
$ source <(kubectl completion bash)

# 显示合并后的 kubeconfig 配置
$ kubectl config view

# 获取pod和svc的文档
$ kubectl explain pods,svc

Создать ресурсный объект

Создать пошагово

# yaml
kubectl create -f xxx-rc.yaml
kubectl create -f xxx-service.yaml

# json
kubectl create -f ./pod.json
cat pod.json | kubectl create -f -

# yaml2json
kubectl create -f docker-registry.yaml --edit -o json

одноразовое создание

kubectl create -f xxx-service.yaml -f xxx-rc.yaml

Создать в соответствии с определением содержимое всех файлов yaml в каталоге

kubectl create -f <目录>

использовать URL для создания ресурса

kubectl create -f https://git.io/vPieo

Просмотр объектов ресурсов

Просмотреть все объекты Node или Namespace

kubectl get nodes
kubectl get namespace

Просмотреть все объекты Pod

# 查看子命令帮助信息
kubectl get --help

# 列出默认namespace中的所有pod
kubectl get pods

# 列出指定namespace中的所有pod
kubectl get pods --namespace=test

# 列出所有namespace中的所有pod
kubectl get pods --all-namespaces

# 列出所有pod并显示详细信息
kubectl get pods -o wide
kubectl get replicationcontroller web
kubectl get -k dir/
kubectl get -f pod.yaml -o json
kubectl get rc/web service/frontend pods/web-pod-13je7
kubectl get pods/app-prod-78998bf7c6-ttp9g --namespace=test -o wide
kubectl get -o template pod/web-pod-13je7 --template={{.status.phase}}

# 列出该namespace中的所有pod包括未初始化的
kubectl get pods,rc,services --include-uninitialized

Посмотреть все ЖБ объекты

kubectl get rc

Просмотреть все объекты развертывания

# 查看全部deployment
kubectl get deployment

# 列出指定deployment
kubectl get deployment my-app

Просмотреть все объекты службы

kubectl get svc
kubectl get service

Просмотр объектов Pod в разных пространствах имен

kubectl get pods -n default
kubectl get pods --all-namespace

Посмотреть описания ресурсов

Показать сведения о модуле

kubectl describe pods/nginx
kubectl describe pods my-pod
kubectl describe -f pod.json

Просмотр сведений об узле

kubectl describe nodes c1

Просмотр информации Pod, связанной с RC

kubectl describe pods <rc-name>

Обновление ресурсов исправления

скользящее обновление

# 滚动更新 pod frontend-v1
kubectl rolling-update frontend-v1 -f frontend-v2.json

# 更新资源名称并更新镜像
kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2

# 更新 frontend pod 中的镜像
kubectl rolling-update frontend --image=image:v2

# 退出已存在的进行中的滚动更新
kubectl rolling-update frontend-v1 frontend-v2 --rollback

# 强制替换; 删除后重新创建资源; 服务会中断
kubectl replace --force -f ./pod.json

# 添加标签
kubectl label pods my-pod new-label=awesome

# 添加注解
kubectl annotate pods my-pod icon-url=http://goo.gl/XXBTWq

патч ресурсы

# 部分更新节点
kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}'

# 更新容器镜像；spec.containers[*].name 是必须的，因为这是合并的关键字
kubectl patch pod valid-pod -p \
    '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}'

Ресурсы масштабирования

# Scale a replicaset named 'foo' to 3
kubectl scale --replicas=3 rs/foo

# Scale a resource specified in "foo.yaml" to 3
kubectl scale --replicas=3 -f foo.yaml

# If the deployment named mysql's current size is 2, scale mysql to 3
kubectl scale --current-replicas=2 --replicas=3 deployment/mysql

# Scale multiple replication controllers
kubectl scale --replicas=5 rc/foo rc/bar rc/baz

удалить ресурсный объект

Удалить объект Pod на основе файла xxx.yaml

# yaml文件名字按照你创建时的文件一致
kubectl delete -f xxx.yaml

Удалить объект модуля, содержащий метку

kubectl delete pods -l name=<label-name>

Удалить объект службы, содержащий метку

kubectl delete services -l name=<label-name>

Удалить объекты модуля и службы, включая метку

kubectl delete pods,services -l name=<label-name>

удалить все объекты pod/services

kubectl delete pods --all
kubectl delete service --all
kubectl delete deployment --all

Редактировать файлы ресурсов

Редактировать любой ресурс API в редакторе

# 编辑名为docker-registry的service
kubectl edit svc/docker-registry

выполнить команду напрямую

На хосте выполнять команды напрямую, не заходя в контейнер

Выполните команду date модуля. По умолчанию для выполнения используется первый контейнер модуля.

kubectl exec mypod -- date
kubectl exec mypod --namespace=test -- date

Укажите контейнер в модуле для выполнения команды даты

kubectl exec mypod -c ruby-container -- date

в контейнер

kubectl exec mypod -c ruby-container -it -- bash

Просмотр журналов контейнера

Просмотр журналов напрямую

# 不实时刷新kubectl logs mypod
kubectl logs mypod --namespace=test

Просмотр обновления журнала в режиме реального времени

kubectl logs -f mypod -c ruby-container

инструменты управления

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

K9s

k9s — это инструментальная панель ресурсов на основе терминала. Он имеет только интерфейс командной строки. Независимо от того, что вы делаете в веб-интерфейсе панели инструментов Kubernetes, вы можете использовать инструмент панели инструментов K9s в терминале, чтобы сделать то же самое. k9s следит за кластерами Kubernetes и предоставляет команды для использования ресурсов, определенных в кластере.

Подробное введение:Инструмент управления кластером Kubernetes K9S

рекомендовать:7 инструментов для простого управления кластерами Kubernetes

Лучшие практики для производственных сред

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

Используются ли проверки работоспособности с помощью тестов живучести и тестов готовности?

Управление большими распределенными системами может быть сложным, особенно когда что-то идет не так, и мы не можем быть уведомлены вовремя. Чтобы убедиться, что экземпляр приложения работает правильно, установитеKubernetesПроверка здоровья имеет решающее значение.

Создавая пользовательскую проверку работоспособности, вы можете эффективно избежать запуска зомби-служб в распределенной системе, которую можно настроить в соответствии со средой и потребностями.

Цель зонда готовности состоит в том, чтобы позволитьKubernetesУзнайте, готово ли приложение обслуживать трафик. Kubernetes всегда будет следить за тем, чтобы проверка готовности прошла и начала распространять сервис, отправляя трафик в под.

Жизнеспособность - проба живости

Как узнать, живо ваше приложение или мертво? Если ваше приложение умрет, Kubernetes удалит старый Pod и заменит его новым Pod.

Resource Management-управление ресурсами

Рекомендуется указывать запросы ресурсов и ограничения для отдельных контейнеров. Еще одна хорошая практика — разделить среду Kubernetes на отдельные пространства имен для разных команд, отделов, приложений и клиентов.

Использование ресурсов Kubernetes

Использование ресурсов Kubernetes относится к количеству ресурсов, которые контейнер/модуль использует в производстве.

Поэтому очень важно уделять пристальное внимание использованию ресурсов модулями. Очевидная причина — стоимость, так как более высокая степень использования ресурсов свидетельствует о меньшем их растрачивании.

Использование ресурсов Использование ресурсов

Команды эксплуатации часто хотят оптимизировать и максимизировать процент ресурсов, потребляемых модулями. Использование ресурсов — это один из показателей того, насколько хорошо на самом деле оптимизирована среда Kubernetes.

Вы можете подумать, что оптимизированныйKubernetesСреднее использование ЦП и других ресурсов контейнерами, работающими в среде, является оптимальным.

Включить RBAC

RBAC расшифровывается как управление доступом на основе ролей. Это метод ограничения доступа и допуска пользователей и приложений в системе/сети. !

Они представили RBAC из Kubernetes версии 1.8. Используйте rbac.authorization.k8s RBAC используется для создания политик авторизации.

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

Инициализация кластера и балансировка нагрузки

Инфраструктура Kubernetes производственного уровня часто требует рассмотрения определенных ключевых аспектов, таких как высокая доступность, кластеры Kubernetes с несколькими мастерами, несколькими и т. д. и т. д. Для настройки таких кластеров обычно используются такие инструменты, как Terraform или Ansible.

После того, как кластер настроен и созданы модули для запуска приложений, эти модули оснащаются балансировщиками нагрузки; эти балансировщики нагрузки направляют трафик к службам. Проект Kubernetes с открытым исходным кодом не является балансировщиком нагрузки по умолчанию, поэтому его необходимо интегрировать с контроллером NGINX Ingress с такими инструментами, как HAProxy или ELB, или любым другим инструментом, который дополняет плагин Kubernetes Ingress для обеспечения возможностей балансировки нагрузки.

Добавляйте метки к объектам Kubernetes

Метки подобны парам ключ/значение, прикрепленным к объектам, таким как модули. Теги используются для идентификации свойств объектов, важных и значимых для пользователя.

Важной проблемой, которую нельзя упускать из виду при использовании Kubernetes в производственной среде, являются метки; метки позволяют запрашивать и манипулировать объектами Kubernetes в пакетном режиме. Метки уникальны тем, что их также можно использовать для идентификации и организации объектов Kubernetes в группы. Один из лучших вариантов использования для этого — группировать модули на основе приложения, к которому они принадлежат. Здесь команды могут создавать и иметь любое количество соглашений по маркировке.

Настройка сетевой политики

Настройка сетевых политик имеет решающее значение при использовании Kubernetes. Сетевая политика — это не что иное, как объект, который позволяет вам явно указывать и решать, какой трафик разрешен, а какой нет. Таким образом, Kubernetes сможет блокировать весь другой нежелательный и несоответствующий трафик. Определение и ограничение сетевого трафика в нашем кластере — одна из основных и необходимых мер безопасности, которую мы настоятельно рекомендуем.

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

Мониторинг кластера и ведение журнала

Мониторинг развертываний имеет решающее значение при работе с Kubernetes. Еще важнее обеспечить безопасность конфигурации, производительности и трафика. Без регистрации и мониторинга невозможно диагностировать, что происходит. Для обеспечения соответствия очень важными становятся мониторинг и ведение журналов. При мониторинге необходимо настроить возможности ведения журналов на каждом уровне архитектуры. Сгенерированные журналы помогут нам включить инструменты безопасности, функции аудита и проанализировать производительность.

Начните с приложения без сохранения состояния

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

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

Запустить автоматическое масштабирование

Kubernetes имеет три функции автоматического масштабирования для развертываний: горизонтальное автоматическое масштабирование модулей (HPA), вертикальное автоматическое масштабирование модулей (VPA) и автоматическое масштабирование кластера.

Горизонтальное автомасштабирование pod автоматически масштабирует количество развертываний, контроллеров репликации, наборов реплик и наборов состояний на основе воспринимаемой загрузки ЦП.

Вертикальное автомасштабирование pod рекомендует подходящие значения для запросов и ограничений ЦП и памяти и может автоматически обновлять эти значения.

Cluster Autoscaler увеличивает и уменьшает размер пула рабочих узлов. Он изменяет размер кластера Kubernetes в зависимости от текущего использования.

Источник вытягивания зеркала управления

Управляет источником образа, который запускает все контейнеры в кластере. Если вы позволите своим модулям извлекать изображения из общедоступных источников, вы не будете знать, что в них на самом деле работает.

Если вы извлекаете их из доверенного реестра, вы можете применить к реестру политики для извлечения безопасных и сертифицированных образов.

непрерывное обучение

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

Защита жизненно важных услуг

Используя приоритет пода, вы можете решить, насколько важно настроить запуск различных служб. Например, для лучшей стабильности вам необходимо убедиться, что модуль RabbitMQ важнее, чем модуль вашего приложения. Или ваши модули контроллера входящего трафика важнее, чем модули обработки данных, чтобы служба оставалась доступной для пользователей.

Нулевое время простоя

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

Используйте антипривязку модулей, чтобы гарантировать, что несколько копий модуля будут запланированы на разных узлах, тем самым обеспечив доступность службы во время запланированного и незапланированного простоя узла кластера.

Используйте стратегию сбоев подов, чтобы любой ценой обеспечить минимальное количество реплик подов!

план провалился

Аппаратное обеспечение в конечном итоге выйдет из строя, а программное обеспечение в конечном итоге заработает. --(Майкл Хаттон)

в заключении

Как мы все знаем, Kubernetes на самом деле сталDevOpsСтандарт платформы оркестровки домена. Kubernetes справляется с производственной бурей с точки зрения доступности, масштабируемости, безопасности, отказоустойчивости, управления ресурсами и мониторинга. Поскольку многие компании используют Kubernetes в производственной среде, для беспрепятственного и надежного масштабирования приложений необходимо следовать упомянутым выше рекомендациям.

Источник контента:no.OSCHINA.net/U/1787735/no…

Представляем 5 лучших инструментов мониторинга журналов Kubernetes

Одна из проблем, которая часто возникает при новых установках Kubernetes, заключается в том, что Служба работает неправильно. Если вы запустили развертывание и создали службу, но не получили ответа при попытке доступа к ней, надеюсь, эта документация (Самая подробная служба K8s во всей сети не может получить доступ к процессу устранения неполадок) может помочь вам определить проблему.

Сводка часто задаваемых вопросов по Kubernetes

Как удалить rc,deployment,service в несогласованном состоянии

В некоторых случаях часто обнаруживается, что процесс kubectl зависает, а потом обнаруживается, что половина его удаляется при get, а другая не может быть удалена.

[root@k8s-master ~]# kubectl get -f fluentd-elasticsearch/
NAME DESIRED CURRENT READY AGE
rc/elasticsearch-logging-v1 0 2 2 15h

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
deploy/kibana-logging 0 1 1 1 15h
Error from server (NotFound): services "elasticsearch-logging" not found
Error from server (NotFound): daemonsets.extensions "fluentd-es-v1.22" not found
Error from server (NotFound): services "kibana-logging" not found

Удалите эти команды развертывания, обслуживания или rc следующим образом:

kubectl delete deployment kibana-logging -n kube-system --cascade=false

kubectl delete deployment kibana-logging -n kube-system  --ignore-not-found

delete rc elasticsearch-logging-v1 -n kube-system --force now --grace-period=0

Как сбросить etcd после удаления

rm -rf /var/lib/etcd/*

Перезагрузите главный узел после удаления.

reset etcd 后需要重新设置网络

etcdctl mk /atomic.io/network/config '{ "Network": "192.168.0.0/16" }'

Не удалось запустить apiserver

Каждый раз, когда я запускаю его, сообщается о следующей проблеме:

start request repeated too quickly for kube-apiserver.service

Но на самом деле проблема не в частоте запуска, нужно проверять /var/log/messages, в моем случае это было из-за того, что ca.crt и другие файлы не могли быть найдены после открытия ServiceAccount, в результате чего ошибка запуска.

May 21 07:56:41 k8s-master kube-apiserver: Flag --port has been deprecated, see --insecure-port instead.
May 21 07:56:41 k8s-master kube-apiserver: F0521 07:56:41.692480 4299 universal_validation.go:104] Validate server run options failed: unable to load client CA file: open /var/run/kubernetes/ca.crt: no such file or directory
May 21 07:56:41 k8s-master systemd: kube-apiserver.service: main process exited, code=exited, status=255/n/a
May 21 07:56:41 k8s-master systemd: Failed to start Kubernetes API Server.
May 21 07:56:41 k8s-master systemd: Unit kube-apiserver.service entered failed state.
May 21 07:56:41 k8s-master systemd: kube-apiserver.service failed.
May 21 07:56:41 k8s-master systemd: kube-apiserver.service holdoff time over, scheduling restart.
May 21 07:56:41 k8s-master systemd: start request repeated too quickly for kube-apiserver.service
May 21 07:56:41 k8s-master systemd: Failed to start Kubernetes API Server.

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

Отказано в доступе

Невозможно создать /var/log/fluentd.log: при настройке fluentd появляется ошибка «Отказано в доступе», это связано с тем, что безопасность SElinux не отключена.

Вы можете отключить SELINUX=enforcing в /etc/selinux/config, а затем перезагрузиться.

Конфигурация на основе ServiceAccount

Сначала сгенерируйте все необходимые ключи, k8s-master необходимо заменить на имя хоста мастера.

openssl genrsa -out ca.key 2048
openssl req -x509 -new -nodes -key ca.key -subj "/CN=k8s-master" -days 10000 -out ca.crt
openssl genrsa -out server.key 2048

echo subjectAltName=IP:10.254.0.1 > extfile.cnf

#ip由下述命令决定

#kubectl get services --all-namespaces |grep 'default'|grep 'kubernetes'|grep '443'|awk '{print $3}'

openssl req -new -key server.key -subj "/CN=k8s-master" -out server.csr

openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -extfile extfile.cnf -out server.crt -days 10000

Если вы измените параметры файла конфигурации /etc/kubernetes/apiserver, systemctl start kube-apiserver не запустится, и появится сообщение об ошибке:

Validate server run options failed: unable to load client CA file: open /root/keys/ca.crt: permission denied

Но сервер API можно запустить из командной строки.

/usr/bin/kube-apiserver --logtostderr=true --v=0 --etcd-servers=http://k8s-master:2379 --address=0.0.0.0 --port=8080 --kubelet-port=10250 --allow-privileged=true --service-cluster-ip-range=10.254.0.0/16 --admission-control=ServiceAccount --insecure-bind-address=0.0.0.0 --client-ca-file=/root/keys/ca.crt --tls-cert-file=/root/keys/server.crt --tls-private-key-file=/root/keys/server.key --basic-auth-file=/root/keys/basic_auth.csv --secure-port=443 &>> /var/log/kubernetes/kube-apiserver.log &

Запустите Controller-manager из командной строки

/usr/bin/kube-controller-manager --logtostderr=true --v=0 --master=http://k8s-master:8080 --root-ca-file=/root/keys/ca.crt --service-account-private-key-file=/root/keys/server.key & >>/var/log/kubernetes/kube-controller-manage.log

ETCD не запускается - проблема

etcd — это процесс zookeeper кластера kubernetes.От запуска etcd зависят почти все сервисы, такие как flanneld, apiserver, docker..... При запуске etcd журнал ошибок выглядит следующим образом:

May 24 13:39:09 k8s-master systemd: Stopped Flanneld overlay address etcd agent.
May 24 13:39:28 k8s-master systemd: Starting Etcd Server...
May 24 13:39:28 k8s-master etcd: recognized and used environment variable ETCD_ADVERTISE_CLIENT_URLS=http://etcd:2379,http://etcd:4001
May 24 13:39:28 k8s-master etcd: recognized environment variable ETCD_NAME, but unused: shadowed by corresponding flag
May 24 13:39:28 k8s-master etcd: recognized environment variable ETCD_DATA_DIR, but unused: shadowed by corresponding flag
May 24 13:39:28 k8s-master etcd: recognized environment variable ETCD_LISTEN_CLIENT_URLS, but unused: shadowed by corresponding flag
May 24 13:39:28 k8s-master etcd: etcd Version: 3.1.3
May 24 13:39:28 k8s-master etcd: Git SHA: 21fdcc6
May 24 13:39:28 k8s-master etcd: Go Version: go1.7.4
May 24 13:39:28 k8s-master etcd: Go OS/Arch: linux/amd64
May 24 13:39:28 k8s-master etcd: setting maximum number of CPUs to 1, total number of available CPUs is 1
May 24 13:39:28 k8s-master etcd: the server is already initialized as member before, starting as etcd member...
May 24 13:39:28 k8s-master etcd: listening for peers on http://localhost:2380
May 24 13:39:28 k8s-master etcd: listening for client requests on 0.0.0.0:2379
May 24 13:39:28 k8s-master etcd: listening for client requests on 0.0.0.0:4001
May 24 13:39:28 k8s-master etcd: recovered store from snapshot at index 140014
May 24 13:39:28 k8s-master etcd: name = master
May 24 13:39:28 k8s-master etcd: data dir = /var/lib/etcd/default.etcd
May 24 13:39:28 k8s-master etcd: member dir = /var/lib/etcd/default.etcd/member
May 24 13:39:28 k8s-master etcd: heartbeat = 100ms
May 24 13:39:28 k8s-master etcd: election = 1000ms
May 24 13:39:28 k8s-master etcd: snapshot count = 10000
May 24 13:39:28 k8s-master etcd: advertise client URLs = http://etcd:2379,http://etcd:4001
May 24 13:39:28 k8s-master etcd: ignored file 0000000000000001-0000000000012700.wal.broken in wal
May 24 13:39:29 k8s-master etcd: restarting member 8e9e05c52164694d in cluster cdf818194e3a8c32 at commit index 148905
May 24 13:39:29 k8s-master etcd: 8e9e05c52164694d became follower at term 12
May 24 13:39:29 k8s-master etcd: newRaft 8e9e05c52164694d [peers: [8e9e05c52164694d], term: 12, commit: 148905, applied: 140014, lastindex: 148905, lastterm: 12]
May 24 13:39:29 k8s-master etcd: enabled capabilities for version 3.1
May 24 13:39:29 k8s-master etcd: added member 8e9e05c52164694d [http://localhost:2380] to cluster cdf818194e3a8c32 from store
May 24 13:39:29 k8s-master etcd: set the cluster version to 3.1 from store
May 24 13:39:29 k8s-master etcd: starting server... [version: 3.1.3, cluster version: 3.1]
May 24 13:39:29 k8s-master etcd: raft save state and entries error: open /var/lib/etcd/default.etcd/member/wal/0.tmp: is a directory
May 24 13:39:29 k8s-master systemd: etcd.service: main process exited, code=exited, status=1/FAILURE
May 24 13:39:29 k8s-master systemd: Failed to start Etcd Server.
May 24 13:39:29 k8s-master systemd: Unit etcd.service entered failed state.
May 24 13:39:29 k8s-master systemd: etcd.service failed.
May 24 13:39:29 k8s-master systemd: etcd.service holdoff time over, scheduling restart.

Основное утверждение:

raft save state and entries error: open /var/lib/etcd/default.etcd/member/wal/0.tmp: is a directory

Войдите в соответствующий каталог, удалите 0.tmp, и тогда вы сможете запустить его!

ETCD не запускается - проблема с тайм-аутом

Предыстория проблемы: в настоящее время развернуты 3 узла etcd, и внезапно в один прекрасный день все 3 кластера отключились. После перезапуска обнаруживается, что кластер K8S можно нормально использовать, но после проверки компонентов обнаруживается, что etcd одной ноды не может быть запущен.

После расследования было обнаружено, что время было неточным.Следующая команда ntpdate ntp.aliyun.com была использована для правильной перенастройки времени, перезапуска etcd, и обнаружил, что он все еще не может встать, и ошибка такая следует:

Mar 05 14:27:15 k8s-node2 etcd[3248]: etcd Version: 3.3.13
Mar 05 14:27:15 k8s-node2 etcd[3248]: Git SHA: 98d3084
Mar 05 14:27:15 k8s-node2 etcd[3248]: Go Version: go1.10.8
Mar 05 14:27:15 k8s-node2 etcd[3248]: Go OS/Arch: linux/amd64
Mar 05 14:27:15 k8s-node2 etcd[3248]: setting maximum number of CPUs to 4, total number of available CPUs is 4
Mar 05 14:27:15 k8s-node2 etcd[3248]: the server is already initialized as member before, starting as etcd member
...
Mar 05 14:27:15 k8s-node2 etcd[3248]: peerTLS: cert = /opt/etcd/ssl/server.pem, key = /opt/etcd/ssl/server-key.pe
m, ca = , trusted-ca = /opt/etcd/ssl/ca.pem, client-cert-auth = false, crl-file =
Mar 05 14:27:15 k8s-node2 etcd[3248]: listening for peers on https://192.168.25.226:2380
Mar 05 14:27:15 k8s-node2 etcd[3248]: The scheme of client url http://127.0.0.1:2379 is HTTP while peer key/cert
files are presented. Ignored key/cert files.
Mar 05 14:27:15 k8s-node2 etcd[3248]: listening for client requests on 127.0.0.1:2379
Mar 05 14:27:15 k8s-node2 etcd[3248]: listening for client requests on 192.168.25.226:2379
Mar 05 14:27:15 k8s-node2 etcd[3248]: member 9c166b8b7cb6ecb8 has already been bootstrapped
Mar 05 14:27:15 k8s-node2 systemd[1]: etcd.service: main process exited, code=exited, status=1/FAILURE
Mar 05 14:27:15 k8s-node2 systemd[1]: Failed to start Etcd Server.
Mar 05 14:27:15 k8s-node2 systemd[1]: Unit etcd.service entered failed state.
Mar 05 14:27:15 k8s-node2 systemd[1]: etcd.service failed.
Mar 05 14:27:15 k8s-node2 systemd[1]: etcd.service failed.
Mar 05 14:27:15 k8s-node2 systemd[1]: etcd.service holdoff time over, scheduling restart.
Mar 05 14:27:15 k8s-node2 systemd[1]: Starting Etcd Server...
Mar 05 14:27:15 k8s-node2 etcd[3258]: recognized environment variable ETCD_NAME, but unused: shadowed by correspo
nding flag
Mar 05 14:27:15 k8s-node2 etcd[3258]: recognized environment variable ETCD_DATA_DIR, but unused: shadowed by corr
esponding flag
Mar 05 14:27:15 k8s-node2 etcd[3258]: recognized environment variable ETCD_LISTEN_PEER_URLS, but unused: shadowed
 by corresponding flag
Mar 05 14:27:15 k8s-node2 etcd[3258]: recognized environment variable ETCD_LISTEN_CLIENT_URLS, but unused: shadow
ed by corresponding flag
Mar 05 14:27:15 k8s-node2 etcd[3258]: recognized environment variable ETCD_INITIAL_ADVERTISE_PEER_URLS, but unuse
d: shadowed by corresponding flag
Mar 05 14:27:15 k8s-node2 etcd[3258]: recognized environment variable ETCD_ADVERTISE_CLIENT_URLS, but unused: sha
dowed by corresponding flag
Mar 05 14:27:15 k8s-node2 etcd[3258]: recognized environment variable ETCD_INITIAL_CLUSTER, but unused: shadowed
by corresponding flag
Mar 05 14:27:15 k8s-node2 etcd[3258]: recognized environment variable ETCD_INITIAL_CLUSTER_TOKEN, but unused: sha
dowed by corresponding flag
Mar 05 14:27:15 k8s-node2 etcd[3258]: recognized environment variable ETCD_INITIAL_CLUSTER_STATE, but unused: sha
dowed by corresponding flag

Решение:

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

Введите каталог хранения данных etcd для резервного копирования Резервное копирование исходных данных:

cd /var/lib/etcd/default.etcd/member/
cp *  /data/bak/

Удалить все файлы данных в этом каталоге

rm -rf /var/lib/etcd/default.etcd/member/*

Остановите два других узла etcd, потому что все узлы необходимо запускать вместе при запуске узлов etcd, и их можно использовать после успешного запуска.

#master 节点
systemctl stop etcd
systemctl restart etcd

#node1 节点
systemctl stop etcd
systemctl restart etcd

#node2 节点
systemctl stop etcd
systemctl restart etcd

Настройка взаимного доверия хостов в CentOS

Выполните следующую команду, чтобы сгенерировать открытый ключ/ключ для имени пользователя, который необходим для установления взаимного доверия между хостами на каждом сервере, по умолчанию нажмите Enter.

ssh-keygen -t rsa

Вы можете увидеть файл, который генерирует открытый ключ.

Для передачи открытого ключа друг другу нужно в первый раз ввести пароль, а дальше все ок.

ssh-copy-id -i /root/.ssh/id_rsa.pub root@192.168.199.132 (-p 2222)

-p Порт по умолчанию для порта не добавляет -p. Если порт был изменен, вы должны добавить -p. Вы можете видеть, что файл author_keys создается в .ssh/, который записывает общедоступную информацию о других серверах, которые можно войти на этот сервер.ключ.

Проверьте, можете ли вы войти в систему:

ssh 192.168.199.132 (-p 2222)

Изменение имени хоста CentOS

hostnamectl set-hostname k8s-master1

Virtualbox реализует функциональность копирования и вставки CentOS

Если он не установлен или не выводится, вы можете изменить обновление на установку и запустить его снова.

yum install update
yum update kernel
yum update kernel-devel
yum install kernel-headers
yum install gcc
yum install gcc make

После запуска

sh VBoxLinuxAdditions.run

Удаление модуля находится в состоянии завершения

Вы можете принудительно удалить с помощью следующей команды

kubectl delete pod NAME --grace-period=0 --force

Удалить пространство имен находится в состоянии завершения

Вы можете принудительно удалить с помощью следующего скрипта

[root@k8s-master1 k8s]# cat delete-ns.sh
#!/bin/bash
set -e

useage(){
    echo "useage:"
    echo " delns.sh NAMESPACE"
}

if [ $# -lt 1 ];then
    useage
    exit
fi

NAMESPACE=$1
JSONFILE=${NAMESPACE}.json
kubectl get ns "${NAMESPACE}" -o json > "${JSONFILE}"
vi "${JSONFILE}"
curl -k -H "Content-Type: application/json" -X PUT --data-binary @"${JSONFLE}" \
    http://127.0.0.1:8001/api/v1/namespaces/"${NAMESPACE}"/finalize

Что может пойти не так с контейнером с действительными запросами ЦП/памяти и без установленных ограничений?

Затем мы создаем соответствующий контейнер, в котором установлены только запросы, но не установлены ограничения,

- name: busybox-cnt02
    image: busybox
    command: ["/bin/sh"]
    args: ["-c", "while true; do echo hello from cnt02; sleep 10;done"]
    resources:
      requests:
        memory: "100Mi"
        cpu: "100m"

Что не так с созданием этого контейнера?

На самом деле, в обычной среде проблем нет, но для модулей на основе ресурсов, если для некоторых контейнеров не установлено ограничение, ресурсы будут вытеснены другими модулями, что может привести к сбою приложения-контейнера. Вы можете использовать стратегию limitrange для сопоставления, чтобы поды устанавливались автоматически, при условии, что правила limitrange настроены заранее.

источник:www.cnblogs.com/passzhang

6 советов по устранению неполадок приложений в KubernetesРекомендуется всем, необходим для ежедневного устранения неполадок.Поделитесь практическим руководством Alibaba Cloud Internal Super Full K8s,бесплатная загрузка!

вопросы интервью

Цель:контейнерЭксплуатация, два местоположения и три центра, четырехуровневое обнаружение сервисов, пять типов общих ресурсов Pod, шесть общих подключаемых модулей CNI, семиуровневая балансировка нагрузки, восемь измерений изоляции, девять принципов сетевой модели, десять типов IP-адресов, 100 продуктовая линейка уровня, физическая машина тысячного уровня, контейнер десятитысячного уровня;k8sЕсть 100 миллионов: 100 миллионов ежедневно обслуживающих людей.

Одна цель: контейнерные операции

Kubernetes (k8s) — это платформа с открытым исходным кодом для автоматизации операций с контейнерами. Эти контейнерные операции включают в себя: развертывание, планирование и масштабирование по кластерам узлов.

Специальные функции:

• Автоматизируйте развертывание и репликацию контейнеров.

• Размер эластичного термоусадочного контейнера в реальном времени.

• Контейнеры организованы в группы и обеспечивают балансировку нагрузки между контейнерами.

• Планирование: на какой машине работает контейнер.

сочинение:

• kubectl: инструмент командной строки на стороне клиента, который служит точкой входа для работы всей системы.

• kube-apiserver: предоставляет интерфейс в виде службы REST API в качестве управляющей записи для всей системы.

• kube-controller-manager: выполнение фоновых задач всей системы, включая статус узла, количество модулей, связь между модулями и службами и т. д.

• kube-scheduler: отвечает за управление ресурсами узла, получает задачи от kube-apiserver для создания модулей и назначает их узлу.

• etcd: отвечает за обнаружение сервисов и обмен конфигурациями между узлами.

• kube-proxy: работает на каждом вычислительном узле и отвечает за сетевой прокси Pod. Регулярно получайте служебную информацию от etcd для создания соответствующих политик.

• kubelet: работает на каждом вычислительном узле, выступает в качестве агента, получает задачи Pod, назначенные узлу, и управляет контейнерами, периодически получает статус контейнера и возвращает информацию kube-apiserver.

• DNS: дополнительная служба DNS, которая создает записи DNS для каждого объекта службы, чтобы все поды могли получить доступ к службе через DNS.

Нижеk8sСхема топологии архитектуры:

Три центра в двух местах

---

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

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

k8s использоватьetcdКомпоненты служат высокодоступным, строго согласованным репозиторием обнаружения служб. Используется для настройки общих ресурсов и обнаружения служб.

это какZookeeperи проекты, вдохновленные doozer. В дополнение ко всем их функциям, они также имеют следующие 4 функции:

• Простота: API на основе HTTP+JSON позволяет легко использовать команды curl.

• Безопасность: Дополнительный механизм аутентификации клиента SSL.

• Быстро: каждый экземпляр поддерживает тысячу операций записи в секунду.

• Trusted: Distributed полностью реализован с использованием алгоритма Raft.

Обнаружение сервисов уровня 4

Сначала картинка для объясненияседьмой сетевой уровеньпротокол:

k8s предоставляет два способа обнаружения сервисов:

• Переменные среды: когда под создается, kubelet вводит в под под соответствующие переменные среды всех сервисов в кластере. Следует отметить, что для внедрения переменных среды службы в модуль служба должна быть создана до модуля. Это почти делает обнаружение служб таким образом непригодным для использования. Например, для службы, имя службы которой — redis-master, а соответствующий ClusterIP:Port — 10.0.0.11:6379, соответствующие переменные среды:

• DNS: вы можете легко создать KubeDNS с помощью надстройки кластера, чтобы выполнять обнаружение служб в службах в кластере.

Вышеупомянутые два метода, один основан на TCP, DNS основан на UDP, они основаны на четырехуровневом протоколе.

Общие ресурсы пяти модулей

Pod — это самая основная рабочая единица в k8s, содержащая один или несколько тесно связанных контейнеров.

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

в той же подушкеконтейнерОни могут общаться друг с другом только через localhost.

Контейнеры приложений в Pod совместно используют пять ресурсов:

• Пространство имен PID: различные приложения в поде могут видеть идентификаторы процессов других приложений.

• Сетевое пространство имен: несколько контейнеров в поде могут получить доступ к одному и тому же IP-адресу и диапазону портов.

• Пространство имен IPC: несколько контейнеров в модуле могут обмениваться данными с помощью очередей сообщений SystemV IPC или POSIX.

• Пространство имен UTS: несколько контейнеров в поде имеют общее имя хоста.

• Тома (общие тома хранилища): Отдельные контейнеры в поде могут получить доступ к томам, определенным на уровне пода.

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

Kubernetes разрабатывает уникальную сетевую конфигурацию для подов, включая назначение IP-адреса каждому поду, использование имени пода в качестве имени хоста для связи между контейнерами и т. д.

Шесть распространенных плагинов CNI

CNI (контейнерный сетевой интерфейс) — это набор стандартов и библиотек для конфигурации контейнерной сети Linux.Пользователям необходимо разработать собственные подключаемые модули контейнерной сети в соответствии с этими стандартами и библиотеками. CNI фокусируется только на решении сетевых подключений контейнеров и высвобождении ресурсов, когда контейнеры уничтожаются, и предоставляет набор фреймворков. Таким образом, CNI может поддерживать большое количество различных сетевых режимов и легко реализуется.

На следующей диаграмме представлены шесть распространенных подключаемых модулей CNI:

Балансировка нагрузки уровня 7

Чтобы обеспечить балансировку нагрузки, вы должны сначала упомянуть связь между серверами.

IDC (Internet Data Center) также может называться дата-центром, компьютерным залом, используемым для размещения серверов. Сеть IDC представляет собой мост для связи между серверами.

На картинке выше много сетевых устройств, для чего они нужны?

Маршрутизаторы, коммутаторы и MGW/NAT — все это сетевые устройства, и у них разные роли в зависимости от производительности и внутренних и внешних сетей.

• Коммутатор доступа к интрасети: также известный как TOR (верхняя часть стойки), это устройство, которое соединяет серверы с сетью. Каждый коммутатор доступа к интрасети подключен к 40-48 серверам, а в качестве серверного сегмента интрасети используется сегмент сети с маской /24.
• Коммутатор ядра интрасети: отвечает за пересылку трафика каждого коммутатора доступа интрасети в пределах IDC и переадресацию трафика между IDC.
• MGW/NAT: MGW или LVS используются для балансировки нагрузки, а NAT используется для трансляции адресов, когда внутренние сетевые устройства получают доступ к внешней сети.
• Основной маршрутизатор внешней сети: подключитесь к единой внешней сетевой платформе Meituan через статические операторы межсетевого взаимодействия или BGP.

Поговорим о балансировке нагрузки на каждом уровне:

• Балансировка нагрузки уровня 2: Балансировка нагрузки уровня 2 на основе MAC-адресов.
• Балансировка нагрузки уровня 3: балансировка нагрузки на основе IP-адресов.
• Балансировка нагрузки уровня 4: балансировка нагрузки на основе IP+порта.
• Балансировка нагрузки уровня 7: Балансировка нагрузки на основе информации прикладного уровня, такой как URL-адреса.

Вот рисунок, иллюстрирующий разницу между балансировкой нагрузки на уровне 4 и уровне 7:

Вышеупомянутые четыре уровня обнаружения сервисов в основном относятся к собственному методу kube-proxy k8s. Доступ к службам k8s в основном осуществляется с помощью метода NodePort, путем привязки порта хоста-миньона, а затем выполнения переадресации запросов Pod и балансировки нагрузки, но этот метод имеет следующие недостатки:

• Сервисов может быть много.Если каждый из них привязан к хост-порту узла, хост должен открыть периферийные порты для сервисных вызовов, что приведет к путанице в управлении.

• Правила брандмауэра, требуемые многими компаниями, не могут быть применены.

Идеальный способ — привязать фиксированный порт, например 80, через внешний балансировщик нагрузки, а затем перенаправить его на следующий IP-адрес службы в соответствии с доменным именем или именем службы.

Nginx отлично справляется с этим требованием, но вопрос в том, как модифицировать и загружать их, если добавляются какие-то новые сервисы.Конфигурация Nginx?

KubernetesПриведенное решение - Ingress. Это схема, основанная на семи слоях.

Восемь изоляционных измерений

Что касается планирования кластера k8s, необходимо создать соответствующие стратегии планирования для описанной выше схемы сверху вниз, от грубой до мелкозернистой изоляции.

Девять принципов сетевой модели

Сетевая модель k8s должна соответствовать четырем основным принципам, трем принципам сетевых требований, одному принципу архитектуры и одному принципу IP.

У каждого пода есть независимый IP-адрес, и предполагается, что все поды находятся в непосредственно подключенном плоском сетевом пространстве и могут быть доступны через IP-адрес пода независимо от того, работают они на одном узле или нет.

IP-адрес Pod в k8s — это IP-адрес с наименьшей степенью детализации. Все контейнеры в одном поде совместно используют сетевой стек, эта модель называется моделью IP-per-Pod.

• IP-адрес пода, фактически назначенный docker0.

• IP-адреса и порты внутри модуля такие же, как и снаружи.

• Разные контейнеры в одном и том же поде совместно используют сеть и могут получать доступ к портам друг друга через локальный хост, подобно разным процессам на одной виртуальной машине.

Модель IP-per-Pod С точки зрения распределения портов, разрешения доменных имен, обнаружения сервисов, балансировки нагрузки и конфигурации приложений Pod можно рассматривать как независимую виртуальную машину или физическую машину.

• Все контейнеры могут взаимодействовать с другими контейнерами без NAT.

• Все узлы могут взаимодействовать со всеми контейнерами с помощью различных методов NAT и наоборот.

• Адрес контейнера — это тот же адрес, который видят другие.

Чтобы соответствовать следующей схеме:

В приведенной выше архитектуре концепция IP переходит извне кластера внутрь кластера:

Десять типов IP-адресов

Все мы знаем, что IP-адреса делятся на категории ABCDE, и есть пять других категорий IP специального назначения.

первый сорт

A 类：1.0.0.0-1226.255.255.255，默认子网掩码/8，即255.0.0.0。
B 类：128.0.0.0-191.255.255.255，默认子网掩码/16，即255.255.0.0。
C 类：192.0.0.0-223.255.255.255，默认子网掩码/24，即255.255.255.0。
D 类：224.0.0.0-239.255.255.255，一般用于组播。
E 类：240.0.0.0-255.255.255.255(其中255.255.255.255为全网广播地址)。E 类地址一般用于研究用途。

Категория 2

0.0.0.0
严格来说，0.0.0.0 已经不是一个真正意义上的 IP 地址了。它表示的是这样一个集合：所有不清楚的主机和目的网络。这里的不清楚是指在本机的路由表里没有特定条目指明如何到达。作为缺省路由。
127.0.0.1 本机地址。

третья категория

224.0.0.1 组播地址。
如果你的主机开启了IRDP（internet路由发现，使用组播功能），那么你的主机路由表中应该有这样一条路由。

Категория 4

169.254.x.x
使用了 DHCP 功能自动获取了 IP 的主机，DHCP 服务器发生故障，或响应时间太长而超出了一个系统规定的时间，系统会为你分配这样一个 IP，代表网络不能正常运行。

Категория 5

10.xxx、172.16.x.x~172.31.x.x、192.168.x.x 私有地址。
大量用于企业内部。保留这样的地址是为了避免亦或是哪个接入公网时引起地址混乱。

Ссылка: blog.csdn.net/huakai_sun/article/details/82378856.

Автоматическая сборка и развертывание на k8s с использованием конвейера jenkins.

10 советов по повышению эффективности контейнеров Kubernetes

Краткое изложение общих навыков эксплуатации и обслуживания Kubernetes