Getting Started Istio

Getting Started Istio on Shinjuku mokumoku programming vol.17

Transcript

1. Getting Started Istio
   @threetreeslight
   on shinjuku mokumoku programming #17
   1 / 23
   

   View Slide

2. Who
   VP of Engineering at
   Event Organizer
   おじさん
   Repro
   2 / 23
   

   View Slide

3. コード書く時間がないので
   ⾃前のサービ
   ス運⽤を通し
   て知⾒を得る
   3 / 23
   

   View Slide

4. わたしのぶろぐ(
   ⽉2
   万)
   4 / 23
   

   View Slide

5. 技術の無駄遣い感はんぱないけど
   Istio
   導⼊じ
   ゃっ！
   5 / 23
   

   View Slide

6. Istio
   って何？
   service mash
   を実現するサービスだよ
   service mesh
   が何かについては以下のブログ⾒てもら
   うと分かりやすいかもしれません threetreeslight
   - Why do we need service mesh?
   6 / 23
   

   View Slide

7. 早速使ってい
   く
   7 / 23
   

   View Slide

8. Install
   Istio
   はinstall
   に必要なkit
   がいい感じにまとまってい
   るので助かる。それだけsystem component
   が多いと
   いうことも⽰している⽤に感じる。
   curl
   でもってきて、 istioctl
   だけpath
   通しておく
   curl -L https://git.io/getLatestIstio | sh -
   cp ./istio-1.0.2/bin/istioctl /usr/local/bin
   8 / 23
   

   View Slide

9. Manual OR Helm?
   Istio
   はいくつかの⽅法がある
   1. helm (kubernates
   ⽤のpakcage manager
   だと思ってもら
   えればOK)
   2. kubectl
   でapply
   していく
   Istio
   公式⾒解としえはhelm
   を使って構築されること
   を期待しているようだ。
   9 / 23
   

   View Slide

10. Helm
    でGo
    ちなみにhelm
    でinstall
    できるcomponents
    は以下の通
    り。
    https://github.com/istio/istio/blob/master/install/kubernete
    keywords:
    - istio
    - security
    - sidecarInjectorWebhook
    - mixer
    - pilot
    - galley
    10 / 23
    

    View Slide

11. Monitoring
    他にもinstallation
    として、prometheus, grafana,
    servicegraph, tracing
    など様々なchart
    が⽤意されてい
    る。幸せ。
    prometheus
    とgrafana
    のchart
    を参考にできるのはあ
    りがたい.
    11 / 23
    

    View Slide

12. Tracing
    tracing chart
    に含まれているのが Zipkin
    ではなく
    jaeger ( )
    だった。
    jaeger
    がデファクトなのかな？
    https://www.jaegertracing.io/
    12 / 23
    

    View Slide

13. ちなみに
    公式ドキュメントを⾒ていてCustom resource
    definision
    を⼿動で⼊れてしまい、helm
    で⼊らんと嘆
    く⼈が多い。
    Helm delete does not clean the custom resource
    definitions
    Tutorial Helm note update
    # Install Istio’s Custom Resource Definitions via kubectl apply, and wait
    $ kubectl apply -f install/kubernetes/helm/istio/templates/crds.yaml
    13 / 23
    

    View Slide

14. istio
    はkubernates
    上で利⽤するcustom resource
    definision
    があり、helm 2.10.0
    より前だと作成できな
    いので⼿動でそのresource
    をapply
    する。
    もちろん私も
    踏んだ。
    14 / 23
    

    View Slide

15. 意気揚々にvalidate
    あるぇ、、、prometheus service
    が⽴ってる、、、
    % kubectl get svc -n istio-system
    NAME TYPE CLUSTER-IP EXTERNAL-IP
    istio-citadel ClusterIP 10.59.252.14
    istio-egressgateway ClusterIP 10.59.252.179
    istio-galley ClusterIP 10.59.247.233
    istio-ingressgateway LoadBalancer 10.59.255.51 35.197.96.12
    istio-pilot ClusterIP 10.59.245.42
    istio-policy ClusterIP 10.59.246.86
    istio-sidecar-injector ClusterIP 10.59.249.91
    istio-statsd-prom-bridge ClusterIP 10.59.245.16
    istio-telemetry ClusterIP 10.59.252.157
    prometheus ClusterIP 10.59.252.174
    15 / 23
    

    View Slide

16. mixier
    の依存っぽい
    components
    のenable,disable
    を制御できるようなの
    で以下のコマンドで再構築すると良い。
    よく sidecarInjectorWebhook
    の制御はこれで⾏
    うらしい。気持わかる
    % helm install install/kubernetes/helm/istio --name istio --namespace ist
    --set prometheus.enabled=false
    16 / 23
    

    View Slide

17. Deploying
    というわけで、⾃前のサービスのns
    を整理して、
    development
    環境から istio-
    injection=enabled flag
    を付与していく
    % kubectl label ns staging istio-injection=enabled
    % kubectl get ns --show-labels
    NAME STATUS AGE LABELS
    default Active 146d
    development Active 2m istio-injection=enabled
    istio-system Active 2h name=istio-system
    kube-public Active 146d
    kube-system Active 146d
    production Active 2m
    staging Active 2m
    17 / 23
    

    View Slide

18. ns
    ガチャガチ
    ャいじったら
    権限とかいろ
    18 / 23
    

    View Slide

19. 以下余談
    19 / 23
    

    View Slide

20. What's CRD?
    ubernates
    にはcustom resource
    という概念がある。
    あたらしく独⾃リソースを定義することで、汎⽤的
    なリソースとして、kubectl
    やkubernates
    のAPI
    を利
    ⽤した操作であったり、権限管理を⾏うことができ
    るようになる。
    20 / 23
    

    View Slide

21. Consider API aggregation if:
    Your API is Declarative.
    You want your new types to be readable and writable
    using kubectl.
    You want to view your new types in a Kubernetes UI,
    such as dashboard, alongside built-in types.
    You are developing a new API.
    You are willing to accept the format restriction that
    Kubernetes puts on REST resource paths, such as API
    Groups and Namespaces. (See the API Overview.)
    Your resources are naturally scoped to a cluster or to
    namespaces of a cluster.
    You want to reuse Kubernetes API support features.
    21 / 23
    

    View Slide

22. 典型的な宣⾔的なAPI
    ⼩さいオブジェクトやリソースから成り⽴っている
    アプリもしくはインフラから定義・設定されることがあ
    り
    よく更新される
    運⽤ために読み書きを⾏う
    基本的な操作はCRUD
    複数のオブジェクトをまたいだトランザクションが無い
    22 / 23
    

    View Slide

23. con gmap + pod
    をcustom
    resource
    として管理しちゃったほ
    うが良いのかな？
    と思ったら書いてあった
    config file format
    があるものだったらconfigmap
    pod
    のプログラムの設定ファイルだったらconfigmap
    の
    が楽
    kubernetes api
    より環境変数で定義しちゃいたくなるも
    のであればconfigmap
    rolling update
    を必要とするものだったらconfigmap
    うーむ。
    23 / 23
    

    View Slide