冬休みでもう少し k8s に親しくなるため、適当に触る
EKS をセットアップ
eksctl からクラスター作成
eksctl create cluster
eksctl get cluster attractive-sculpture-1672376633
eksctl get nodegroup --cluster attractive-sculpture-1672376633
kubeconfig をアップデート
aws eks update-kubeconfig --region ap-northeast-1 --name attractive-sculpture-1672376633
kubectl get all
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kubernetes ClusterIP 10.100.0.1 <none> 443/TCP 14m
Add-Onがほぼない
eksctl get addon --cluster attractive-sculpture-1672376633
コンソールから色々追加
- CoreDNS
- AmazonVPC CNI
- AWS DIstro for OpenTelemetry
- kube-proxy
eksctl get addon --cluster attractive-sculpture-1672376633
2022-12-30 14:41:03 [ℹ] Kubernetes version "1.24" in use by cluster "attractive-sculpture-1672376633"
2022-12-30 14:41:03 [ℹ] getting all addons
2022-12-30 14:41:06 [ℹ] to see issues for an addon run `eksctl get addon --name <addon-name> --cluster <cluster-name>`
NAME VERSION STATUS ISSUES IAMROLE UPDATE AVAILABLE CONFIGURATION VALUES
coredns v1.8.7-eksbuild.2 ACTIVE 0
kube-proxy v1.23.7-eksbuild.1 ACTIVE 0 v1.24.7-eksbuild.2,v1.23.13-eksbuild.2,v1.23.8-eksbuild.2
vpc-cni v1.10.4-eksbuild.1 ACTIVE 0 v1.12.0-eksbuild.1,v1.11.4-eksbuild.2,v1.11.4-eksbuild.1
kubectl get events
アプリ追加
kubectl apply -f examples/guestbook/
kubectl get pods
NAME READY STATUS RESTARTS AGE
frontend-f7d9c57d4-8rt4b 0/1 ContainerCreating 0 9s
frontend-f7d9c57d4-h8tqx 0/1 ContainerCreating 0 9s
frontend-f7d9c57d4-lpv56 0/1 ContainerCreating 0 9s
redis-master-857d99cc8-gqrjk 0/1 ContainerCreating 0 9s
redis-replica-566d4f87dc-2tbs9 0/1 ContainerCreating 0 9s
redis-replica-566d4f87dc-nszz5 0/1 ContainerCreating 0 9s
Ingress Controller の追加
kubectl apply -f deploy.yaml
kubectl get events
AWS Console から作成
![[Pasted image 20221229143755.png]]
eksctl
eksctl register cluster --name test --provider EKS_ANYWHERE --region ap-northeast-1
# クラスター情報確認
eksctl get cluster test
NAME VERSION STATUS CREATED VPC SUBNETS SECURITYGROUPS PROVIDER
test 1.24 ACTIVE 2022-12-29T03:30:06Z vpc-0d809879c178a4b0a subnet-066b742eb83b445be,subnet-0939c5e5328791a0c,subnet-0
# リソース確認
eksctl get nodegroup --cluster test
CLUSTER NODEGROUP STATUS CREATED MIN SIZE MAX SIZE DESIRED CAPACITY INSTANCE TYPE IMAGE ID ASG NAME TYPE
test test-nodegroup CREATE_FAILED 2022-12-29T05:17:51Z 2 2 2 t3.medium AL2_x86_64 eks-test-nodegroup-10c2ae28-5701-cfa2-01cc-e3e3a0ea8e9e managed
# add-on確認
eksctl get addon --cluster test
2022-12-29 16:26:35 [ℹ] Kubernetes version "1.24" in use by cluster "test"
2022-12-29 16:26:35 [ℹ] getting all addons
2022-12-29 16:26:37 [ℹ] to see issues for an addon run `eksctl get addon --name <addon-name> --cluster <cluster-name>`
NAME VERSION STATUS ISSUES IAMROLE UPDATE AVAILABLE CONFIGURATION VALUES
coredns v1.8.7-eksbuild.3 DEGRADED 1
kube-proxy v1.24.7-eksbuild.2 ACTIVE 0
vpc-cni v1.11.4-eksbuild.1 ACTIVE 0 v1.12.0-eksbuild.1
kubectl
aws eks update-kubeconfig --region ap-northeast-1 --name test
- ekssctl : eks が管理するクラスターマスターノード周りの管理や情報確認、アドオンとかバージョンアップとか
- kubectl : 実際にデプロイされる k8s アプリケーション側の設定とか
アプリ追加してみる
git clone git@github.com:kubernetes/examples.git
ls -la examples/guestbook
total 64
drwxr-xr-x 14 shuaki staff 448 Dec 29 16:53 .
drwxr-xr-x 19 shuaki staff 608 Dec 29 16:53 ..
-rw-r--r-- 1 shuaki staff 367 Dec 29 16:53 MAINTENANCE.md
-rw-r--r-- 1 shuaki staff 239 Dec 29 16:53 README.md
drwxr-xr-x 5 shuaki staff 160 Dec 29 16:53 all-in-one
-rw-r--r-- 1 shuaki staff 900 Dec 29 16:53 frontend-deployment.yaml
-rw-r--r-- 1 shuaki staff 437 Dec 29 16:53 frontend-service.yaml
drwxr-xr-x 5 shuaki staff 160 Dec 29 16:53 legacy
drwxr-xr-x 7 shuaki staff 224 Dec 29 16:53 php-redis
-rw-r--r-- 1 shuaki staff 607 Dec 29 16:53 redis-master-deployment.yaml
-rw-r--r-- 1 shuaki staff 233 Dec 29 16:53 redis-master-service.yaml
-rw-r--r-- 1 shuaki staff 947 Dec 29 16:53 redis-replica-deployment.yaml
-rw-r--r-- 1 shuaki staff 215 Dec 29 16:53 redis-replica-service.yaml
drwxr-xr-x 5 shuaki staff 160 Dec 29 16:53 redis-slave
cat README.md
# Example: Guestbook application on Kubernetes
This directory contains the source code and Kubernetes manifests for PHP
Guestbook application.
PHPアプリがある
apply でディレクトリ指定した場合、そのディレクトリのマニフェストファイルが全部実行される
grep -rn apiVersion * -A 5
めっちゃある
kubectl apply -f examples/guestbook/
設定確認
kubectl get all
NAME READY STATUS RESTARTS AGE
pod/frontend-f7d9c57d4-66kpf 0/1 Pending 0 22s
pod/frontend-f7d9c57d4-kt2gc 0/1 Pending 0 22s
pod/frontend-f7d9c57d4-vgr9s 0/1 Pending 0 22s
pod/redis-master-857d99cc8-t8q7c 0/1 Pending 0 22s
pod/redis-replica-566d4f87dc-m4bx2 0/1 Pending 0 21s
pod/redis-replica-566d4f87dc-p8nq7 0/1 Pending 0 21s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/frontend NodePort 10.100.214.71 <none> 80:30482/TCP 22s
service/kubernetes ClusterIP 10.100.0.1 <none> 443/TCP 4h29m
service/redis-master ClusterIP 10.100.31.164 <none> 6379/TCP 21s
service/redis-replica ClusterIP 10.100.88.254 <none> 6379/TCP 21s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/frontend 0/3 3 0 22s
deployment.apps/redis-master 0/1 1 0 22s
deployment.apps/redis-replica 0/2 2 0 21s
NAME DESIRED CURRENT READY AGE
replicaset.apps/frontend-f7d9c57d4 3 3 0 22s
replicaset.apps/redis-master-857d99cc8 1 1 0 22s
replicaset.apps/redis-replica-566d4f87dc 2 2 0 21s
外部からのアクセスを許可(Ingress Controller を追加)
https://aws.amazon.com/jp/premiumsupport/knowledge-center/eks-access-kubernetes-services/ LB配置が必要。AWS の LB もしくは、NGINXを利用
wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/aws/deploy.yaml
# めちゃくちゃ長いので抜粋
cat deploy.yaml
- namespace のデプロイ
- serviceaccount のデプロイ : Pod から k8s API を呼び出すための認可の仕組み
- ingress-nginx
- ingress-nginx-admission
- role のデプロイ : ServiceAccount の 認可を定義するもの
- Rules : 認可の仕組み。Allow 飲み
- ingress-nginx
- 一杯権限ついてる
- ingress-nginx-admission
- 権限ほぼついてない
rules の例
- apiGroups:
- ""
resources:
- namespaces
verbs:
- get
[""]はコアの API グループを示す・ resources は名前空間。 verbs が API の種類
- ClusterRole
- Role : ある namespace で権限を設定する
- ClusterRole : NameSpace に属さないリソース
- nginx-ingress
- ingress-nginx-admission
- RoleBinding
- バインドする設定
- ConfigMap
- https://kubernetes.io/ja/docs/concepts/configuration/configmap/
- 機密性の高いデータを保存する KVS
- data
- allow-snippet-annotations: “true”
- Service
- ingress-nginx-controller : アノテーションで設定を記載
- ingress-nginx-controller-admission
- Deployment : Pod と ReplicaSet のアップデート機能を提供 : アップデートの仕組みを提供するためのグループとかそういうの。Deployment 単位で B/G デプロイとかが可能
- Job : Jobは一つ以上のPodを作成し、指定された数のPodが正常に終了するまで、Podの実行を再試行し続ける
- IngressClass
- 特定の Ingress Controller を Ingress に関連づけるためのもの.
- Kubernetes クラスター内の Ingress タイプを指定するために使用
- ValidatingWebhookConfiguration
- その名の通りリクエストを通していいかどうかのチェックのための設定
- clientConfig がチェック内容
clientConfig:
service:
name: ingress-nginx-controller-admission
namespace: ingress-nginx
path: /networking/v1/ingresses
すべての service.beta.kubernetes.io アノテーションを以下に置き換えます。
service.beta.kubernetes.io/aws-load-balancer-backend-protocol: tcp
service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true"
service.beta.kubernetes.io/aws-load-balancer-type: "external"
service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "instance"
service.beta.kubernetes.io/aws-load-balancer-scheme: "internet-facing"
デプロイ
kubectl apply -f deploy.yaml
no nodes available to schedule pods
kubectl get nodes
No resources found
確かにない
kubectl get events
LAST SEEN TYPE REASON OBJECT MESSAGE
3m11s Warning FailedScheduling pod/frontend-f7d9c57d4-66kpf no nodes available to schedule pods
3m11s Warning FailedScheduling pod/frontend-f7d9c57d4-kt2gc no nodes available to schedule pods
3m11s Warning FailedScheduling pod/frontend-f7d9c57d4-vgr9s no nodes available to schedule pods
3m11s Warning FailedScheduling pod/redis-master-857d99cc8-t8q7c no nodes available to schedule pods
3m11s Warning FailedScheduling pod/redis-replica-566d4f87dc-m4bx2 no nodes available to schedule pods
3m11s Warning FailedScheduling pod/redis-replica-566d4f87dc-p8nq7 no nodes available to schedule pods
eksctl get nodegroups --cluster test
CLUSTER NODEGROUP STATUS CREATED MIN SIZE MAX SIZE DESIRED CAPACITY INSTANCE TYPE IMAGE ID ASG NAME TYPE
test test CREATING 2022-12-29T17:40:15Z 2 2 2 t3.medium AL2_x86_64 managed
test test-role CREATING 2022-12-29T17:45:07Z 2 2 2 t3.medium AL2_x86_64 managed
あ〜、eksctl で create してないと一部しかコマンド使えない https://eksctl.io/usage/unowned-clusters/
eksctl get cluster --name test
NAME VERSION STATUS CREATED VPC SUBNETS SECURITYGROUPS PROVIDER
test 1.24 ACTIVE 2022-12-29T03:30:06Z vpc-0d809879c178a4b0a subnet-066b742eb83b445be,subnet-0939c5e5328791a0c,subnet-0e61cc31aa55151be sg-0f9e3910323937b46 EKS
一応、ファイルからやればノード登録は可能らしい
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: test
region: ap-northeast-1
vpc:
id: "vpc-0d809879c178a4b0a"
securityGroup: "sg-0f9e3910323937b46" # this is the ControlPlaneSecurityGroup
subnets:
private:
private1:
id: "subnet-066b742eb83b445be"
private2:
id: "subnet-0939c5e5328791a0c"
private3:
id: "subnet-0e61cc31aa55151be"
managedNodeGroups:
- name: eks-ng-blue
instanceType: t2.small
desiredCapacity: 2
minSize: 1
maxSize: 3
privateNetworking: true
ssh:
publicKeyName: rsa_com_key
allow: true
labels: {role: worker}
tags:
nodegroup-role: worker
eksctl create nodegroup -f node.yaml
2022-12-30 03:36:30 [ℹ] will use version 1.24 for new nodegroup(s) based on control plane version
2022-12-30 03:36:31 [!] no eksctl-managed CloudFormation stacks found for "test", will attempt to create nodegroup(s) on non eksctl-managed cluster
2022-12-30 03:36:34 [ℹ] nodegroup "eks-ng-blue" will use "" [AmazonLinux2/1.24]
2022-12-30 03:36:34 [ℹ] using EC2 key pair "rsa_com_key"
2022-12-30 03:36:34 [ℹ] 2 existing nodegroup(s) (test,test-role) will be excluded
2022-12-30 03:36:34 [ℹ] 1 nodegroup (eks-ng-blue) was included (based on the include/exclude rules)
2022-12-30 03:36:34 [ℹ] will create a CloudFormation stack for each of 1 managed nodegroups in cluster "test"
2022-12-30 03:36:34 [ℹ] 1 task: { 1 task: { 1 task: { create managed nodegroup "eks-ng-blue" } } }
2022-12-30 03:36:34 [ℹ] building managed nodegroup stack "eksctl-test-nodegroup-eks-ng-blue"
2022-12-30 03:36:34 [ℹ] deploying stack "eksctl-test-nodegroup-eks-ng-blue"
2022-12-30 03:36:34 [ℹ] waiting for CloudFormation stack "eksctl-test-nodegroup-eks-ng-blue"
Fargate Profile : どの Pod が Fargate を使うかを決めるもの
eksctl create fargateprofile
eksctl create fargateprofile \
--cluster test \
--name my-fargate-profile \
--namespace test \
--labels key=value
以下が制約っぽい？
--namespace my-kubernetes-namespace \
--labels key=value
Node :
https://kubernetes.io/ja/docs/concepts/architecture/nodes/
- コンテナを配置する Pod を実行するための物理マシン or VM
- 1ノード中には kubelet、コンテナランタイム、kube-proxy が最低限含まれる（他ノードとの通信用）
- 登録方法は2type
- すでに稼働しているノード自身から kubelet で所属する（kubelet で register コマンドがある）
- ノードを作成して登録する
- 基本は Pod がノード上に配置される。配置されないようにするには Cordon を行う cordon = schedule 不可のマークをつけること
EKS の設定確認
https://kubernetes.io/docs/reference/kubectl/cheatsheet/
kubectl config view
# cat .kube/config からほとんど同じ情報を持ってくる
- cluster:
certificate-authority-data: DATA+OMITTED
server: https://497C2C8D101DA10B0B6BBA1304551ABE.gr7.ap-northeast-1.eks.amazonaws.com
name: arn:aws:eks:ap-northeast-1:hogehoge:cluster/test
kube-system 名前空間のものを確認
kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
default frontend-f7d9c57d4-66kpf 0/1 Pending 0 9h
default frontend-f7d9c57d4-kt2gc 0/1 Pending 0 9h
default frontend-f7d9c57d4-vgr9s 0/1 Pending 0 9h
default redis-master-857d99cc8-t8q7c 0/1 Pending 0 9h
default redis-replica-566d4f87dc-m4bx2 0/1 Pending 0 9h
default redis-replica-566d4f87dc-p8nq7 0/1 Pending 0 9h
ingress-nginx ingress-nginx-admission-create-4bk9v 0/1 Pending 0 47m
ingress-nginx ingress-nginx-admission-patch-lvc7x 0/1 Pending 0 47m
ingress-nginx ingress-nginx-controller-6f7bd4bcfb-w89gs 0/1 Pending 0 47m
kube-system coredns-5fc8d4cdcf-l9p9v 0/1 Pending 0 14h
kube-system coredns-5fc8d4cdcf-n2gpk 0/1 Pending 0 14h
kubectl get namespace
NAME STATUS AGE
default Active 14h
ingress-nginx Active 52m
kube-node-lease Active 14h
kube-public Active 14h
kube-system Active 14h
kubectl get pods --namespace=kube-system
NAME READY STATUS RESTARTS AGE
coredns-5fc8d4cdcf-l9p9v 0/1 Pending 0 14h
coredns-5fc8d4cdcf-n2gpk 0/1 Pending 0 14h
# おそらくデプロイ時に指定したもの？
kubectl get pod coredns-5fc8d4cdcf-n2gpk -o yaml --namespace=kube-system
coredns 設定確認
- Podをデプロイしている
- Node Affinity : デプロイしたいPod を、適当な Node ではなくて、特定の Node 集合へスケジュールするための仕組み。今回だと、EKS のサービス側コアノードにデプロイしたい? それとも全ノードへインストールする感じ？それともコア側は無視する？ Ignore だから除外条件を指定しているっぽい
- その下にコンテナイメージ設定とポートバインディング設定がある
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/os
operator: In
values:
- linux
- key: kubernetes.io/arch
operator: In
values:
- amd64
- arm64
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- podAffinityTerm:
labelSelector:
matchExpressions:
- key: k8s-app
operator: In
values:
- kube-dns
topologyKey: kubernetes.io/hostname
weight: 100
https://docs.aws.amazon.com/eks/latest/userguide/sec-group-reqs.html k8s の NG 作成時にタグ指定しつつ、SG も追加