カッティングボード

カルマをカットしてます

kubernetesのContainer IPの活用法

はじめに

KubernetesのContainer IPはほとんど使うことがないと思います.

再起動するたびに変動するものなので,通常であればCluster IPの方を使いますよね.

Kubernetesのdnsから引けてくるIPはCluster IPなので,Service設定をしてちゃんとKubernetes使ってる人だったらCluster IPを利用していると思います.

Cluster IP

Cluster IPは各コンテナごとに振られたIPではないため,コンテナ等を再起動したとしても変動しないIPです.

まぁ基本的に固定されているIPですし,dnsから引けてくるので利用しやすいIPです.

コンテナのIPではないのにコンテナと通信することができるのはkube-proxyがいい感じにしてくれてるからです.

正直kube-proxyの詳しい挙動については勉強不足な部分が多いのでどうやって通信を繋いでるかとかに関しては詳細は記述しないです.

kubernetes1.9では,Cluster IPからはServiceで公開されているポートにしかアクセスできません.

Container IP

各コンテナに対して振られているIPのことです.

このIPのネットワークはKubernetesで利用しているオーバーレイネットワーク等です.

なので別ノードで展開されているコンテナだったとしても,Container IPでアクセスすることができます.

Container IP経由でアクセスすることで,コンテナ内でポートへのアクセス等を制御していない限りはどのポートに対してもアクセスすることができます.

Serviceで公開していないポートに対してもアクセスすることができるので,動的にポートが変わってしまうサービスだったりした際にはContainer IPを用いることで容易にネットワークの問題を解決できるかもしれないです.

まとめ

Container IPからだったらどのポートに対してもアクセスできる.

まぁ正直裏技的な部分があったり,IPが変わって困ってしまうこととかもあるのでその辺は考慮してください.

Ubuntu16.04でアクセスポイント

はじめに

Ubuntu16.04を用いてアクセスポイント化する方法はいくつか検索すれば出てくるのですが,再起動したりすると設定が消えるのでその辺も踏まえてメモ.

hostapdの設定

hostapdをインストールする hostapdとはユーザー空間で動作するアクセスポイントと認証サーバーである.

sudo apt install hostapd
sudo vim /etc/hostapd/hostapd.conf

hostapdの設定ファイルを作っていく. インターフェイス名とかはiwconfigとかでいい感じに確認する driverはよくわからんけどnl80211で大抵OKらしい.IEEEの規格とかの話なのかな?

#インタフェース名
#iwconfigとかでwifiのインターフェイス名を確認できます.
interface=wlp2s0

#無線LANアダプタのドライバ
driver=nl80211

#クライアントに表示される無線LANアクセス・ポイント(SSID)名 
ssid=SSID
hw_mode=g
channel=7
wpa=2 # WPA2

#認証パスワード 
wpa_passphrase=PASS
wpa_key_mgmt=WPA-PSK
rsn_pairwise=CCMP

hostapd.confをhostapdサービス起動時の設定ファイルとして設定.

sudo vim /etc/default/hostapd

10行目のコメントアウトを外して下に書き換える

DAEMON_CONF="/etc/hostapd/hostapd.conf"

DHCPの設定

isc-dhcp-serverをインストールする

sudo apt install isc-dhcp-server

dhcpdの設定

sudo vim /etc/dhcp/dhcpd.conf

一番下に下記を追加

subnet 192.168.190.0 netmask 255.255.255.0 {
  range 192.168.190.50 192.168.190.100;
  option domain-name-servers 192.168.189.7, 8.8.8.8;
  option domain-name "internal.example.org";
  option routers 192.168.190.1;
  option broadcast-address 192.168.190.255;
  default-lease-time 600;
  max-lease-time 7200;
}

dhcpdのインターフェイスを設定する.

sudo vim /etc/default/isc-dhcp-server

21行目を下記に書き換える.

INTERFACES="wlp2s0";

IPフォワーディングの有効化

sudo sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward"
sudo vim /etc/sysctl.conf

28行目のコメントアウトを外す.

wifiNIC設定

sudo vim /etc/network/interfaces

一番下に下記を追加

auto wlp2s0
iface wlp2s0 inet static
address 192.168.190.1
netmask 255.255.255.0

NetworkManagerの停止

NetworkManagerの停止と,自動起動の無効. これやらなくても大丈夫な気がする.

sudo stop network-manager
echo "manual" | sudo tee /etc/init/network-manager.override

iptablesの設定

sudo iptables -t nat -A POSTROUTING -s 192.168.190.0/255.255.255.0 -o enp3s0 -j MASQUERADE
sudo sh -c "iptables-save > /etc/iptables.ipv4.nat"
sudo vim /etc/network/interfaces

下記のようにpre-upの記述を追加

auto wlp2s0
iface wlp2s0 inet static
pre-up iptables-restore /etc/iptables.ipv4.nat
address 192.168.190.1
netmask 255.255.255.0

参考文献

LinuxPCをWiFiアクセスポイントにする hostapdとは

DockerからホストPCのネットワーク接続に対するメモ

最近ブログ書いてなかったですけど,このままズルズルずっと書かないと習慣が完全にきえうせるので徐々に書き始めたいと思います.

Dockerのファイルシステムのやつは書いてたメモが消え去ったので,気分が乗った時に書きなおします.

はじめに

DockerのコンテナからホストノードのLANに接続できるのかどうかに関して,研究室の人と意見が分かれたので実際に検証してみました.

結果

ホストPCのネットワークに対して普通に接続できます.

なんでできるんや,IPマスカレードでもしてるのか?と思ったらしてました.

↓のIPが172で始まるところの記述の部分がIPマスカレードの設定の部分です.

細かいIPレンジとかに関してはノードによって変わるかもしれないです.

$ sudo iptables --list -t nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
DOCKER     all  --  anywhere             anywhere             ADDRTYPE match dst-type LOCAL

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
DOCKER     all  --  anywhere            !127.0.0.0/8          ADDRTYPE match dst-type LOCAL

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
MASQUERADE  all  --  172.17.0.0/16        anywhere

Chain DOCKER (2 references)
target     prot opt source               destination
RETURN     all  --  anywhere             anywhere

まぁ考えてみると当たり前のことなんですよね.

dockerを立ち上げると,docker0とかいう仮想NICが立ち上がってそのNICをdockerコンテナでは利用してると思います.

なので,IPマスカレード設定がされてなければ外部のネットワークに一切接続できないですよね.

まぁIPマスカレード設定がされてて普通にホストノードから通信が出て行くんだから,ホストノードのLANに対してアクセスできますよね...

GPUの負荷テストをcliツールで行う

はじめに

GPU2枚をフルで使用すると電力が足りなくて落ちてしまうといったように見える現象が起きました,

そこでGPUにフルで負荷をかけるとどうなるか試したかったのですが,cliツールを紹介してる日本語サイトが見つからなかったのでメモ.

Ubuntu 16.04でCPUとGPUの両方に負荷をかける – 電気飴

↑みたいな感じでguiツールとかだったら普通にあるので,gui普通に使ってやる人とかはその辺参考にすればいいと思います.

gpu burn

gnu burnとかいういう名前的にめっちゃ怖いけどいい感じのツールがありました.

ソースコードは↓にあります. 普通にメイクするだけで大丈夫です.

github.com

↓のサイトで使い方とかまとめてくれてます.

Multi-GPU CUDA stress test

基本的にgpuの数だけ,cpuのコアも100%にしてくれてるっぽい感じがします.

使い方

git clone https://github.com/Microway/gpu-burn.git

# cudaの9.1とか◯.0以外のバージョンを使ってる場合は,Makefileの11行目とかを自分の使ってるバージョンに書き換えてください

cd cpu-burn

make

./gpu_burn -d 60

dockerのストレージドライバ(ファイルシステム)を調べる

はじめに

最近,↓のようにdockerのストレージドライバレベルに近い部分を触ったりしてるのに全く理解してないので何日かにわたって調べていきたいと思います.

cut-ter.hatenablog.com

cut-ter.hatenablog.com

ファイルシステムとかめっちゃ詳しいわけじゃないので,間違いとかあるかもしれないです.

dockerコンテナに利用されているファイルシステム

基本的にユニオンマウントという概念を用いたファイルシステムが使われているみたいです.

dockerを触ったことがある人はわかると思いますが,一つのdockerイメージは複数のdockerイメージを組み合わせられていることが多いです.

どのようにしてそれを行っているかというと,一つのマウントポイントに対して垂直に重ね合わせて行っているイメージのようです.

コンテナを実行する際には,イメージの時系列順にリードオンリーで重ね合わせます.その後ライトできる新たなイメージをその上に重ねます.基本的にコンテナ内で作業した内容はライトできる新たなイメージ部分に書き込まれるようです.

ファイルに関しては上の方に存在している情報が優先され,ディレクトリに関しては内容を組み合わせるようになっています.

ストレージデバイスの種類

今現在dockerでは7種類のストレージデバイスがあるみたいです.

  • overlay
  • overlay2
  • aufs
  • brtfs
  • device mapper
  • vfs
  • zfs

今回はここに調べることはしませんが,明日以降調べたりいきたいと思います.

デフォルトで利用されているストレージデバイス

特に意識してなかったのですが,↓の記事の調査してる時にストレージデバイスが判明してました. cut-ter.hatenablog.com

17.09.0-ceではoverlay2が利用されています.

今日のところはこんな感じにします.ストレージデバイスによってはnfsとかも許容できる可能性もあるのでしっかりと調べていきたいと思います.

dockerイメージのバックアップを2重に取る

はじめに

dockerイメージをレジストリとかにpushしてちゃんとバックアップ取ったりしたいですよね.

基本的に自前でレジストリ立てて管理したりとかしてると思います.

私もそうしているのですが,この間レジストリにpushしておいたらpullできなくなって死を迎えました.

そうならないようにレジストリにpushする以外のバックアップも取っておきましょう.

バックアップとるだけじゃなくてバックアップから復元できることを事前に確認しておけって話ですが....

バックアップと復元

↓のコマンドでイメージをtarにまとめることができます.

sudo docker save test >test.tar

↓のコマンドでtarからイメージを読み込むことができます.

sudo docker load < test.tar

バックアップは取ればいいってもんじゃなくて復元できないと意味ないんだよなぁ.

nvidia-dockerでgpuのリソースを制限する

はじめに

nvidia-dockerを何も考えずに複数動かしてしまうと,後から動き始めた方がメモリが足りないよーとかエラー吐いてしまってまともに動きません.

複数同時に並行して動かしたいときはgpuリソースを制限しながらやってあげないとダメみたいなので制限しましょう.

やり方

nvidia-docker

NV_GPU='0,1' nvidia-docker run -it nvidia/cuda nvidia-smi

nvidia-docker2

docker run --runtime=nvidia -e NVIDIA_VISIBLE_DEVICES='0,1' --rm nvidia/cuda nvidia-smi

↑みたいな感じにすると,コンテナからは指定されたデバイスidの物しか見えなくなるみたいです.

nvidia-docker2の変更点的なのは↓のサイトみたいな感じでまとめてくれてる人がいました.

aetros.com

雑談

今日作業してたら突如としてネットワークに繋がらなくなって焦りました.

原因としてはDHCPサーバーが死んでたのが原因だったのですが,LANケーブルかハブが調子悪いのかなぁとか調べてたら結構時間かかってしまいました.

固定ip取得してるやつだけ生き残ってるっぽかったので最終的にDHCPだとわかりましたが,1年前だったら絶対に気付けなかったので少しづつは成長できてるのかなー.