>

```apiVersion: v1 kind: PersistentVolume metadata: name: redis labels: app: redis ...```

пасиб, попробую через лейбл

error validating "./storagetest/pvc.yaml": error validating data: found invalid field selector for v1.PersistentVolumeClaimSpec

kind: PersistentVolumeClaim apiVersion: v1 metadata: name: teststor spec: accessModes: - ReadWriteMany resources: requests: storage: 1Gi selector: matchLabels: app: teststor

это у меня 1.2.4 селекторы не поддерживает или я туплю где-то?

чот вроде все ок

в 1.2 работало

@exename $ kubectl get pvc --namespace=bots -o jsonpath='{.items[0].spec.selector}' map[matchLabels:map[app:redis]]%

но сейчас в 1.3 формат немного другой

а хотя не

все так же

$ kubectl get pvc --namespace=bots data-redis-0 -o jsonpath='{.spec.selector}' matchLabels:<key:"app" value:"redis" > %

так, мб тут всё таки появились ковырявшие OpenShift? или хотя бы объясните мне суть ClusterIP в kubernates

суть ClusterIP в kubernetes очень проста у тебя есть поды и сервисы поды "настоящие", они оседают на routable-адресах, которые выдает CNI, или фланель, или докер демон, запущенный с --networking а сервисы - "эфемерные", они гребут адреса из рейнджа, который выдает аписервер ключем --service-cluster-ip-range и вот эти адреса не терминируются вообоще нигде, у них нет "физического" воплощения весь роутинг этих адресов ложится на плечи iptables и внешнего лоад-балансера (если ты в амазоне или gce)

пример:

$ knife ssh "name:web0*" "sudo iptables-save |grep 10.222.222.222" web02-amplifr-ru.singlehop.infra.evilmartians.com -A KUBE-SERVICES -d 10.222.222.222/32 -p tcp -m comment --comment "kube-system/kube-dns:dns-tcp cluster IP" -m tcp --dport 53 -j KUBE-SVC-ERIFXISQEP7F7OF4 web02-amplifr-ru.singlehop.infra.evilmartians.com -A KUBE-SERVICES -d 10.222.222.222/32 -p udp -m comment --comment "kube-system/kube-dns:dns cluster IP" -m udp --dport 53 -j KUBE-SVC-TCOU7JCQXEZGVUNU web01-amplifr-ru.singlehop.infra.evilmartians.com -A KUBE-SERVICES -d 10.222.222.222/32 -p udp -m comment --comment "kube-system/kube-dns:dns cluster IP" -m udp --dport 53 -j KUBE-SVC-TCOU7JCQXEZGVUNU web01-amplifr-ru.singlehop.infra.evilmartians.com -A KUBE-SERVICES -d 10.222.222.222/32 -p tcp -m comment --comment "kube-system/kube-dns:dns-tcp cluster IP" -m tcp --dport 53 -j KUBE-SVC-ERIFXISQEP7F7OF4 web04-amplifr-ru.singlehop.infra.evilmartians.com -A KUBE-SERVICES -d 10.222.222.222/32 -p tcp -m comment --comment "kube-system/kube-dns:dns-tcp cluster IP" -m tcp --dport 53 -j KUBE-SVC-ERIFXISQEP7F7OF4 web04-amplifr-ru.singlehop.infra.evilmartians.com -A KUBE-SERVICES -d 10.222.222.222/32 -p udp -m comment --comment "kube-system/kube-dns:dns cluster IP" -m udp --dport 53 -j KUBE-SVC-TCOU7JCQXEZGVUNU

$ knife ssh "name:web0*" "ip a|grep 10.222.222.222" $

@SinTeZoiD ^^^

вот в моем случае 10.222.222.222 - это clusterip

и вот эти адреса не терминируются вообоще нигде, у них нет "физического" воплощения

ё

оок, давайте теперь про router

куда должен роутить haproxy

в pod?

$ kubectl get svc --namespace=kube-system kube-dns NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE kube-dns 10.222.222.222 <none> 53/UDP,53/TCP 51d

все эти iptables-правила выше менеджатся процессами kube-proxy на хостах

куда должен роутить haproxy

в сервис а сервис - это тот самый эфемерный кластерайпи

ок, а из сервиса до пода как оно идёт? через правила iptables ?

дада

сервис "знает", какие "физические" адреса принадлежат его подам

через ендпойнты

$ kubectl get ep --namespace=kube-system kube-dns NAME ENDPOINTS AGE kube-dns 192.168.160.1:53,192.168.160.1:53 51d

вот 192.168.160.1 - это уже "физический" адрес

и ты из хапрокси можешь придти и прямо к нему тоже

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

кубернетес это сделал за тебя

и ты из хапрокси можешь придти и прямо к нему тоже

но правильнее прийти к сервису и через него средствами iptables прийти в pod ?

с помощью сервиса с кластер-айпи

но правильнее прийти к сервису и через него средствами iptables прийти в pod ?

бинго! подов-то может быть дохуя

так, стало лучше) Спасибо!

$ kubectl get svc --namespace=apps preview NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE preview 10.222.118.166 <none> 8081/TCP 90d

хотя бы в общих чертах понятнее

$ kubectl get ep --namespace=apps preview NAME ENDPOINTS AGE preview 192.168.160.3:8081,192.168.224.4:8081 90d

вот видишь

тут сервис один, а пода - два

и у каждого пода свой айпишник

как ты их будешь в хапрокси искать?

теперь мне уже интересно, а как оно между подами рулится? всмысле какой куда

не понял вопроса

ну вот ты долбишься в сервис например mariadb 3306 в какой под оно уйдет

или я че-то еще не понял

в любой

если их больше одного

ну вот если я постучу в preview.apps.svc.kubernetes.local:8081, то оно уйдет ЛИБО в 192.168.160.3:8081, ЛИБО в 192.168.224.4:8081

ок, mariadb.myservice.local myservice.local это у меня главная нода, а mariadb.myservice.local тоже должен стучаться в главную ноду?

и оттуда уже в ноду на которой под?

нет

ноды здесь вообще не причем

все сервисы "routable" на всех нодах, где есть процесс kube-proxy

ну то есть неважно на какой ноде ты постучишь в mariadb.<namespace>.svc.<cluster-name>:3306

оно пойдет к какому-то из подов, с которыми связан этот сервис

сначала днс выдаст тебе айпишик сервиса mariadb.<namespace>.svc.<cluster-name>

потом через ряд цепочек айпитаблес ты попадешь в порт 3306 на одном из подов

ок, как мне правильно прописать dns что бы я долбился на mariadb.<namespace>,svc.<cluster-name>

?

ERROR: S client not available

ну то есть вот я пишу со своего компа запрос mariadb.<namespace>,svc.<cluster-name> как он должен правильно отрезолвится

во что

# dig @10.222.222.222 preview.apps.svc.kubernetes.local +short 10.222.118.166

ну ты со своего компа должен иметь доступ к kube-dns по порту 53

ага, спасибо большое!

то есть вот я выше там показывал, что у сервиса preview два пода

путь к ним выглядит так:

адрес сервиса: # dig @10.222.222.222 preview.apps.svc.kubernetes.local +short 10.222.118.166 цепочка сервиса: # iptables-save | grep 10.222.118.166 -A KUBE-SERVICES -d 10.222.118.166/32 -p tcp -m comment --comment "apps/preview:preview-port cluster IP" -m tcp --dport 8081 -j KUBE-SVC-HUK3B4EWTJRXREKD поды: # iptables-save | grep KUBE-SVC-HUK3B4EWTJRXREKD :KUBE-SVC-HUK3B4EWTJRXREKD - [0:0] -A KUBE-SERVICES -d 10.222.118.166/32 -p tcp -m comment --comment "apps/preview:preview-port cluster IP" -m tcp --dport 8081 -j KUBE-SVC-HUK3B4EWTJRXREKD -A KUBE-SVC-HUK3B4EWTJRXREKD -m comment --comment "apps/preview:preview-port" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-FKNIPTZJYNJ3PO4C -A KUBE-SVC-HUK3B4EWTJRXREKD -m comment --comment "apps/preview:preview-port" -j KUBE-SEP-EUJT5BGXMZWIKAQE

таким образом, с вероятностью 0.50000000000 мы попадаем либо в цепочку KUBE-SEP-FKNIPTZJYNJ3PO4C, либо в KUBE-SEP-EUJT5BGXMZWIKAQE

и вот эти цепочки ведут уже к "физическому" поду:

# iptables-save | grep KUBE-SEP-FKNIPTZJYNJ3PO4C :KUBE-SEP-FKNIPTZJYNJ3PO4C - [0:0] -A KUBE-SEP-FKNIPTZJYNJ3PO4C -s 192.168.160.3/32 -m comment --comment "apps/preview:preview-port" -j KUBE-MARK-MASQ -A KUBE-SEP-FKNIPTZJYNJ3PO4C -p tcp -m comment --comment "apps/preview:preview-port" -m tcp -j DNAT --to-destination 192.168.160.3:8081

через эту мы приходим к 192.168.160.3:8081

через вторую, соответственно, ко второму поду

@SinTeZoiD сложилось?

ага

ушёл искать косяки)

точнее сначала обедать, потом искать)

Если что еще спрошу)

ВСЕ эти цепочки формирует kube-proxy

если на каком-то хосте он не запущен, то и правил не будет

ну и к подам ты не попадешь, соответственно

[естественно ничто не мешает все эти правила руками прописать без всяких kube-proxy. какое-то время будет работать, очевидно]

эээ дык на cluster-ip можно попасть из кластера кубернетса, а не из внешнего ha-proxy

teamur а что мешает внешнему хапрокси быть в той же сети?

или у тебя кубернетес в одном DC, хапрокси в другом, а роутинга между ними нет?

просто в разных вланах

ну в любом случае тебе нужно будет експозить кубернетес наружу-то

просто в разных вланах

ну вот у тебя из дикого интернета приходит запрос к балансеру ему же нужно как-то пророутиться до кубернетеса-то за данными

ну пока видимл через всякие там ingress и шаблоны для nginx

иначе как?

ингресы хороши, когда ты в облаке

как это все завести на железе я пока не понимаю