とんちゃんといっしょ

Cloudに関する技術とか日常とかについて書いたり書かなかったり

IIJのDNSフィルタリング?

週末に我が家のネットがおかしくなったので子どもたちからYoutubeが見られないと大層クレームを受け、 私もSlackに繋がらなくなり、Amazon Eco dotも反応しなくなり、何だこれと思いルータやONUの再起動をしても今ひとつなんともならず。

月曜日に帰宅後設定を見ても特に変更がないので障害かと思い調べてみても特に障害情報が上がっておらず困ってTwitterでつぶやいたところ

DNSフィルタリングなんて始めてるのな・・・

そんなわけでDNSフィルタリングされてないDNSを設定したところ

ひとまずこれで子供に怒られなくて済むようにはなったものの、一応切り分けをしてみた。

フィルタリングされたDNSの場合

slack.comへのアクセス

dig は通る。

% dig slack.com

; <<>> DiG 9.10.6 <<>> slack.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 705
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;slack.com.            IN    A

;; ANSWER SECTION:
slack.com.        20    IN    A    99.84.134.165

;; AUTHORITY SECTION:
slack.com.        97990    IN    NS    ns-166.awsdns-20.com.
slack.com.        97990    IN    NS    ns-1901.awsdns-45.co.uk.
slack.com.        97990    IN    NS    ns-606.awsdns-11.net.
slack.com.        97990    IN    NS    ns-1493.awsdns-58.org.

;; Query time: 4 msec
;; SERVER: 2404:1a8:7f01:b::3#53(2404:1a8:7f01:b::3)
;; WHEN: Tue Jul 02 21:26:08 JST 2019
;; MSG SIZE  rcvd: 191

tracerouteは通らない

% traceroute slack.com
traceroute to slack.com (99.84.134.165), 64 hops max, 52 byte packets
 1  192.168.1.1 (192.168.1.1)  2.305 ms  1.443 ms  1.207 ms
 2  chiba01-z03.flets.2iij.net (160.13.161.x)  3.436 ms  4.215 ms  4.982 ms
 3  chiba1-ntteast1.flets.2iij.net (160.13.161.25)  5.739 ms  7.775 ms  9.502 ms
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  *^C

twitter.comへのアクセス

なぜかTwitterも通らなくなる

% traceroute twitter.com
traceroute: Warning: twitter.com has multiple addresses; using 104.244.42.1
traceroute to twitter.com (104.244.42.1), 64 hops max, 52 byte packets
 1  192.168.1.1 (192.168.1.1)  3.188 ms  2.069 ms  1.245 ms
 2  chiba01-z03.flets.2iij.net (160.13.161.x)  10.634 ms  12.700 ms  16.098 ms
 3  chiba1-ntteast1.flets.2iij.net (160.13.161.25)  21.534 ms  20.587 ms  13.338 ms
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
^C

でもdigは反応あり

% dig twitter.com

; <<>> DiG 9.10.6 <<>> twitter.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15264
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 10, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;twitter.com.            IN    A

;; ANSWER SECTION:
twitter.com.        243    IN    A    104.244.42.65
twitter.com.        243    IN    A    104.244.42.1

;; AUTHORITY SECTION:
twitter.com.        4935    IN    NS    ns3.p34.dynect.net.
twitter.com.        4935    IN    NS    ns2.p34.dynect.net.
twitter.com.        4935    IN    NS    d01-02.ns.twtrdns.net.
twitter.com.        4935    IN    NS    c.r06.twtrdns.net.
twitter.com.        4935    IN    NS    ns4.p34.dynect.net.
twitter.com.        4935    IN    NS    d01-01.ns.twtrdns.net.
twitter.com.        4935    IN    NS    a.r06.twtrdns.net.
twitter.com.        4935    IN    NS    ns1.p34.dynect.net.
twitter.com.        4935    IN    NS    b.r06.twtrdns.net.
twitter.com.        4935    IN    NS    d.r06.twtrdns.net.

;; Query time: 5 msec
;; SERVER: 2404:1a8:7f01:b::3#53(2404:1a8:7f01:b::3)
;; WHEN: Tue Jul 02 21:27:09 JST 2019
;; MSG SIZE  rcvd: 279

google.comへのアクセス

googleは通る

% traceroute www.google.com
traceroute to www.google.com (172.217.26.4), 64 hops max, 52 byte packets
 1  192.168.1.1 (192.168.1.1)  2.922 ms  1.291 ms  1.186 ms
 2  chiba01-z03.flets.2iij.net (160.13.161.x)  3.250 ms  3.576 ms  3.562 ms
 3  chiba1-ntteast0.flets.2iij.net (160.13.161.21)  4.318 ms  6.603 ms  5.416 ms
 4  tky008lip30.iij.net (202.214.41.93)  5.959 ms  8.551 ms  8.190 ms
 5  tky008bb00.iij.net (210.130.142.89)  9.827 ms  12.476 ms  13.610 ms
 6  tky001bb10.iij.net (58.138.88.1)  13.059 ms  14.238 ms  12.825 ms
 7  tky001ix04.iij.net (58.138.100.62)  12.169 ms
    tky001ix02.iij.net (58.138.100.54)  12.029 ms  9.808 ms
 8  72.14.242.38 (72.14.242.38)  8.725 ms
    202.232.1.86 (202.232.1.86)  7.361 ms
    72.14.242.38 (72.14.242.38)  5.072 ms
 9  * * *
10  72.14.233.220 (72.14.233.220)  10.889 ms
    nrt20s02-in-f4.1e100.net (172.217.26.4)  8.486 ms
    108.170.242.161 (108.170.242.161)  12.765 ms

digもとおる

% dig www.google.com

; <<>> DiG 9.10.6 <<>> www.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44530
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.google.com.            IN    A

;; ANSWER SECTION:
www.google.com.        260    IN    A    172.217.161.68

;; Query time: 4 msec
;; SERVER: 2404:1a8:7f01:b::3#53(2404:1a8:7f01:b::3)
;; WHEN: Tue Jul 02 21:29:31 JST 2019
;; MSG SIZE  rcvd: 59

フィルタリングされていないDNSの場合

slack.comへのアクセス

% traceroute slack.com
traceroute to slack.com (99.84.134.165), 64 hops max, 52 byte packets
 1  192.168.1.1 (192.168.1.1)  13.403 ms  10.315 ms  7.211 ms
 2  chiba01-z03.flets.2iij.net (160.13.161.x)  48.603 ms  39.201 ms  38.889 ms
 3  chiba1-ntteast0.flets.2iij.net (160.13.161.21)  41.529 ms  50.059 ms  41.740 ms
 4  tky008lip30.iij.net (202.214.41.93)  39.944 ms  48.148 ms  50.577 ms
 5  tky008bb00.iij.net (210.130.142.89)  52.023 ms  42.148 ms  62.208 ms
 6  tky001bb10.iij.net (58.138.88.1)  51.263 ms  55.101 ms  61.491 ms
 7  tky001ix15.iij.net (58.138.102.210)  57.440 ms  42.014 ms
    tky001ix11.iij.net (58.138.102.202)  35.866 ms
 8  210.173.176.188 (210.173.176.188)  37.971 ms  42.719 ms  38.336 ms
 9  52.95.30.171 (52.95.30.171)  52.017 ms
    52.95.30.183 (52.95.30.183)  56.138 ms
    52.95.30.169 (52.95.30.169)  41.881 ms
10  52.95.30.18 (52.95.30.18)  71.838 ms
    52.95.30.54 (52.95.30.54)  60.939 ms
    52.95.30.58 (52.95.30.58)  38.320 ms
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  server-99-84-134-165.nrt57.r.cloudfront.net (99.84.134.165)  30.975 ms  45.644 ms  30.776 ms

twitter.comへのアクセス

% traceroute twitter.com
traceroute: Warning: twitter.com has multiple addresses; using 104.244.42.1
traceroute to twitter.com (104.244.42.1), 64 hops max, 52 byte packets
 1  192.168.1.1 (192.168.1.1)  150.819 ms  88.796 ms  8.696 ms
 2  chiba01-z03.flets.2iij.net (160.13.161.x)  36.320 ms  39.820 ms  95.059 ms
 3  * chiba1-ntteast1.flets.2iij.net (160.13.161.25)  40.946 ms  47.746 ms
 4  tky008lip31.iij.net (202.214.41.97)  53.321 ms  57.417 ms  61.216 ms
 5  tky008bb01.iij.net (210.130.142.93)  50.467 ms  35.077 ms  27.107 ms
 6  tky001bb11.iij.net (58.138.88.5)  31.195 ms  42.001 ms  38.530 ms
 7  tky001ix15.iij.net (58.138.102.214)  37.889 ms  39.328 ms
    tky001ix11.iij.net (58.138.102.206)  40.044 ms
 8  210.173.176.152 (210.173.176.152)  29.130 ms  31.093 ms  27.638 ms
 9  * * *
10  104.244.42.1 (104.244.42.1)  31.713 ms  298.895 ms  180.441 ms

よくわからん。。。

一応公式には

宛先がレピュテーションデータに含まれている場合、IIJが別途用意するサーバのIPアドレスに宛先を置き換えることで、本来の宛先へアクセスしないようにします。

と書かれているので本来の宛先へアクセスはしてないわけであるが、Twitterを見ても私のように困ってる人もいないのでますます謎は深まる・・・

私はNWは全然強くないので会社の強い人に聞いてみると、どこかでルーティングが書き換えられてるか、単純に機器故障じゃないかといわれた。

何にせよ再び我が家に自由なインターネットが戻ってきたのでこんなもんにしておく。

やっぱりネットワーク良くわからん。。。。

frigga にみるNetflixのクラスタ命名規則とChaos Monkeyがkubernetes provider v2でうまく動かない理由

タイトルが長いけど簡単に言うと、Chaos Monkeyはk8s対応を謳ってますが k8s provider v2(Manifest)で Deployment などを使うと動かないことがあります。

github.com

Chaos Monkey should work with any backend that Spinnaker supports (AWS, Google Compute Engine, Azure, Kubernetes, Cloud Foundry). It has been tested with AWS, GCE, and Kubernetes.

理由はNetflixクラスタ命名規則に従っていないから。

以下、解説

frigga

friggaはNetflixから公開されているOSSです。

github.com

Utilities for working with Asgard named objects

friggaはAsgardで扱うオブジェクトの名前管理(バリデーションなど)をするライブラリらしいです。

AsgardはSpinnakerの前身であり、AWSのアプリケーションデプロイと管理をするWebコンソールでしたが、今はマルチクラウドでCI/CDを実現するSpinnakerに移行したようです。

github.com

Spinnakerでクラスタをデプロイしたことがある人はわかるかもしれませんが、SpinnakerではApplicaation Name, Stack, Detailで appName-stack-detail という名前をつけて各クラスタを把握していますが、以下のコードを見ると実はこれをfriggaが生成/管理していることがわかります。

Chaos Monkey

Chaos MonkeyもNetflixから公開されているOSSです。

Chaos MonkeyはNetflixがChaos Engineeringを行うためのツールとして代表的なものです。

ここでポイントなのはChaos MonkeyはNetflixが開発しており、Chaos Monkeyにおいてもfriggaがライブラリとして使われているということです。

そしてChaos Monkey v2と呼ばれるバージョンからはChaos Monkeyの動作はSpinnakerと連携するようになっています。 Chaos MonkeyはSpinnakerからクラスタインスタンスの名前を取得した上で対象となるインスタンスやPodを落とすようになっています。

Spinnaker

次にSpinnakerですが、上記でも述べたようにSpinnakerはAsgardの後継としてAWSだけではなくマルチクラウドでCI/CDを実現するOSSです。

www.spinnaker.io

対象とするクラウドAWSGCPなど以外にもOpenStackやKubernetesなども含まれており、こうしたクラウド環境に対してChaos Monkeyと連携しChaos Engineeringを実現することが可能となっています。

・・・というのがREADMEなどに書かれている内容なんですが、実はKubernetes provider v2においてdeploymentなどを使うとChaos Monkeyが動きません。

原因は以下のSpinnakerドキュメントに書いてあるとおりです。

Kubernetes Provider V2 (Manifest Based) - Spinnaker

You can deploy existing manifests without rewriting them to adhere to Frigga. Resource relationships (for example between applications and clusters) are managed using Kubernetes annotations, and Spinnaker manages these using its Moniker library.

ApplicationやClusterをKubernetesアノテーションやSpinnakerのMonikerというライブラリで管理するので、friggaに準拠しなくても良いようにしたとのことですが、これが原因でKubernetes provider v2においてはChaos Monkeyがfriggaの命名規則に合致しない deployment appName-stack-detail などという名前が出来上がった結果、friggaが管理する命名規則と合致せずエラーを起こしChaos Monkeyが動かないケースが有るという状態になっております。

一応こちらのIssueに上がっており、Slackでもお話はしてコミュニティには伝えたもののまだ対応はされてない模様。

github.com

Serge Poueme [3 months ago] Hi @mahito seems to be that yes. I just had a call with Ben, Ethan and Isaac ( Spinnaker office hours ) and they mentioned the mismatch between the v2 provider responses and chaosmonkey. A workaround would be to use replicasets instead of deployments. I will see if I can try that on our current dev project with minimal impact on the overall service definition.

今の所Chaos Monkeyの対象を Deployment にすると動かないので ReplicaSetを使うのが回避策らしい。

リュック選び

そろそろ今使っているリュックがダメになってきたので新しいリュックを探している。

仲間内のSlackで聞いてみると以下の6つが候補に。

[ドイター] deuter グラント D80604 7000 (ブラック)

[ドイター] deuter グラント D80604 7000 (ブラック)

[ミレスト] バックパック LAGOPUS PC収納可 MLS238-NV ネイビー

[ミレスト] バックパック LAGOPUS PC収納可 MLS238-NV ネイビー

GW明けをめどにポチる予定。

v2 Managed Pipeline Template

Spinnaker v1.12.0 からManaged Pipeline Template v2 というのがでてきたらしい。

www.spinnaker.io

This release adds alpha API and spin CLI support for MPT v2. See the blog post for more information.

詳しくは以下のBlogを見ろということらしい。

blog.spinnaker.io

ブログを読んでみると多分こういうことらしい(英語力不足)

MPT v2でできること

  • テンプレートの作成と編集の改善としてSpinnakerから取得したPipelineのJSONをそのままテンプレートの定義として使える。
  • spinからの MPT v2利用
  • テンプレートの標準化としてSpring Expression Language(SpEL)を、パイプラインとテンプレート用の単一の共有式言語として利用。
  • テンプレートの多重継承のサポートを辞めることで、サーバーサイドのMPTバックエンドを簡素化

今後何ができるか

  • v2 Pipeline Templateに対してFiatによる権限管理によりSpinnakerの管理者はどのユーザがPipeline Templateの作成、編集、読み込みコントロールできるように。
  • Sponnetライブラリが複数ソース、サポートされているモジュール、継承などから構成されるpipeline templateの構成をサポートすることで、MPT v1の頃よりMPTのバックエンドが大幅に簡素化される。
  • UIサポートの改善し、指定されたパイプラインのインスタンスがどのテンプレートを元にしたのか、どの変数値を指定されたのかなどを可視化が簡単に。

その他

sponnet library の変更の方を見てみたが、以前より大きい違いはmetadataとvariablesで、特に前者のmetadataのなかでscopeが設定できるようなので、ここがFiatと連携をして権限管理をしてくれるのかなと思う。

github.com

Amazon Prime会員の値上げにも気にならないお得なAmazon Mastercardゴールドの作り方

最近 Amazon Primeが年会費を1000円あげるというのが話題になったが、私もAmazon Prime会員なので以下のお便りが来た。

Amazon プライム会員の皆様

平素よりAmazonプライムをご利用いただきありがとうございます。Amazonプライムの会費変更に関するお知らせです。

Amazonプライムは2007年に配送特典のみで開始し、以降11年間、同価格でより多くの特典を追加してまいりました。配送特典対象商品は現在では数百万点に増え、プライム会員はその対象商品の配送を追加料金なしで無制限にお使いいただけます。さらに、Prime Videoの会員特典対象コンテンツへのアクセスや、Prime Music、Prime Reading、プライム・ワードローブ、世界各国で同時開催されているプライムデーなど増え続ける多様な特典の多くをご利用いただけます。プライム会員の皆様の生活を便利で豊かにするため、努めてまいります。

この度2019年4月12日付でAmazonプライムの年会費を3,900円(税込)から4,900円(税込)に変更する事となりました。

お客様がご登録されている年会費のお支払いプランにて会員登録の更新をされる場合は、2019年5月17日以降の会員登録更新時に新しい会費への変更が適用されます。

プライム会費の変更に伴う追加の手続きは必要ありません。会員登録は「アカウントサービス」でいつでも変更いただけます。

引き続きAmazonプライムをお楽しみください。

Amazon プライム

値上げがあるけどまだやめるような値段でもないので継続はしようと思っていたのだが、ちょうどクレジットカードを今の手持ちから変えようと思っていたところのAmazonプライム会員の値上げである。いろいろ調べているとどうも Amazon Mastercardゴールドがお得そうだということがわかった。

Amazon Mastercardゴールドは年会費10,800円が毎年必要なものの、プライム会員の会費が不要らしくこれだけで4,900円が浮く。 また2年目以降は年会費が最大6,480円割引のため実質無料でAmazonゴールドカードが持てることになる。

ご利用状況により、2年目以降から年会費が最大6,480円割引(税込み)割引 ・「マイ・ペイすリボ」でおトク ゴールドカードの方で「マイ・ペイすリボ」にご登録の方は、年に1回以上カードをご利用になれば、2年目以降から年会費が半額の「5,400円(税込み)」割引となります。

・「WEB明細書サービス」でおトク さらに「カードご利用代金WEB明細書サービス」のご利用で2年目以降年会費が「1,080円(税込み)」割引となります。 よって、最大税込み6,480円の割引となりますので是非ご利用ください。

よし、ではAmazon Mastercardゴールドを申し込もうと思ったところ、 どうも以下のようにAmazon Mastercardクラシックから申し込んだほうが良いとわかったのでまとめておく。

クラシック ⇒ ゴールド 最適オペレーション

クラシック ⇒ ゴールド 最適オペレーション

上記のユーザコメントでは以下のような手順が最適だと言っている

  1. Amazonにログインする
  2. AmazonMasterCardのリンクからAmazon Mastercardクラシックを選択する
  3. 5000ポイント獲得の文言があるのを確認したうえで申し込みをする(※Myペイすリボを申し込む(重要))
  4. クラシックカードが届くまで首を長くしてまつ
  5. 届いたらまずvPassを登録する
  6. そのままWeb明細を申込する
  7. Myペイすリボの月の支払額をカードの限度額に設定する
  8. Amazon Mastercardゴールドへの切り替えを申し込む
  9. ゴールドカードが届くまで首を長くしてまつ
  10. ゴールドカードが届いたらまずvPassに追加する
  11. Myペイすリボの月の支払額をゴールドカードの限度額に設定する
  12. Amazonアカウントの支払用クレジットカードにゴールドカードを登録
  13. Amazonの支払用カードからテンポラリーカードとクラシックカードを削除する

いきなりゴールドカードに申し込むとAmazonポイント5000ポイントが貰えないらしく、 クラシックカードを申し込み5000ポイントを得てからゴールドカードにしたほうがお得という流れらしい。

しかし、知人の情報によると7月のプライムデーは毎年ゴールドガード申込でキャッシュバックのキャンペーンがあるらしく、

「8. Amazon Mastercardゴールドへの切り替えを申し込む」の部分を

8. 7月のプライムデー Amazon Mastercardゴールドへの切り替えを申し込む」

とすることでよりお得にAmazonゴールドカードを手に入れられるらしい。

そんなわけで早速Amazon Mastercardクラシックを申し込んだので受け取り待ちのため、 次は7月のプライムデーを逃さず切り替えをしていく予定。

pumbaを調べてみた

前回 に続きChaos Engineering系の調べ物

今回は pumba について調べてみた。

github.com

Chaos testing and network emulation tool for Docker

pumba はDocker向けのChaos testingとネットワークエミュレーションを行うツールらしい。

できること

コンテナ単位で

  • コンテナを壊す(kill/rm)
    • killの場合signalの指定が可能
  • コンテナを止める(pause/stop)
    • pauseの場合止める時間を指定可能
  • NWのエミュレーション
    • 遅延
    • パケットロス
      • パケットロスの方式に異なる3つがある模様(loss, loss-state, loss-gemodel)
    • トラフィックへのレートリミット
    • パケットの重複
    • パケットの破損
  • 対象とするコンテナの指定(名前, 正規表現マッチ)

できないこと

  • namespace単位での設定やブラックリスト登録
    • 気をつけないと kube-system 配下のコンテナが殺されたり遅延する
  • 動作のスケジューリング
    • chaosmonkeyやkube-monkeyと違って1回だけの動作もしくは一定間隔で動作を続ける
    • intervalなどで動作間隔の調整は可能

動作

コマンドラインから定期的/単発にランダム/特定のコンテナの

  • 破壊/停止を行う
  • NW障害をエミュレーションする

動かし方

注:manifestは全部Spinnakerから放り込んだのでSpinnakerがなければ kubectl で作成してください。

namespaceの作成

一応作っておく

$ kubectl create namespace pumba
namespace/pumba created

nginxのデプロイ

apiVersion: apps/v1
kind: Deployment
metadata:
  name: pumba-nginx
  namespace: pumba
  labels:
    app: pumba-nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: pumba-nginx
  template:
    metadata:
      labels:
        app: pumba-nginx
    spec:
      containers:
        - image: nginx
          name: nginx
          ports:
            - containerPort: 80

nginx(service)のデプロイ

apiVersion: v1
kind: Service
metadata:
  labels:
    app: pumba-nginx
  name: pumba-nginx
  namespace: pumba
spec:
  ports:
    - port: 80
      protocol: TCP
  selector:
    app: pumba-nginx

pumbaのデプロイ

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: pumba
  namespace: pumba
spec:
  selector:
    matchLabels:
      app: pumba
  template:
    metadata:
      labels:
        app: pumba
        com.gaiaadm.pumba: "true" # prevent pumba from killing itself
      name: pumba
    spec:
      containers:
      - image: gaiaadm/pumba:master
        imagePullPolicy: Always
        name: pumba
        # Pumba command: modify it to suite your needs
        # Currently: randomly try to kill some container every 3 minutes
        args:
          - --random
          - --interval
          - "3m"
          - kill
          - --signal
          - "SIGKILL"
          - re2:pumba-nginx
        resources:
          requests:
            cpu: 10m
            memory: 5M
          limits:
            cpu: 100m
            memory: 20M
        volumeMounts:
          - name: dockersocket
            mountPath: /var/run/docker.sock
      volumes:
        - hostPath:
            path: /var/run/docker.sock
          name: dockersocket

動作確認(kill)

$ kubectl get pods -n pumb
NAME                           READY   STATUS             RESTARTS   AGE
pumba-d92ms                    1/1     Running            0          3h
pumba-m56gr                    1/1     Running            0          3h
pumba-m7szx                    1/1     Running            0          3h
pumba-nginx-78cbbc666d-lczjr   0/1     CrashLoopBackOff   37         1d
pumba-nginx-78cbbc666d-lfglj   1/1     Running            34         1d
pumba-nginx-78cbbc666d-nb2t5   0/1     CrashLoopBackOff   47         1d

RESTARTSが増えていくのが確認できた

alpine(ping)のデプロイ

apiVersion: apps/v1
kind: Deployment
metadata:
  name: pumba-ping
  namespace: pumba
  labels:
    app: pumba-ping
spec:
  replicas: 1
  selector:
    matchLabels:
      app: pumba-ping
  template:
    metadata:
      labels:
        app: pumba-ping
    spec:
      containers:
        - image: alpine
          name: pumba-ping
          command: ["/bin/ping"]
          args: 
            - "10.0.3.182" # 適当なPodのIPを指定

pumba(delay)のデプロイ

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: pumba-delay
  namespace: pumba
spec:
  selector:
    matchLabels:
      app: pumba-delay
  template:
    metadata:
      labels:
        app: pumba-delay
        com.gaiaadm.pumba: "true" # prevent pumba from killing itself
      name: pumba-delay
    spec:
      containers:
      - image: gaiaadm/pumba:master
        imagePullPolicy: Always
        name: pumba-delay
        # Pumba command: modify it to suite your needs
        # Currently: randomly try to kill some container every 3 minutes
        args:
          - --random
          - --interval
          - "1m"
          - netem
          - --tc-image
          - "gaiadocker/iproute2"
          - --duration
          - "20s"
          - delay
          - re2:pumba-ping
        volumeMounts:
          - name: dockersocket
            mountPath: /var/run/docker.sock
      volumes:
        - hostPath:
            path: /var/run/docker.sock
          name: dockersocket

実行結果(delay)

64 bytes from 8.8.8.8: seq=1864 ttl=121 time=94.832 ms
64 bytes from 8.8.8.8: seq=1865 ttl=121 time=93.230 ms
64 bytes from 8.8.8.8: seq=1866 ttl=121 time=94.726 ms
64 bytes from 8.8.8.8: seq=1867 ttl=121 time=96.826 ms
64 bytes from 8.8.8.8: seq=1868 ttl=121 time=109.091 ms
64 bytes from 8.8.8.8: seq=1869 ttl=121 time=100.854 ms
64 bytes from 8.8.8.8: seq=1870 ttl=121 time=97.063 ms
64 bytes from 8.8.8.8: seq=1871 ttl=121 time=109.645 ms
64 bytes from 8.8.8.8: seq=1872 ttl=121 time=107.117 ms
64 bytes from 8.8.8.8: seq=1873 ttl=121 time=101.009 ms
64 bytes from 8.8.8.8: seq=1874 ttl=121 time=103.168 ms
64 bytes from 8.8.8.8: seq=1875 ttl=121 time=98.855 ms
64 bytes from 8.8.8.8: seq=1876 ttl=121 time=97.942 ms
64 bytes from 8.8.8.8: seq=1877 ttl=121 time=97.129 ms
64 bytes from 8.8.8.8: seq=1878 ttl=121 time=108.756 ms
64 bytes from 8.8.8.8: seq=1879 ttl=121 time=95.386 ms
64 bytes from 8.8.8.8: seq=1880 ttl=121 time=104.386 ms
64 bytes from 8.8.8.8: seq=1881 ttl=121 time=95.275 ms
64 bytes from 8.8.8.8: seq=1882 ttl=121 time=110.080 ms
64 bytes from 8.8.8.8: seq=1883 ttl=121 time=94.726 ms
64 bytes from 8.8.8.8: seq=1884 ttl=121 time=96.021 ms
64 bytes from 8.8.8.8: seq=1885 ttl=121 time=97.216 ms
64 bytes from 8.8.8.8: seq=1886 ttl=121 time=100.285 ms
64 bytes from 8.8.8.8: seq=1887 ttl=121 time=0.598 ms
64 bytes from 8.8.8.8: seq=1888 ttl=121 time=0.545 ms
64 bytes from 8.8.8.8: seq=1889 ttl=121 time=0.555 ms
64 bytes from 8.8.8.8: seq=1890 ttl=121 time=0.598 ms
64 bytes from 8.8.8.8: seq=1891 ttl=121 time=1.746 ms
64 bytes from 8.8.8.8: seq=1892 ttl=121 time=1.066 ms
64 bytes from 8.8.8.8: seq=1893 ttl=121 time=1.235 ms
64 bytes from 8.8.8.8: seq=1894 ttl=121 time=0.581 ms

20秒遅延が発生しているのが確認できた

pumba(loss)のデプロイ

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: pumba-loss
  namespace: pumba
spec:
  selector:
    matchLabels:
      app: pumba-loss
  template:
    metadata:
      labels:
        app: pumba-loss
        com.gaiaadm.pumba: "true" # prevent pumba from killing itself
      name: pumba-loss
    spec:
      containers:
      - image: gaiaadm/pumba:master
        imagePullPolicy: Always
        name: pumba-loss
        # Pumba command: modify it to suite your needs
        # Currently: randomly try to kill some container every 3 minutes
        args:
          - --random
          - --interval
          - "1m"
          - netem
          - --tc-image
          - "gaiadocker/iproute2"
          - --duration
          - "20s"
          - loss
          - --percent
          - "100"
          - re2:pumba-ping
        volumeMounts:
          - name: dockersocket
            mountPath: /var/run/docker.sock
      volumes:
        - hostPath:
            path: /var/run/docker.sock
          name: dockersocket

結果(loss)

64 bytes from 8.8.8.8: seq=809 ttl=121 time=0.490 ms
64 bytes from 8.8.8.8: seq=810 ttl=121 time=0.587 ms
64 bytes from 8.8.8.8: seq=811 ttl=121 time=0.509 ms
64 bytes from 8.8.8.8: seq=832 ttl=121 time=1.199 ms
64 bytes from 8.8.8.8: seq=833 ttl=121 time=0.535 ms
64 bytes from 8.8.8.8: seq=834 ttl=121 time=0.717 ms
64 bytes from 8.8.8.8: seq=835 ttl=121 time=0.552 ms
64 bytes from 8.8.8.8: seq=836 ttl=121 time=0.530 ms
64 bytes from 8.8.8.8: seq=837 ttl=121 time=0.470 ms
64 bytes from 8.8.8.8: seq=838 ttl=121 time=0.481 ms
64 bytes from 8.8.8.8: seq=839 ttl=121 time=0.466 ms
64 bytes from 8.8.8.8: seq=840 ttl=121 time=0.504 ms

seq=811から832まで20s消えているのが確認できた

pumba(rate)のデプロイ

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: pumba-rate
  namespace: pumba
spec:
  selector:
    matchLabels:
      app: pumba-rate
  template:
    metadata:
      labels:
        app: pumba-rate
        com.gaiaadm.pumba: "true" # prevent pumba from killing itself
      name: pumba-rate
    spec:
      containers:
      - image: gaiaadm/pumba:master
        imagePullPolicy: Always
        name: pumba-rate
        # Pumba command: modify it to suite your needs
        # Currently: randomly try to kill some container every 3 minutes
        args:
          - --random
          - --interval
          - "1m"
          - netem
          - --tc-image
          - "gaiadocker/iproute2"
          - --duration
          - "20s"
          - rate
          - --rate
          - "100kbit"
          - re2:pumba-ping
        volumeMounts:
          - name: dockersocket
            mountPath: /var/run/docker.sock
      volumes:
        - hostPath:
            path: /var/run/docker.sock
          name: dockersocket

実行結果(rate)

64 bytes from 8.8.8.8: seq=1163 ttl=121 time=1.178 ms
64 bytes from 8.8.8.8: seq=1164 ttl=121 time=9.096 ms
64 bytes from 8.8.8.8: seq=1165 ttl=121 time=8.444 ms
64 bytes from 8.8.8.8: seq=1166 ttl=121 time=8.358 ms
64 bytes from 8.8.8.8: seq=1167 ttl=121 time=8.377 ms
64 bytes from 8.8.8.8: seq=1168 ttl=121 time=8.477 ms
64 bytes from 8.8.8.8: seq=1169 ttl=121 time=8.507 ms
64 bytes from 8.8.8.8: seq=1170 ttl=121 time=8.390 ms
64 bytes from 8.8.8.8: seq=1171 ttl=121 time=8.377 ms
64 bytes from 8.8.8.8: seq=1172 ttl=121 time=8.396 ms
64 bytes from 8.8.8.8: seq=1173 ttl=121 time=8.590 ms
64 bytes from 8.8.8.8: seq=1174 ttl=121 time=8.429 ms
64 bytes from 8.8.8.8: seq=1175 ttl=121 time=8.570 ms
64 bytes from 8.8.8.8: seq=1176 ttl=121 time=8.303 ms
64 bytes from 8.8.8.8: seq=1177 ttl=121 time=9.068 ms
64 bytes from 8.8.8.8: seq=1178 ttl=121 time=8.332 ms
64 bytes from 8.8.8.8: seq=1179 ttl=121 time=8.336 ms
64 bytes from 8.8.8.8: seq=1180 ttl=121 time=8.512 ms
64 bytes from 8.8.8.8: seq=1181 ttl=121 time=8.393 ms
64 bytes from 8.8.8.8: seq=1182 ttl=121 time=9.980 ms
64 bytes from 8.8.8.8: seq=1183 ttl=121 time=9.001 ms
64 bytes from 8.8.8.8: seq=1184 ttl=121 time=0.991 ms
64 bytes from 8.8.8.8: seq=1185 ttl=121 time=0.758 ms
64 bytes from 8.8.8.8: seq=1186 ttl=121 time=3.291 ms
64 bytes from 8.8.8.8: seq=1187 ttl=121 time=1.169 ms
64 bytes from 8.8.8.8: seq=1188 ttl=121 time=0.613 ms
64 bytes from 8.8.8.8: seq=1189 ttl=121 time=0.597 ms
64 bytes from 8.8.8.8: seq=1190 ttl=121 time=0.772 ms

seq=1165から20sほど遅延しているのが確認できた

pumba(corrupt)のデプロイ

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: pumba-corrupt
  namespace: pumba
spec:
  selector:
    matchLabels:
      app: pumba-corrupt
  template:
    metadata:
      labels:
        app: pumba-corrupt
        com.gaiaadm.pumba: "true" # prevent pumba from killing itself
      name: pumba-corrupt
    spec:
      containers:
      - image: gaiaadm/pumba:master
        imagePullPolicy: Always
        name: pumba-corrupt
        # Pumba command: modify it to suite your needs
        # Currently: randomly try to kill some container every 3 minutes
        args:
          - --random
          - --interval
          - "1m"
          - netem
          - --tc-image
          - "gaiadocker/iproute2"
          - --duration
          - "20s"
          - corrupt
          - --percent
          - "100"
          - re2:pumba-ping
        volumeMounts:
          - name: dockersocket
            mountPath: /var/run/docker.sock
      volumes:
        - hostPath:
            path: /var/run/docker.sock
          name: dockersocket

実行結果(corrupt)

64 bytes from 10.0.3.182: seq=333 ttl=62 time=0.540 ms
64 bytes from 10.0.3.182: seq=334 ttl=62 time=0.372 ms
64 bytes from 10.0.3.182: seq=335 ttl=62 time=0.272 ms
64 bytes from 10.0.3.182: seq=336 ttl=62 time=0.300 ms
64 bytes from 10.0.3.182: seq=337 ttl=62 time=6.558 ms
64 bytes from 10.0.3.182: seq=357 ttl=62 time=1.927 ms
64 bytes from 10.0.3.182: seq=358 ttl=62 time=0.221 ms
64 bytes from 10.0.3.182: seq=359 ttl=62 time=0.360 ms
64 bytes from 10.0.3.182: seq=360 ttl=62 time=0.376 ms
64 bytes from 10.0.3.182: seq=361 ttl=62 time=0.238 ms
64 bytes from 10.0.3.182: seq=362 ttl=62 time=1.223 ms
64 bytes from 10.0.3.182: seq=363 ttl=62 time=0.519 ms

seq=337から357まで20seq応答がなくなっているのがわかる

除外

  • duplicate: pingだと意味なさそうなので今回はパス
  • loss-state: lossと同じっぽいので今回はパス
  • loss-gemodel: 同上

小ネタ

  • kube-monkeyと違ってコンテナを落とすのでPodからはErrorとして扱われるのでRestartsのカウントが増えていく
  • /var/run/docker.sock はCRIソケットという訳でもなくdockerクライアント向けのソケットなのでdocker依存かも?
  • pumbaのchaos test対象コンテナにtcがないとエラーになる(その場合対象コンテナに iproute2 を入れるか --tc-image gaiadocker/iproute2 が必要)
  • gaiaadm/pumba:master タグ以外で動くかどうか怪しい・・・

最近の寝かせつけ

ちょっと前まで寝かせつけではベッドの上で同じ本を何度も読まされ大変だった。

でも最近の寝かせつけはもっぱらこれに頼っている。

ディズニー ピクサーキャラクターズ Dream Switch(ドリーム スイッチ)

商品紹介には

親子の眠る前が楽しくなる、寝室の天井にディズニーのお話を投影する絵本プロジェクター。
50種のコンテンツからお話を選択し、10分程度のお話が始まり、お話が終るとオートオフで消えます。
天井に映し出させるディズニーのお話が夢の世界へ誘います!

<コンテンツ 50種>
毎日使える! 長く使える! ボリュームの50種! !
・【えほん 30種】講談社のディズニーゴールド絵本から厳選された30作品 (日本語字幕の有無が選択できるため、声で読み聞かせすることもできます。)
・【ことば 11種】ABCやあいうえお、生活習慣が学べる、ことばに関するコンテンツ
・【おたのしみ 9種】ディズニーの星空やひつじかぞえなどのエンターテイメントコンテンツ

とあるように5分〜10分程度のディズニーコンテンツが入っているので天井に映しながら寝かせつけを行っている。

いいところ

  • 天井に映すと子供がベッドに寝っ転がってくれる
  • 日本語/英語モードがある
  • いろいろな話がある
  • オートオフの機能がある
  • 本と違って自分が読まなくてもいい(これ大事)

わるいところ

  • 1歳児には今ひとつ効果が薄い
  • 自分が眠たくなって先に寝てしまう

結論

ドリームスイッチを使うと子供をベッドに誘いやすくなるし、本を読みすぎて自分の喉が乾くのは防げる。 あと英語になれさせたりするのに便利(と思ってる)。

でもこれを使っても子供は寝るときは寝るし、寝ないときは寝ないので、結局子供との仁義なき戦いは終わらない・・・