GKE on Jan 14, 2024 9:59 PM
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
January 14, 2024 List
January 14, 2024
GKE
モダンか何か知らんが、豚玉かイカ玉で十分じゃ
＝＝＝＝＝＝＝＝＝＝＝
kubectlチートシート | Kubernetes
フォルダに .py と requirements.txt と .dockerignore と Dockerfile を入れてアップロードしている
＝＝＝＝＝＝＝＝＝＝＝
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設定
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 master
run使用中のコンテナが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 all
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/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不要
ワークロードでyamlの spec: replicas: 0を保存するとアクセスを止められる
コンフィグマップ：構成ファイル、コマンドライン引数、環境変数、ポート番号を別途持っていてPodにバインドする(マニフェストに書くと抜き出され見れる)
シークレット：Base64の値？(マニフェストに書くと抜き出され見れる）甘いのでsecret mgrを使う方が良い？
config map/secretはマニフェストで編集する必要がある（見れるだけと思われる）
エディタで見てみる：yamlとかステータスが見れる
■LBに静的IPを振る
■LBに静的IPを振る
hello-app-addressと名付けたIPを取得
LBのアノテーションで設定
# ingress.yaml（NWはNodePort、Route
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
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)LB
spec:
defaultBackend:
service:
name: hello-deployment
port:
number: 8080
ServiceのLBはリージョン指定するタイプの静的IP
IngressはグローバルIPOK
apiVersion: v1
kind: Service
metadata:
name: hoge
labels:
app: hoge
spec:
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はどこに置く
サービス画面のkubectrlから
# backend-config.yaml を作り kubectl apply -f backend-config.yaml
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
namespace: default
name: hello-backend-config
spec:
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要チェック
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/2c4bbe4365b544
ArgoでGKEのCICD（Argoは別ホストでGithubにアクセスし、GKEを操る）
https://www.asobou.co.jp/blog/web/argo-cd
サービスアカウント
Workload Identity Federation for GKEの新しい設定方法を解説 - G-gen Tech Blog
●メモ
忙しいときはスケールアウトするが、落ち着き始めるとスケールinし、必要なPodも落とされてしまう
サービスアカウント
Workload Identity Federation for GKEの新しい設定方法を解説 - G-gen Tech Blog
１）ノードに紐付いたサービスアカウントKSAをそのまま使用する(裏でimpersonate）
gkeのサービスアカウントとIAMサービスアカウントの紐づけが不要になった
VPCサービスコントロールで管理したい場合impersonateのSAを指定できないためWIFが要る
VPCサービスコントロールで管理したい場合impersonateのSAを指定できないためWIFが要る
２）サービスアカウントのキーを Kubernetes Secret として GKE クラスタに登録する
３）Workload Identity FederationをつかうGCP の Workload Identity サービスについてのまとめ #GoogleCloud - Qiita
Githubとか外部のサービスから利用するためSAを連携させる
IAM＞Workload identity連携画面で設定が見れる
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の略）
■GKE関連の運用
GKEクラスタ認証ローテーション
30日以内になると自動ローテーションするが危険なので手動が由
GKEはマイクロサービスのエンドポイントでのサービス提供かgcloud api利用が前提といえるのでこれでOK
1) ローテ開始 (CPのIPとクレデンシャル)
2) ノード再作成
3) APIクライアントを更新 (クレデンシャル再取得)
4) ローテ完了 (元IPと旧クレデンシャルの停止)
GKEクラスタ認証ローテーションの考慮
セキュアなGKEクラスタ
コントロールプレーンの自動アップグレード＆IPローテーション＆ノードブールの自動アップグレードで死ぬ
CPの更新後はクレデンを取得しなおす必要がある、ArgoでCICDを組んでいるとクラスタに認証入りなおす必要があるノードが入れ替わりに時間が掛かり、時間差で問題がでることがあるので注意
Posted by funa : 09:59 PM | Web | Comment (0) | Trackback (0)
- モバイルキーボードアクションカメラ on Aug 17
- ノーの状態 on Jul 18
- BT on Jun 21
- スト６ on Jun 19
- GCP hands-off 3 on Jun 01
| < January 2024 > | ||||||
| Sun | Mon | Tue | Wed | Thi | Fri | Sat |
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 | 31 | |||
- August 2024
- July 2024
- June 2024
- May 2024
- April 2024
- March 2024
- February 2024
- January 2024
- December 2023
- October 2023
- June 2023
- May 2023
- April 2023
- March 2023
- February 2023
- January 2023
- September 2022
- July 2022
- May 2022
- April 2022
- March 2022
- February 2022
- January 2022
- December 2021
- June 2021
- May 2021
- April 2021
- March 2021
- February 2021
- January 2021
- December 2020
- October 2020
- August 2020
- July 2020
- May 2020
- April 2020
- Photo Boo
- デスクトップ通知スケジューラー
- オフライン予約システム
- オフライン予約システム(trancate)
- マラソンペース計算アプリ
- 時給計算アプリ
- ホワイトボード
- Tool(Winパス生成)
- AMAモトクロスマニアッX
- BANGBOOマップ
- えいごたん.jp
- Is This English???
- 無料でセキュリティカメラを設置する
- TOKIO Shock Exchange
- LPIC レベル100
- ICTIL (ITIL)
- DISCO (シスコCCNA)
- Java Lot (Java)
- Jクエネー(jQuery)
- メディアトレーニング
- Hiphop From TV
- BANGBOOナレッジマネジメント
- BANGBOOビジネスカード
