■24/4/27 11:27PM
HELM
Helm Templateについて色々説明してみる #kubernetes - QiitaHighway to Helm (zenn.dev)Helmの概要とChart(チャート)の作り方 #Docker - QiitaHelm | 一般的な慣習
helmはコマンド一発だが生k8sはマニフェストファイルの数だけkubectl apply(delete)を繰り返す必要がある helm upgrade chart名 -f 環境毎yamlファイル
文法覚えるより繰り返した方がええんじゃないhelmはテンプレートフォルダ以下がマニフェスのようなもの ループ処理が記述可、関数が使える、関数を作れる
helmは基本はテキストの整形用と言える（ヘルパー関数やビルトイン関数を使い外部ファイルを取り込んで変形したり、変数yamlを環境yamlで上書きし外部の値を使う等で沢山のGKEアセットをループ的に生成しようとしている）
helm create <チャート名>templates/ マニフェスト (テンプレート)env/ 自分で作成するが環境毎に異なる値の入る変数を記述┣dev.yaml┣prd.yamlvalues.yaml 繰り返す値等 (dev/prd.yamlが優先され上書きされる) helm upgrade-install <release名> <Helmチャートの圧縮ファイル名>
●●helmテンプレートの文法 (.ファイル名.親.子で表す、.はルートオブジェクト、Valuesはvaluesオブジェクト、$変数:=値、ymlインデントはスペース2つ)●templates/deployment.yaml{{ $env := Values.environment }}{{ $serviceAccountName := Values.serviceAccountName }}image: {{ .Values.deployment.image }}:{{.Values deployment.imageTag }} //nginx:latestserviceAccountName: {{ $serviceAccountName }}-{{ $env }} //sample-sa-dev↑●values.yamldeployment: image: nginx imageTag: latestserviceAccountName: sample-sa●env/dev.yamlenvironment: dev
※values.yaml よりdev/prd.yamlが優先され上書きされ.Valueで使う
●●helmテンプレートのループ (range～end)●templates/es.yamlspec: nodeSets: ((- range .Values.es.nodeSets }} name: {{ .name }} config: node.attr.zone: {{ .zone }} {{- end }}↑●values yamies: nodeSets: - name: node-a zone: asia-northeast1-a - name, node-b zone: asia-northeast1-b
●●helmテンプレートのIF (if-end)●templates/ingress.yaml((- if .Values.ingress.enabled -))apiVension: networking k8s.io/v1kind: Ingress{(- end }}●env/prd.yamlingress: enabled: true●env/dev.yamlingress: enabled: false
●●helmテンプレートの複数値 (toYaml、nindentは関数)●templates/ingress.yamlmetadata: annotations: {{- toYaml .Values.ingress.annotations | nindent 4 }}●values.yamlingress: annotations: kubernetes.io/ingress.global-static-ip-name: sample-ip-name kubernetes.io/ingress.class: "gce-internal"
●●その他中括弧内側の前後にダッシュ {{--}} をつけることができ、前に付けた場合は前の半角スペースを、 後ろにつけた場合は改行コードを取り除くhoge: {{- $piyo := "aaa" -}} "fuga"/* */で囲まれた部分はコメント構文{{-/* a comment */ -}}
.Releaseでリリースの情報を使用できる
{{ .ReleaseName }}とか{{ .ReleaseNamespace }}
●●_helpers.tpl
Helmの_helpers.tplを使える人になりたい #kubernetes - Qiitahelm create [チャート名]で自動でtemplates ディレクトリに_helpers.tplが作成されるが、 partialsやhelpersと呼ばれる共通のコードブロック (defineアクションで定義されtemplateアクションで呼び出される)や、ヘルパー関数などが定義される。_アンスコ始まりのファイルは、他のテンプレートファイル内のどこからでも利用できるという共通部品。 これは内部にマニフェストがないものとみなされる。種類としては、values.yamlが差し替え可能な変数、ローカル変数が定義したTemplateファイル内でのみ使える変数、_helpers.tplはチャート内で自由に使える変数●templates/_helpers.tpl{{- define "deployment" -}}apiVersion: apps/v1kind: Deploymentmetadata: labels: app: {{.name }} name: {{ .name }}-deploymentspec: replicas: {{ .replicas }} selector: matchLabels: app: {{ .name }} template: metadata: labels: app: {{.name}} spec: containers: - image: {{ .image }} name: {{ .name }}{{- end -}}●values.yamlnginx: replicas: "1" name: nginx image: docker.io/nginx:1.25.1httpd: replicas: "3" name: httpd image: docker.io/httpd:2.4.57●deployment-nginx.yami{{ include "deployment" .Values.nginx }}
※{{ include "deployment" 引数 }}で関数を呼ぶ
●●英語サイトだともっと情報がある
Helm | Built-in Objects
.Filesなどのビルトインオブジェクトがあったりと、、、
GKEクラスタを作成しておくkubectlでArgo adminとシークレット作成？brew install argocdArgo cd設定ファイルリポジトリのcloneargocd cluster add <context name>argocd repo add <repo url> --ssh-private-key-path ~/.ssh/id_rsaargocd-configuration に設定を追加argocd-insallation に設定を追加argo cd上からinstallationをsyncするargocd login --grpc-web --sso dev-argocd.dev.bb.com
＝＝＝ArgoはSettingsにリポジトリ、クラスター、プロジェクト、他にUserの設定 アプリ設定でhelmのパス等を指定（Argo内部でhelm upgradeでなくkubectrl applyに変換しでやってもらえるお作法：helmコマンドのインストール不要でArgoでhelm文法が使える）
総務省｜報道資料｜「クラウドの設定ミス対策ガイドブック」の公表 (soumu.go.jp)
Comment (0)
■24/1/14 9:59PM
GKE
モダンか何か知らんが、豚玉かイカ玉で十分じゃ
＝＝＝＝＝＝＝＝＝＝＝
kubectlチートシート | Kubernetes
フォルダに .py と requirements.txt と .dockerignore と Dockerfile を入れてアップロードしているgcloud builds submit --tag asia-northeast2-docker.pkg.dev/bangboo-prj/xxx/image001
helloworld@bangboo-prj.iam.gserviceaccount.com 作成アクセス元のIPを確認するCloud run作成 ドメインないと無理なのでLBとIAPをあきらめ生成されるURLで十分 Cloud runでアクセス元IPを表示するヤツ runのallUsersのinvokerを削除したらアクセス不可になった（この方法で管理する）curl http://ifconfig.me/ で十分だったが
GKE
k8sの内部NWは通常別途いるがGKEは速い奴が動作
GKEはクラスタ内部のDNSでサービス名で名前解決できる
サービスのIPとポートは環境変数で参照可
kubectlを使うには、gcloud container cluters get-credentials を打つ必要がある
GKE設定-クラスタ:側の設定（IP範囲とかセキュリティとか？） 一般/限定公開:外部IPを使うか使わないか コントロール プレーン承認済みネットワーク：CPにアクセスできるセキュリティ範囲-ワークロード:マニフェストで設定
一般か限定公開か？コントロールプレーンが外部IPか？CPがグローバルアクセス可か？承認NWか？ 一般公開で承認NWが良いのでは？簡単だし、 限定公開で使うには＞CPに外部IPで承認NWでいいのでは？ NW:default subnet:default 外部IPでアクセス許可 CP アドレスの範囲 192.168.1.0/28とか172.16.0.0/28(サブネット重複しない奴) コントロール プレーン承認済みネットワーク home (169.99.99.0/24ではなくGCPのIPぽい) 限定公開ならnatが要る CPの VPCのIP範囲は、クラスタの VPC 内のサブネットと重複不可。CPとクラスタは VPC ピアリングを使用してプライベートで通信します グローバルアクセスは別リージョンからという意味っぽい、cloud shellからのkubectlのためONが良いデフォルト設定なら作成したサブネットのIP範囲でなくクラスタが作られない 面倒ならdefault-defaultで良いかも
サブネットをVPCネットワークを考えて指定する方が偉いかも知れんがdefault asia-northeast2 10.174.0.0/20 の場合 サブネットは asia-northeast2 10.174.27.0/24 とか
ARにあるコンテナからGKEをデプロイが簡単にできるCloud Source Repositories でソース管理gitが下記のようにできる gcloud source repos clone bangboo-registry --project=bangboo-prj cd bangboo-registry git push -u origin masterrun使用中のコンテナがGKE上では上手くいかない runのコンテナは8080のようだ Dockerfileとmain.py上ではポートは何でもよい仕様だが、runで自動的に8080割り当てるようだ それが駄目でありGKEは環境変数でPORT 8080を指定 CrashLoopBackOff問題がでる https://www.scsk.jp/sp/sysdig/blog/container_security/content_7.htmlデプロイ公開でポート80 ターゲットポート8080に（クラスタを作成後、ワークロードでデプロイする）
developmentのspec: containers: ports: - containerPort: 8080 を入れる？ yamlでなく、コンソールで設定時に入れると良い
$ kubectl get allNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEservice/flask-1-service LoadBalancer 10.48.4.134 34.97.169.72 80:32147/TCP 20m
us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0 これは簡単に上手く行く、環境変数PORT8080不要 クイックスタート: アプリを GKE クラスタにデプロイする | Google Kubernetes Engine (GKE) | Google Cloud
ワークロードでyamlの spec: replicas: 0を保存するとアクセスを止められる
コンフィグマップ：構成ファイル、コマンドライン引数、環境変数、ポート番号を別途持っていてPodにバインドする(マニフェストに書くと抜き出され見れる)シークレット：Base64の値？(マニフェストに書くと抜き出され見れる）甘いのでsecret mgrを使う方が良い？ config map/secretはマニフェストで編集する必要がある（見れるだけと思われる）エディタで見てみる：yamlとかステータスが見れる
■LBに静的IPを振る
GKE で Ingress を使用して Google マネージド SSL 証明書を使用した外部 HTTP(S) ロードバランサを作成する - G-gen Tech Bloghello-app-addressと名付けたIPを取得LBのアノテーションで設定# ingress.yaml（NWはNodePort、RouteapiVersion: networking.k8s.io/v1kind: Ingressmetadata: name: hello-ingress namespace: default annotations: kubernetes.io/ingress.global-static-ip-name: hello-app-address # IP networking.gke.io/managed-certificates: hello-managed-cert # 証明書 kubernetes.io/ingress.class: "gce" # 外部 HTTP(S)LBspec: defaultBackend: service: name: hello-deployment port: number: 8080
GKEでロードバランサのIPを指定するとき、グローバルに属するIPアドレスリソースは使用できないので注意 #GoogleCloud - QiitaServiceのLBはリージョン指定するタイプの静的IPIngressはグローバルIPOKapiVersion: v1kind: Servicemetadata: name: hoge labels: app: hogespec: ports: - port: 80 selector: app: hoge tier: frontend environment : stage type: LoadBalancer loadBalancerIP: xxx.xxx.xxx.xxx
ArmorでIP制限１）サービスから対象を選択しingressを作成することでLBを追加しArmorも設定可能２）デフォルトLBに付けるにはkubectl要りそう、backendconfig.yamlはどこに置く Cloud ArmorでGKE IngressへのアクセスをIPで制御する #GoogleCloud - Qiitaサービス画面のkubectrlから# backend-config.yaml を作り kubectl apply -f backend-config.yamlapiVersion: cloud.google.com/v1kind: BackendConfigmetadata: namespace: default name: hello-backend-configspec: securityPolicy: name: "bangboo-armor"
serviceのyamlに下記を追加metadata: annotations: cloud.google.com/backend-config: '{"ports": {"8080":"hello-backend-config"}}'↑これでは不足する どこで設定状態を見るか？ingress作成してLBとArmorつけて、デフォルトLBを削除してみる？
GKEの外部からのアクセスを制限するには？ 限定公開＋コントロールプレーンは承認済み等でアクセスしKubectlする ArmorでIP制限＋アダプティブ設定（ArmorはLBが要る）
GKEでNodePort TypeのServiceに対してインターネットアクセス許可する - IK.AM
限定公開クラスタ＋踏み台サーバにIAPで入りKubectl（承認済みNWでの制御はIPのみなので危ういらしい）
GKE(Google Kubernetes Engine) Autopilotの限定公開クラスタにIAPを利用してアクセスする | Tech-Tech (nddhq.co.jp)
【GKE/Terraform】外部ネットワークからの全てのアクセスを制限した限定公開クラスタを作成し、踏み台サーバーからkubectlする (zenn.dev)
コントロールプレーンとPod間で自動FWされない場合もありFirewall要チェック
Cloud shellのグローバルIPを取得しシェルを承認済みNWにできないか？＞OK curl http://ifconfig.me/
GKEでPythonをCron定期実行させたいArgoでDAGを実行させたい https://zenn.dev/ring_belle/articles/2c4bbe4365b544ArgoでGKEのCICD（Argoは別ホストでGithubにアクセスし、GKEを操る） https://www.asobou.co.jp/blog/web/argo-cd
サービスアカウント
Workload Identity Federation for GKEの新しい設定方法を解説 - G-gen Tech Blog
１）ノードに紐付いたサービスアカウントKSAをそのまま使用する(裏でimpersonate）
gkeのサービスアカウントとIAMサービスアカウントの紐づけが不要になった
VPCサービスコントロールで管理したい場合impersonateのSAを指定できないためWIFが要る２）サービスアカウントのキーを Kubernetes Secret として GKE クラスタに登録する３）Workload Identity Federationをつかう
GCP の Workload Identity サービスについてのまとめ #GoogleCloud - Qiita
Githubとか外部のサービスから利用するためSAを連携させる
IAM＞Workload identity連携画面で設定が見れる※KSAはノード単位で設定、Pod単位でGCPのリソースにアクセスできるように管理したい？
●メモ
忙しいときはスケールアウトするが、落ち着き始めるとスケールinし、必要なPodも落とされてしまう
safe-to-evict をymlのannotationで明示して特定Podはスケールinしない等にしておくannotations: cluster-autoscaler.kubernetes.io/safe-to-evict:"false"クラスタのオートスケーラー イベントの表示 | Google Kubernetes Engine (GKE) | Google Cloud
■Workloads リソースPod：Workloadsリソースの最小単位ReplicaSet：Podのレプリカを作成し、指定した数のPodを維持し続けるリソースです。Deployment：ローリングアップデートやロールバックなどを実現するリソースです。DaemonSet(ReplicaSet亜種)：各ノードにPodを一つずつ配置するリソースです。StatefulSet(ReplicaSet亜種)：ステートフルなPodを作成できるリソースです。Job：Podを利用して、指定回数のみ処理を実行させるリソースです。(使い捨てPod)CronJob：Jobを管理するリソースです。Config connector：GKEでGCPリソースを調節してくれるアドオン。Podの増加減少にあたり必要なアカウントや権限やPubSub等々を自動作成や管理する。マニフェストのymlにcnrmのAPIを記載したりする（Config connector resource nameの略）Config Connectorを試してみる (zenn.dev)
■GKE関連の運用GKEクラスタ認証ローテーション30日以内になると自動ローテーションするが危険なので手動が由GKEはマイクロサービスのエンドポイントでのサービス提供かgcloud api利用が前提といえるのでこれでOK1) ローテ開始 (CPのIPとクレデンシャル)2) ノード再作成3) APIクライアントを更新 (クレデンシャル再取得)4) ローテ完了 (元IPと旧クレデンシャルの停止)クラスタ認証情報をローテーションする | Google Kubernetes Engine (GKE) | Google CloudGKEクラスタ認証ローテーションの考慮Google Kubernetes Engine のクラスタ認証情報をローテーションするまでに考えたこと - DMM insideセキュアなGKEクラスタそれなりにセキュアなGKEクラスタを構築する #GoogleCloud - Qiitaコントロールプレーンの自動アップグレード＆IPローテーション＆ノードブールの自動アップグレードで死ぬGKEシングルクラスタ構成で障害発生してサービス停止しちゃったのでマルチクラスタ構成にした話 (zenn.dev) CPの更新後はクレデンを取得しなおす必要がある、ArgoでCICDを組んでいるとクラスタに認証入りなおす必要がある
ノードが入れ替わりに時間が掛かり、時間差で問題がでることがあるので注意
(More)
Comment (0)
■23/10/31 10:57PM
GCP Network Connectivity
●共有 VPC
同組織のプロジェクトのホストプロジェクト(親)のVPCをサービスプロジェクト(子)に共有●VPC ネットワーク ピアリング
異なる組織間の接続（双方のVPCでコネクションを作成する、内部IPで通信する、サブネットは重複しないこと、2ホップ制限で1:1＝3つ以上の場合は古メッシュでコネクション作成要）、k8sサービスとPod ipをVPCピアリング経由する利用法もある
●ハイブリッド サブネット Cloud VPN/Interconnect等が必要、オンプレルータとCloud RouterをBGPでつなぐ、オンプレとGCPをつなぐ
●Cloud Interconnect
DCと専用線で閉域網接続、Cloud VPNより低レイテンシ/帯域安定●Cloud VPN オンプレとIPsec VPN接続、アドレス帯の重複だめ、Cloud VPN側でBGPIP設定やIKEキー生成をしオンプレルータ側でそれらを設定する
●内部範囲
VPCで使うIPをCIDRで定義しIP範囲の使用方法を事前に決定しておく、IPが勝手に使われたりしない等ができる
●限定公開の Google アクセス（Private Google Access）
外部IPを持たないGCE等はデフォルトのインターネットゲートウェイ0.0.0.0を経由してGoogle APIにアクセスする、VPC＞Routesで見れる
●オンプレミス ホスト用の限定公開の Google アクセス CloudVPNやInterconnectを経由してオンプレから内部IPを利用してGoogleAPIにアクセス、GCP側ではCloudDNSで特定のドメインのAレコードを入れる、選択したドメインのIPアドレス範囲を静的カスタムルートでVPC内のプライベートIPからルーティングできるように設定する、オンプレにはCloudRouterからドメインのIPアドレス範囲をBGPでルーティング広報する、VPNやInterconnectがないと0.0.0.0でGoogleAPIにアクセスするがこれだとRFC1918に準拠しない199.33.153.4/30などのIPを使う必要がありルーティングが複雑化したり、オンプレを通る場合があり通信は慎重に設計をすること●Private Service Connect 「限定公開の Google アクセス」の発展版、オンプレをNATでVPCに接続、内部IPでGoogleAPIにアクセスできる、PSCエンドポイントを介して内部IPで公開できる、NATされ内部IPの公開先での重複OK
●プライベート サービス アクセス
VPCペアリングを併用してサービスプロデューサをVPCに接続し内部IPで次のようなサービスに内部IPでアクセスできるようにする（Cloud VPNまたはInterconnectを付け足せばオンプレからも可）、Cloud SQL/AlloyDB for posgre/Memorystore for Redis/Memcached/Cloud build/Apigee等の限られたもの●サーバーレス VPC アクセス
サーバレスからVPC内リソースにアクセスするためのコネクタ（通常は外部IP通信になるがコレだと内部IPでVPCにルーティングされる、/28のサブネットを指定）、例えば既存のcloud runサービスを編集しても付けられず初期構築時のみ設定できる
●外部 IP アドレスを持つ VM から API にアクセスする
IPv6をVMに設定し限定公開DNSゾーン設定をすればトラフィックはGCP内にとどまりインターネットを通りません
●CDN Interconnect
Cloud CDNもあるが他社のCDNに接続する、Akamai/Cloud flare/fastly等々
●Network Connectivity Center
ハブとなりCloudVPN/InterconnectをメッシュしGCP/オンプレ含め通信させる、Googleのバックボーンでユーザ企業の拠点間を接続できる
●ダイレクト ピアリング
GoogleのエッジNWに直接ピアリング接続を確立し高スループット化、Google workspaceやGoogleAPI用だが普通は使わずInterconnectを使う●キャリア ピアリング
ダイレクトピアリングの高度な運用が自社対応できない等でサービスプロバイダ経由でGoogle workspaceなどのGoogleアプリに品質よくアクセスする
Google CloudのVPCを徹底解説！(応用編) - G-gen Tech Blog
●トンネル系の下記は色々権限が要りそうで候補
Compute OS login/IAP-secured tunnel user/Service account user/viewer/compute.instance*
■ポートフォワードは止めないと別につないで繋いでいるつもりでも同じところに繋ぎ続ける
lsof -i 3128
ps ax | grep 3128
ps ax | sshkill [PID]
■IAPトンネルexport http_proxy=http://localhost:3128export https_proxy=http://localhost:3128gcloud compute start-iap-tunnel --zone asia-northeast1-a gce-proxy001 3128 --local-host-port=localhost:3128 --project=gcp-proxy-prjでコマンドを打てばIAP踏み台トンネルを通って外部に通信できる
■踏み台コマンドgcloud compute ssh --projet gcp-prj-unco --zone asia-northeast1-a gce-step-svrでSSHログインしそこからcurl等で操作する
■シークレットからPWを取りつつコマンドを打つgcloud compute ssh --project gcp-prj --zone asia-northeast1-b stp-srv --tunnel-through-iap fNL 3306:mysql.com: 3306mysql -u baka_usr -p"$(gcloud secrets versions access latest --secret mysql_pw --project=gcp-prj)" -h 127.0.0.1-P 3306 mysqlコマンドのpオプションは空白なしでPWを入れる、baka_usrはMySQLのユーザ、mysql_pwはsecret mgrに保存した名前
$()のLinuxコマンドでgcloudコマンドを入れ子。ワンライナーの形で利用ができるsecret mgrのコマンド シークレット バージョンにアクセス | Secret Manager Documentation | Google Cloudワンライナー解説（変数と$()とバッククォート /// BANGBOO BLOG /// - Linux cmd
■SSHトンネル
sshの基本はこれ、セキュアシェル、トンネルは特殊？SSH [オプション] [ログイン名@]接続先 [接続先で実行するcmd]
接続先に権限があること
SSHの疎通確認ssh baka@stp_srv.unco.com
設定例.ssh/config User baka Hostname step_srv ProxyCommand ssh -W %h:%p baka@step_srv.unco.com PubkeyAuthentication no PasswordAuthentication yes
※sshはPWは危険なので鍵認証のみにしたい IPアドレス元を制限や同一IPのログイン試行は拒否する仕組み等は欲しい
SSHコネクション上でトンネル作るssh step_srv -L 8080:dest.benki.com:80 とか ssh -L 8080:dest.benki.com:80 ahouser@step_srv.unco.com※ポート22でstep_srvにSSHコネクションを貼り、ローカル:8080のリクエストはdest:80に転送する↓ブラウザか新規ターミナルでcurlhttp://localhost:8080ダメなら転送設定したターミナルはstep_srvにいるのでcurl
GCP、AWS、Azure 別に見るクラウド VM への攻撃経路まとめ (paloaltonetworks.jp)
＝＝＝＝＝＝＝＝＝＝＝＝＝
なぜレッドオーシャン化する前にサービスを グロースできなかったのか？ - フリマアプリ編 - (フリル)サービスを急拡大させる意思決定が遅く競合に遅れ競合出現後も経営方針を大きく変えなかった勝利条件はユーザ数で機能差ではなかったパワープレーでいかにプロモーションばら撒いて認知広げて第一想起をとるかだった先行者優位で過ごせる期間は短いスタープレイヤーの採用、手数料無料化、TVCM等PLを超えた手法があった、BS経営すべきだった成長のキャップが創業者の能力になっていた有能な人材：耳の痛いことを言ってくれる人材を経営チームに採用しても良かったCTOが開発をし、組織運営の雑務をし、採用もやっていたCEOは机の組み立てをするな。CTOはPCの購入をするな役割の変化に素早く適用し権限移譲を行い、やるべきことをやれる状況を作るあるいは必要な組織を大きくすることに注力する、例えば開発組織を大きくする戦時のCEO、皆に戦時であることを伝える、企業文化に背く意思決定も行う研究や教育等、やった方が良さそうな耳障りの良いタスクも拒否するどうやったら市場で勝てるかの戦略↓
IPOとか目指さなければConfort zoneを見つけてじっくりまったりビジネスを継続させる手もある
メルカリやPay2をみた結果論、このやり方も古いというかアレ
視力回復の音
(16) HOKKORI 📽💫🐈🐢 on X: "視力回復してください❤️🩹😹 https://t.co/Zug4pEbvys" / X (twitter.com)
Comment (0)
Navi: < 1 | 2 | 3 | 4 >
-Home
-Column [128]
-Europe [9]
-Gadget [77]
-Web [133]
-Bike [4]
@/// BANGBOO BLOG ///
