Масштабирование Kubernetes в Pinterest: через сбои и аварии

Спасибо большое за перевод, это действительно сложная работа. Но мне сложно понимать о чем идет речь когда читаю буквальный перевод терминов. Как например пространство имён и узлы, постоянно приходит держать в голове что это namespaces и nodes. Это как встречать в некоторых статьях "стручки", у вас они остались подами. В конечном итоге ушел читать оригинал. Но с вашим переводом он стал понятнее. спасибо.

Столичные банки начали нанимать IT-специалистов из регионов, чтобы сбить зарплаты

на Украине уровень зарплат ИТ специалистов выше и в долларах, там давно уже ИТ рынок работает на европу/америку

О столе для работы стоя, здоровье позвоночника и личной эффективности

использую его две недели. Долго не усидишь, но по-моему это как раз и плюс. периодически встаю, разминаться. Жена сказала что осанка улучшилась. вес мой — 100.

Аутентификация в Kubernetes с помощью GitHub OAuth и Dex

почему не получится? у нас сейчас реализовано именно так. oauth2_proxy и dex находятся в одном месте, так же как и dexK8sAuthenticator. Дkя дашбордов ингрессы в один auth2_proxy. на всех кластерах прописан oidc один dex. в dexK8sAuthenticator в configmap добавлены несколько кластеров для генерации всего в одном месте

Аутентификация в Kubernetes с помощью GitHub OAuth и Dex

storage наверное лучше сделать kubernetes а не локальный sqlite

Аутентификация в Kubernetes с помощью GitHub OAuth и Dex

можно обойтись одним oauth2_proxy и ингрессами с Auth Request. смотрите сюда
thenewstack.io/single-sign-on-for-kubernetes-dashboard-experience
github.com/pusher/oauth2_proxy/tree/whitelist-domains
пример ингресса:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/auth-url: "https://OAUTH2_PROXY_ADDRESS/oauth2/auth"
    nginx.ingress.kubernetes.io/auth-signin: "https://OAUTH2_PROXY_ADDRESS/oauth2/start?rd=https://$host$request_uri$is_args$args"
    nginx.ingress.kubernetes.io/configuration-snippet: |
       auth_request_set $token $upstream_http_authorization;
       proxy_set_header Authorization $token;
  name: dashboard 
  namespace: kube-system
spec:
  rules:
  - host: ADDRESS
    http:
      paths:
      - backend:
          serviceName: kubernetes-dashboard
          servicePort: 80
        path: /
  tls:
  - secretName: SECRET
    hosts:
      - ADDRESS

со стороны oauth2_proxy:

        args:
        - --email-domain=example.com
        - --upstream=file:///dev/null
        - --http-address=0.0.0.0:8080
        - --redirect-url=https://OAUTH2_PROXY_ADDRESS/oauth2/callback
        - --provider=oidc
        - --oidc-issuer-url=https://DEX_ADDRESS
        - --cookie-domain=.example.com
        - --whitelist-domain=.example.com
        - --pass-authorization-header=true
        - --set-authorization-header=true
        - --pass-basic-auth=false
        - --pass-access-token=false

правда я смержил whitelist-domains с мастером и сбилдил свой имэдж что бы были и --pass-authorization-header с --set-authorization-header и --whitelist-domain

Резервное копирование на удаленный сервер

Это я погорячился. Потребность в руте нужна для того что бы сохранить права файлов при бэкапе. rsync запускается с опцией -a, но очевидно что при отсутствии привилегий — этого не получится.

Резервное копирование на удаленный сервер

имелось в виду «непарольного» для бэкапа с удаленной машины (если мы говорим о полном бэкапе контейнеров) нужен рутовый доступ на эту машину. ТО есть разработчики rsnapshot предлагают организовать доступ по ключу.
А что касается доступа на сервер бэкапа. тот тут все происходит по иному. За счет настроек rsync сервера во первых область хранения бэкапов конкретного сервера на едином сервере бэкапов зачрутена, да еще и предлагается ограничить IP с которого позволительно обращаться к этому хранилищу,
[$usernames]
comment = backups for $usernames
path = /home/$usernames/rsyncbackups
use chroot = true
uid = root
gid = root
log file = /var/log/rsyncd/$usernames.log
read only = false
write only = false
hosts allow = 1.2.3.4
hosts deny = *
transfer logging = false

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

А для операций ротации на стороне сервера бэкапов используется не привилегированный доступ. Для бэкапов каждого клиента заводится отдельный доступ.

Резервное копирование на удаленный сервер

НУ да :)

Резервное копирование на удаленный сервер

Да, принципиален именно пуш бэкапа. и NFS мы отмели

Резервное копирование на удаленный сервер

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

Резервное копирование на удаленный сервер

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

Резервное копирование на удаленный сервер

ну и да, после фазы следующего бэкапа — симлинк заменяется новым — на свежий бэкап

Резервное копирование на удаленный сервер

Объясню почему не rsnapshot. в силу удаленности нашего сервера бэкапов, использование монтирования по ssh или NFS мы отмели за ненадежностью. В другом случае rsnapshot делать удаленный бэкапы не умеет, в силу как раз использования хардлинков (да суть та же rsnapshot работает на базе rsync). В нашем случае это удалось обойти использованием rsync сервера, почему к этому не пришли разработчики rsnapshot — не понятно :)

Резервное копирование на удаленный сервер

--link-dest=DIR

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

Lshell вместо chroot ssh

Да, извините сразу забыл указать это, уже поправил

затем достаточно добавить шел пользователю
user:x:502:502::/home/user:/usr/bin/lshell

Lshell вместо chroot ssh

allowed_cmd_path — каталоги, в которых пользователю разрешено запускать исполняемые файлы или свои программы.