Ранее у нас было общее представление об основных компонентах и концепциях K8s, и мы реализовали предварительный процесс CI/CD на основе K8s, но различные задействованные объекты (такие как Namespace, Pod, Deployment, Service, Ingress, PVC и т. ) и управлению различными объектами может еще не хватать глубокого понимания и практики.В следующей статье давайте углубимся в каждый компонент K8s, чтобы это выяснить. На следующем рисунке представлена структурная схема K8s, основанная на личном понимании, которая иллюстрирует, как различные компоненты (включены только основные компоненты) работают вместе.
В последующих статьях будут организованы и представлены компоненты, задействованные в этой диаграмме.В этой статье в основном исследуется часть пространства имен ResourceQuota/LimitRange и ограничения ресурсов, связанные с управлением пространством имен.
Namespace
понимать
Пространство имен — это пространство имен, которое выполняет две основные функции:
- Изоляция ресурсов: он может предоставлять пространство виртуального кластера для разных команд/пользователей (или проектов) для совместного использования ресурсов одного и того же кластера Kubernetes. Например, вы можете создать пространство имен ns-a для команды A, все проекты команды A развернуты и запущены в ns-a, а группа B может создать еще одно пространство имен ns-b, все проекты которого развернуты и запущены в ns- b или для разработки создайте разные пространства имен для тестовой и производственной сред, чтобы изолировать друг друга и не влиять друг на друга. Мы можем использовать ResourceQuota и Resource LimitRange, чтобы указать и ограничить выделение ресурсов и использование каждого пространства имен.
- Контроль разрешений: вы можете указать, какие пользователи могут получить доступ к пространству имен, а какие — нет.
После успешной установки Kubernetes по умолчанию создаются три пространства имен:
- default: пространство имен по умолчанию. Если при создании объекта Kubernetes не указано metadata.namespace, объект будет создан в пространстве имен по умолчанию.
- kube-system: объекты, созданные системой Kubernetes, размещаются в этом пространстве имен, Kube-apiserver, etcd, kube-proxy и т. д., о которых мы упоминали ранее, находятся в этом пространстве имен.
- kube-public: как следует из названия, общее пространство имен, доступное для чтения всем пользователям. Он в основном зарезервирован для кластера и обычно не создает объекты в пространстве имен.
упражняться
1. Просмотр пространства имен
kubectl get namespaces
kubectl get namesapce
kubectl get ns # 三个操作等效
kubectl get ns --show-labels # 显示namespace的labelМожно использовать nameapce, nameapce и ns. Все пространства имен в текущем кластере перечислены следующим образом.
[root@kmaster ~]# kubectl get ns
NAME STATUS AGE
default Active 34d
develop Active 17d
ingress-nginx Active 33d
kube-node-lease Active 34d
kube-public Active 34d
kube-system Active 34d
kubernetes-dashboard Active 31d
pre-release Active 17dможно использоватьkubectl describeКоманда для просмотра сводной информации о пространстве имен, например
[root@kmaster ~]# kubectl describe ns default
Name: default
Labels: <none>
Annotations: <none>
Status: Active
No resource quota.
No resource limits.2. Создайте пространство имен
Есть два способа: создать через файл определения yaml или напрямую использовать команду для создания.
# 方式1. 通过yaml定义文件创建
[root@kmaster ~]# vim test-namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
name: test # namespace的名称
labels:
name: ns-test
[root@kmaster ~]# kubectl create -f ./test-namespace.yaml
# 方式2. 直接使用命令创建
[root@kmaster ~]# kubectl create ns test3. Создание объектов в пространстве имен
# 1. 在yaml中通过metadata.namesapce 指定
[root@kmaster ~]# kubectl get deploy my-nginx -o yaml
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
run: my-nginx
name: my-nginx
namespace: test # 指定namespace
spec:
...
# 2. 在命令中通过 -n 或 --namesapce 指定
[root@kmaster ~]# kubectl run dev-nginx --image=nginx:latest --replicas=3 -n test4. Установите контекст nameapce kubectl
Контекст kubectl представляет собой комбинацию кластера, пространства имен и пользователя.Настройка контекста kubectl означает, что пользователь, указанный контекстом, может выполнять управление операциями в кластере и пространстве имен, указанных контекстом. Просмотр текущего контекста kubectl кластера
# 查看当前kubectl上下文
[root@kmaster ~]# kubectl config view
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: DATA+OMITTED
server: https://192.168.40.111:6443
name: kubernetes
contexts:
- context:
cluster: kubernetes
user: kubernetes-admin
name: kubernetes-admin@kubernetes
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
- name: kubernetes-admin
user:
client-certificate-data: REDACTED
client-key-data: REDACTEDВидно, что текущий контекст — kubernetes-admin@kubernetes (current-context: kubernetes-admin@kubernetes).
Создайте контекст kubectl
[root@kmaster ~]# kubectl config set-context test --namespace=test --cluster=kubernetes --user=kubernetes-admin
Context "test" created.выполнить сноваkubectl config viewКонтекст теста, созданный выше, будет виден.
переключить контекст
# 设置当前上下文
[root@kmaster ~]# kubectl config use-context test
Switched to context "test".
# 查看当前所在的上下文
[root@kmaster ~]# kubectl config current-context
testКонтекст указывается, и последующие операции выполняются в пространстве имен, соответствующем контексту, и нет необходимости явно указывать пространство имен. создать объект в контексте
# 在当前上下文中创建对象
[root@kmaster ~]# kubectl run my-nginx --image=nginx:latest --replicas=2
kubectl run --generator=deployment/apps.v1 is DEPRECATED and will be removed in a future version. Use kubectl run --generator=run-pod/v1 or kubectl create instead.
deployment.apps/my-nginx created
# 查看创建的对象，不需要指定namespace
[root@kmaster ~]# kubectl get deploy
NAME READY UP-TO-DATE AVAILABLE AGE
my-nginx 2/2 2 2 25m
[root@kmaster ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
my-nginx-667764d77b-ldb78 1/1 Running 0 24m
my-nginx-667764d77b-wpgxw 1/1 Running 0 24mудалить контекст
[root@kmaster ~]# kubectl config delete-context test
deleted context test from /root/.kube/configВы также можете использовать следующую команду для прямого переключения пространства имен по умолчанию
# 将默认namespace设置为test
[root@kmaster ~]# kubectl config set-context --current --namespace=test5. Удалить пространство имен
можно использоватьkubectl delete ns <namespace名称>для удаления пространства имен, которое удаляет все в пространстве имен.
[root@kmaster ~]# kubectl delete ns testResource Quota
Квота ресурсов — это квота ресурсов, которая ограничивает общий объем ресурсов кластера, которые можно использовать в одном пространстве имен, включая два измерения:
- Ограничьте общее количество объектов, которые могут быть созданы типом объекта (например, Pod);
- Ограничьте общее количество вычислительных ресурсов (ЦП, память) и ресурсов хранения (заявки на объем хранилища), которые могут потребляться типом объекта.
Если ResourceQuota установлена для вычислительных ресурсов ЦП и памяти в пространстве имен, пользователи должны указывать запросы и лимиты при создании объектов (Pod, Service и т. д.); если ресурсы, запрашиваемые при создании или обновлении объектов, конфликтуют с ResourceQuota пространства имен, то apiserver вернет код состояния HTTP 403 и соответствующее сообщение об ошибке. Когда общая емкость в кластере меньше суммы квот ресурсов каждого пространства имен, может возникнуть конкуренция за ресурсы, и Kubernetes будет выделять ресурсы в порядке поступления.
Ограничение количества объектов
Формат декларации:count/<resource>.<group>, форматы объявления различных объектов перечислены ниже
count/persistentvolumeclaims
count/services
count/secrets
count/configmaps
count/replicationcontrollers
count/deployments.apps
count/replicasets.apps
count/statefulsets.apps
count/jobs.batch
count/cronjobs.batch
count/deployments.extensionsОграничения вычислительных ресурсов
Определяет общий объем ЦП, запросов к памяти и используемых лимитов, в том числе
- limit.cpu: в пространстве имен ограничение ЦП для всех незавершенных подов, сумма ресурсов.limits.cpu не может превышать это значение.
- limit.memory: в пространстве имен общий лимит памяти resources.limits.memory всех незавершенных подов не может превышать это значение.
- Requests.cpu: в пространстве имен общее количество запросов CPU resources.request.cpu всех нетерминальных подов не может превышать это значение.
- Requests.memory: в пространстве имен сумма запросов CPU resources.requests.memory всех нетерминальных подов не может превышать это значение.
лимит ресурсов хранения
Определите общий объем хранилища, запрошенный претензией тома хранилища, или ограничение на количество созданных заявок тома хранилища, включая
- request.storage: в пространстве имен общий объем хранилища, запрошенный всеми утверждениями тома хранилища (PersistentVolumeClaim), не может превышать это значение.
- персистентволумеклаймс: в пространстве имен общее количество утверждений тома хранилища, которое может быть создано, не может превышать это значение.
-
<storage-class-name>.storageclass.storage.k8s.io/requests.storage: в пространстве имен общий объем хранилища, запрашиваемый всеми томами хранения, связанными с указанным классом хранения (StorageClass), не может превышать это значение. -
<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims: общее количество заявок на тома хранилища, связанных с указанным классом хранилища в пространстве имен, не может превышать это значение.
Кроме того, вы также можете определить ограничения на ресурсы локального временного хранилища.
- request.ephemeral-storage: в пространстве имен сумма запросов локального эфемерного хранилища для всех подов не может превышать это значение.
- limit.ephemeral-storage: в пространстве имен сумма лимитов локального эфемерного хранилища всех подов не может превышать это значение.
упражняться
Проверьте, включена ли поддержка квоты ресурсов, которая обычно включена по умолчанию. Если нет, то можно добавить пункт конфигурации ResourceQuota в параметр --enable-admission-plugins при запуске аписервера.
1. Создайте ResourceQuota
# 创建namespace
[root@kmaster ~]# kubectl create namespace test
# 编辑ResourceQuota定义文档
[root@kmaster ~]# vim quota-test.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
name: quota-test
namespace: test
spec:
hard:
requests.cpu: "2"
requests.memory: 2Gi
limits.cpu: "4"
limits.memory: 4Gi
requests.nvidia.com/gpu: 4
pods: "3"
services: "6"
# 创建ResourceQuota
[root@kmaster ~]# kubectl apply -f quota-test.yaml
# 查看
[root@kmaster ~]# kubectl get quota -n test
NAME CREATED AT
quota-test 2020-05-26T10:31:10Z
[root@kmaster ~]# kubectl describe quota quota-test -n test
Name: quota-test
Namespace: test
Resource Used Hard
-------- ---- ----
limits.cpu 0 4
limits.memory 0 4Gi
pods 0 3
requests.cpu 0 2
requests.memory 0 2Gi
requests.nvidia.com/gpu 0 4
services 0 6Или используйте команду kubectl, например
[root@kmaster ~]# kubectl create quota quota-test --hard=count/deployments.extensions=2,count/replicasets.extensions=4,count/pods=3,count/secrets=4 --namespace=testМы создали ResourceQuota в тесте пространства имен, который ограничивает запросы ЦП и памяти до 2 и 2 ГБ, ограничивает использование ЦП и памяти до 4 и 4 ГБ и ограничивает количество подов до 3 и т. д.
Давайте попробуем создать развертывание, определенное следующим образом, чтобы протестировать его:
# 创建一个测试deploy
[root@kmaster ~]# vim quota-test-deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: quota-test-deploy
spec:
selector:
matchLabels:
purpose: quota-test
replicas: 3
template:
metadata:
labels:
purpose: quota-test
spec:
containers:
- name: quota-test
image: nginx
resources:
limits:
memory: "2Gi"
cpu: "1"
requests:
memory: "500Mi"
cpu: "500m"
[root@kmaster ~]# kubectl apply -f quota-test-deploy.yaml -n test
# 查看pod
[root@kmaster ~]# kubectl get pod -n test
NAME READY STATUS RESTARTS AGE
quota-test-deploy-6b89fdc686-2dthq 1/1 Running 0 3m54s
quota-test-deploy-6b89fdc686-9m2qw 1/1 Running 0 3m54s
# 查看deploy状态
[root@kmaster ~]# kubectl get deploy quota-test-deploy -n test -o yaml
message: 'pods "quota-test-deploy-6b89fdc686-rmktq" is forbidden: exceeded quota:
quota-test, requested: limits.memory=2Gi, used: limits.memory=4Gi, limited:
limits.memory=4Gi'Реплики: 3 определяет создание трех реплик пода, но успешно создаются только два пода.В части статуса развертывания (результат последней команды) мы видим, что сообщение подсказывает, что третий под был отклонен, когда он был создан, потому что память достигла предела. Мы также можем настроить limit.memory на 1Gi и реплики на 4, чтобы проверить ограничение на количество Pod. Видно, что в итоге были запущены только три пода, и статусная часть сообщения подсказываетpods "quota-test-deploy-9dc54f95c-gzqw7" is forbidden: exceeded quota:quota-test, requested: pods=1, used: pods=3, limited: pods=3.
Resource Limit Range
понимать
Квота ресурсов ограничивает общее использование ресурсов в пространстве имен, а диапазон ограничения ресурсов ограничивает использование ресурсов определенного пода или контейнера. По умолчанию потребление ресурсов модулями или контейнерами в пространстве имен не ограничено, что может привести к утечкам памяти в приложении-контейнере, которые истощают ресурсы и влияют на другие приложения. Ограничить диапазон можно использовать для ограничения количества ресурсов, которые может потреблять под (или контейнер) в пространстве имен.
Используя объект LimitRange, мы можем:
- Ограничьте минимальные и максимальные вычислительные ресурсы на модуль или контейнер в пространстве имен.
- Ограничьте соотношение между запросом и лимитом каждого вычислительного ресурса Pod или контейнера в пространстве имен.
- Ограничьте минимальное и максимальное пространство для хранения, которое может использоваться каждым утверждением тома хранилища (PersistentVolumeClaim) в пространстве имен.
- Установите запрос и ограничение вычислительных ресурсов контейнера по умолчанию в пространстве имен и автоматически вставьте их в контейнер во время выполнения.
Если запрос на создание или обновление объекта (Pod, Container, PersistentVolumeClaim) конфликтует с LimitRange, API-сервер вернет код состояния HTTP 403 и соответствующее сообщение об ошибке; если LimitRange определен в пространстве имен для ограничения вычислительных ресурсов, таких как ЦП и используемая память. , пользователь должен указать запрос и лимит ЦП или памяти при создании пода или контейнера, иначе он будет отклонен системой; когда общий лимит пространства имен меньше суммы лимитов пода и контейнер, произойдет конфликт ресурсов, под или контейнеры не будут созданы, но это не повлияет на уже созданные поды или контейнеры.
упражняться
Создайте тестовое пространство имен test-limitrange,
# 创建测试namespace
[root@kmaster ~]# kubectl create namespace test-limitrange
# 切换默认的namespace
[root@kmaster ~]# kubectl config set-context --current --namespace=test-limitrangeСоздайте файл определения LimitRange lr-test.yaml
apiVersion: v1
kind: LimitRange
metadata:
name: lr-test
spec:
limits:
- type: Container #资源类型
max:
cpu: "1" #限定最大CPU
memory: "1Gi" #限定最大内存
min:
cpu: "100m" #限定最小CPU
memory: "100Mi" #限定最小内存
default:
cpu: "900m" #默认CPU限定
memory: "800Mi" #默认内存限定
defaultRequest:
cpu: "200m" #默认CPU请求
memory: "200Mi" #默认内存请求
maxLimitRequestRatio:
cpu: 2 #限定CPU limit/request比值最大为2
memory: 1.5 #限定内存limit/request比值最大为1.5
- type: Pod
max:
cpu: "2" #限定Pod最大CPU
memory: "2Gi" #限定Pod最大内存
- type: PersistentVolumeClaim
max:
storage: 2Gi #限定PVC最大的requests.storage
min:
storage: 1Gi #限定PVC最小的requests.storageЭтот файл определяет пространство именtest-limitrange, ограничения ресурсов контейнеров, подов и PVC в этом пространстве имен, только при соблюдении следующих условий объект может быть успешно создан
- контейнер
resources.limitsЧасть ЦП должна быть между 100м-1 и память должна быть между 100Ми-1Ги, иначе создание не удастся - контейнер
resources.limitsНекоторые процессоры иresources.requestsМаксимальное соотношение некоторых процессоров равно 2, а максимальное соотношение памяти равно 1,5, иначе создание не удастся. - всех контейнеров в поде
resources.limitsМаксимальная сумма некоторых CPU равна 2, а максимальная сумма памяти равна 2Gi, иначе создание не удастся - ПВХ
resources.requests.storageМаксимум 2Ги, минимум 1Ги, иначе создание не получится
Если контейнер определяет
resources.requestsНе определеноresources.limits, часть по умолчанию в LimitRange будет введена в контейнер как лимит; если контейнер определяетresources.limitsно не определеноresources.requests, значение запросов также устанавливается равным значению лимитов; если ни один контейнер не определен, в качестве лимитов используется значение по умолчанию в LimitRange, а в качестве значения запросов используется defaultRequest
Создать и просмотреть LimitRange,
# 创建LimitRange
[root@kmaster ~]# kubectl apply -f lr-test.yaml
# 查看
[root@kmaster ~]# kubectl describe limits lr-test
Name: lr-test
Namespace: test-limitrange
Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio
---- -------- --- --- --------------- ------------- -----------------------
Container cpu 100m 1 200m 900m 2
Container memory 100Mi 1Gi 200Mi 800Mi 1500m
Pod cpu - 2 - - -
Pod memory - 2Gi - - -
PersistentVolumeClaim storage 1Gi 2Gi - - -Мы можем создавать контейнеры или объекты Pod с различными конфигурациями для проверки, а шаги проверки не указаны для экономии места.
Суммировать
В этой статье более подробно рассматривается пространство имен K8s и управление ограничениями ресурсов ResourceQuota и LimitRange для пространства имен. ResourceQuota ограничивает использование ресурсов всего пространства имен, а LimitRange ограничивает использование ресурсов одного пода или контейнера. Управление разрешениями пространства имен может быть реализовано на основе RBAC, который будет представлен отдельно позже.
Оригинальный адрес:blog.J boost.talent/maybe 8 равно 4 - так что сп...
Связанное чтение:
- Примечания Kubernetes (1): разверните среду K8s за десять минут
- Kubernetes Notes (2): Понимание основных компонентов и концепций k8s.
- Kubernetes Notes (3): Gitlab+Jenkins Pipeline+Docker+k8s+Helm Automated Deployment Practice (совместное использование сухих товаров!)
Автор: песня дождя
Добро пожаловать, чтобы обратить внимание на официальный аккаунт автора: песня Halfway Rain, учитесь и растите вместе