ツナワタリマイライフ

日常ネタから技術ネタ、音楽ネタまで何でも書きます。

「KnativeとIngress Gateway」メモ

techbookfest.org

Knative

  • Serving
    • Revision
    • Configuration
    • Route
    • Service(Kubernetes の Service とは違う)
  • Eventing
    • Sources
    • Broker

この時点ではよくわかんないけど、Kubernetes の上に Gateway 層(Istio とか他) がいて、その上に Knative がいるようだ。

Gateway

  • Ingress は L7 Load Balancer
    • Type LoadBalancer Service や
    • Type NodePort Service もクラスタ外に公開するが

Knative が利用する Gateway というのは Envoy とかでよく説明される Front Proxy - North / South traffic のこと。この手段がいくつかある。

  • Ambassador
  • Contour
  • Gloo
  • Kourier
  • Istio

いずれも Envoy を Proxy に利用している。

その代表として Istio の説明。

Istio

結局イマイチ Knative いれるのになんで Istio(Gateway?)がいるのかがよくわかってない。

Typo をみつけたけど PR 投げられない。

3.5 Istio のコンポーネント つぎは主要なコンポーネントのインストールです。ここでは Helm を使って kubectl で apply する YAML ファイルを生成して apply います。

Istio で gateway つくって、それを外部から Knative に流すためにいるんかな。そのために Istio はヘビーじゃない？と思うが。

Ambassador

基本的に north-south トラフィック を制御するためのプロダクトです。east-west トラフィックの制御は Istio、Consul、 Linkerd とのインテグレーションを提供しています。

ほーん

.... よくわからんかった

Contour

おぉ、これは試そうと思ってたやつ。

Ingress を HTTTPProxy というカスタムリソースで表現するらしい。

Kourier

Knative 用の Ingress らしい。

Gloo

エンタープライズ版の API Gateway

ほう

おわりに

うちは Type LoadBalancer Service で AWS の LB で受けて、Node Port で受けて中にある Nginx に流してそこから各 Service に Proxy するというアーキテクチャをとっている。

いわゆるここの Front Proxy が将来どうなるか。Ingress を使う、Envoy を使う可能性は十分あると思う。

例えばこの Front の部分で path base routing なり header みてどうなり、percent base で canary をやるなりするなら Service Mesh があったほうが多分楽なのかなあ。

それとも Canary とかはその先の、Istio だったら Virtual Service 層でできるのかな、多分。

いずれにしろ、今は Service Mesh Control Plane は決着がついてない状況なので、Solution Base で、最小の構成で試して価値を出しつつ、学んでいきたいと思う。

Knative はどうなんだろうなあ、今のところ Layer 増えるジャンっていうイメージしかもってなくて、それでどんだけ幸せになれるかピンときてないです。Platform やる側だからかな。

LEARN ENVOY - Health Checks

www.envoyproxy.io

  • Load Balancing をうまくやるために
    • Health Checking(active monitoring)
    • Outlier Detection(passive monitoring)

Health Checking

  • endpoint ごとに生きているかを確認する
  • cluster 単位で行う
  • とはいえ health check だけでじゃ十分でない場合があり、異常値(outlier detection) と組み合わせると良い

Outlier Detection

  • Health Check とは反対に、実際の Response から Healthy かどうかを判別する
  • 例えば3回連続の503が帰ったら cluster から外す、という挙動をとる
  • 使えないホストにトラフィックを流さない判断がさっさとできるのはよさそうだが、それで復帰するのかなあ

Implementing Health Checking

  • Health check はコードに手をいれず実現できて便利だが
  • check しているのは service の health ではなく、host の health だ
  • つまり、host が auto-healing しないと意味がない
  • サービスが十分なトラフィックを受けているなら、5回の5xxエラーなどの統計情報が十分 Outlier Detection として役に立つ
  • もし initialize 処理が終わる前にトラフィックが流れるような場合は、Outlier Detection が役立ちます（まぁそうならんようんするやろ）
  • トラフィックが少ないが重要な場合は、Active Helath Check が役に立ちます

おわりに

Active と Passive の Healthcheck があり、まぁ Passive Health check が場合によっては便利な場面があるんやなーと思いました。

LEARN ENVOY - Automatic Retries

www.envoyproxy.io

Retry も重要。このへんが Application によってしてくれたりしてくれなかったりするのを Envoy がしてくれると助かるよね。

  • Envoy は Resilience のために retry を system の外で実装できるぞ
    • Choose appropriate defaults
    • Limit retry-able requests
    • Consider the calling context

Choose appropriate defaults / A typical Envoy retry policy

まぁ simple な retry 設定はこんな感じ

retry_on: "5xx"
num_retries: 3
per_try_timeout_ms: 2000

ふむ。

それぞれ default 値がある。 per_try_timeout_ms は retry のときの timeout, default は通常の request のときの timeout。

Limit Retry-able Requests

  • Retry 可能であるものだけを Retry すべき
  • つまり non idempotent 冪等でないリクエストは Retry すべきではない
    • キャンセルできないリクエストも同様
    • http GET なんかはリトライしやすい好例

Consider the Calling Context

リトライを設定するときには呼び出し側がどのようにリクエストするかを考慮する必要がある。

parameter としては timeout_ms , per_try_timeout_ms , num_retries とある。 per_try_timeout_ms * num_retries は timeout_ms を超えられない。retry ははやめに fail させたほうがよい。

また、global timeout がない場合で、timeout も長く retry がある場合はパフォーマンスは大きく低下する。このような高ファンアウト処理は retry をするべきではない。

最後に、retry と合わせて circuit breaking を同時に設定したほうがいい。retry は cascading failure を招きかねない。それを防ぐためにも必要。

このへん、最終的にはチューニング必要なんだなと思いつつ、前提としての考え方はめっちゃ重要だと思った。

3月

もう10日も過ぎてしまっている。

1月いっぱいかなり忙しくて、よーし2月はゆっくりする！生活をする！となったはいいが、それはそれでいろいろ行き先迷子になってしまったので、せめて短期的に、今月何するかだけ羅列しておく。

英語

  • DMM 英会話は継続
    • Vocabulary Material が終わって、Discussion Material へ
    • 英会話では Speaking 重視で、教材を読む中心から、何もないところから自分が発するようなところに寄せていきたい
    • Describing Pictures / Advanced Describing Pictures とか Daily News が次の候補かな
  • TOEIC は3月は中止、4月に受けるので、abceed で予測スコア750 目指す
  • 英検準1級 5/31 も受ける。Vocabulary の教材を abceed でやる トク単 https://amzn.to/2TSi5SG
  • Podcast を Script を読んで聞いてブログにまとめる Kubernetes Podcast Kubernetes Podcast from Google
  • Coursera Hybrid Cloud Service Mesh with Anthos 動画は2、3週でシャドーイング Hybrid Cloud Service Mesh with Anthos | Coursera

写真

音楽

  • アルバムリリースする
  • mix 4曲
  • cubase 環境再構築

仕事

生活

  • 自炊
    • 回鍋肉とペペロンチーノをマスターしたので、別の中華料理1つと、パスタ 料理1つをレパートリーに増やす
  • 1日1回1時間以上散歩
  • お風呂で読書する
    • 月10冊は読みたい

LEARN ENVOY - Circuit Breaking

Service Mesh / Envoy でもっとも実現したい機能の1つなのでちゃんと読んでいく。

www.envoyproxy.io

  • microservices の文脈では cascading failure を避けるために circuit breaking 重要よ
  • envoy では cluster 単位で circuit breakers field を使って設定するよ
  • 設定例はそのまんまという感じ、priority で threashold をグルーピングできるので、例えば High は POST のリクエストなどができそうな雰囲気
  • http/1.1 と http/2 では挙動が違うので、設定もそれぞれ対応したものを使う
    • http/1.1 は max_connections
    • http/2 は max_requests
  • 適切な threshold は request 数と latency の2つに依存する
    • この例だと、この設定は 10 seconds * 2000 までの間で検討しましょう
    • 実際にはどのぐらいの spike がくるかの期待と、どれだけ overprovision しておくかによります
  • Advanced circuit braking
      1. Break–on–latency / 前述したように、service is excessively slow, but not fully down の条件で設定しましょう
      1. Configure breaking based on a long queue of retries / retry の回数に応じて braking するのもまた有効です。max_retries パラメタを考慮して閾値を調整しましょう

明確に Down した場合よりは、Down してないけど遅いときが cascading failure を起こしてしまう、ほんとそれという感じ。 具体的な latency で cuicuit braking もきっとできると思うけど、遅い場合は結局 connections が滞留するので、ここで braking するのはなるほど合理的だと思いました。

LEARN ENVOY - Service Mesh

blog.chaspy.me

はい。Service Mesh 編ですね。読んでいきましょう。

  • east-wast traffic と呼ばれる internal call をすべて Envoy 経由にすることによって、load balancing や resilience strategies を適用できる
  • sidecar として、すべての network は localhost に向けて Envoy へ proxy される

Envoy as a Sidecar

  • Kubernetes での設定例。Envoy の Container を Pod にいれればよい

Sidecar Configuration

すべてのトラフィックを Internal network がやってることと同じように扱えば良い。

  • Expose a single listener for your services to send outbound traffic to
  • Serve the full route table in all sidecars
  • Consider using dynamic configuration for instance discovery in the first iteration

Observability

Service Mesh の最大の利点の1つ。 - Pick metrics that relate to customer experience - Segmentation of simple metrics, not more types of metrics - Add tracing in Envoy

Tracing もここでできるんだ。

Multiple Regions

Data Center ごとに Front Proxy が必要だよ。

ふむ！という感じでした！流し読みでよさそう。

LEARN ENVOY - Front Proxy

www.envoyproxy.io

One of the most powerful ways to deploy Envoy is as a front proxy

ふむ。

Front Proxy、つまり自分たちのネットワークに入ってくる入り口のところに Envoy を立てるパターンの話。

いまのところこれに相当するのは Nginx が立ってるし、まぁ参考程度にみた感じ。

実際には NLB だとかの後ろに Front Proxy としての Envoy が立つ感じなんかな。