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

はじめに

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

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

要約

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

serviceのyamlを取得

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

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でデータ分析のマネごとをしてました。なんのアルゴリズムかはお楽しみに、早ければ今月中に本番に乗るかもしれません。