_From @andersla 27 октября 2016 г., 18: 8_
СООБЩЕНИЕ ОБ ОШИБКЕ
Версия Kubernetes (используйте kubectl version
):
последний
Окружающая среда :
Контейнер Docker в Ubuntu 16.04
Что случилось :
При попытке установить Kubeadm внутри контейнера докеров Ubuntu 16.04 это не удается.
Моя идея заключалась в том, чтобы использовать один контейнер докеров в качестве главного «узла», а второй контейнер в качестве рабочего «узла» (кубернетес в докере).
Это проблема с системой? (кое-что, с чем я столкнулся, когда "гуглил" ответы)
Образ докеры внутри Ubuntu 16.04, который я устанавливаю с помощью: apt-get install -y kubeadm
журнал настройки:
...
...
...
all: Setting up socat (1.7.3.1-1) ...
all: Setting up kubelet (1.4.3-00) ...
all: /var/lib/dpkg/info/kubelet.postinst: 38: /var/lib/dpkg/info/kubelet.postinst: [[: not found
all: Setting up kubectl (1.4.3-00) ...
all: Setting up kubeadm (1.5.0-alpha.0-1534-gcf7301f-00) ...
all: Failed to connect to bus: No such file or directory
**all: dpkg: error processing package kubeadm (--configure):**
all: subprocess installed post-installation script returned error exit status 1
all: Setting up netcat-traditional (1.10-41) ...
all: update-alternatives: using /bin/nc.traditional to provide /bin/nc (nc) in auto mode
all: Setting up netcat (1.10-41) ...
all: Setting up patch (2.7.5-1) ...
all: Setting up rename (0.20-4) ...
all: update-alternatives: using /usr/bin/file-rename to provide /usr/bin/rename (rename) in auto mode
all: Setting up tcpd (7.6.q-25) ...
all: Setting up ubuntu-fan (0.9.1) ...
all: invoke-rc.d: could not determine current runlevel
all: invoke-rc.d: policy-rc.d denied execution of start.
all: Setting up xz-utils (5.1.1alpha+20120614-2ubuntu2) ...
all: update-alternatives: using /usr/bin/xz to provide /usr/bin/lzma (lzma) in auto mode
all: Setting up python3 (3.5.1-3) ...
all: running python rtupdate hooks for python3.5...
all: running python post-rtupdate hooks for python3.5...
all: Setting up apparmor (2.10.95-0ubuntu2.2) ...
all: update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
all: Setting up dh-python (2.20151103ubuntu1.1) ...
all: Processing triggers for libc-bin (2.23-0ubuntu4) ...
all: Processing triggers for systemd (229-4ubuntu11) ...
all: Processing triggers for initramfs-tools (0.122ubuntu8.5) ...
all: Processing triggers for dbus (1.10.6-1ubuntu3) ...
all: Errors were encountered while processing:
all: kubeadm
all: E: Sub-process /usr/bin/dpkg returned an error code (1)
==> all: Killing the container: 93babb5045461c343a803109ba683a2acf68f1f453447a336b09171a1b190f38
Build 'all' errored: Script exited with non-zero exit status: 100
==> Some builds didn't complete successfully and had errors:
--> all: Script exited with non-zero exit status: 100
_Копировано из оригинального выпуска: kubernetes / kubernetes # 35712_
_From @luxas 27 октября 2016 г. 18:14_
cc @errordeveloper и @marun, поскольку они запускали systemd внутри контейнера
@andersla Имейте в
_From @zreigz 28 октября 2016 г., 7:36.
Если вы не возражаете, я хотел бы взглянуть поближе и попытаться исправить это.
_From @andersla 28 октября 2016 г., 8:48_
@zreigz Пожалуйста, сделайте это!
Вот как я пытаюсь его установить:
docker run -it --privileged ubuntu /bin/bash
А потом:
echo "Updating Ubuntu..."
apt-get update -y
apt-get upgrade -y
echo "Install os requirements"
apt-get install -y \
curl \
apt-transport-https \
dialog \
python \
daemon
echo "Add Kubernetes repo..."
sh -c 'curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -'
sh -c 'echo "deb http://apt.kubernetes.io/ kubernetes-xenial main" > /etc/apt/sources.list.d/kubernetes.list'
apt-get update -y
echo "Installing Kubernetes requirements..."
apt-get install -y \
docker.io \
kubelet \
kubernetes-cni \
kubectl \
kubeadm
И это ошибка, которую я получаю при установке kubeadm:
root<strong i="16">@82f5321d45cb</strong>:/# apt-get install kubeadm
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
kubeadm
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 7981 kB of archives.
After this operation, 59.2 MB of additional disk space will be used.
Get:1 https://packages.cloud.google.com/apt kubernetes-xenial/main amd64 kubeadm amd64 1.5.0-alpha.0-1534-gcf7301f-00 [7981 kB]
Fetched 7981 kB in 0s (8532 kB/s)
Selecting previously unselected package kubeadm.
(Reading database ... 14222 files and directories currently installed.)
Preparing to unpack .../kubeadm_1.5.0-alpha.0-1534-gcf7301f-00_amd64.deb ...
Unpacking kubeadm (1.5.0-alpha.0-1534-gcf7301f-00) ...
Setting up kubeadm (1.5.0-alpha.0-1534-gcf7301f-00) ...
Failed to connect to bus: No such file or directory
dpkg: error processing package kubeadm (--configure):
subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
kubeadm
E: Sub-process /usr/bin/dpkg returned an error code (1)
_From @zreigz 28 октября 2016 г., 9:10_
Я воспроизвел это и работаю над этим
_From @zreigz 31 октября 2016 г., 7:24_
Есть две проблемы.
Первый: ll: /var/lib/dpkg/info/kubelet.postinst: 38: /var/lib/dpkg/info/kubelet.postinst: [[: not found
В системах Ubuntu / bin / sh - это тире, а не bash, а тире не поддерживает ключевое слово с двойной скобкой. Хорошо, что проблема исправлена в основной ветке и скоро будет доступна: https://github.com/kubernetes/release/blob/master/debian/xenial/kubelet/debian/postinst#L40
Второй не такой уж и тривиальный. Запуск systemctl в контейнере завершается ошибкой с Failed to get D-Bus connection
. Похоже, что systemd не работает должным образом в контейнере. Сейчас я работаю над этим
_From @andersla 31 октября 2016 г., 7:42_
Большой!
Я просто не понимаю, зачем вообще для установки kubeadm systemd / systemctl?
_From @zreigz 31 октября 2016 г., 7: 47_
Из-за этих двух строк: https://github.com/kubernetes/release/blob/master/debian/xenial/kubeadm/debian/postinst#L25
systemctl daemon-reload
systemctl restart kubelet
Не получается на первой линии
_From @zreigz 31 октября 2016 г., 7: 48_
это объяснение:
# because kubeadm package adds kubelet drop-ins, we must daemon-reload
# and restart kubelet now. restarting kubelet is ok because kubelet
# postinst configure step auto-starts it.
_From @zreigz 31 октября 2016 г., 7: 52_
Есть несколько шагов по настройке, чтобы заставить его работать, но я должен сначала попробовать. Если найду что-нибудь, дам тебе знать.
_From @zreigz 2 ноября 2016 г. 7:19_
Хорошие новости. Мне удалось решить все вопросы. Ему нужны последние тесты, и я опубликую решение, как запустить kubeadm в контейнере Docker.
_From @andersla 2 ноября 2016 г., 7:23_
Супер! Помогу в тестировании, как только оно будет готово! - хотя остальную часть недели я в отпуске :)
_From @zreigz 2 ноября 2016 г., 10:13_
Есть две основные проблемы, связанные с установкой kubeadm в контейнер Docker. Сначала systemd работает в контейнере. Во-вторых, установка докера внутри контейнера. Успешно проблемы устранены. Вот Dockerfile, который необходимо использовать для подготовки образа Ubuntu.
FROM ubuntu
ENV container docker
RUN apt-get -y update
RUN apt-get update -qq && apt-get install -qqy \
apt-transport-https \
ca-certificates \
curl \
lxc \
vim \
iptables
RUN curl -sSL https://get.docker.com/ | sh
RUN (cd /lib/systemd/system/sysinit.target.wants/; for i in *; do [ $i == systemd-tmpfiles-setup.service ] || rm -f $i; done); \
rm -f /lib/systemd/system/multi-user.target.wants/*;\
rm -f /etc/systemd/system/*.wants/*;\
rm -f /lib/systemd/system/local-fs.target.wants/*; \
rm -f /lib/systemd/system/sockets.target.wants/*udev*; \
rm -f /lib/systemd/system/sockets.target.wants/*initctl*; \
rm -f /lib/systemd/system/basic.target.wants/*;\
rm -f /lib/systemd/system/anaconda.target.wants/*;
VOLUME /sys/fs/cgroup
VOLUME /var/run/docker.sock
CMD /sbin/init
Я использую эту команду для создания образа в каталоге, содержащем Dockerfile.
docker build -t kubeadm_docker .
Теперь вы можете запустить подготовленный образ и завершить установку kubeadm.
Используйте следующую команду для запуска kubeadm_docker
image:
docker run -it -e "container=docker" --privileged=true -d --security-opt seccomp:unconfined --cap-add=SYS_ADMIN -v /sys/fs/cgroup:/sys/fs/cgroup:ro -v /var/run/docker.sock:/var/run/docker.sock kubeadm_docker /sbin/init
Найти идентификатор работающего контейнера
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
7dd73057620d kubeadm_docker "/sbin/init" About an hour ago Up About an hour furious_fermi
Теперь вы можете открыть консоль контейнера:
docker exec -it 7dd73057620d /bin/bash
Это ваш скрипт (с небольшими изменениями) для установки kubeadm
echo "Updating Ubuntu..."
apt-get update -y
apt-get upgrade -y
systemctl start docker
echo "Install os requirements"
apt-get install -y \
curl \
apt-transport-https \
dialog \
python \
daemon
echo "Add Kubernetes repo..."
sh -c 'curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -'
sh -c 'echo "deb http://apt.kubernetes.io/ kubernetes-xenial main" > /etc/apt/sources.list.d/kubernetes.list'
apt-get update -y
echo "Installing Kubernetes requirements..."
apt-get install -y \
kubelet
# This is temporary fix until new version will be released
sed -i 38,40d /var/lib/dpkg/info/kubelet.postinst
apt-get install -y \
kubernetes-cni \
kubectl \
kubeadm
И, наконец, вы можете выполнить
# kubeadm init
Все работает так же, как на локальной машине.
Удачи :)
_From @SuperStevenZ 17 ноября 2016 г., 7: 21_
@zreigz Это решило
_From @zreigz 17 ноября 2016 г., 7:30 _
Без проблем :)
Мы должны настроить CI с элементами docker-in-docker.
@errordeveloper @zreigz Сможете ли вы с этим
По крайней мере, мы должны где-то задокументировать, как запускать kubeadm внутри контейнера ...
Звучит хорошо для меня. Конечно, нам нужно поместить все это в образ докера, а также несколько сценариев config / start, чтобы различать мастер и узел. Хорошим началом было бы создать для него проект вроде kubernetes / kubeadm-docker. Также подходящее место для Dockerfile, скриптов и документации.
Сначала создайте это как частный проект под zreigz /, и в конечном итоге мы, вероятно, объединим этот код в это репо.
Но сначала создайте прототип в своем собственном пространстве, и мы посмотрим, как это получится.
Настоящий правопреемник - @zreigz
Да, хороший момент. Я сделаю это. На следующей неделе (понедельник, вторник) я на конференции, поэтому начну в среду.
@luxas Мне было интересно, как мне предоставить пакеты kubeadm и kubernetes-cni. Если мне нужно собрать его из текущих источников (чтобы иметь возможность протестировать новейшую реализацию) или просто загрузить новейшую версию из репозитория? Для целей CI я считаю, что мы должны иметь текущее состояние кода, чтобы иметь возможность его протестировать, или он нужен нам только для тестирования версии выпуска?
Привет, спасибо за исправление, но проблема все еще возникает после инициализации kubeadm. Я получаю 0/3 на DNS, DNS, похоже, вообще не работает
Каждые 2.0 с: kubectl get pods --all-namespaces Пт 16 декабря 17:00:50 2016
NAMESPACE ИМЯ СОСТОЯНИЕ ГОТОВНОСТЬ ВОЗВРАЩАЕТСЯ ВОЗРАСТ
kube-system dummy-2088944543-17sey 1/1 Бег 0 11м
kube-system etcd-8dd8c92c6c38 1/1 Бег 2 12 м
kube-system kube-apiserver-8dd8c92c6c38 1/1 Бег 4 12м
kube-system kube-controller-manager-8dd8c92c6c38 1/1 Бег 2 11м
kube-system kube-discovery-1150918428-m506w 1/1 Бег 0 11 м
kube-system kube-dns-654381707-vuijm 0/3 КонтейнерСоздание 0 11м
kube-system kube-proxy-tuw6u 0/1 CrashLoopBackOff 6 11 мес.
kube-system kube-scheduler-8dd8c92c6c38 1/1 Бег 2 10 м
попробовал установить сетевую политику
корень @ 8dd8c92c6c38 : / # kubectl apply -f calico.yaml
путь "calico.yaml" не существует
корень @ 8dd8c92c6c38 : / # kubectl create -f calico.yaml
путь "calico.yaml" не существует
корень @ 8dd8c92c6c38 : / # kubectl apply -f kube-flannel.yml
путь "kube-flannel.yml" не существует
корень @ 8dd8c92c6c38 : / # kubectl apply -f https://git.io/weave-kube
демонсет "weave-net" создан
root @ 8dd8c92c6c38 : / # kubectl get pods --all-namespaces
NAMESPACE ИМЯ СОСТОЯНИЕ ГОТОВНОСТЬ ВОЗВРАЩАЕТСЯ ВОЗРАСТ
kube-system dummy-2088944543-17sey 1/1 Бег 0 46м
kube-system etcd-8dd8c92c6c38 1/1 Бег 2 46м
kube-system kube-apiserver-8dd8c92c6c38 1/1 Бег 4 46м
kube-system kube-controller-manager-8dd8c92c6c38 1/1 Бег 2 45м
kube-system kube-discovery-1150918428-9m6rr 0/1 В ожидании 0 3 мес.
kube-system kube-dns-654381707-vuijm 0/3 КонтейнерСоздание 0 45м
kube-system kube-proxy-tuw6u 0/1 CrashLoopBackOff 13 45m
kube-system kube-scheduler-8dd8c92c6c38 1/1 Бег 2 44 м
kube-system weave-net-iv0bc 0/2 Создание контейнера 0 49s
информация: 1 завершенный объект (ы) не отображался (не отображались) в списке модулей. Передайте --show-all, чтобы увидеть все объекты.
Привет еще раз @zreigz
Теперь у меня, наконец, было время пойти дальше и протестировать его - я почти могу это сделать, но есть ошибка, из-за которой докер выбирает драйвер хранилища vfs (вероятно, потому, что он не может использовать aufs поверх aufs? Но как вы описываете обходной путь выше я монтирую внешний докер .sock во внутреннем докере, чтобы можно было писать с помощью aufs?
docker info
на моем хосте сообщает, что на нем запущен драйвер хранилища aufs. - Если я сделаю docker info
внутри контейнера докеров с кубернетами, он говорит, что использует драйвер хранилища vfs.
Любые идеи того, почему у меня возникает следующая проблема при запуске
kubeadm init
root<strong i="13">@f50f087baa83</strong>:/# kubeadm init
[kubeadm] WARNING: kubeadm is in alpha, please do not use it for production clusters.
[preflight] Running pre-flight checks
[preflight] The system verification failed. Printing the output from the verification:
OS: Linux
KERNEL_VERSION: 4.4.0-43-generic
CONFIG_NAMESPACES: enabled
CONFIG_NET_NS: enabled
CONFIG_PID_NS: enabled
CONFIG_IPC_NS: enabled
CONFIG_UTS_NS: enabled
CONFIG_CGROUPS: enabled
CONFIG_CGROUP_CPUACCT: enabled
CONFIG_CGROUP_DEVICE: enabled
CONFIG_CGROUP_FREEZER: enabled
CONFIG_CGROUP_SCHED: enabled
CONFIG_CPUSETS: enabled
CONFIG_MEMCG: enabled
CONFIG_INET: enabled
CONFIG_EXT4_FS: enabled
CONFIG_PROC_FS: enabled
CONFIG_NETFILTER_XT_TARGET_REDIRECT: enabled (as module)
CONFIG_NETFILTER_XT_MATCH_COMMENT: enabled (as module)
CONFIG_OVERLAY_FS: enabled (as module)
CONFIG_AUFS_FS: enabled (as module)
CONFIG_BLK_DEV_DM: enabled
CGROUPS_CPU: enabled
CGROUPS_CPUACCT: enabled
CGROUPS_CPUSET: enabled
CGROUPS_DEVICES: enabled
CGROUPS_FREEZER: enabled
CGROUPS_MEMORY: enabled
DOCKER_VERSION: 1.12.1
DOCKER_GRAPH_DRIVER: vfs
[preflight] Some fatal errors occurred:
unsupported graph driver: vfs
[preflight] If you know what you are doing, you can skip pre-flight checks with `--skip-preflight-checks`
root<strong i="14">@f50f087baa83</strong>:/#
Еще немного информации после того, как попробуем еще немного.
Я изменил драйвер хранилища докеров на «оверлей» на хосте. Затем докер внутри докера выбрал aufs в качестве водителя, и я прошел «предполетные проверки», но теперь я застрял в
[apiclient] Created API client, waiting for the control plane to become ready
Во время другого тестирования я понял, что докер не выбирает тот же драйвер хранилища, когда он был запущен как служба через / sbin / init
Если бы я запустил образ докера таким образом, он не запускал тот же драйвер, что и хост (как упоминалось выше):
sudo docker run -it --privileged=true -d --security-opt seccomp:unconfined --cap-add=SYS_ADMIN -v /sys/fs/cgroup:/sys/fs/cgroup:ro -v /var/run/docker.sock:/var/run/docker.sock kubeadm_docker /sbin/init
Если бы я запустил его без /sbin/init
а не как демон вроде этого:
sudo docker run -it --privileged=true --security-opt seccomp:unconfined --cap-add=SYS_ADMIN -v /sys/fs/cgroup:/sys/fs/cgroup:ro -v /var/run/docker.sock:/var/run/docker.sock kubeadm_docker /bin/bash
тогда докер выбирал тот же драйвер хранилища, что и хост (но теперь systemctrl
не работал)
Еще несколько обновлений:
Теперь я могу создать рабочий kubeadm-in-docker-container с помощью этого Dockerfile:
FROM ubuntu:xenial-20161213
ARG DEBIAN_FRONTEND=noninteractive
RUN apt-get update -qq
RUN apt-get install -y \
apt-transport-https \
apt-utils \
ca-certificates \
curl \
dialog \
python \
daemon \
vim \
jq \
linux-image-$(uname -r)
# remove unwanted systemd services
RUN for i in /lib/systemd/system/sysinit.target.wants/*; do [ "${i##*/}" = "systemd-tmpfiles-setup.service" ] || rm -f "$i"; done; \
rm -f /lib/systemd/system/multi-user.target.wants/*;\
rm -f /etc/systemd/system/*.wants/*;\
rm -f /lib/systemd/system/local-fs.target.wants/*; \
rm -f /lib/systemd/system/sockets.target.wants/*udev*; \
rm -f /lib/systemd/system/sockets.target.wants/*initctl*; \
rm -f /lib/systemd/system/basic.target.wants/*;\
rm -f /lib/systemd/system/anaconda.target.wants/*;
# install docker (after removing unwanted systemd)
RUN apt-get install -y \
docker.io
RUN echo "Add Kubernetes repo..."
RUN sh -c 'curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -'
RUN sh -c 'echo "deb http://apt.kubernetes.io/ kubernetes-xenial main" > /etc/apt/sources.list.d/kubernetes.list'
RUN echo "Installing Kubernetes requirements..."
RUN apt-get update -y && apt-get install -y \
kubelet \
kubernetes-cni \
kubectl
RUN echo "Installing Kubeadm - this will fail at post-install but that doesn't matter"
RUN apt-get install -y \
kubeadm; exit 0
# Create volume for docker
VOLUME /var/lib/docker
Я строю с помощью: docker build -t kubeadm_docker .
А затем запустите:
docker run -it --privileged=true --name=master -d --security-opt seccomp:unconfined --cap-add=SYS_ADMIN -v /sys/fs/cgroup:/sys/fs/cgroup:ro kubeadm_docker /sbin/init
Подождите несколько (10-15) секунд, пока systemd и docker не запустятся.
Затем я запускаю kubeadm внутри работающего контейнера:
docker exec -it master kubeadm init --token=acbec6.2852dff7cb569aa0
Когда он запускается, я запускаю второй «рабочий» узел:
docker run -it --privileged=true --name=node -d --security-opt seccomp:unconfined --cap-add=SYS_ADMIN -v /sys/fs/cgroup:/sys/fs/cgroup:ro kubeadm_docker /sbin/init
И через несколько секунд присоединяйтесь к мастеру:
docker exec -it edge kubeadm join --token=acbec6.2852dff7cb569aa0 172.17.0.2
В настоящее время существует некоторая проблема с сетью докеров, потому что kube-proxy запускается и входит в CrashLoopBackOff.
Если я вместо этого установлю --net=host
при запуске докера выше, тогда kube-proxy и все модули будут работать нормально, но это не вариант, поскольку мне нужно, чтобы контейнеры работали в сети докеров с их ip: s
Я также ранее пытался запустить докер с тем же процессом, что и на хосте: -v /var/run/docker.sock:/var/run/docker.sock
но у меня так и не получилось, что он работает, потому что, когда докер внутри контейнера запускается с помощью systemd, он не берет носок (или что-то вроде что).
Спасибо @andersla!
Можете ли вы вставить, с чем не работает kube-proxy?
Спасибо @luxas за
К сожалению, в journalctl -xeu kubelet
подробностей нет
Это все, что я нашел о kube-proxy (повторяется много раз). Я также прилагаю полный журнал.
Jan 09 14:40:02 1355b98bf8c7 kubelet[244]: I0109 14:40:02.690862 244 docker_manager.go:2524] checking backoff for container "kube-proxy" in pod "kube-proxy-7886l"
Jan 09 14:40:03 1355b98bf8c7 kubelet[244]: I0109 14:40:03.984818 244 docker_manager.go:2538] Back-off 20s restarting failed container=kube-proxy pod=kube-proxy-7886l_kube-system(71a1e950-d679-11e6-a9f7-02429d4c0f01)
Jan 09 14:40:03 1355b98bf8c7 kubelet[244]: E0109 14:40:03.984833 244 pod_workers.go:184] Error syncing pod 71a1e950-d679-11e6-a9f7-02429d4c0f01, skipping: failed to "StartContainer" for "kube-proxy" with CrashLoopBackOff: "Back-off 20s restarting failed container=kube-proxy pod=kube-proxy-7886l_kube-system(71a1e950-d679-11e6-a9f7-02429d4c0f01)"
В полном журнале тоже жалуются на kube-dns - но это потому, что я еще не начал плести.
Вот журнал из kubectl describe pod -n kube-system kube-proxy-w0ng5
Name: kube-proxy-w0ng5
Namespace: kube-system
Node: 3551807cba77/172.17.0.2
Start Time: Tue, 10 Jan 2017 18:03:06 +0000
Labels: component=kube-proxy
k8s-app=kube-proxy
kubernetes.io/cluster-service=true
name=kube-proxy
tier=node
Status: Running
IP: 172.17.0.2
Controllers: DaemonSet/kube-proxy
Containers:
kube-proxy:
Container ID: docker://dcc2bc0b50a2477b72d451b776f35e327f1faf09e3cddb25d5609569c6f2a242
Image: gcr.io/google_containers/kube-proxy-amd64:v1.5.1
Image ID: docker-pullable://gcr.io/google_containers/kube-proxy-amd64<strong i="7">@sha256</strong>:3b82b2e0862b3c0ece915de29a5a53634c9b0a73140340f232533c645decbd4b
Port:
Command:
kube-proxy
--kubeconfig=/run/kubeconfig
State: Waiting
Reason: CrashLoopBackOff
Last State: Terminated
Reason: Error
Exit Code: 1
Started: Tue, 10 Jan 2017 18:08:48 +0000
Finished: Tue, 10 Jan 2017 18:08:48 +0000
Ready: False
Restart Count: 6
Volume Mounts:
/run/kubeconfig from kubeconfig (rw)
/var/run/dbus from dbus (rw)
/var/run/secrets/kubernetes.io/serviceaccount from default-token-g0ft5 (ro)
Environment Variables: <none>
Conditions:
Type Status
Initialized True
Ready False
PodScheduled True
Volumes:
kubeconfig:
Type: HostPath (bare host directory volume)
Path: /etc/kubernetes/kubelet.conf
dbus:
Type: HostPath (bare host directory volume)
Path: /var/run/dbus
default-token-g0ft5:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-g0ft5
QoS Class: BestEffort
Tolerations: dedicated=master:NoSchedule
Events:
FirstSeen LastSeen Count From SubObjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
9m 9m 1 {kubelet 3551807cba77} spec.containers{kube-proxy} Normal Pullingpulling image "gcr.io/google_containers/kube-proxy-amd64:v1.5.1"
9m 9m 1 {kubelet 3551807cba77} spec.containers{kube-proxy} Normal CreatedCreated container with docker id ecf446de342a; Security:[seccomp=unconfined]
9m 9m 1 {kubelet 3551807cba77} spec.containers{kube-proxy} Normal StartedStarted container with docker id ecf446de342a
9m 9m 1 {kubelet 3551807cba77} spec.containers{kube-proxy} Normal Pulled Successfully pulled image "gcr.io/google_containers/kube-proxy-amd64:v1.5.1"
9m 9m 1 {kubelet 3551807cba77} spec.containers{kube-proxy} Normal CreatedCreated container with docker id f562fb667a64; Security:[seccomp=unconfined]
9m 9m 1 {kubelet 3551807cba77} spec.containers{kube-proxy} Normal StartedStarted container with docker id f562fb667a64
9m 9m 2 {kubelet 3551807cba77} Warning FailedSync Error syncing pod, skipping: failed to "StartContainer" for "kube-proxy" with CrashLoopBackOff: "Back-off 10s restarting failed container=kube-proxy pod=kube-proxy-w0ng5_kube-system(09c4f65d-d75f-11e6-814c-0242255c9a68)"
9m 9m 1 {kubelet 3551807cba77} spec.containers{kube-proxy} Normal Started Started container with docker id 1a7d7d4f682b
9m 9m 1 {kubelet 3551807cba77} spec.containers{kube-proxy} Normal Created Created container with docker id 1a7d7d4f682b; Security:[seccomp=unconfined]
9m 9m 2 {kubelet 3551807cba77} Warning FailedSync Error syncing pod, skipping: failed to "StartContainer" for "kube-proxy" with CrashLoopBackOff: "Back-off 20s restarting failed container=kube-proxy pod=kube-proxy-w0ng5_kube-system(09c4f65d-d75f-11e6-814c-0242255c9a68)"
8m 8m 1 {kubelet 3551807cba77} spec.containers{kube-proxy} Normal Started Started container with docker id 89bdf4ba7e0b
8m 8m 1 {kubelet 3551807cba77} spec.containers{kube-proxy} Normal Created Created container with docker id 89bdf4ba7e0b; Security:[seccomp=unconfined]
8m 8m 3 {kubelet 3551807cba77} Warning FailedSync Error syncing pod, skipping: failed to "StartContainer" for "kube-proxy" with CrashLoopBackOff: "Back-off 40s restarting failed container=kube-proxy pod=kube-proxy-w0ng5_kube-system(09c4f65d-d75f-11e6-814c-0242255c9a68)"
8m 8m 1 {kubelet 3551807cba77} spec.containers{kube-proxy} Normal Created Created container with docker id f2b7a2b5078d; Security:[seccomp=unconfined]
8m 8m 1 {kubelet 3551807cba77} spec.containers{kube-proxy} Normal Started Started container with docker id f2b7a2b5078d
8m 7m 6 {kubelet 3551807cba77} Warning FailedSync Error syncing pod, skipping: failed to "StartContainer" for "kube-proxy" with CrashLoopBackOff: "Back-off 1m20s restarting failed container=kube-proxy pod=kube-proxy-w0ng5_kube-system(09c4f65d-d75f-11e6-814c-0242255c9a68)"
6m 6m 1 {kubelet 3551807cba77} spec.containers{kube-proxy} Normal Created Created container with docker id 28deaf41d920; Security:[seccomp=unconfined]
6m 6m 1 {kubelet 3551807cba77} spec.containers{kube-proxy} Normal Started Started container with docker id 28deaf41d920
6m 4m 12 {kubelet 3551807cba77} Warning FailedSync Error syncing pod, skipping: failed to "StartContainer" for "kube-proxy" with CrashLoopBackOff: "Back-off 2m40s restarting failed container=kube-proxy pod=kube-proxy-w0ng5_kube-system(09c4f65d-d75f-11e6-814c-0242255c9a68)"
9m 4m 6 {kubelet 3551807cba77} spec.containers{kube-proxy} Normal Pulled Container image "gcr.io/google_containers/kube-proxy-amd64:v1.5.1" already present on machine
4m 4m 1 {kubelet 3551807cba77} spec.containers{kube-proxy} Normal Created Created container with docker id dcc2bc0b50a2; Security:[seccomp=unconfined]
4m 4m 1 {kubelet 3551807cba77} spec.containers{kube-proxy} Normal Started Started container with docker id dcc2bc0b50a2
9m 10s 43 {kubelet 3551807cba77} spec.containers{kube-proxy} Warning BackOff Back-off restarting failed docker container
4m 10s 18 {kubelet 3551807cba77} Warning FailedSync Error syncing pod, skipping: failed to "StartContainer" for "kube-proxy" with CrashLoopBackOff: "Back-off 5m0s restarting failed container=kube-proxy pod=kube-proxy-w0ng5_kube-system(09c4f65d-d75f-11e6-814c-0242255c9a68)"
Да, я вижу _это_ что-то зависание, но не могли бы вы дать, например, kubectl -n kube-system logs kube-proxy-w0ng5
?
Итак, мы действительно видим причину _why_: smile:
Эй, это здорово :)
root @ 3551807cba77 : / # kubectl -n журналы системы kube kube-proxy-w0ng5
I0110 18:29:01.705993 1 server.go:215] Using iptables Proxier.
W0110 18:29:01.706933 1 proxier.go:254] clusterCIDR not specified, unable to distinguish between internal and external traffic
I0110 18:29:01.706947 1 server.go:227] Tearing down userspace rules.
I0110 18:29:01.712693 1 conntrack.go:81] Set sysctl 'net/netfilter/nf_conntrack_max' to 262144
I0110 18:29:01.712927 1 conntrack.go:66] Setting conntrack hashsize to 65536
write /sys/module/nf_conntrack/parameters/hashsize: operation not supported
Я могу исправить это с помощью обходного пути: установив --conntrack-max-per-core=0
а затем перезапустив прокси. Значение 0 пропускает реконфигурацию nf_conntrack_max и оставляет как есть (65536). Я ввожу параметр запуска следующим образом:
Сначала войдите в контейнер докеров:
docker exec -it master bash
затем примените исправление:
kubectl -n kube-system get ds -l 'component=kube-proxy' -o json | jq '.items[0].spec.template.spec.containers[0].command |= .+ ["--conntrack-max-per-core=0"]' | kubectl apply -f - && kubectl -n kube-system delete pods -l 'component=kube-proxy'
Теперь я получаю CrashLoop на Weave вместо этого, когда я позже использую kubectl apply -f weave.yaml
, следующий вывод журнала из модуля weave:
/proc/sys/net/bridge/bridge-nf-call-iptables not found
Я также попытался начать с параметра kube-proxy --proxy-mode=userspace
но результат тот же.
Думаю, это решит проблему плетения: https://github.com/weaveworks/weave/pull/2659
@andersla Да, похоже, проблема решена. Можете попробовать сборку из HEAD?
Например, вы можете использовать изображения luxas/weave-(kube|npc):v1.9.0-alpha.5
из HEAD ~ ish.
Сообщите мне, работает ли это, и, пожалуйста, прокомментируйте здесь, что именно вы делаете сейчас (команды оболочки, Dockerfile, другие скрипты и т. Д.), Чтобы другие могли воспользоваться этим.
Я использовал последнее изображение от weaveworks / weave-kube
Я также использовал последний yaml-шаблон https://github.com/weaveworks/weave/blob/master/prog/weave-kube/weave-daemonset.yaml
К сожалению, kube-dns не работал (он завязан в ContainerCreating. Сообщение об ошибке от kubelet после запуска weave:
an 15 16:14:30 7c12205804da kubelet[540]: I0115 16:14:30.443327 540 operation_executor.go:917] MountVolume.SetUp succeeded for volume "kubernetes.io/secret/c23fb73d-db39-11e6-b84d-0242b1ac1840-default-token-142vd" (spec.Name: "default-token-142vd") pod "c23fb73d-db39-11e6-b84d-0242b1ac1840" (UID: "c23fb73d-db39-11e6-b84d-0242b1ac1840").
Jan 15 16:14:31 7c12205804da kubelet[540]: E0115 16:14:31.381741 540 docker_manager.go:373] NetworkPlugin cni failed on the status hook for pod 'kube-dns-2924299975-9gjcg' - Unexpected command output Device "eth0" does not exist.
Jan 15 16:14:31 7c12205804da kubelet[540]: with error: exit status 1
Если я запустил только главный узел и не присоединился к другому узлу, тогда kubedns подошел нормально, когда я применил weave.yaml
Я также протестировал weave.yaml с последней версией weave-kube на установке Vagrant, а не в моем эксперименте с докерами, и тогда все заработало.
Это weave.yaml, который я использовал для kubectl apply -f weave.yaml
apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
name: weave-net
namespace: kube-system
spec:
template:
metadata:
labels:
name: weave-net
annotations:
scheduler.alpha.kubernetes.io/tolerations: |
[
{
"key": "dedicated",
"operator": "Equal",
"value": "master",
"effect": "NoSchedule"
}
]
spec:
hostNetwork: true
hostPID: true
containers:
- name: weave
image: weaveworks/weave-kube:latest
imagePullPolicy: Always
command:
- /home/weave/launch.sh
livenessProbe:
initialDelaySeconds: 30
httpGet:
host: 127.0.0.1
path: /status
port: 6784
securityContext:
privileged: true
volumeMounts:
- name: weavedb
mountPath: /weavedb
- name: cni-bin
mountPath: /host/opt
- name: cni-bin2
mountPath: /host/home
- name: cni-conf
mountPath: /host/etc
- name: dbus
mountPath: /host/var/lib/dbus
resources:
requests:
cpu: 10m
- name: weave-npc
image: weaveworks/weave-npc:latest
imagePullPolicy: Always
resources:
requests:
cpu: 10m
securityContext:
privileged: true
restartPolicy: Always
volumes:
- name: weavedb
emptyDir: {}
- name: cni-bin
hostPath:
path: /opt
- name: cni-bin2
hostPath:
path: /home
- name: cni-conf
hostPath:
path: /etc
- name: dbus
hostPath:
path: /var/lib/dbus
эй, ребята, я наткнулся на эту ветку, и это чертовски круто! отличный материал.
Я действительно хочу использовать этот подход для CI против нашего репо (что, честно говоря, довольно сложно). у нас есть требование Helm / Tiller для запуска довольно большого количества диаграмм для CI. Кто-нибудь из вас сталкивался с этим или есть предложения по его реализации? Тиллер, кажется, в этой ситуации борется с самим собой:
root<strong i="7">@JINKITNIX05</strong>:~/openstack-helm# kubectl logs tiller-deploy-3299276078-6kdzw -n kube-system
Error from server (BadRequest): the server rejected our request for an unknown reason (get pods tiller-deploy-3299276078-6kdzw)
root<strong i="8">@JINKITNIX05</strong>:~/openstack-helm#
Я могу попробовать с другими SDN. мы до сих пор использовали Calico, потому что L3 немного проще устранять неполадки в хакерских ситуациях, но если Weave лучше (поскольку это L2) ... Я попробую все, что поможет нам решить проблему Tiller. Я думаю, что Тиллер недоволен, потому что в конце концов кажется, что он ассоциируется с 127.0.0.1 ... и я видел, что это вызывает проблемы в прошлом, тестируя другие вещи. любой ввод был бы потрясающим. Опять же, действительно отличный реквизит для ребят, которые взламывают! Спасибо!!
Привет! Здорово, что все больше людей хотят, чтобы это работало. У меня нет опыта работы с ситцем. В облаке мы запускаем Weave, поэтому я хотел работать над этим проектом. Но я застрял, и у меня не было времени копать дальше, почему не появляется kube-dns, когда я применяю Weave, как описано выше.
Теперь последнее стабильное переплетение работает лучше, чем раньше ....
kubectl apply -f https://git.io/weave-kube
..но, к сожалению, все еще та же проблема с kube-dns, который не запускается, застрял в ContainerCreating:
root<strong i="9">@18a7d1ec5124</strong>:/# kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system dummy-2088944543-pvvdx 1/1 Running 0 5m
kube-system etcd-18a7d1ec5124 1/1 Running 0 4m
kube-system kube-apiserver-18a7d1ec5124 1/1 Running 2 5m
kube-system kube-controller-manager-18a7d1ec5124 1/1 Running 0 4m
kube-system kube-discovery-1769846148-6tv4l 1/1 Running 0 5m
kube-system kube-dns-2924299975-4608d 0/4 ContainerCreating 0 5m
kube-system kube-proxy-k0stq 1/1 Running 0 4m
kube-system kube-proxy-tnm8h 1/1 Running 0 4m
kube-system kube-scheduler-18a7d1ec5124 1/1 Running 0 4m
kube-system weave-net-mff6t 2/2 Running 0 3m
kube-system weave-net-t7zcl 2/2 Running 0 3m
и после применения плетения это сообщение об ошибке прекращается:
Feb 04 18:06:57 18a7d1ec5124 kubelet[252]: E0204 18:06:57.125434 252 pod_workers.go:184] Error syncing pod 7dc68091-eb04-11e6-a321-02425e578ba1, skipping: failed to "SetupNetwork" for "kube-dns-2924299975-4608d_kube-system" with SetupNetworkError: "Failed to setup network for pod \"kube-dns-2924299975-4608d_kube-system(7dc68091-eb04-11e6-a321-02425e578ba1)\" using network plugins \"cni\": cni config unintialized; Skipping pod"
а вместо этого однажды я вижу:
Feb 04 18:06:59 18a7d1ec5124 kubelet[252]: E0204 18:06:59.615375 252 docker_manager.go:373] NetworkPlugin cni failed on the status hook for pod 'kube-dns-2924299975-4608d' - Unexpected command output Device "eth0" does not exist.
Feb 04 18:06:59 18a7d1ec5124 kubelet[252]: with error: exit status 1
Если я использую Flannel в качестве сетевого плагина, он работает.
docker exec -it master bash
curl -sSL "https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml?raw=true" | kubectl create -f -
Итак, если вы используете Flannel, то все работает, вот полная настройка:
Dockerfile:
FROM ubuntu:xenial-20161213
ARG DEBIAN_FRONTEND=noninteractive
RUN apt-get update -qq
RUN apt-get install -y \
apt-transport-https \
apt-utils \
ca-certificates \
curl \
dialog \
python \
daemon \
vim \
jq
# remove unwanted systemd services
RUN for i in /lib/systemd/system/sysinit.target.wants/*; do [ "${i##*/}" = "systemd-tmpfiles-setup.service" ] || rm -f "$i"; done; \
rm -f /lib/systemd/system/multi-user.target.wants/*;\
rm -f /etc/systemd/system/*.wants/*;\
rm -f /lib/systemd/system/local-fs.target.wants/*; \
rm -f /lib/systemd/system/sockets.target.wants/*udev*; \
rm -f /lib/systemd/system/sockets.target.wants/*initctl*; \
rm -f /lib/systemd/system/basic.target.wants/*;\
rm -f /lib/systemd/system/anaconda.target.wants/*;
# install docker (after removing unwanted systemd)
RUN apt-get install -y \
docker.io
RUN echo "Add Kubernetes repo..."
RUN sh -c 'curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -'
RUN sh -c 'echo "deb http://apt.kubernetes.io/ kubernetes-xenial main" > /etc/apt/sources.list.d/kubernetes.list'
RUN echo "Installing Kubernetes requirements..."
RUN apt-get update -y && apt-get install -y \
kubelet \
kubernetes-cni \
kubectl
RUN echo "Installing Kubeadm - this will fail at post-install but that doesn't matter"
RUN apt-get install -y \
kubeadm; exit 0
# Create volume for docker
VOLUME /var/lib/docker
Создайте его с помощью:
docker build -t kubeadm_docker .
А затем запустите:
docker run -it --privileged=true --name=master -h master -d --security-opt seccomp:unconfined --cap-add=SYS_ADMIN -v /sys/fs/cgroup:/sys/fs/cgroup:ro kubeadm_docker /sbin/init
Подождите несколько (10-15) секунд, пока systemd и docker не запустятся.
Затем я запускаю kubeadm внутри работающего контейнера:
docker exec -it master kubeadm init --skip-preflight-checks --token=acbec6.2852dff7cb569aa0
Когда он запускается, я запускаю второй «рабочий» узел:
docker run -it --privileged=true --name=node -h node -d --security-opt seccomp:unconfined --cap-add=SYS_ADMIN -v /sys/fs/cgroup:/sys/fs/cgroup:ro kubeadm_docker /sbin/init
И через несколько секунд (пока не запустятся systemd и docker) присоединитесь к мастеру:
docker exec -it node kubeadm join --skip-preflight-checks --token=acbec6.2852dff7cb569aa0 172.17.0.2
Когда они присоединятся, введите master и примените обходной путь для сбоя kube-proxy:
docker exec -it master bash
kubectl -n kube-system get ds -l 'component=kube-proxy' -o json | jq '.items[0].spec.template.spec.containers[0].command |= .+ ["--conntrack-max-per-core=0"]' | kubectl apply -f - && kubectl -n kube-system delete pods -l 'component=kube-proxy'
Наконец, примените фланелевую оверлейную сеть:
curl -sSL "https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml?raw=true" | kubectl create -f -
У меня не было проблем с установкой Helm, Traefic или GlusterFS в Kubernetes в этой настройке :)
kubeadm-dind-cluster в основном делает то, что описано в последнем комментарии, обеспечивая автоматизацию, поэтому вам не нужно вводить команды вручную (хотя на данный момент он использует плагин моста CNI с некоторыми хаками вместо фланели, но это я исправлю довольно скоро).
Это также упрощает сборку компонентов k8s и kubeadm из локального источника и использования двоичных файлов в запускаемом вами кластере. Кроме того, были некоторые неочевидные проблемы, с которыми я столкнулся во время работы над ним, например, agetty, съедающий 100% ЦП и вызывающий сбои докеров, если вы не отключите его.
В kubeadm-dind-cluster скоро появятся некоторые изменения:
kubeadm-dind-cluster также обеспечивает автоматизацию тестов e2e. Еще одна интересная особенность заключается в том, что вы можете использовать один и тот же удаленный движок докеров как для сборки k8s, так и для запуска kubeadm-dind-cluster без копирования двоичных файлов (он извлекает их непосредственно из контейнера данных сборки), что может быть важно, если вы работаете с удаленным докером через медленное соединение.
... забыл упомянуть, что он настраивает локальный kubectl для вас, поэтому вам не нужно делать docker exec
в вашем главном контейнере для доступа к вашему кластеру.
Как я уже упоминал, хотя DIND может показаться простым на первый взгляд, с ним могут возникнуть некоторые неожиданные проблемы. Некоторые проблемы уже исправлены в kubeadm-dind-cluster и используемом им базовом образе . Например, вам нужно выполнить несколько монтирований , также вам нужно использовать STOPSIGNAL SIGRTMIN+3
и не поддаваться искушению использовать /sbin/init
как ENTRYPOINT
, а драйвер vfs иногда может работать довольно медленно. Итак ... вот драконы;)
@ ivan4th Спасибо за всю работу, которую вы проделали с kubeadm и dind :)
Можете ли вы открыть новую проблему, относящуюся к этой проблеме, где мы можем обсудить MVP, необходимый для слияния kubeadm-dind-cluster с этим репо?
Быстро посмотрев, я обнаружил несколько моментов, которые мы могли бы сделать перед возможным MVP:
Что вы думаете? Спасибо за отличный старт, мне не терпится интегрировать это во что-то официальное от kubeadm: +1:
cc @jbeda @lukemarsden @errordeveloper @mikedanese @timothysc @sttts
Спасибо за отличный старт, мне не терпится интегрировать это во что-то официальный сайт kubeadm
если бы мы могли разработать-построить, kubeadm-local-up-cluster, это было бы фантастически.
@ ivan4th @luxas Какой у этого статус?
Я правда не знаю ... @ ivan4th
@jamiehannaford
В целом kdc вполне можно использовать в его нынешней форме IMO. У него также есть собственный общедоступный CI на основе Travis (кстати, мне также удалось запустить DIND на CircleCI, если это представляет некоторый интерес)
@luxas Может быть, мы можем использовать решение @andersla вместо полноценного DIND-кластера? Если да, нужно ли нам разместить образ Docker где-нибудь или просто задокументировать, как выглядит файл Docker?
Было бы здорово, если бы мы могли исправить эту проблему в версии 1.9.
У меня нет циклов, чтобы над этим работать. Если кто-то еще, пожалуйста, сделайте!
Проблема @jamiehannaford в том, что большая часть «полного» кластера DIND предназначена для решения многочисленных проблем, возникающих при «простом» использовании DIND. Иногда они могут быть довольно неясными, см., Например, https://github.com/Mirantis/kubeadm-dind-cluster/commit/405c8bead4fb443582328fd3c7b8f01452872438 (я думаю, мне нужно отправить исправление для k8s для этого). Что касается kubeadm-dind-cluster , его все еще можно использовать, и я стараюсь поддерживать его в актуальном состоянии ( @danehans и @pmichali используют его для тестирования k8s IPv6 e2e, а Виртлет использует его для запуска тестов e2e на CircleCI), хотя я трачу много времени на другие проекты, поэтому мне пока не удалось переписать его на Go.
Мы говорили об этом вчера на собрании SIG, и мы собираемся закрыть этот вопрос.
Разработка и поддержка полномасштабного решения DIND не входит в задачи основной команды kubeadm в обозримом будущем, если вообще когда-либо. Мы очень рады, что сообщество предоставляет эти решения, как, например, усердная работа
Самый полезный комментарий
Итак, если вы используете Flannel, то все работает, вот полная настройка:
Dockerfile:
Создайте его с помощью:
docker build -t kubeadm_docker .
А затем запустите:
docker run -it --privileged=true --name=master -h master -d --security-opt seccomp:unconfined --cap-add=SYS_ADMIN -v /sys/fs/cgroup:/sys/fs/cgroup:ro kubeadm_docker /sbin/init
Подождите несколько (10-15) секунд, пока systemd и docker не запустятся.
Затем я запускаю kubeadm внутри работающего контейнера:
docker exec -it master kubeadm init --skip-preflight-checks --token=acbec6.2852dff7cb569aa0
Когда он запускается, я запускаю второй «рабочий» узел:
docker run -it --privileged=true --name=node -h node -d --security-opt seccomp:unconfined --cap-add=SYS_ADMIN -v /sys/fs/cgroup:/sys/fs/cgroup:ro kubeadm_docker /sbin/init
И через несколько секунд (пока не запустятся systemd и docker) присоединитесь к мастеру:
docker exec -it node kubeadm join --skip-preflight-checks --token=acbec6.2852dff7cb569aa0 172.17.0.2
Когда они присоединятся, введите master и примените обходной путь для сбоя kube-proxy:
docker exec -it master bash
kubectl -n kube-system get ds -l 'component=kube-proxy' -o json | jq '.items[0].spec.template.spec.containers[0].command |= .+ ["--conntrack-max-per-core=0"]' | kubectl apply -f - && kubectl -n kube-system delete pods -l 'component=kube-proxy'
Наконец, примените фланелевую оверлейную сеть:
curl -sSL "https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml?raw=true" | kubectl create -f -
У меня не было проблем с установкой Helm, Traefic или GlusterFS в Kubernetes в этой настройке :)