BloomScheme Blog

株式会社ブルームスキーム公式ブログ

kubernetesのservice(Discovery&LBリソース)の相互変換についてのtips

f:id:BloomScheme:20190419202010p:plain

はじめに

GKEを触っていて、デプロイを外部アドレスつきで公開(LBリソース)したあと、別に外部から接続できる必要がなかった、あるいはなくなることがあると思います。(ingressの使用、LBの節約など)

今回はこういったときに使えるTIPSをご紹介します。

要約

  • serviceのyamlを取得する
  • yamlを変換したいリソースに書き換える
  • kubectl replace -f service.yaml

serviceのyamlを取得

大体手元にファイルがあるはずですが、GKE等でワークロードからデプロイを公開したときは、手元にyamlがないことがあります。
そういうときは、GKE => サービス => 目的のサービスの詳細ページ => YAML のページからyamlをコピペしましょう。

f:id:BloomScheme:20190419194035p:plain
serviceの詳細画面

yamlを変換したいリソースのものに書き換える

例えば、こんな感じのNodePortのserviceがあったとします。

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: 2019-04-19T11:03:58Z
  labels:
    app: nginx-1
  name: nginx-1-service
  namespace: default
spec:
  clusterIP: xxxxxxxxxxxxxx
  externalTrafficPolicy: Cluster
  ports:
  - nodePort: 32438
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx-1
  sessionAffinity: None
  type: NodePort
status:
  loadBalancer: {}

そこから余分な部分を削り、clusterIPのservice.yamlを作ります。

apiVersion: v1
kind: Service
metadata:
  labels:
    app: nginx-1
  name: nginx-1-service
  namespace: default
spec:
  clusterIP: xxxxxxxxxxxxxx
  externalTrafficPolicy: Cluster
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx-1
  sessionAffinity: None
  type:  ClusterIP

変更点は、 * statusの削除 * spec.type: をNodePort から ClusterIP に変更 * spec.ports.nodeport を削除

だいたいこれくらいです

反映

先程作成したyamlを反映します。
ここが割と味噌で、kubectl apply だとうまく動かず、kubectl replaceする必要があったことです。

以上です

追伸

最近GCPにcloud Runというプロダクトが追加されたみたいで、すごく触ってみたい感じです。いろいろな記事を見聞きしたところフルマネージドなknativeらしいです。
インフラをいろいろ触りたいなぁと思いながら、先週今週はほとんどjavascriptでゴリゴリアルゴリズムを書いたりpythonでデータ分析のマネごとをしてました。なんのアルゴリズムかはお楽しみに、早ければ今月中に本番に乗るかもしれません。