Teller

Основная цель Teller — помочь разработчикам и предоставить безопасный способ использования секретов без hardcode их в исходном коде, оболочке или их неправильного размещения в неправильных файлах. С помощью файла teller.yaml вы можете настроить Teller для подключения к хранилищу секретов Vault, Consul, AWS Secret Manager, Google Secret Manager и многих других, чтобы безопасно извлекать из них секреты.

Teller имеет еще несколько функций, так как он может использоваться для целей DevSecOps в процессе CI для проверки секретов в исходном коде, а также используется в качестве инструмента, который позволяет не хранить секреты в файлах, логах и и т.д.

В дополнение, еще одна крутая тула для синхронизации секретов в Kubernetes из разных хранилищ секретов

External Secrets Operator - это оператор Kubernetes, который интегрирует внешние системы управления секретами, такие как AWS Secrets Manager, HashiCorp Vault, Google Secrets Manager, Azure Key Vault, IBM Cloud Secrets Manager и многие другие. Оператор считывает информацию из внешних API и автоматически вводит значения в Kubernetes Secret.

netshoot: a Docker + Kubernetes network trouble-shooting swiss-army container

Образ (container image) для поиска и устранения неисправностей в сетях Docker и Kubernetes. При понимании того, как работают сети Docker и Kubernetes, а также при наличии правильного набора инструментов, вы сможете устранять неполадки и решать эти сетевые проблемы.

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

$ docker run -it --net container:<container_name> nicolaka/netshoot

Kube-DNS: The Essential Service for Kubernetes Clusters

 • Ensure that DNS records are configured correctly: If your DNS records are inaccurate, they may as well not exist at all, because your DNS server will provide bad information. Properly configure DNS records for all services in the cluster to ensure that requests for services reach the desired endpoints.
 • Monitor the health of kube-dns: Monitor the health of kube-dns by regularly checking its performance and functionality. The kube-dns troubleshooting strategies we outlined above can help with this purpose.
 • Configure a separate DNS zone for each environment: By configuring separate DNS zones for each environment, such as production and staging, you can better protect critical services from malicious attacks.
 • Use a resolver for external domains: For external domains, use a reliable DNS resolver to prevent potential outages. This can also help in some ways to keep the cluster secure by protecting it against malicious attacks.

Spegel, mirror in Swedish, is a stateless cluster local OCI registry mirror.

• Locally cache images from external registries with no explicit configuration.
• Avoid cluster failure during external registry downtime.
• Improve image pull speed and pod startup time by pulling images from the local cache first.
• Avoid rate-limiting when pulling images from external registries (e.g. Docker Hub).
• Decrease egressing traffic outside of the clusters network.
• Increase image pull efficiency in edge node deployments.

Некоторые используют Helm + Kustomize для установки публичных Helm-чартов.

Есть идеи в чем преимущества? Почему не использовать только values файл?
Возможно, для правок манифестов без правки исходного чарта.

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

Why I Will Never Use Alpine Linux Ever Again

Некоторые различия между Alpine и, например Ubuntu, связаны с тем, как musl (и, следовательно, также Alpine) обрабатывает DNS (это всегда DNS), более конкретно, musl (по замыслу) не поддерживает DNS-over-TCP. Обычно вы не замечаете этой разницы, потому что в большинстве случаев одного UDP-пакета (512 байт) достаточно для разрешения имен... и когда этого недостаточно, и ваше приложение (работающее на Kubernetes), которое ранее работало совершенно нормально в течение нескольких месяцев, внезапно начинает выбрасывать исключения "Unknown host" для одного конкретного узла (очень критического). Хуже всего то, что это может проявляться случайным образом в любое время, когда какое-либо изменение внешней сети приводит к тому, что разрешение какого-либо конкретного домена требует более 512 байт, доступных в одном UDP-пакете.

https://www.figma.com

неплохой аналог Miro с бесплатными шаблонами для различных облаков (GCP, AWS, Azure)

Устаревший реестр образов k8s.gcr.io будет заморожен с 3 апреля 2023 года

Образы для Kubernetes 1.27 не будут доступны в реестре образов k8s.gcr.io.

Начиная с Kubernetes 1.25, реестр образов контейнеров изменился с k8s.gcr.io на registry.k8s.io. Этот новый реестр распределяет нагрузку между несколькими облачными провайдерами и регионами, функционируя как своего рода сеть доставки контента (CDN) для образов контейнеров Kubernetes. Это изменение снижает зависимость проекта от одной сущности и обеспечивает более быструю загрузку для большого количества пользователей.

Тут есть описание причин принятого решения — https://github.com/kubernetes/k8s.io/wiki/New-Registry-url-for-Kubernetes-(registry.k8s.io)#why-a-new-url

Вкратце: теперь oci-proxy будет определять из какого облачного провайдера пришел запрос, и следовательно предлагать загрузить образы из этого же облака, с целью уменьшения накладных расходов на инфраструктуру сообщества, так как загружать образы из GCP в AWS выходит дорого с ростом использования Kubernetes.

https://habr.com/ru/company/ods/blog/716918/

Интересная статья про устройство ChatGPT

Есть перевод

https://habr.com/ru/company/productivity_inside/blog/721508/