GoogleCloudPlatform/gke-managed-certs を覗いていたら普段あまり使わないunix commandがあったのでメモ wait $pid 特定プロセスの完了を待つ。 ついついwhile loopでpolingしちゃうことがあるんだけど、そんなことしなくて良いよね。 e.g. backgroud jobに飛ばした処理を待ってなにかする % sleep 1 &; wait $! && echo 'finished!' [1] 16769 [1] + done sleep 1 finished! kill -0 $pid kill -0 はprocessが存在することを確認することができる e.g. processが存在していたら処理を実行する。 % sleep 1 &; kill -0 $! && echo "existing" [1] 16575 existing ~/src/github.com/GoogleCloudPlatform/gke-managed-certs master % [1] + done sleep 1 ~/src/github.com/GoogleCloudPlatform/gke-managed-certs master % sleep 1 &; wait $! && kill -0 $! [1] 16603 [1] + done sleep 1 kill: kill 16603 failed: no such process ちなみに、以下のようにwhileしてpidがあるときだけwaitを繰り返す理由は調べてみたのだがわからない 🤔 ... Read more

GCPでは2018-10頃よりGCLBにGoogle-Managed certificateを利用できるようになったので、GCLB on GKEで利用できるように設定していく。 Create Google-Managed Certificate manually まずはgoogle managed certificateをGCLBに利用するにはどうしたらよいのか、とりあえずマニュアルで使ってみる。 Google Cloud - Creating a Google-managed SSL certificate resource 発行される証明書はDV証明書であるため、何かしらの形でDNS recordで確証が取れる必要がある。 このときGoogle Managed Certificateでは以下を満たすことで、GCLBとの疎通確認ができることが証明され証明書のprovisioningを実現する。 from GCP - Creating Content-Based Load Balancing domainのDNSレコードは、GCLBのtarget proxyのIPを参照する target proxyはGoogleが管理する証明書リソースを参照する forwarding ruleの作成など、ロードバランサーの設定が完了している つまり流れとしては以下 certificate申請後 GCLBの作成 httpsのforwarding-ruleを作成する Create Certificate まずはcertificateをapply % gcloud beta compute ssl-certificates create test-threetreeslight-com --domains test.threetreeslight.com % gcloud beta compute ssl-certificates list NAME TYPE CREATION_TIMESTAMP EXPIRE_TIME MANAGED_STATUS test-threetreeslight-com MANAGED 2019-01-04T22:43:02. ... Read more

GCPではACMのようなサービス提供を期待するIssueが2016年にあり、以下のように回答している。 Given the above, can we consider this request to be asking convenient provisioning of Google-signed certificates for GCP customers? なぜこのような話に至ったのか気になるので、自身の理解を深めるためにも調べてみた。 理解が間違っている可能性もありますので、その点は了承ください。 Certificate Authority SSLエコシステムではだれでもsigning keyを作成し、そのkeyを利用して新しい証明書を作成することが出来ます。 しかし、この証明書が信頼できる認証局( Certificate Authority、以下CA )によって直接的・間接的に署名されていない限り、有効な通信とはみなされません。 CA Types この直接的・間接的な署名を行う認証局が以下です。 Root CA 直接的な証明を行う認証局 Intermediate CA 間接的な証明を行う認証局 これら信頼できる認証局の情報は、大抵のケースではOSやweb browserにbundleされています。 OSやbrowserにbundleされていないCA(大抵の場合は Intermediate CA)があると、それをOSやbrowserはCAの証明書を元に探りに行きます。 CA list = security level 信頼できるCA listはとても重要で、システムのセキュリティレベルを決定すると言っても過言ではありません。 そのため、OSやbrowserそれぞれにbundleされているCA listには差分があります。 このため、中間証明書を含まない証明書を通信に利用すると、Browserで見るとValidなHTTPS通信と見なされるにもかかわらず特定のOSやlibraryによってはUnknown Authorityとみなされてしまうケースがあるので、必ず中間証明書を含む証明書を利用することが求められます。 How to provide a service like ACM これらの前提を理解しながら、Googleの回答を理解していきます。 ... Read more

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を利用している場合めちゃめちゃ重宝する。超嬉しい。知って嬉しい。たまらん。 さっくさくだぁ