Чтобы перевести базу данных в read-only, нужно задать флаг "default_transaction_read_only" в значение "true"
ALTER DATABASE dababase_name SET default_transaction_read_only = true;
Где "dababase_name" — имя необходимой базы данных
Возвращаем возможность записи в БД:
ALTER DATABASE dababase_name SET default_transaction_read_only = false;
Посмотреть текущее значение флага можно так:
SELECT name, setting FROM pg_settings WHERE name = 'default_transaction_read_only';
Для AMI Linux 2 нужно Redis-CLI собирать из исходников
Ссылка на скрипт, который был взят за основу.
#!/bin/bash sudo yum install -y gcc wget wget http://download.redis.io/redis-stable.tar.gz tar -xf redis-stable.tar.gz cd redis-stable make sudo cp -a src/redis-cli /usr/local/bin/ cd .. rm -rf redis-stable.tar.gz rm -rf redis-stable
Подключаемся к Redis'у:
redis-cli -h redis.artem.services -p 6379
Создадим Secret с содержимым существующего JSON файла "app-config.json" и примонтируем внутрь пода как JSON файл.
Создаем Secret:
kubectl create secret generic app-config --from-file=app-config.json
Монтируем Secret в Pod:
spec:
template:
spec:
containers:
- image: "my-image:latest"
name: my-app
...
volumeMounts:
- mountPath: "/var/app"
name: app-config
readOnly: true
volumes:
- name: app-config
secret:
secretName: app-config
Получить доступ к Kubernetes Dashboard по доменному имени, а не используя "kubectl proxy". Так же подключение должно осуществляться по HTTPS, но при этом вести на внутренний локальный адрес, доступный только через VPN, и не используя для этого никаких Ingress'ов.
Редактируем деплоймент "kubernetes-dashboard":
kubectl edit deployments.apps -n kubernetes-dashboard kubernetes-dashboard
Приводим аргументы к следующему виду:
spec:
containers:
- args:
- --namespace=kubernetes-dashboard
- --enable-insecure-login
- --insecure-port=8443
А так же для "livenessProbe" меняем "scheme: HTTPS" на "scheme: HTTP":
livenessProbe:
failureThreshold: 3
httpGet:
path: /
port: 8443
scheme: HTTP
initialDelaySeconds: 30
periodSeconds: 10
Теперь дашборд будет доступен по HTTP.
В консоли AWS переходим в "Certificate Manager", выбираем регион, в котором развернут EKS и делаем запрос на сертификат для нужного домена. После того, как сертификат валидирован, копируем его ARN.
Создаем манифест с Kubernetes сервисом.
apiVersion: v1
kind: Service
metadata:
labels:
k8s-app: kubernetes-dashboard
annotations:
service.beta.kubernetes.io/aws-load-balancer-internal: 0.0.0.0/0
service.beta.kubernetes.io/aws-load-balancer-ssl-cert: 'arn:aws:acm:<AWS_REGION>:<ACCOUNT_ID>:certificate/<CERTIFICATE_ID>'
service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "*"
name: kubernetes-dashboard-internal
namespace: kubernetes-dashboard
spec:
ports:
- port: 443
protocol: TCP
targetPort: 8443
selector:
k8s-app: kubernetes-dashboard
sessionAffinity: None
type: LoadBalancer
Применим его:
kubectl apply -f kubernetes-dashboard-internal.yaml
Теперь остается только создать ALIAS запись в Route53 на внутреннее имя созданного LoadBalancer'а, посмотреть его имя можно так:
kubectl get svc -n kubernetes-dashboard kubernetes-dashboard-internal
Теперь из внутренних сетей AWS или используя VPN, по доменному имени будет доступен Kubernetes Dashboard.
Установим NFS provisioner в Kubernetes кластер, для существующего NFS сервера
Дано:
Устанавливаем используя HELM:
helm install nfs-client-provisioner --set fullnameOverride=nfs-client-provisioner --set nfs.server=192.168.1.1 --set nfs.path=/var/lib/nfs stable/nfs-client-provisioner
Опцией "fullnameOverride" перезапишем полное имя чарта, так как он после имени все равно добавит "nfs-client-provisioner"
Делаем NFS типом хранилища по умолчанию:
kubectl patch storageclass nfs-client -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
Теперь можно создать PVC, NFS provisioner сам отследит запрос и создаст PV
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: test-pv-claim
labels:
app: test-app
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 1Gi
Создаем PVC:
kubectl apply -f test-pv-claim.yaml
Проверяем созданный PVC и PV:
kubectl get pvc kubectl get pv
Так как все что перечислено в "fstab" монтируется при запуске системы, еще до запуска сети, то примонтировать директорию получится если добавить опцию "_netdev". Но если NFS директория доступна только через VPN, который уже стартует после запуска сети то остается вариант "rc.local" или смонтировать диск используя Systemd.
В данном примере дано следующее:
Загружаем модуль NFS:
modprobe nfs
Создаем Systemd mount service с именем "home-artem-web.mount"
vim /usr/lib/systemd/system/home-artem-web.mount
Важно, чтобы имя было основано на пути, куда монтируется NFS директория, иначе сервис не запустится. Слеши заменяются тире.
Со следующим содержимым:
[Unit] Description=Mount NFS Share After=network.target [email protected] [Mount] What=192.168.1.1:/var/www/html Where=/home/artem/web Type=nfs Options=_netdev,auto [Install] WantedBy=multi-user.target
Перечитываем список демонов:
systemctl daemon-reload
Запускаем и ставим в автозагрузку:
systemctl start home-artem-web.mount systemctl enable home-artem-web.mount
Пример Ansible Playbook'а для копирования файла конфигурации с одного хоста на другой, в данном случае с "openvpn_server" на "openvpn_client"
- hosts: openvpn_client
tasks:
- name: Transfer client.conf from OpenVPN server
synchronize:
src: /etc/openvpn/client.conf
dest: /etc/openvpn/client.conf
delegate_to: openvpn_server
Для этого на всех хостах должен быть установлен пакет "rsync"
Пример сервиса, который ссылается на внешний адрес, в данном случае RDS.
apiVersion: v1 kind: Service metadata: name: artem-sqlproxy spec: type: ExternalName externalName: artem.cmart19ttgdd.eu-central-1.rds.amazonaws.com
Данный Playbook отключает Swap и удаляет его из файла "/etc/fstab"
---
- name: Disable Swap
gather_facts: No
hosts: localhost
tasks:
- name: Disable SWAP
shell:
cmd: |
swapoff -a
args:
executable: /bin/bash
- name: Remove Swap from fstab
mount:
name: swap
fstype: swap
state: absent
Применяем Playbook:
ansible-playbook docker.yaml
Спасибо Daniel Vaughan за данную статью.
Для горизонтального автоскалирования подов (HPA) на основе кастомных метрик, нам понадобятся:
Все это, мы будем устанавливать используя Helm. Установку Helm'а можно посмотреть тут.
Создадим директорию для хранения Helm values:
mkdir helm-values
Создадим values файл для Prometheus Operator'а:
cat <<EOF >helm-values/prometheus-operator-values.yaml
# This configuration means all ServiceMonitors in the namespace will be picked up
# Use with caution!
prometheus:
prometheusSpec:
serviceMonitorSelectorNilUsesHelmValues: false
serviceMonitorSelector: {}
EOF
Устанавливаем Prometheus Operator:
helm install stable/prometheus-operator -n prom \
-f helm-values/prometheus-operator-values.yaml
Читать далее "Kubernetes — Horizontal pod autoscaler на основе кастомных метрик"