Все в Google работает в контейнерах

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

И в ближайшие годы спрос на Kubernetes Administatrots будет огромным, так как многие компании переносят свою собственную инфраструктуру на Kubernetes.

Я работаю над Kubernetes уже более года, а также работал над облачными платформами Kubernetes, такими как GKE и AKS.

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

  • Сервер/система Ubuntu
  • Миникуб

Небольшая история Kubernetes

Borg, внутренняя система Google для управления приложениями, послужила источником вдохновения для Kubernetes (например, Gmail, Apps, Google Compute Engine).

Kubernetes — это безопасный выбор, когда дело доходит до управления контейнерами, поскольку Google вложил в него ценную информацию, полученную при создании и эксплуатации Borg за более чем 15 лет. Хотя Kubernetes — мощный инструмент, большая часть его нынешнего роста заключается в том, чтобы упростить работу с рабочими нагрузками, которые не размещаются в Google, и управлять ими.

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

Kubernetes разработан на Go, переносимом языке программирования, представляющем собой нечто среднее между C++, Python и Java.

Основные компоненты и возможности Kubernetes

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

  • Мастер-узел — двоичные файлы уровня управления будут загружены на главный узел, также известный как узел уровня управления, и он будет единолично отвечать за все компоненты уровня управления, такие как etcd. и сервер kube-api.
  • Рабочий узел — они используются для запуска определяемых пользователем контейнеров и будут иметь экземпляр kubelet, kube-proxy и среды выполнения контейнера, работающие на каждом узле.

Etcd: основным хранилищем данных Kubernetes является etcd, распределенное хранилище ключей и значений. Он сохраняет и реплицирует состояние кластера Kubernetes.

Сервер Kube-API.Сервер kube-api имеет решающее значение для функциональности кластера Kubernetes. Этот агент отвечает за все звонки, как внутренние, так и внешние.

Этот агент является единственным соединением с базой данных etcd, и он принимает и проверяет все действия.

Kube-Scheduler: чтобы определить, на каком узле будет размещаться Pod контейнеров, kube-scheduler использует алгоритм.

Планировщик попытается привязать доступные ресурсы (например, тома) перед повторной попыткой развернуть модуль в зависимости от доступности и успеха.

Kubelet: изменения и конфигурация рабочих узлов обрабатываются процессом kubelet systemd.

Он отвечает на запросы API для спецификаций Pod. Он будет продолжать настраивать локальный узел до тех пор, пока не будет выполнено требование.

Kube-proxy. Идея службы Kubernetes реализуется через kube-proxy, сетевой прокси-сервер, который работает на каждом узле в вашем кластере. На узлах kube-proxy отслеживает сетевые правила.

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

Если уровень фильтрации пакетов операционной системы существует и доступен, kube-proxy использует его. В противном случае трафик перенаправляется kube-proxy.

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

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

Развертывания/рабочие нагрузки

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

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

In order to create a deployment of nginx you can use this command
kubectl run nginx --image=nginx

Или вы можете использовать kubectl apply или создать -f ‹nginx.yaml› для создания развертывания. Вот пример файла

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

Вы можете проверить журналы развертывания, используя kubectl logs ‹имя развертывания›, и можете удалить развертывание, используя kubectl delete ‹имя развертывания›.

стручки

В Kubernetes модули — это самые простые и базовые развертываемые объекты. В вашем кластере под представляет собой один экземпляр работающего процесса.

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

Теперь модули имеют различные типы жизненных циклов, поскольку они эфемерны. Существует четыре фазы жизненного цикла Pod:

  • Ожидание. Хотя Pod создан и подтвержден кластером, один или несколько его контейнеров еще не запущены.
  • Успешно: все контейнеры модуля успешно завершены. Поды, которые были завершены, не будут перезапущены.
  • Выполняется. Все контейнеры созданы, а Pod подключен к узлу. По крайней мере один контейнер работает, готовится к запуску или перезапускается.
  • Ошибка: все контейнеры модуля завершены, причем по крайней мере один контейнер завершил работу с ошибкой. Если контейнер выходит с ненулевым статусом, говорят, что он вышел из строя.
  • Неизвестно. Невозможно определить состояние модуля.

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

Есть несколько вещей, таких как initContainers и side-car-контейнеры, мы обсудим их подробнее в моей следующей статье. Здесь мы сосредоточимся на базовом обзоре, чтобы начать изучение Kubernetes самостоятельно.

Услуга

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

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

Таким образом, в K8s есть в основном три типа Сервиса.

  • NodePort: клиенты отправляют запросы к IP-адресу узла, используя одно или несколько значений nodePort, определенных Службой.
  • ClusterIP: это значение по умолчанию. Вы не можете делать запросы к своим модулям из-за пределов кластера Kubernetes, поскольку служба доступна только внутри кластера.
  • LoadBalancer: функция балансировки нагрузки облачного провайдера делает сервис доступным извне. Эта функция доступна в GCP, AWS, Azure и OpenStack. Облачный провайдер настроит балансировщик нагрузки, который будет автоматически перенаправлять запросы в вашу службу Kubernetes.

Атрибут типа службы определяет, как служба предоставляется в сети. Он изменяет места, из которых Сервис может быть доступен. Вот пример файла службы YAML для справки;

apiVersion: v1
kind: Service
metadata:
  name: sample-service
spec:
  selector:
    app: my-app
  type: ClusterIP 
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

Объемы

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

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

  • Постоянные тома. В кластере ресурсы PersistentVolume используются для управления долговременным хранилищем. Постоянный диск обычно создает резервную копию PersistentVolume в GKE. Также доступны другие варианты хранения, такие как NFS.
  • PersistentVolumeClaim. Запрос пользователя на хранилище называется PersistentVolumeClaim (PVC). Похоже на Под. Ресурсы узла потребляются модулями, а ресурсы PV потребляются PVC. PersistentVolumeClaim привязан к PersistentVolume, который удовлетворяет запросу, если он существует или может быть предоставлен.

Вот пример файла для PV, PVC и того, как он будет использоваться в развертывании.

#pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: sample-pv
  namespace: development
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 5Gi
  claimRef:
    apiVersion: v1
    kind: PersistentVolumeClaim
    name: sample-pvc
    namespace: development
  hostPath:
    path: /tmp/hostpath-provisioner/dev/
    type: ""
  persistentVolumeReclaimPolicy: Delete
  storageClassName: local-storage
  volumeMode: Filesystem
--- 
#pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: sample-pvc
  namespace: development
spec: 
  storageClassName: local-storage
  accessModes:
    - ReadWriteOnce 
  resources: 
    requests:
      storage: 5Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: mongo
  name: mongo
  namespace: development
spec:
  replicas: 1
  selector:
    matchLabels:
      name: mongo
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: mongo
        name: mongo
    spec:
      containers:
      - env:
        - name: MONGODB_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              key: mongodb-root-password
              name: mongo
        - name: ALLOW_EMPTY_PASSWORD
          value: "no"
        - name: MONGODB_SYSTEM_LOG_VERBOSITY
          value: "0"
        - name: MONGODB_DISABLE_SYSTEM_LOG
          value: "no"
        - name: MONGODB_ENABLE_IPV6
          value: "no"
        - name: MONGODB_ENABLE_DIRECTORY_PER_DB
          value: "no"
        image: mongo
        name: mongo
        ports:
        - containerPort: 27017
          protocol: TCP
        resources:
          limits:
            cpu: 1Gi
            memory: 4Gi
          requests:
            cpu: 500m
            memory: 2Gi
        volumeMounts:
        - mountPath: /data/db
          name: db-persistent-storage
      dnsPolicy: ClusterFirst
      hostname: onein-mongo-db
      restartPolicy: Always
      volumes:
      - name: db-persistent-storage
        persistentVolumeClaim:
          claimName: sample-pvc

В дополнение к этому есть одна вещь, которую вы все читатели должны знать. Если вы используете minikube или Google Kubernetes Engine, постоянные тома динамически подготавливаются сами по себе, поэтому вам нужен только PVC-файл.

Но если вы используете EKS или локальный кластер на Red Hat Server, динамическая подготовка недоступна, поэтому вам понадобится файл pv.

Давайте кратко повторим то, что мы обсуждали в этой статье о kubernetes.

  • Кубернетес — Введение
  • История Кубернета
  • Компоненты K8s
  • Развертывания
  • стручки
  • Услуги
  • Объемы

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

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





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



Присоединяйтесь к FAUN: Сайт💻|Подкаст🎙️|Twitter🐦|Facebook👥 |Instagram📷|Группа Facebook🗣️|Группа Linkedin💬| Slack 📱|Cloud Native Новости📰|Дополнительно.

Если этот пост был полезен, пожалуйста, несколько раз нажмите кнопку аплодисментов 👏 ниже, чтобы выразить свою поддержку автору 👇