ты про кодовую базу или базу базы?)

я про базу базы

база в моем понимани - образ системы

ну вот я хочу просто подсунуть свои файлы мускульной базы.

база в моем понимани - образ системы

а под базовым имаджем я подразумеваю имадж с голым мускулем, да, образ системы

а под базовым имаджем я подразумеваю имадж с голым мускулем, да, образ системы

ну голый тада это без мускуля:)

суть не в в голой базе а в том что это твоя база

на которой ты уже строишь свои мускули

твоя проверенная твоими безопасниками

а не "а че нам, го с хаба центос запулим"

мы ща в понятиях так попутаемся, )

давай понятия распределим базовый образ это FROM

назовем ее базой

а мускуль назовем СУБД

это всё ясно) что было понятней- я обозначил выше две сущности- имадж с заранее заготовленной моей базой с моими данными и образ с голой базой

Кстати интересная тема) У меня пока извращенная схема, при разворачивании нового test/dev/stage прямо в докер файле подключение к бэкапу прода и забор данных оттуда)

Вобщем я отчаялся заиметь свою закотовленную базу с имаджа. Попробую взять базовый образ для деплой пода, а вот чтоб положить свою базу- на сколько хорошее решение создать одноразовый под, который на нужный вольюм мне развернёт данные, а потом просто использовать этот вольюм в моём поде?

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

Кстати интересная тема) У меня пока извращенная схема, при разворачивании нового test/dev/stage прямо в докер файле подключение к бэкапу прода и забор данных оттуда)

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

не знаю был ли доклад как именно они этот контейнер строят, но точно они это рассказывали в контексте подготовки данных с прода для стейджинга (типа вырезать и анонимизировать связанный семпл данных)

интересно, поищу на выходных видос)

Привет. Вопрос, есть под из двух контейнеров, в одном запускается доверенный код, а в другом недоверенный. Можно как-то ограничить сеть для недоверенного контейнера оставив доверенному все сетевые возможности?

нет

у них один linux network namespace

и т.д.

Привет. Вопрос, есть под из двух контейнеров, в одном запускается доверенный код, а в другом недоверенный. Можно как-то ограничить сеть для недоверенного контейнера оставив доверенному все сетевые возможности?

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

привет. помогите понять что я делаю не так. поставил kubernetes пробую поднять кластер на 1 ноде дашборд не запускаетсья в coredns ошибки

Инициализация kubeadm init --apiserver-advertise-address=1.1.1.1 --pod-network-cidr=10.244.0.0/16 Текущее состояние NAMESPACE NAME READY STATUS RESTARTS AGE IP kube-system coredns-78fcdf6894-gp2vs 0/1 CrashLoopBackOff 10 34m 10.244.0.5 kube-system coredns-78fcdf6894-ncswc 0/1 CrashLoopBackOff 10 34m 10.244.0.2 kube-system etcd-k8s.example.com 1/1 Running 0 33m 176.99.2.69 kube-system kube-apiserver-k8s.example.com 1/1 Running 0 33m 176.99.2.69 kube-system kube-controller-manager-k8s.example.com 1/1 Running 0 33m 176.99.2.69 kube-system kube-flannel-ds-amd64-9nshb 1/1 Running 0 34m 176.99.2.69 kube-system kube-proxy-m28m4 1/1 Running 0 34m 176.99.2.69 kube-system kube-scheduler-k8s.example.com 1/1 Running 0 33m 176.99.2.69 kube-system kubernetes-dashboard-6948bdb78-plwcc 0/1 CrashLoopBackOff 8 19m 10.244.0.6

сделай describe поду который крешится

а так как понять то

логи дашборда: 2018/07/13 10:26:28 Error while initializing connection to Kubernetes apiserver. This most likely means that the cluster is misconfigured (e.g., it has invalid apiserver certificates or service accounts configuration) or the --apiserver-host param points to a server that does not exist. Reason: Get https://10.96.0.1:443/version: dial tcp 10.96.0.1:443: getsockopt: no route to host

Привет. Вопрос, есть под из двух контейнеров, в одном запускается доверенный код, а в другом недоверенный. Можно как-то ограничить сеть для недоверенного контейнера оставив доверенному все сетевые возможности?

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

логи coredns: E0713 10:31:35.276819 1 reflector.go:205] github.com/coredns/coredns/plugin/kubernetes/controller.go:315: Failed to list *v1.Endpoints: Get https://10.96.0.1:443/api/v1/endpoints?limit=500&resourceVersion=0: dial tcp 10.96.0.1:443: connect: no route to host

сделай describe поду который крешится

kubectl describe -n kube-system kubernetes-dashboard-6948bdb78-plwcc error: the server doesn't have a resource type "kubernetes-dashboard-6948bdb78-plwcc”

kubectl describe pod -n kube-system pod-name-ergw45

не может достучатся он до сервиса api чо в логах flannel, kube-proxy?

сделай describe поду который крешится

под с дашбордом https://pastebin.com/um1qAm4R

сделай describe поду который крешится

под с coredns https://pastebin.com/v5sitvER

если с хост машины стучаться на этот адрес - ответ есть curl https://10.96.0.1:443/version -k { "major": "1", "minor": "11", "gitVersion": "v1.11.0", "gitCommit": "91e7b4fd31fcd3d5f436da26c980becec37ceefe", "gitTreeState": "clean", "buildDate": "2018-06-27T20:08:34Z", "goVersion": "go1.10.2", "compiler": "gc", "platform": "linux/amd64" }#

не может достучатся он до сервиса api чо в логах flannel, kube-proxy?

kubectl logs -n kube-system kube-flannel-ds-amd64-r5jdl I0713 10:44:24.483880 1 main.go:475] Determining IP address of default interface I0713 10:44:24.484256 1 main.go:488] Using interface with name enp2s0 and address 1.1.1.1 I0713 10:44:24.484271 1 main.go:505] Defaulting external address to interface address (1.1.1.1) I0713 10:44:24.494065 1 kube.go:131] Waiting 10m0s for node controller to sync I0713 10:44:24.494141 1 kube.go:294] Starting kube subnet manager I0713 10:44:25.494288 1 kube.go:138] Node controller sync successful I0713 10:44:25.494325 1 main.go:235] Created subnet manager: Kubernetes Subnet Manager - k8s.example.com I0713 10:44:25.494331 1 main.go:238] Installing signal handlers I0713 10:44:25.494402 1 main.go:353] Found network config - Backend type: vxlan I0713 10:44:25.494471 1 vxlan.go:120] VXLAN config: VNI=1 Port=0 GBP=false DirectRouting=false I0713 10:44:25.498650 1 main.go:300] Wrote subnet file to /run/flannel/subnet.env I0713 10:44:25.498679 1 main.go:304] Running backend. I0713 10:44:25.498691 1 main.go:322] Waiting for all goroutines to exit I0713 10:44:25.498708 1 vxlan_network.go:60] watching for new subnet leases

у меня колесико мышки сломалось(

kubectl logs -n kube-system kube-proxy-9shm6 I0713 10:43:50.950544 1 feature_gate.go:230] feature gates: &{map[]} W0713 10:43:50.953470 1 proxier.go:469] Failed to load kernel module ip_vs with modprobe. You can ignore this message when kube-proxy is running inside container without mounting /lib/modules W0713 10:43:50.954125 1 proxier.go:469] Failed to load kernel module ip_vs_rr with modprobe. You can ignore this message when kube-proxy is running inside container without mounting /lib/modules W0713 10:43:50.954810 1 proxier.go:469] Failed to load kernel module ip_vs_wrr with modprobe. You can ignore this message when kube-proxy is running inside container without mounting /lib/modules W0713 10:43:50.955460 1 proxier.go:469] Failed to load kernel module ip_vs_sh with modprobe. You can ignore this message when kube-proxy is running inside container without mounting /lib/modules W0713 10:43:50.958932 1 server_others.go:287] Flag proxy-mode="" unknown, assuming iptables proxy I0713 10:43:50.959835 1 server_others.go:140] Using iptables Proxier. I0713 10:43:50.967851 1 server_others.go:174] Tearing down inactive rules. W0713 10:43:50.977211 1 proxier.go:469] Failed to load kernel module ip_vs with modprobe. You can ignore this message when kube-proxy is running inside container without mounting /lib/modules W0713 10:43:50.977901 1 proxier.go:469] Failed to load kernel module ip_vs_rr with modprobe. You can ignore this message when kube-proxy is running inside container without mounting /lib/modules W0713 10:43:50.978589 1 proxier.go:469] Failed to load kernel module ip_vs_wrr with modprobe. You can ignore this message when kube-proxy is running inside container without mounting /lib/modules W0713 10:43:50.979334 1 proxier.go:469] Failed to load kernel module ip_vs_sh with modprobe. You can ignore this message when kube-proxy is running inside container without mounting /lib/modules I0713 10:43:50.980606 1 server.go:448] Version: v1.11.0 I0713 10:43:50.985845 1 conntrack.go:98] Set sysctl 'net/netfilter/nf_conntrack_max' to 262144 I0713 10:43:50.985894 1 conntrack.go:52] Setting nf_conntrack_max to 262144 I0713 10:43:50.985944 1 conntrack.go:98] Set sysctl 'net/netfilter/nf_conntrack_tcp_timeout_established' to 86400 I0713 10:43:50.985983 1 conntrack.go:98] Set sysctl 'net/netfilter/nf_conntrack_tcp_timeout_close_wait' to 3600 I0713 10:43:50.986131 1 config.go:102] Starting endpoints config controller I0713 10:43:50.986139 1 config.go:202] Starting service config controller I0713 10:43:50.986142 1 controller_utils.go:1025] Waiting for caches to sync for endpoints config controller I0713 10:43:50.986152 1 controller_utils.go:1025] Waiting for caches to sync for service config controller I0713 10:43:51.086321 1 controller_utils.go:1032] Caches are synced for endpoints config controller I0713 10:43:51.086342 1 controller_utils.go:1032] Caches are synced for service config controller

вроде ничего криминального…

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

Ага, так и думал, но вдруг...

маршруты в поде ip route default via 10.244.0.1 dev eth0 10.244.0.0/24 dev eth0 src 10.244.0.11 10.244.0.0/16 via 10.244.0.1 dev eth0 как сделать правильно доступ до 10.96.0.1 ? или он через kube-proxy должен быть?

kube-proxy должен нарисовать nat правила до 10.96.0.1

из пода 10.244.0.1 доступен по icmp например?

с прокси - доступ нормально # curl https://10.96.0.1:443/version -k { "major": "1", "minor": "11", "gitVersion": "v1.11.0", "gitCommit": "91e7b4fd31fcd3d5f436da26c980becec37ceefe", "gitTreeState": "clean", "buildDate": "2018-06-27T20:08:34Z", "goVersion": "go1.10.2", "compiler": "gc", "platform": "linux/amd64" }#

подскажите, поднимаю апликуху и базу через helm для апликухе хочу передать коннекшен стринг через ENV таким образом env: - name: ConnectionStrings__DefaultConnection connectionString: Data Source=tcp:{{ template "chartname.fullname" . }}.{{ .Release.Namespace }}.svc.cluster.local,1433;Initial Catalog=Local; если делаю dry-run всё отрабатывает правильно, если реальный запуск - пустое значение так делать нельзя? или что-то не так делаю?

с coredns ошибка такая: ping 10.244.0.11 PING 10.244.0.11 (10.244.0.11): 56 data bytes ping: permission denied (are you root?)

подскажите, поднимаю апликуху и базу через helm для апликухе хочу передать коннекшен стринг через ENV таким образом env: - name: ConnectionStrings__DefaultConnection connectionString: Data Source=tcp:{{ template "chartname.fullname" . }}.{{ .Release.Namespace }}.svc.cluster.local,1433;Initial Catalog=Local; если делаю dry-run всё отрабатывает правильно, если реальный запуск - пустое значение так делать нельзя? или что-то не так делаю?

env: - name: NAME value: VALUE

env: - name: NAME value: VALUE

это понятно, оно там так и есть. когда я value брал из переменных было все хорошо, когда я попытался сделать его комбинацией переменных и текста всё сломалось

В кавычки нужно взять name и value думаю

пробовал, к сожалению не помогает. dry-run всё ок, выводит как нужно, а реальный запуск - всё равно нет name/value

с coredns ошибка такая: ping 10.244.0.11 PING 10.244.0.11 (10.244.0.11): 56 data bytes ping: permission denied (are you root?)

для icmp нужен root, можно попробовать через nsenter уйти в namespace контейнера ))) я бы на вашем месте сначала проверил ходит ли трафик через фланнел, например tcpdump-ом и если бы нет ковырял бы flannel возможно неправильно натится трафик на самой ноде, это тоже можно проверить tcpdump-ом…

env: - name: NAME value: VALUE

а, блин, к пятнице уже что-то мозги не варят почему то вместо value написал фигню и ждал чего то... даже не понял сразу намёка, спасибо

?

а, блин, к пятнице уже что-то мозги не варят почему то вместо value написал фигню и ждал чего то... даже не понял сразу намёка, спасибо

иногда помогает get -o yaml и сверить с тем, что ты ожидаешь

для icmp нужен root, можно попробовать через nsenter уйти в namespace контейнера ))) я бы на вашем месте сначала проверил ходит ли трафик через фланнел, например tcpdump-ом и если бы нет ковырял бы flannel возможно неправильно натится трафик на самой ноде, это тоже можно проверить tcpdump-ом…

вместо flannel можно что то другое использовать?

из-за iptables может сеть не работать?

Ребят а в kubernetes-dashboard возможно ли видеть hpa (horizontalpodautoscalers)

а то у меня нет там

вместо flannel можно что то другое использовать?

я думаю что flannel проще всего

как оверлейная сеть может быть проще чем не-оверлейная сеть?

?

ERROR: S client not available

я думаю что flannel проще всего

ну в целом да, фланелька норпм

Ребят а в kubernetes-dashboard возможно ли видеть hpa (horizontalpodautoscalers)

вроде нет, там вообще многих штук нету

бнопня. Вот есть такая штука https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#pausing-and-resuming-a-deployment Если я поставлю деплой на паузу, а потом сделаю scale up/down, количество реплик изменится сразу, или после resume?

похоже, что сразу

печаль

как оверлейная сеть может быть проще чем не-оверлейная сеть?

я так понимаю flannel в kubeadm по дефолту, и скорее всего по причине простоты/простаты кому как нравится )))

а не калико?

хз, никогда не юзал kubeadm

я так понимаю flannel в kubeadm по дефолту, и скорее всего по причине простоты/простаты кому как нравится )))

я ставил калико-) в адм я вообще фланнел не увидел, и я против всякого kubeadm

в кубадм вообще нет дефолта, он не ставит сеть

calico ?

в кубадм вообще нет дефолта, он не ставит сеть

ага Set /proc/sys/net/bridge/bridge-nf-call-iptables to 1 by running sysctl net.bridge.bridge-nf-call-iptables=1 to pass bridged IPv4 traffic to iptables’ chains. This is a requirement for some CNI plugins to work, for more information please see here. @alchazov вот это запилил?

ага Set /proc/sys/net/bridge/bridge-nf-call-iptables to 1 by running sysctl net.bridge.bridge-nf-call-iptables=1 to pass bridged IPv4 traffic to iptables’ chains. This is a requirement for some CNI plugins to work, for more information please see here. @alchazov вот это запилил?

Да. 1 в параметрах

нужен совет по обновлению деплоя. Текущий пайплайн реализован так: 1. Обновляем образ: kubectl set image deploy/app app=appimage:newtag 2. Ждём статуса kubectl rollout status deploy/app 3. Если статус Completed - завершаемся 4. Если статус Failed - kubectl rollout undo deploy/app Теперь мне надо вставить в пайплайн миграции, которые могут быть несовместимы с текущей версией. Соответственно я предполагал сделать так: 1. Выключаем деплой масштабированием в 0: kubectl scale deploy/app —replicas=0 2. Делаем бэкап базы 3. Делаем миграции 4. Обновляем образ: kubectl set image deploy/app app=appimage:newtag 5. Включаем деплой масштабированием в 1 (далее hpa поднимет выше, если надо): kubectl scale deploy/app —replicas=1 6. Проверяем статус ???? 7. Если всё хорошо, завершаемся 8. Если всё плохо, проворачиваем назад Вопрос возникает на шаге 6: я уже не могу использовать rollout status, потому что при количестве реплик 0 он сразу возвращает Completed

но ведь это же с даунтаймом?

да, даунтайм приемлем

и если ты сделаешь руками scale 0 то HPA тебе вернёт обратно до минимального

нет

у меня возвращал

кубер 1.8

а у меня не возвращает

https://github.com/kubernetes/kubernetes/pull/29212/commits/c5e82a01b15136141801ba93de810fdf3165086b

прикольно тебе

вообще не возвращает или какое-то время?

вообще

это новая фича hpa

хм

написано в 2016 замёржено

у вас наверное уже тоже не возвращает - легко проверить

я минут 5 назад проверил