Go to Qiita Advent Calendar 2024 Top
LoginSignup
54
35

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

ぼっち(´・ω・`)Advent Calendar 2018

Day 4
@ozotain日鉄ソリューションズ株式会社

お勧めできないKubernetesの〇〇集

Last updated at Posted at 2018-12-03
  • 完全に個人の独断と偏見に基づく、Kubernetes関連でお勧めできない製品・行為を紹介します。
  • なぜこんな記事を書いたか
    • 基本的に過去の自分の失敗や、過去に調査・検討してダメだった内容の共有です
    • 同じ失敗や同じ調査・検討する無駄が減らせれば、という思いです

凡例

  • お勧めしない度：私がどれほど強く「やめとけ」と思うかを★1〰5で表します
  • お勧めしない理由：理由を解説します
  • 代替案：もしあれば挙げます

製品編

flannel

  • KubernetesのCNIの一つです。よく使ってる記事を見る気がします

講評

  • お勧めしない度: ★★★★

お勧めしない理由

  • 開発が停滞しています
    • v0.10.0が2018年1月に出たきりです
    • そろそろ次のバージョンはリリースされるみたいですが、積極的に活動してるようには見えないです→延期しそうです

　　　　image.png

  • Network Policyをサポートしません

代替案

  • Calico
    • 開発は活発です
      • 3.2.4や、他のバージョン複数（おそらく旧verのバグフィックス）が2018年11月にリリース

　　　　　　image.png

  • Weave
    • 開発はそれなりに行われています
      • 2018年11月にv2.5.0がリリース
    • Network Policyをサポートします

補足

  • CalicoとWeaveの大まかな違い
    • WeaveはVXLANです。外部との通信はNATされます。（src,dst共に）
    • CalicoはBGPでルーティングするのがメインです。
    • つまりCalicoで十分・・・？
      • Weaveしか使ったことはないのでこれ以上の言及はできないです。 後日気が向いたら比較検証してみます

Ceph(Rook)

RookとCephについて

  • RookはKubernetes上にストレージを構築するプロジェクトです
  • Cephはオブジェクトストレージの製品です
  • Rookの記事でよくCephを使っているものを見ますが、私はおすすめしません
  • 論旨としてはCephが信用できないので、Rookを使う場合はCeph以外にしましょうという内容です。Rook自体には触れません。

講評

  • お勧めしない度: ★★★★

お勧めしない理由

  • 過去にjewelバージョンで使っていたが、苦痛だった
    • ログが読めない
      • 開発者がソースコードデバッグする視点のログばかりで、運用者が読んでトラシューするようなログでない
      • cephのbug trackerに報告されているログを見てもらえば伝わると思います
        • 雰囲気だけ伝えるために抜粋するとこんな感じです
2018-10-28 23:23:07.173 7ff73e5b8700  1 -- 172.21.15.118:6813/34020 <== osd.0 172.21.15.118:6801/97454 124 ==== rep_scrubmap(1.c e310 from shard 0) v2 ==== 40+0+42 (2203346794 0 3641534724) 0x561093d72d80 con 0x561092add800
2018-10-28 23:23:07.173 7ff71e4f0700 20 osd.3 969 share_map osd.0 172.21.15.118:6801/97454 310
2018-10-28 23:23:07.173 7ff71e4f0700 20 osd.3 969 should_share_map osd.0 172.21.15.118:6801/97454 310
2018-10-28 23:23:07.173 7ff7224f8700  1 -- 172.21.15.118:6813/34020 --> 172.21.15.118:6801/97454 -- MOSDScrubReserve(1.c RELEASE e969) v1 -- 0x56109353aa00 con 0
2018-10-28 23:23:07.173 7ff7224f8700  1 -- 172.21.15.118:6813/34020 --> 172.21.15.118:6801/97454 -- pg_info((query:969 sent:969 1.c( empty local-lis/les=310/311 n=0 ec=282/14 lis/c 310/310 les/c/f 311/311/0 310/310/14))=([0,0] intervals=) epoch 969) v5 -- 0x561092990f00 con 0
2018-10-28 23:23:54.655 7ff73e5b8700  1 -- 172.21.15.118:6813/34020 >> 172.21.15.118:6801/97454 conn(0x561092add800 legacy :-1 s=STATE_CONNECTION_ESTABLISHED l=0).read_bulk peer close file descriptor 46
2018-10-28 23:23:54.655 7ff73e5b8700  1 -- 172.21.15.118:6813/34020 >> 172.21.15.118:6801/97454 conn(0x561092add800 legacy :-1 s=STATE_CONNECTION_ESTABLISHED l=0).read_until read failed
2018-10-28 23:23:54.655 7ff73e5b8700  1 -- 172.21.15.118:6813/34020 >> 172.21.15.118:6801/97454 conn(0x561092add800 legacy :-1 s=OPENED pgs=3 cs=1 l=0).handle_message read tag failed
  • Dockerで構築すると同じjewelでも物理版と比べてソースコードが古く、バグ修正があたっていませんでした
    • これは当時の状況なので今は違うかも
  • 障害よく起きてました。。。
    • 構築の仕方が悪かった可能性もあります。
      • かなり小規模かつ社内利用の緩い環境だったので大ごとにはなりませんでしたが。。
  • お勧めしない度★5にしない理由は次を考慮してです
    • 今の最新版はもしかすると違うかもしれない
    • 私が悪かっただけで実は普通の人ならトラブルなく運用できたかも
      • (私の前任者もしょっちゅうcephの障害対応してましたが)
    • スケールアウト等、メリットも多い製品

代替案

  • Minio
    • 私はこれに乗り換えました
    • 時々障害も起きますが、ceph時代に比べれば全然楽です。ログが読めるのが大きい

Helm

  • kubernetes上のシステムをパッケージ化するものです。
  • kubernetesのyamlを変数で穴埋めする形のテンプレートにすることで使いまわしが効くようにします
  • 公式リポジトリからシステムを落としてこれたりします。LAMPとかElastic-stackとか。
  • そんなに悪くない製品ですが、つらみもあるのでお勧めはしないぐらいの製品です

講評

  • お勧めしない度: ★

お勧めしない理由

  • 穴埋め形式のテンプレートのため、次のデメリットがあります
    • 対応項目が増えるほどテンプレートが複雑になり、読みにくくなります
      • 条件分岐とかループとか合わさってくると結構大変です
    • 公式リポジトリからちょっとだけ項目追加したいというときに、自分でテンプレート一式落としてきて編集する羽目になります
      • 穴埋め形式なので、穴が空いていないと何もできない
    • 公式リポジトリからちょっとだけ項目を消したい（不要な設定が入ってる）場合も上と同じです
  • 後述のKustomizeの方が有望

代替案

  • kustomize
    • 穴埋めでなく、複数yamlを組み合わせたり、上書きできるそうです。なので上記のつらみは解決されそう
    • kubectlに統合される前提だそうです。つまり将来Kubernetesのデフォルトになることが期待できます

行為編

タグかshaを指定せずにイメージを使う

  • お勧めしない度: ★★★★★
  • お勧めしない理由
    • これはよく言われてますよね
    • 指定していないといつかそのyamlは動かなくなります
    • 動かなくなってから動いていたイメージを探す羽目になるかもしれません

DockerHubのイメージがいつまでもあると思う

  • お勧めしない度: ★★★
  • お勧めしない理由
    • 消されることもそりゃあります
    • imageのsaveをしておくと安心です
      • Dockerfile確保で済ませる場合はBASEイメージの確保が必要です
        • 結局BASEイメージを確保しないといけなくなるので、imageのsaveの方が無難です
    • もしくはPrivate Registryを立ててそこに入れておくと安心です　

インターネットにホワイトリストアクセス制限の掛かっている環境で使おうとする

  • お勧めしない度: ★★★★
  • お勧めしない理由
    • DockerHubへのPullに問題が生じます
    • Docker Registry API v2の仕様上、イメージのLayerのpull先はリダイレクトが可能です
      • This endpoint may issue a 307 (302 for <HTTP 1.1) redirect to another service for downloading the layer and clients should be prepared to handle redirects.
      • リダイレクト先は当然変わることもありえるので、そのタイミングでイメージがPullできなくなります
    • DockerHubへの直接のPullを制限したい企業であれば別にいいですが。。。

マルチテナントで使う

  • テナント間のセキュリティを考える必要があったり、悪意あるユーザーの想定をしないといけないような使い方を指しています

  • お勧めしない度: ★★

  • お勧めしない理由

    • カーネルリソースの競合が起きえます。記事
    • ストレージを使う場合は、データのセキュリティも結構難しいです
      • 内部動作としては、Nodeがマウント→コンテナに見せる、という2段階になります
      • マウントするのはNodeなので、テナントごとにソースIPで制限する等はできません
      • KubernetesのPVはテナント（namespace）に所属しないオブジェクトで、全テナントに見えるはずです
    • 基本的にデフォルト設定がマルチテナント向きでないので、かなり手を入れていく必要があります
    • マルチテナントで使うなら今はVMの方がいいかな、という感想です
      • そのうちベストプラクティスが整備されれば、という感じです。

Twelve-Factor Appを知らずに使う

  • お勧めしない度: ★★★
  • お勧めしない理由
    • これを知っているとKubernetsの機能に気づかずに残念な使い方をすることが回避できると思います
    • 例えば、Dockerイメージ内に環境固有値（プロキシとか）を埋め込む等です
      • ConfigMapで設定するほうがビルドする手間も少なく、環境変化（プロキシ変更等）にも強くなります
      • Twelve-Factor Appを知っていれば、こういう行為に違和感を持てます
        • （やむをえないケースももちろんありますが）
      • 基本的にTwelve-Factor AppはKubernetsの機能で実現できます

masterのリソースをけちる

  • お勧めしない度: ★★
  • お勧めしない理由
    • Kubernetesのノードはmasterに定期的に状態報告します(デフォルトで10s間隔)
      • そのためNodeが増えるとmasterの負荷が上がっていきます
      • 障害検知速度を上げるには報告間隔を短くするのですが、そうすると負荷も当然上がります
    • masterをHDDのPCに立てたNode10台の環境ではkubectl get nodesに10秒近くかかってます
      • 障害検知速度を上げてるので、それも原因ではあります

異なるアーキテクチャのサーバーが混在したクラスタを組む

  • 例えばIAサーバーとPowerが混在したクラスタを組むなどです　

  • お勧めしない度: ★★★★★

  • お勧めしない理由

    • 通常はKubernetesが動きません
    • 動かない理由は、次のためです
      • 一般的に、IA用にコンパイルしたアプリはPower上では動きません。逆もそうです
      • Kubernetesのシステムコンポーネントには、DaemonSetで全Nodeに配布されるコンテナがあります
        • pauseイメージや、CNIのコンテナ等です
        • 単一イメージなので、IAサーバーかPowerのどちらかでしか動きません
          • そのためIAサーバーとPowerが混在したクラスタでは、どうしてもどれかのNodeでDaemonSetのコンテナが動かないことになります
    • (厳密なことを言えばbeta.kubernetes.io/arcラベルでサーバーアーキテクチャは選択できるので、システムコンポーネントのyamlを書き換えれば不可能ではないですが、お勧めはしません)

image.png

証明書更新せずに使い続ける

  • お勧めしない度: ★★★★★
  • お勧めしない理由
    * 証明書の期限が切れると動かなくなります
    * デフォルトは1年です
    * Kubernetes1.12から、更新機能がGAになってます
54
35
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
54
35

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?