Machine: 「「10.0.0.0/24」のサブネットサンドボックス結合に失敗しました:vxlanインターフェイスの作成中にエラーが発生しました:操作はサポートされていません」

作成日 2016年01月06日  ·  22コメント  ·  ソース: docker/machine

docker.comの Getstartedwith 」の記事を使用してセットアップされた群れでdocker-composeを実行する際に問題が発生しました。ただし、GenericDriverを使用する場合を除きます。

docker-machine create --driver generic --generic-ip-address $HOST1 --generic-ssh-user root --swarm --swarm-discovery="consul://$(docker-machine ip consul):8500" --engine-opt="cluster-store=consul://$(docker-machine ip consul):8500" --engine-opt="cluster-advertise=eth0:2376" node-b

各ホストにとってはすべて問題ないようです

群れを構成しています...
Dockerへの接続を確認しています...
Dockerが稼働しています!

ただし、このコマンドを実行すると(Docker Hubにリストされているコンテナーのみを使用)

docker-compose --x-networking --x-network-driver=overlay up -d

エラー:コンテナ4f55c34c5687bc810aaafd58f22d0a60a118d353bc4209993881265e25d171a8を開始できません:「10.0.0.0/24」のサブネットサンドボックス結合に失敗しました:vxlanインターフェイスの作成中にエラーが発生しました:操作はサポートされていません

drivegeneric

最も参考になるコメント

私はLinodeでDockerSwarmと約2日間苦労しているので、ここに到着した他の人のためにそれを解決する方法についての私の指示があります。

スクリーンショット付きの手順は次のとおりです。手順で迷子になるのは非常に簡単だと思います。他の人がすべての苦労を回避できることを願っています。

  • 標準のLinodeから始めて、「Linodeプロファイル」の「編集」リンクをクリックします。

selection_001

  • 設定には、カーネルを選択するためのドロップダウンがあり、デフォルトではLinodeカーネルがあります(これがDocker Swarmで問題を引き起こす原因です):

selection_002

  • カーネルを選択GRUB 2

selection_003

  • 変更を保存します。

selection_004

  • 新しいプロファイルには、最後に(GRUB 2)れます。 これで、Linodeを再起動できます。 何かをインストールしたり、再デプロイしたりする必要はありません。

selection_005

  • 再起動後、動作するはずです。

全てのコメント22件

ホストにはどのバージョンのカーネルがありますか?
https://github.com/docker/docker/issues/14145を参照して

4.1.5-x86_64-linode61

ここでも同じですが、composeを使用していません。単に、Dockerとオーバーレイネットワークドライバーを使用しています。 カーネル:
Linux vagrant-ubuntu-trusty-64 4.2.0-23-generic #28~14.04.1-Ubuntu SMP Thu Dec 31 13:40:42 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

VMを再起動すると、動作します。

そしてここLinodeでも同じです..それはカーネルの問題です。 Linodeでさえ、ボックスは4.xを実行していると言っていますが、公式カーネル(> = 3.16)をインストールし、RInodeをGRUB2から起動するように設定すると、動作します。

閉鎖。 これはカーネルの問題です

申し訳ありませんが、私はここで同じ問題を抱えています。 でも理由がわかりません。 誰かがもう少し詳細を教えてもらえますか?

カーネルが古すぎるか、サポートされていない可能性があります。

まあこれは私が混乱する方法です。 カーネルのバージョンは古くはありませんが、それでもこのエラーが発生します。
カーネルバージョンは4.4.0-x86_64-linode63、OSはUbuntu14.04です。
およびDocker情報:

Containers: 6
 Running: 0
 Paused: 0
 Stopped: 6
Images: 37
Server Version: 1.10.2
Storage Driver: devicemapper
 Pool Name: docker-8:0-65539-pool
 Pool Blocksize: 65.54 kB
 Base Device Size: 107.4 GB
 Backing Filesystem: ext4
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 2.264 GB
 Data Space Total: 107.4 GB
 Data Space Available: 21.93 GB
 Metadata Space Used: 3.138 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.144 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: false
 Deferred Deletion Enabled: false
 Deferred Deleted Device Count: 0
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 WARNING: Usage of loopback devices is strongly discouraged for production use. Either use `--storage-opt dm.thinpooldev` or use `--storage-opt dm.no_warn_on_loop_devices=true` to suppress this warning.
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.77 (2012-10-15)
Execution Driver: native-0.2
Logging Driver: json-file
Plugins: 
 Volume: local
 Network: overlay bridge null host
Kernel Version: 4.4.0-x86_64-linode63
Operating System: Ubuntu 14.04.4 LTS
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 991.7 MiB
Name: localhost
ID: S4LH:BUBO:ZCVX:QDGD:UWAI:GIFD:DL2I:KGP2:HDDL:WLQ3:WPO4:ZB34
WARNING: No swap limit support
Cluster store: consul://xxx.xxx.xxx:8500/network
Cluster advertise: xxx.xxx.xxx:2375

はい、Linodeの4.4カーネルにはこの問題があります。 Ubuntuリポジトリから署名されたカーネル(lts-wilyなど)をインストールし、Linodeが実際にそのカーネルを(VM設定のどこかで)起動することを確認してください。

apt-get install -y linux-signed-generic-lts-wily

ダッシュボード->プロファイルの編集->カーネル-> Grub2

どうもありがとう。 これは本当に問題を解決しました。 :)
しかし、plsは私が尋ねることを可能にします、これの背後にある理由は何ですか? Linodeの4.4カーネルには、この問題を引き起こす可能性のある署名付きカーネルとは異なるものがありますか?
私はgithubでいくつかの問題を読みました。通常、これは古いカーネル<3.16が原因ですが、4.4にまだこれがあるのはなぜですか。

残念ながらわかりません。

ばかげた質問だとお詫びしますが、私にもこの問題があります。 apt-getインストールが機能するために/etc/apt/sources.listに必要なエントリは、私が試したもので機能させることができなかったためです。

気にしないでください-trusty / trusty-updatesリポジトリについて知りました

最近のカーネルでもこの​​問題が発生する可能性のある方へ。
CONFIG_VXLANが設定されていないOVHによって提供されたカーネル(すべての適切なドライバーが埋め込まれている)でも同じ問題が発生しました。
したがって、構成がある場合は構成を確認し、CONFIG_VXLANとCONFIG_VETHが組み込みまたはモジュールとして有効になっていることを確認しながら、カーネルを再コンパイルします。

@matevargaに感謝します。 今日もCentOS7を搭載したLinodeで同じです。カーネルを自分でインストールする必要はありませんでした。マシンを再構築し、LinodeのパネルでGRUB 2に設定してから、最初に起動しました。

私はLinodeでDockerSwarmと約2日間苦労しているので、ここに到着した他の人のためにそれを解決する方法についての私の指示があります。

スクリーンショット付きの手順は次のとおりです。手順で迷子になるのは非常に簡単だと思います。他の人がすべての苦労を回避できることを願っています。

  • 標準のLinodeから始めて、「Linodeプロファイル」の「編集」リンクをクリックします。

selection_001

  • 設定には、カーネルを選択するためのドロップダウンがあり、デフォルトではLinodeカーネルがあります(これがDocker Swarmで問題を引き起こす原因です):

selection_002

  • カーネルを選択GRUB 2

selection_003

  • 変更を保存します。

selection_004

  • 新しいプロファイルには、最後に(GRUB 2)れます。 これで、Linodeを再起動できます。 何かをインストールしたり、再デプロイしたりする必要はありません。

selection_005

  • 再起動後、動作するはずです。

見つけてくれてありがとう@tiangolo完璧に働いた

ありがとう@tiangoloは私のために完璧に働いた

誰かが古いLinodeで@tiangoloの指示に従い、 https ://www.linode.com/docs/tools-reference/custom-kernels-distros/runを参照して

https://www.linode.com/docs/platform/manager/how-to-change-your-linodes-kernel/#no-upstream-kernel-installedの問題に直面してい

Ubuntu Server 16.04 LTS

  1. sudo apt update
  2. apt list -a linux-image-generic
  3. sudo apt install linux-image-generic grub2
  4. ls / boot
  5. sudo vim / etc / default / grub
  6. sudo update-grub
GRUB_DEFAULT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX="console=ttyS0,19200n8 net.ifnames=0"

GRUB_TERMINAL=serial
GRUB_DISABLE_OS_PROBER=true
GRUB_SERIAL_COMMAND="serial --speed=19200 --unit=0 --word=8 --parity=no --stop=1"
GRUB_DISABLE_LINUX_UUID=true
GRUB_GFXPAYLOAD_LINUX=text

参照:
https://askubuntu.com/questions/879888/how-do-i-update-kernel-to-the-latest-mainline-version
https://askubuntu.com/questions/119080/how-to-update-kernel-to-the-latest-mainline-version-without-any-distro-upgrade

10.0.0.0/24は無効なサブネットであることに注意してください。 10.0.0.0/8(クラスA)ネットワーク内の最初の有効なサブネットは、 /24サブネットマスクでスライスされています... 10.0.1.0/24 。 そのビットマスクのホスト側の上部/下部の場合と同じように、ネットワーク側の上部/下部を破棄する必要があります。 同じ理由で、10.255.255.0 / 24も無効です。

任意のサブネットマスクに対して、 2x -2サブネットと2x -2ホストがあります

...ここで、xはマスクのその側のビット数です。 したがって、 /24 、ネットワーク側で24、ホスト側で8となり、16777214サブネットと254ホストになります。 ビットマスクのネットワーク側での計算の「-2」の部分に注意してください。 つまり、この場合、tcp / ipのトランスポート層にとって何かを意味するため、それらを破棄する必要があります(発行できません)。

これは、 10.x.y.0/24 10.x.y.255/24アドレスと

19.03 DockerSwarmでこれを取得し始めました

このページは役に立ちましたか?
0 / 5 - 0 評価