да

да

ну вот я описываю anchor: &anchor "что-то там" потом: name: *anchor ругается unknown field "anchor" in io.k8s.kubernetes.pkg.apis.extensions.v1beta1.Ingress;

стоп а что ещё за anchor в кубере?

yaml

при чём тут yaml и поле ancord

yaml это язык манифестов

конфиги куба на ямле

ок?

ну да, только при чём тут anchor

якорь

хотите я назову его ass? %)

https://en.wikipedia.org/wiki/YAML#Advanced_components

там еще есть references %)

apiVersion: extensions/v1beta1 kind: Deployment metadata: name: kubernetes-dashboard namespace: kube-system labels: k8s-app: kubernetes-dashboard kubernetes.io/cluster-service: "true" addonmanager.kubernetes.io/mode: Reconcile spec: selector: matchLabels: k8s-app: kubernetes-dashboard template: metadata: labels: k8s-app: kubernetes-dashboard annotations: scheduler.alpha.kubernetes.io/critical-pod: '' spec: containers: - name: kubernetes-dashboard image: gcr.io/google_containers/kubernetes-dashboard-amd64:v1.6.3 resources: # keep request = limit to keep this container in guaranteed class limits: cpu: 100m memory: 300Mi requests: cpu: 100m memory: 100Mi ports: - containerPort: 9090 livenessProbe: httpGet: path: / port: 9090 initialDelaySeconds: 30 timeoutSeconds: 30 tolerations: - key: "CriticalAddonsOnly" operator: "Exists"

Это yaml который кушает кубер

так тут нет якорей

привет.. kubectl понимает анкоры yaml?

вот такой был вопрос

сорки, моя не понимать что такое анкор...

скорее всего оно вообще не понимает расширения yaml

ну вот я описываю anchor: &anchor "что-то там" потом: name: *anchor ругается unknown field "anchor" in io.k8s.kubernetes.pkg.apis.extensions.v1beta1.Ingress;

видимо он пытается смаппить поле anchor в структуру Ingress и не находит его там

т.е. видимо сам якорь-то резолвится, но anchor остается в структуре и из-за этого не десериализуется, потому что десериализатор выбрасывает ошибку при встрече незнакомого поля (а не просто игнорирует его)

ребят, может кто поделится ссылкой на issues, по поводу баги, из-за которой initContainers при kubectl apply не обновляются ?

починили это в 1.8 ?

аннотации? или нативные инит контейнеры

кажется только аннотация не работала

(ну и при любом раскладе, обновления init container не вызывает пересоздания подов в deployment)

кстати, вопрос в воздух... разумно ли ожидать что при проблемах с kubectl apply обновление бинарника kubectl решит проблему или там все глубоко переплетено?

зависит от проблем

но kubectl делает минимальную работу по доставке yaml до самого кубера, так что маловероятно

ясно, я так и ожидал. спасибо

по мониторингу вопрос, развернул prometheus, тот обнаружил таргеты с метриками: kubernetes-apiservers, kubernetes-nodes, kubernetes-service-endpoints. попробовал несколько дашбордов в grafana для k8s, всем на cAdvisor опираются. Кто подскажет для этих изкоробки k8s метрик (apiserver/nodes) дашборд?

по мониторингу вопрос, развернул prometheus, тот обнаружил таргеты с метриками: kubernetes-apiservers, kubernetes-nodes, kubernetes-service-endpoints. попробовал несколько дашбордов в grafana для k8s, всем на cAdvisor опираются. Кто подскажет для этих изкоробки k8s метрик (apiserver/nodes) дашборд?

- job_name: 'kubernetes-cadvisor' tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token scheme: https kubernetes_sd_configs: - role: node relabel_configs: - action: labelmap regex: __meta_kubernetes_node_label_(.+) - target_label: __address__ replacement: kubernetes.default.svc:443 - source_labels: [__meta_kubernetes_node_name] regex: (.+) target_label: __metrics_path__ replacement: /api/v1/nodes/${1}:4194/proxy/metrics

не, cAdvisor я разберусь как поставить =)

А что там за метрики?

у apiserver /metrics

у каждой ноды: https://kubernetes.default.svc:443/api/v1/nodes/<nodename>/proxy/metrics

такая информация по нодам есть например # HELP kubelet_docker_operations Cumulative number of Docker operations by operation type. # TYPE kubelet_docker_operations counter kubelet_docker_operations{operation_type="create_container"} 14 kubelet_docker_operations{operation_type="info"} 1 kubelet_docker_operations{operation_type="inspect_container"} 65 kubelet_docker_operations{operation_type="inspect_image"} 33 kubelet_docker_operations{operation_type="list_containers"} 555904 kubelet_docker_operations{operation_type="list_images"} 20622 kubelet_docker_operations{operation_type="remove_container"} 4 kubelet_docker_operations{operation_type="start_container"} 14 kubelet_docker_operations{operation_type="stop_container"} 11 kubelet_docker_operations{operation_type="version"} 67883

у apiserver /metrics

Это эндпоинты.

Попробуй дашборды с id: 2, 162, 704, 22, 747, 737

ок =) спасибо

по мониторингу вопрос, развернул prometheus, тот обнаружил таргеты с метриками: kubernetes-apiservers, kubernetes-nodes, kubernetes-service-endpoints. попробовал несколько дашбордов в grafana для k8s, всем на cAdvisor опираются. Кто подскажет для этих изкоробки k8s метрик (apiserver/nodes) дашборд?

я чет про cadvisor не пойму, его функциональность встроена в к8с?

- job_name: 'kubernetes-cadvisor' tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token scheme: https kubernetes_sd_configs: - role: node relabel_configs: - action: labelmap regex: __meta_kubernetes_node_label_(.+) - target_label: __address__ replacement: kubernetes.default.svc:443 - source_labels: [__meta_kubernetes_node_name] regex: (.+) target_label: __metrics_path__ replacement: /api/v1/nodes/${1}:4194/proxy/metrics

нашел pr с описание ${1}:4194 https://github.com/prometheus/prometheus/pull/2918/files стало понятнее к чему это было

В кубере вся документация ниже 1.8 теперь считается устаревшей. Но на 1.8 страшно пока переходить...

оо

я чет про cadvisor не пойму, его функциональность встроена в к8с?

она встроена в kubelet

да, разобрался уже куда спрятали: # This is required for Kubernetes 1.7.3 and later, where cAdvisor metrics # (those whose names begin with 'container_') have been removed from the # Kubelet metrics endpoint. This job scrapes the cAdvisor endpoint to # retrieve those metrics. # # In Kubernetes 1.7.0-1.7.2, these metrics are only exposed on the cAdvisor # HTTP endpoint; use "replacement: /api/v1/nodes/${1}:4194/proxy/metrics" # in that case (and ensure cAdvisor's HTTP server hasn't been disabled with # the --cadvisor-port=0 Kubelet flag).

В кубере вся документация ниже 1.8 теперь считается устаревшей. Но на 1.8 страшно пока переходить...

а 1,8 релизнули?

давно

Да. 5 дней назад.

давно

5 дней...как давно то....

для кубера это, считай, эпоха

вечность

Что-то надоело мне, что glusterfs постоянно эндпоинт отваливается. В логах - всё нормально. Никаких сообщений. Просто пропадает и всё... Хочу что-то по типу облака. Чтобы монтировать, как hostPath, но каталоги меж собой синхронизировались автоматом при изменении файлов. Кто-нибудь делал что-то подобное? Файлов не много - буквально 200 метров. Нужна высокая доступность. И сравнительно быстрая синхронизация при изменении.

для кубера это, считай, эпоха

Пфф я работаю в крупном ентерпрайз, для нас 5 дней это меньше мгновения........

Что-то надоело мне, что glusterfs постоянно эндпоинт отваливается. В логах - всё нормально. Никаких сообщений. Просто пропадает и всё... Хочу что-то по типу облака. Чтобы монтировать, как hostPath, но каталоги меж собой синхронизировались автоматом при изменении файлов. Кто-нибудь делал что-то подобное? Файлов не много - буквально 200 метров. Нужна высокая доступность. И сравнительно быстрая синхронизация при изменении.

а я ведь предупреждал

Я не верил)

Пфф я работаю в крупном ентерпрайз, для нас 5 дней это меньше мгновения........

энтерпрайзников даже жалеть нельзя :)

Зато тут тепло и мухи не летают)

Так что - всё-таки ceph?

Или cephfs?

ceph, без fs

обязательно обдумайте резервное копирование. Я вот не обдумал и теперь мучаюсь

Поскольку у меня чуть чуть файлов - бэкапится просто rsync'ом. Или там подводные камни есть?

обязательно обдумайте резервное копирование. Я вот не обдумал и теперь мучаюсь

?

Поскольку у меня чуть чуть файлов - бэкапится просто rsync'ом. Или там подводные камни есть?

а как вы будете бэкапить рсинком что-то из RBD-устройства, которое у вас уже подмонтировано?

дважды один девайс смонтировать вы не сможете

А смысл бекапить на ceph..если делать толерантность 1 то всё живёт при смерти 1 osd

можно повысить до 2х.... и мы живём при 2х мёртвых osd

или глубина репликации 2 и 3 соответвенно

Ой. Вот это и плохо! Я не смогу в два пода смонтировать девайс?

Ой. Вот это и плохо! Я не смогу в два пода смонтировать девайс?

https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes

Выходит, что ceph мне не подходит(

Ой. Вот это и плохо! Я не смогу в два пода смонтировать девайс?

а мне кто-нибудь объяснит ЗАЧЕМ?!

а мне кто-нибудь объяснит ЗАЧЕМ?!

У меня поды с пхп. Иногда пользователь загружает свою аватарку, например. Подов у меня несколько, так как нагрузка большая. Картинки отдаёт nginx, в него тоже смонтирован волюм - ему и RO достаточно. Но пхп может любой под писать в этот волюм.

У меня поды с пхп. Иногда пользователь загружает свою аватарку, например. Подов у меня несколько, так как нагрузка большая. Картинки отдаёт nginx, в него тоже смонтирован волюм - ему и RO достаточно. Но пхп может любой под писать в этот волюм.

прикрутите s3 в свою адовую конструкцию

s3 либы есть под любой сторадж

прикрутите s3 в свою адовую конструкцию

Это локально?

Это локально?

нет, это делают нормальные люди для хранения статики