IstioにおけるSSL通信のためにcert-managerを使ったほうが良いと謎の理解をしていて危うかったので、isitoのtraffic flowを改めて理解し どのようにSSL通信する方法があるのか 今回はどのような方法でアプローチするか をまとめていく。 Istio Traffic Flow Istioがpublic internetを用いて通信するときは、公式ドキュメントにもある通り以下のような図となる。 基本的にgatewayとServiceEntry resourceで通信を制御している。 ただ、これだけだと「ん？SSL通信どうするの？まったくわからん」という状態。 Istio Service and Gateway resource Istioの構成をより詳しく見ていくと、デフォルトでは以下のような流れであるようだ。 Public Internet -request-> service(type: loadbalancer) -gateway-> ... なぜこの構成なのか？ 昔はingress controllerで処理されていたようだが、いまはserviceとして定義されている。 つまり、serviceのtypeを変更できるということ。こうすることで serviceのtypeを nodeport なりにすることで既存loadbalancerからつなぎこむことができる service meshへはhttpでアクセスすることができる Chart definision helmの定義を見ていく。 https://github.com/istio/istio/blob/1.0.4/install/kubernetes/helm/istio/charts/ingress/templates/service.yaml apiVersion:v1kind:Servicemetadata:name:istio-ingressnamespace:{{.Release.Namespace}}labels:chart:{{.Chart.Name}}-{{.Chart.Version| replace "+" "_" }} release: {{ .Release.Name }} heritage: {{ .Release.Service }} istio: ingress annotations: {{- range $key, $val := .Values.service.annotations }} {{ $key }}: {{ $val }} {{- end }}spec:{{-if. ... Read more

istio のtraffic managemntするためのresoruceについて学ぶ。 （誤りがあるかもしれない点は了承ください） What is Istio? kubernetes上にservice meshを実現するフレームワークです decouples traffic flow and infrastructure scaling 上記に記述されたようにtraffic flowとscalingが切り離されている。 触っているとこれが本当によくできているように感じる。 以下のようなことが宣言的に設定できるようになる。 mirraring 仮想的なlatencyを付与 load balancingのweight 特定のheader情報のユーザーだけ制御 宣言的に設定できるということは、大分カスタマイズされているということだ。 Istio Custom Resources これらのtraffic managementを実現するためにIstioでは以下のcustom resourceを定義している VirtualService DestinationRule ServiceEntry Gateway 外部から通信が会ったときのresourceの流れを簡単に示す。 （ちょっと怪しい） -> Gateway -> VirtualService -> Service -> DistinationRule -> Deployment A -> Deployment B -> Deployment C -> ServiceEntry VirtualService VirtualServiceはkubernetes Service へのrequestがあったときに、それをservice mesh内でどのservice およびそのsubsetにroutingするかを定義する。 DistinationRuleで定義されたsubsetを利用して以下のような制御を行うことが可能となる。 mirraring 仮想的なlatencyを付与 load balancingのweight 特定のheader情報のユーザーだけ制御 なお、複数ホスト(kubernetes service)を一つのVirutualServiceとして取り扱うのは、システムマイグレーションを意識してのことだと推察。 ... Read more

Prometheusとgrafanaのhealth checkのpath、なんかしっくりこなかったので調べてみた Prometheus health check endpoint実装されてた https://github.com/prometheus/prometheus/blob/47a673c3a0d80397f715105ab6755db2aa6217e1/web/web.go#L303 router.Get("/-/healthy", func(w http.ResponseWriter, r *http.Request) { w.WriteHeader(http.StatusOK) fmt.Fprintf(w, "Prometheus is Healthy.\n") }) router.Get("/-/ready", readyf(func(w http.ResponseWriter, r *http.Request) { w.WriteHeader(http.StatusOK) fmt.Fprintf(w, "Prometheus is Ready.\n") })) 揉めずにサクッとはいっていた模様。/-/ready が先にあったからかな？ Add /-/healthy and /-/ready endpoints #2831 deployment シンプルになった 😇 livenessProbe:httpGet:path:/-/healthyport:9090readinessProbe:httpGet:path:/-/readyport:9090 Grafana Grafana 4.3で /api/health endpointが提供されていた。 https://github.com/grafana/grafana/blob/e78c1b4abc7eda7a065e390dc04b7a0c0435268c/pkg/api/http_server.go#L250 func (hs *HTTPServer) healthHandler(ctx *macaron.Context) { notHeadOrGet := ctx.Req.Method != http.MethodGet && ctx.Req.Method != http.MethodHead if notHeadOrGet || ctx.Req.URL.Path != "/api/health" { return } data := simplejson. ... Read more

Istioを使ってserviceを稼働させるとまずハマったのが、kubernetes service resourceからのlivenessProbeおよびreadinessProbeが通らなくなるという事象。 この問題にぶつかる人は多い様子。 istio issues - Liveness Readiness Probe Istio #2628 istio faq - security/k8s-health-checks Requirement Istioはマイナーバージョンが変わるだけでCustom Resourceがなくなったりするので、本記事のkubernetesとistioのversionを記述する kubernetes master version: 1.10.9-gke.5 Node version: 1.10.9-gke.5 Istio version: 1.0.3 Istio導入前のprobe設定 blogに利用するnginxに /healthy endpointを切って server { listen 8080; ... location /healthy { default_type text/plain; return 200 'ok'; } blogのdeploymentは/healthy を叩くだけ。 ...readinessProbe:httpGet:path:/healthyport:8080... istioを稼働させるとpod内でのreadinessProbeは通るのだが、serviceからのhealthcheckが一切通らなくなる。 原因 これはsidecarとして可動しているenvoyがkubeletからのHTTP/TCP requestを拒否しているから他ならない。 istio issues - Liveness Readiness Probe Istio #2628 Do the FAQ have answer? ... Read more

Occation prometheus resourceを削除したく、istioを削除 -> 再インストールしてみると以下のエラーにぶち当たる $ kubectl delete -f $HOME/istio.yaml $ helm install install/kubernetes/helm/istio \ --name istio \ --namespace istio-system \ --set prometheus.enabled=false Error: customresourcedefinitions.apiextensions.k8s.io "gateways.networking.istio.io" already exists istioを削除してもcustom resourceが消えないようだ。 Cause Helm delete does not clean the custom resource definitions herefore, since they are unmanaged Helm won’t delete them. Similar to the installation the users are expected to delete them by executing kubectl delete -f install/kubernetes/helm/istio/templates/crds.yaml -n istio-system. ... Read more

helmを雰囲気で使っていたので、この際ちゃんと調べてみようと思う。 What is helm helm ( https://helm.sh/ ) とは、CNCF ( https://www.cncf.io/ ) でhostingされているkubernetes上のpackage manager。 Helmは複雑なkubernetesの設定ファイル(spec)をtemplate化されることでpackage化されている。 そうすることで、同じようなyamlを何度も書くような煩雑なspec記述作業から開放されることを目的に作られている（多分）。 stop the copy-and-paste madness. という表現がまさにそれを物語っているように思える 🤔 このtemplate化されたyamlの集合 = package = chart と呼ばれ、localだけではなくgoogleにhostingされているchartも利用することができる。 How to apply package helm client -create w/ chart-> tiller(on local OR cluster) -create w/ chart-> Estanblished package resouces! What is Chart もう少しchartについてほってみる。chartは基本的にkubernetes resouceのsetを表現している。 Istioに同梱されているchartを参考に見ていく。 https://github.com/istio/istio/blob/master/install/kubernetes/helm/ Chart.yaml Chatの命名やversionなどの定義が記述されている。 versionによってtillerがcustom resouceの作成などできなかったりするので、tillerのversionは大事。 apiVersion:v1name:istioversion:1.0.1appVersion:1.0.1tillerVersion:">=2.7.2-0"description:Helmchartforallistiocomponentskeywords:-istio-security-sidecarInjectorWebhook-mixer-pilot-galleysources:-http://github.com/istio/istioengine:gotplicon:https://istio.io/favicons/android-192x192.png requirements.yaml chartに依存するchartを記述する。 その依存をinstallするか制御するcondition parameterなども記述することができる。 例えば、istioのisntallにgrafanaとprometheus一緒に入れるか？など dependencies:-name:sidecarInjectorWebhookversion:1.0.1condition:sidecarInjectorWebhook.enabled-name:securityversion:1.0.1condition:security.enabled-name:ingressversion:1.0.1condition:ingress.enabled-name:gatewaysversion:1.0.1condition:gateways.enabled-name:mixerversion:1.0.1condition:mixer.enabled-name:pilotversion:1.0.1condition:pilot.enabled-name:grafanaversion:1.0.1condition:grafana.enabled-name:prometheusversion:1.0.1condition:prometheus.enabled-name:servicegraphversion:1.0.1condition:servicegraph.enabled-name:tracingversion:1.0.1condition:tracing.enabled-name:galleyversion:1.0.1condition:galley.enabled-name:kialiversion:1.0.1condition:kiali.enabled-name:certmanagerversion:1.0.1condition:certmanager.enabled values.yaml requirements. ... Read more

ahmetb/kubectx を知ったので改めて紹介したい。 kubectlのcontextとnamespaceのdefaultをガシガシ切り替えるやつ。 localの開発環境であったり、複数のkubernates clusterを利用している場合めちゃめちゃ重宝する。超嬉しい。知って嬉しい。たまらん。 さっくさくだぁ

Kubernatesにおけるsecretはとても便利だが、どのようにrepositoryの中で管理していのかが悩ましい。 Yamlファイルを平分で書いておくわけにもいかない。 そんなときに便利なのが shyiko/kubesec kubesecを使うと、yamlの構造を保持した上で、secret化したい値をPGP, AWS KMS, GCP KMSで暗号化してくれる便利ツール。 更新するときは復号化した標準出力をkubectlに食わせてあげるだけで良い。 Google KMSで暗号化し、secretの更新ができるか早速利用してみる Create secret 仮に passwrod: password というkey-valueを暗号化するとする % echo -n 'password' | base64 cGFzc3dvcmQK 上記を利用したsecretを作成します apiVersion:v1kind:Secretmetadata:name:sampletype:Opaquedata:password:cGFzc3dvcmQK Prepare KMS https://cloud.google.com/kms/docs/quickstart gcloud auth application-default login gcloud kms keyrings create test --location global gcloud kms keys create sample --location global --keyring test --purpose encryption gcloud kms keys list --location global --keyring test NAME PURPOSE LABELS PRIMARY_ID PRIMARY_STATE projects/threetreeslight/locations/global/keyRings/test/cryptoKeys/sample ENCRYPT_DECRYPT 1 ENABLED うん、期待するkeyringとkeyが作られている。 ... Read more

blogなどにかっこいい感じにterminalの情報を上げたいときがある。 この方法について、いくつかの方法があったので紹介したい。 mjording/ttyrec おなじみttyrec, ttyplay Usage # Install brew install ttyrec # rec start with: ttyrec demo.tty # stop by exit tty # reply with: ttyplay demo.tty asciinema よく見るasciinema. ホスティングもコマンド一発なのでホント楽。 ちなみにpecoとかfzf噛むとその画面は記録されない :sweet_face: Usage brew install asciinema # Start recording with: asciinema rec # Upload operation with: asciinema upload faressoft/terminalizer node製のterminal操作記録ツール。 操作をyamlで書き出してあとから編集できたり、いろいろ嬉しい。 anigifや外部の動画サービスに書き出しが気楽なのも良い。 Usage npm install -g terminalizer terminalizer init# Start recording with: terminalizer record demo # Generate anigif with: terminalizer render demo こんな

最近巷でIstioに代表されるservice meshの話を聞くようになりました。 そんなservice mesh、全く理解できていない。 Phil Calçado - Pattern: Service Mesh などをヒントに、なぜservice meshというものが必要となってきたのか理解を深めていきます。 コンピューターサイエンスをちゃんとやってきたプログラマーではないので、誤っている可能性は多分にあるので、その点は理解ください。 Distributed System 世の中のサービスの大半は、複雑度の違いはあれど分散システムとして構成されることを前提とされている。 A distributed system is a system whose components are located on different networked computers, which then communicate and coordinate their actions by passing messages to one other とあるように、分散システムとは、ネットワーク上の異なるコンピュータ上にコンポーネントが配置されているシステムとして考えて良い。 例えば、AWS上のマネージドサービスを使っていたら分散システムであるといえる。 service A,B が存在し、それが通信してやりとりする分散システムを例になぜ必要となるのか考えを深めていく。 牧歌的な分散システム サービス間はメッセージをやりとりするための、通信のスタックがあり、その通信スタックを経由してservice間の通信を行う これで良くない？と思うかもしれないが、分散システムには気をつけなければならないことはとても多い。 Fallacies of distributed computing L Peter DeutschやSun Microsystemsの他の人が書いた、「分散アプリケーションを初めて使うプログラマは常に間違っている」という話があるようです。 Fallacies of distributed computing ネットワークは落ちない 遅延はゼロ 無限の帯域 セキュア 変更されないトポロジ 一人の管理者 転送コストはゼロ 均一なネットワーク 一見するととても当たり前のことを書いてあるように見えるのですが、上記に関わる対策がアプリケーションコードとして実装できているか？というと、そうでもありません。 ... Read more