Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Kubernetesの基礎.pdf
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
yosshi_
March 25, 2019
Technology
15k
22
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Kubernetesの基礎.pdf
yosshi_
March 25, 2019
More Decks by yosshi_
See All by yosshi_
From 5 to 1,300+ Clusters: Declarative Scaling for Private Kubernetes
yosshi_
0
50
Scaling In Kubernetes Safely on On-Prem KaaS Across 1,300+ Clusters and 40,000+ Nodes
yosshi_
1
87
Getting Started with Kubernetes Observability
yosshi_
8
2.8k
PromQL_Compatibility_Testing_Recap
yosshi_
0
1.2k
プロダクト誕生の背景から学ぶ PrometheusとGrafana Loki
yosshi_
11
3.8k
これから学ぶKubernetesのReconciliation Loop
yosshi_
16
5.3k
伝統的なエンプラ企業で取り組むインフラの設計書のモダナイゼーション.pdf
yosshi_
13
6.4k
KubeCon2019_NA_Recap__NATS_.pdf
yosshi_
0
220
“Running Apache Samza on Kubernetes” Recap : KubeCon2019@NA
yosshi_
3
1.3k
Other Decks in Technology
See All in Technology
サイバー捜査員研修(後半)
nomizone
1
800
Webアクセシビリティ入門 2026
recruitengineers
PRO
2
450
取引先から届く 「セキュリティチェックシート」の読み解き方
kamadamakoto
0
130
AI ネイティブな組織に Gemini Enterprise Agent Platform がなぜ必要なのか
asei
1
190
関東Kaggler会発表資料
takoi
1
170
OSPN.JPバージョンアップ作業進捗のご報告 / 20260801-osc26kyoto
akkiesoft
0
410
【CEDEC2026】『ウマ娘 プリティーダービー』 英語版のキャラクターの方言や口調をローカライズするための創造的アプローチ
cygames
PRO
1
200
【CEDEC2026】グラフィックスエンジニアのためのニューラルシェーディング入門
cygames
PRO
0
120
ホームラボ紹介
y_sera15
0
110
トヨタ⽣産⽅式(TPS)⼊⾨
recruitengineers
PRO
2
630
ブラウザ研修 2026
recruitengineers
PRO
4
780
【CEDEC2026】ゲームシナリオライターを支援するAIツール開発の実践 ― 設計とプロンプトの工夫 ―
cygames
PRO
1
770
Featured
See All Featured
Money Talks: Using Revenue to Get Sh*t Done
nikkihalliwell
0
460
4 Signs Your Business is Dying
shpigford
187
22k
Effective software design: The role of men in debugging patriarchy in IT @ Voxxed Days AMS
baasie
0
470
Heart Work Chapter 1 - Part 1
lfama
PRO
8
36k
Discover your Explorer Soul
emna__ayadi
2
1.2k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
17k
What the history of the web can teach us about the future of AI
inesmontani
PRO
1
650
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
35
2.5k
How GitHub (no longer) Works
holman
316
150k
Why Our Code Smells
bkeepers
PRO
340
58k
The Pragmatic Product Professional
lauravandoore
37
7.4k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
47
8.3k
Transcript
ç Kubernetes基礎 NTT Tech Conference#4 @yosshi_
• 吉村 翔太 • NTTコミュニケーションズ所属 • データサイエンスチーム • インフラエンジニア/データエンジニアリング •
Kubernetes 、Prometheus etc • 登壇 CNDT “Kubernetes Logging入門” etc • コミュニティ活動 “Cloud Native Developers JP” @yosshi_ 自己紹介 “Prometheus Meetup Tokyo”
今日話す内容 • Kubernetesの全体像 – Cluster – kubectl • 基本的な構成要素 –
Workload – Configuration – Discovery & LB – Metadata • kubectlによるオペレーション – Manifestを中心にしたオペレーション – よく使うkubectl
Kubernetesの全体像
Kuberntes(k8s)の全体像 k8s Cluster node master API Server etcd cluster Controller
Manager Scheduler etcd Kubelet Kube-proxy Container runtime コンテナ node Kubelet Kube-proxy Container runtime コンテナ Kubectl これを 今から説明します API Server経由でetcdの操作を行い、etcdの状態に応じてアクションする
Infrastructure components • Master – k8sを管理するコンポーネントが配置されるサーバ群 • Node – コンテナが配置されるサーバ群
• etcd cluster – コンテナが配置されるサーバ群高信頼性KVS、k8sのデータが保存される
Master components • API Server – etcdへのwrite、readを行うAPIサーバ – 複数台配置して冗長化構成をとることができる •
Controller Manager – デプロイするコンテナの個数等を管理する – 複数台配置できるがリーダは1つだけ • Scheduler – コンテナをどのNodeにデプロイするか決める – 複数台配置できるがリーダは1つだけ
Node components • Container runtime – 文字通りコンテナのランタイム – Docker以外を使用することもできる •
Kubelet – Node上に配置されるエージェント – コンテナの起動停止等を行う • Kube-proxy – コンテナとの接続を保証するためにNodeのNWを管理する
kubectl • kubectl – ユーザがk8sを操作する際に使う – 詳細は後述
参考:MasterとControl Plane componentsの違い API Server Scheduler Controller Manager Kubelet Kube-proxy
API Server Scheduler Controller Manager 参照 < https://kubernetes.io/docs/concepts/architecture/master-node-communication/ > こんなニュアンスが多そうだか その限りでもなさそうで困る Master to Clusterの通信とかなんだよ・・ • Control Plane components – k8sを管理するコンポーネントが配置されるサーバ群 • Master – k8sを管理するコンポーネントが配置されるサーバ群
参考:Master Nodeの中身 Controller Manager Kubelet Container runtime API Server Scheduler
Master Control Planeもコンテナだったりする
Kubeadmで構築時のMaster $ systemctl status docker • docker.service - Docker Application
Container Engine Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled) Active: active (running) since Sun 2019-03-24 01:04:19 UTC; 23h ago Docs: https://docs.docker.com Main PID: 1229 (dockerd) Tasks: 211 Memory: 874.2M CPU: 39min 29.172s CGroup: /system.slice/docker.service ├─1229 /usr/bin/dockerd -H fd:// ├─1254 docker-containerd --config /var/run/docker/containerd/containerd.toml ├─2820 docker-containerd-shim -namespace moby -workdir /var/lib/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/808fb・・・ ├─2822 docker-containerd-shim -namespace moby -workdir /var/lib/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/2f33b・・・ $ systemctl status kubelet • kubelet.service - kubelet: The Kubernetes Node Agent Loaded: loaded (/lib/systemd/system/kubelet.service; enabled; vendor preset: enabled) Drop-In: /etc/systemd/system/kubelet.service.d └─10-kubeadm.conf Active: active (running) since Sun 2019-03-24 01:05:58 UTC; 23h ago Docs: https://kubernetes.io/docs/home/ Main PID: 2691 (kubelet) Tasks: 17 Memory: 75.0M CPU: 48min 37.605s CGroup: /system.slice/kubelet.service └─2691 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubel・・・ API Server Controller Manager Scheduler ①Dockerの起動 ②Kubeletの起動 ③ Control Plane componentsが コンテナとして起動
参考:systemctlで“kubelet”を確認する (1/4) $ systemctl status kubelet • kubelet.service - kubelet:
The Kubernetes Node Agent Loaded: loaded (/lib/systemd/system/kubelet.service; enabled; vendor preset: enabled) Drop-In: /etc/systemd/system/kubelet.service.d └─10-kubeadm.conf Active: active (running) since Sun 2019-07-21 03:13:41 UTC; 2 days ago Docs: https://kubernetes.io/docs/home/ Main PID: 17633 (kubelet) Tasks: 18 (limit: 4915) CGroup: /system.slice/kubelet.service └─17633 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --cgroup-driv 起動時にこのconfigを読んでる
参考:systemctlで“kubelet”を確認する (2/4) $ cat /var/lib/kubelet/config.yaml address: 0.0.0.0 apiVersion: kubelet.config.k8s.io/v1beta1 authentication:
anonymous: enabled: false : : serializeImagePulls: true staticPodPath: /etc/kubernetes/manifests streamingConnectionIdleTimeout: 4h0m0s syncFrequency: 1m0s volumeStatsAggPeriod: 1m0s 参考< https://kubernetes.io/docs/tasks/administer-cluster/static-pod/ > Static Pods機能を使うと 起動時に指定したmanifestに書かれたPodを 起動することができる
参考:systemctlで“kubelet”を確認する (3/4) $ ls /etc/kubernetes/manifests etcd.yaml kube-apiserver.yaml kube-controller-manager.yaml kube-scheduler.yaml kubelet起動時にStaticPodsで指定した
Control Plane ComponentsのPodが立つことでKubernetesとして機能している 参考< https://kubernetes.io/docs/tasks/administer-cluster/static-pod/ >
参考systemctlで“kubelet”を確認する (4/4) $ cat /etc/kubernetes/manifests/kube-apiserver.yaml apiVersion: v1 kind: Pod metadata:
creationTimestamp: null labels: component: kube-apiserver tier: control-plane name: kube-apiserver namespace: kube-system spec: containers: : : 中身は普通のyaml
Kuberntes(k8s)の全体像 k8s Cluster node master API Server etcd cluster Controller
Manager Scheduler etcd Kubelet Kube-proxy Container runtime コンテナ node Kubelet Kube-proxy Container runtime コンテナ Kubectl API Server経由でetcdの操作を行い、etcdの状態に一致するようにk8sが変更される
参考:API Serverからetcdにいかない例外の4パターン • “/proxy” – API Serverとの間にproxyをはる • “/exec” –
コンテナでコマンドで実行 • “/attach” – コンテナにattach • “/logs” – コンテナのログを取得 “logs”の場合の通信 Mnaging Kubernetes
Kuberntes(k8s)の全体像 k8s Cluster node master API Server etcd cluster Controller
Manager Scheduler etcd Kubelet Kube-proxy Container runtime コンテナ node Kubelet Kube-proxy Container runtime コンテナ Kubectl マネージドサービスを使うと だけ考えれば良いことが多い オンプレミスだとこれら全てを理解して保証する必要がある
基本的な構成要素
構成要素の全体像 Resources mgt Network / exposition Configuration Storage IAM Pod
generator Creates References Kubernetes Ressources Map 参考< https://github.com/kubernetes/community/tree/master/icons > :今日話す範囲
構成要素の全体像 Resources mgt Network / exposition Configuration Storage IAM Pod
generator Creates References Kubernetes Ressources Map 参考< https://github.com/kubernetes/community/tree/master/icons > :今日話す範囲 ① コンテナの制御 ② コンテナのConfig ③ NW ④ 仮想ク ラスタ 権限制御 ストレージ リソース制限
Workload Configuration Discovery & LB Deployment ReplicaSet Pod Service Secret
ConfigMap k8s Cluster Namespace 今日話す基本的な構成要素の全体図
Workload
Workload Configuration Discovery & LB Deployment ReplicaSet Pod Service Secret
ConfigMap k8s Cluster Namespace 今日話す基本的な構成要素の全体図
Workloadの一覧 名前 略称 説明 Pod - コンテナのデプロイの最小単位 ReplicaSet rs デプロイしたPod数を維持するリソース
Deployment deploy RollingUpdateするためにReplicaSetを管理するリソース DaemonSet ds 各Nodeに1個ずつPodをデプロイするリソース StatefulSet sts Statefulなコンテナのデプロイに対応したリソース Job - Job用のコンテナをデプロイするリソース CronJob - Jobをcron実行するリソース :今日話す範囲
Pod(po) • コンテナのデプロイの最小単位 – 1個のPodに複数のコンテナを定義できる(Sidecar) – 定義された複数のコンテナは必ず同一のNodeにデプロイされる – 複数のコンテナは同一のIPアドレスを共有 node
Kubelet Kube-proxy node Kubelet Kube-proxy コンテナB コンテナA Pod 必ずPod単位でNodeにデプロイされる
Pod(po) コンテナB コンテナA Pod $ kubectl get po –o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nginx-deployment-756bf884bf-gr6qt 2/2 Running 0 10s 10.244.1.2 worker01 <none> <none> spec: containers: - name: nginx1 image: nginx:1.7.9 - name: nginx2 image: nginx:1.7.9 Podの定義 k8s Clusterの状態 NIC Podの中にコンテナが 2個あることが分かる Pod単位にNICが1個ある Podをデプロイすると
ReplicaSet(rs) コンテナA Pod app: nginx 1個のPodにLabelを複数付与できるので、目的の違う PodのLabelの組み合わせが被らないように設計しよう コンテナA Pod app:
nginx コンテナA Pod app: nginx ReplicaSet “replicas: 3” Label Selector ”app: nginx” Podが死んだ場合でも 個数が3になるように管理する • デプロイしたPod数を維持するリソース – Podに付与されているlabelを意識してReplicaSetが制御する
ReplicaSet(rs) kubectl get rs,po -o wide NAME DESIRED CURRENT READY
AGE CONTAINERS IMAGES SELECTOR replicaset.extensions/nginx-deployment-76fbb7bd7b 3 3 3 6s nginx1 nginx:1.7.9 app=nginx,pod-template-hash=76fbb7bd7b NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod/nginx-deployment-76fbb7bd7b-9rhdr 1/1 Running 0 6s 10.244.2.9 worker02 <none> <none> pod/nginx-deployment-76fbb7bd7b-kdsfl 1/1 Running 0 6s 10.244.3.9 worker03 <none> <none> pod/nginx-deployment-76fbb7bd7b-x566n 1/1 Running 0 6s 10.244.1.9 worker01 <none> <none> spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx1 image: nginx:1.7.9 ReplicaSetの定義 k8s Clusterの状態 同一のreplicasetの管理下で あることが分かる ReplicaSetをデプロイすると ReplicaSetで管理するPodのLabel Podに付与するLabel ReplicaSetのLabel Selector
Deployment(deploy) コンテナA Pod ReplicaSet 旧 コンテナA Pod コンテナA’ Pod ReplicaSet
新 コンテナA’ Pod Deployment 新しいReplicaSetが作られて Podも順次作られる 旧のReplicaSetのreplicas の数が減って Podも順次削除される • RollingUpdateするためにReplicaSetを管理するリソース
Deployment(deploy) kubectl get deploy,rs,po -o wide NAME READY UP-TO-DATE AVAILABLE
AGE CONTAINERS IMAGES SELECTOR deployment.extensions/nginx-deployment 3/3 3 3 118m nginx1 nginx:1.12 app=nginx NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR replicaset.extensions/nginx-deployment-5fbf59df75 2 2 1 3s nginx1 nginx:1.12 app=nginx,pod-template-hash=5fbf59df75 replicaset.extensions/nginx-deployment-76fbb7bd7b 2 2 2 114m nginx1 nginx:1.7.9 app=nginx,pod-template-hash=76fbb7bd7b NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod/nginx-deployment-5fbf59df75-55j5b 0/1 ContainerCreating 0 1s <none> worker03 <none> <none> pod/nginx-deployment-5fbf59df75-fwqpn 1/1 Running 0 3s 10.244.1.10 worker01 <none> <none> pod/nginx-deployment-76fbb7bd7b-9rhdr 1/1 Running 0 114m 10.244.2.9 worker02 <none> <none> pod/nginx-deployment-76fbb7bd7b-kdsfl 1/1 Running 0 114m 10.244.3.9 worker03 <none> <none> pod/nginx-deployment-76fbb7bd7b-x566n 1/1 Terminating 0 114m 10.244.1.9 worker01 <none> <none> k8s Clusterの状態 Podの削除と新規作成が 順次行われる imageを変更してデプロイ “1.7.9” -> “1.12” spec: containers: - name: nginx1 image: nginx:1.12 新しいReplicaSetが作られる Deploymentの定義
Workloadの一覧 名前 略称 説明 Pod - コンテナのデプロイの最小単位 ReplicaSet rs デプロイしたPod数を維持するリソース
Deployment deploy RollingUpdateするためにReplicaSetを管理するリソース DaemonSet ds 各Nodeに1個ずつPodをデプロイするリソース StatefulSet sts Statefulなコンテナのデプロイに対応したリソース Job - Job用のコンテナをデプロイするリソース CronJob - Jobをcron実行するリソース :今日話す範囲
参考:WorkLoadのリソースの関係 Deployment CronJob ReplicaSet StatefulSet Pod DaemonSet Job Pod Pod
Pod StatefulSetがReplicaSetを操作してたりするわけじゃない Kuberntes完全ガイド
Configuration
Workload Configuration Discovery & LB Deployment ReplicaSet Pod Service Secret
ConfigMap k8s Cluster Namespace 今日話す基本的な構成要素の全体図
Configurationの一覧 名前 説明 Configmap 設定情報をkey-valueの形式で保持するリソース Sercret 機密情報を保持するリソース
ConfigMap • 設定情報をkey-valueの形式で保持するリソース • 作り方 – Manifestを書く – ファイルから作る (–frome-file,kustomize:configMapGenerator)
• 使い方 – 環境変数とする – Volumeとしてマウントする apiVersion: v1 kind: Pod metadata: name: dapi-test-pod spec: containers: - name: test-container image: k8s.gcr.io/busybox command: [ "/bin/sh", "-c", "env" ] env: - name: SPECIAL_LEVEL_KEY valueFrom: configMapKeyRef: name: special-config key: special.how apiVersion: v1 kind: ConfigMap metadata: name: special-config namespace: default data: special.how: very ConfigMapの定義 Podの定義
Sercretの一覧 種類 説明 opaque Key-valueで機密情報を保持する kubernetes.io/service-account-token サービスアカウント用の機密情報を保持する kubernetes.io/dockerconfigjson Dockerレジストリ用の機密情報を保持する kubernetes.io/basic-auth
Basic認証用の機密情報を保持する kubernetes.io/ssh-auth SSH用の機密情報を保持する kubernetes.io/tls TLS用の機密情報を保持する 参考< https://docs.koki.io/short/resources/secret/ > :今日話す範囲
Sercret”Type:Opaque”について • Key-valueの形式で機密情報を保持する – 扱い方はConfigmap • Configmapと違い – 値がBASE64エンコードされる –
ディスクではなく、tmpfsに配置される – リソースタイプがConfigmapではなくSecret
Sercret”Type:Opaque”について • 使う目的 – ID,Password等を格納する (例えばDBのアクセス用のとか) • 使い方 – secretに対して特定のユーザを除き”Get”、”List”の権限を与えない
– Gitで管理するときにConfigmapとは管理方法を分ける Configmapとは別のリソースタイプなのでそれぞれ別の権限管理を 行えることに意味がある。 名前から受ける印象じゃなくて 仕様を理解して使うことが大事
Discovery & LB
Workload Configuration Discovery & LB Deployment ReplicaSet Pod Service Secret
ConfigMap k8s Cluster Namespace 今日話す基本的な構成要素の全体図
ClusterIP コンテナ B Pod ClusterIP コンテナA Pod コンテナ B Pod
コンテナ B Pod LBされる 10.244.1.10 10.244.1.10 Service名で アクセスする 10.244.2.10 10.244.3.10 アプリがDBにアクセスするときもよく使う • クラスタ内のアクセスを保証する – クラスタ内のPodへアクセスをLBする – Service名で名前解決してクラスタ内のPodへアクセスする LabelとSelectorの仕組みにより IPアドレスの管理から解放される
NodePort • クラスタ外からクラスタのPortを指定してアクセスする – クラスタの全てのNodeの特定のPortへのアクセスをPodへ保証する
Serviceのデプロイ kubectl get svc,po -o wide NAME TYPE CLUSTER-IP EXTERNAL-IP
PORT(S) AGE SELECTOR service/svc-sample NodePort 10.110.100.22 <none> 8080:31706/TCP 17s app=nginx NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod/nginx-deployment-5fbf59df75-55j5b 1/1 Running 0 83m 10.244.3.10 worker03 <none> <none> pod/nginx-deployment-5fbf59df75-6hnbq 1/1 Running 0 83m 10.244.2.10 worker02 <none> <none> pod/nginx-deployment-5fbf59df75-fwqpn 1/1 Running 0 83m 10.244.1.10 worker01 <none> <none> NodePortをデプロイする apiVersion: v1 kind: Servicemetadata: name: svc-sample spec: type: NodePort ports: - name: "http-port“ protocol: "TCP“ port: 8080 targetPort: 80 selector: app: nginx NodePortが確認できる NodePortでも ClusterIPが付与される
Describeで、より詳細を見てみる kubectl describe svc svc-sample Name: svc-sample Namespace: default Labels:
<none> Annotations: kubectl.kubernetes.io/last-applied-configuration: {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"name":"svc-sample","namespace":"defaultSelector: app=nginxType: NodePortIP: 10.110.100.22 Port: http-port 8080/TCP TargetPort: 80/TCP NodePort: http-port 31706/TCP Endpoints: 10.244.1.10:80,10.244.2.10:80,10.244.3.10:80 Session Affinity: None External Traffic Policy: Cluster Events: <none> k8s Clusterの状態 ServiceとPodが対応してることがわかる kubectl get po -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod/nginx-deployment-5fbf59df75-55j5b 1/1 Running 0 83m 10.244.3.10 worker03 <none> <none> pod/nginx-deployment-5fbf59df75-6hnbq 1/1 Running 0 83m 10.244.2.10 worker02 <none> <none> pod/nginx-deployment-5fbf59df75-fwqpn 1/1 Running 0 83m 10.244.1.10 worker01 <none> <none> NodePortが確認できる
kubeadm config view kubeadm config view apiServer: extraArgs: authorization-mode: Node,RBAC
timeoutForControlPlane: 4m0s apiVersion: kubeadm.k8s.io/v1beta1 certificatesDir: /etc/kubernetes/pki clusterName: kubernetescontrolPlane Endpoint: "“ controllerManager: {} dns: type: CoreDNSetcd: local: dataDir: /var/lib/etcdimageRepository: k8s.gcr.io kind: ClusterConfiguration kubernetesVersion: v1.13.4 networking: dnsDomain: cluster.local podSubnet: 10.244.0.0/16 serviceSubnet: 10.96.0.0/12 scheduler: {} k8s Clusterの状態 PodとServiceはNWが別
Metadata
Workload Configuration Discovery & LB Deployment ReplicaSet Pod Service Secret
ConfigMap k8s Cluster Namespace 今日話す基本的な構成要素の全体図
Namespace • 1つのクラスタの中を仮想のクラスタで分けることができる • 使い方 – 商用、検証、開発環境で1つのクラスタの中で分ける – 開発チーム単位で分ける –
あるプロダクト単位で分ける – etc Namespace単位で分けてもクラスタ全体に対する障害については影響を受ける 爆発半径はクラスタ単位で分けた方が小さいが、クラスタ管理コストが増える傾向にある
Workload Configuration Discovery & LB Deployment ReplicaSet Pod Service Secret
ConfigMap k8s Cluster Namespace 今日話す基本的な構成要素の全体図(復習)
kubectl
Manifestを中心にしたオペレーション apiVersion: v1 kind: Servicemetadata: name: svc-sample spec: type: NodePort
ports: - name: "http-port“ protocol: "TCP“ port: 8080 targetPort: 80 selector: app: nginx Kubectl API Server k8s Cluster • 基本的にManifestを作成してk8sを操作する – 他のやり方も可能だが状態が観測できなくなる – git等でManifestを管理することでk8sの状態を把握しやすくなる
よく使うkubectlコマンド 種類 説明 kubectl apply リソースを作成する kubectl delete リソースを削除する kubectl
get Node pod などのリソースの情報を取得 kubectl describe リソースの詳細情報を取得 kubectl logs コンテナのログを確認する kubectl exec コンテナでコマンドを実行する
参考:書籍 しくみがわかるKuberntes Kubernetes実践入門 Mnaging Kubernetes Kuberntes完全ガイド