Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
Kubernetesの基礎.pdf
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
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 Vanilla Kubernetes to a Batteries-Included Platform: Developer Experience at 1,300+ Clusters
yosshi_
0
740
From 5 to 1,300+ Clusters: Declarative Scaling for Private Kubernetes
yosshi_
1
96
Scaling In Kubernetes Safely on On-Prem KaaS Across 1,300+ Clusters and 40,000+ Nodes
yosshi_
1
170
Getting Started with Kubernetes Observability
yosshi_
8
2.8k
PromQL_Compatibility_Testing_Recap
yosshi_
1
1.2k
プロダクト誕生の背景から学ぶ PrometheusとGrafana Loki
yosshi_
11
3.9k
これから学ぶKubernetesのReconciliation Loop
yosshi_
16
5.4k
伝統的なエンプラ企業で取り組むインフラの設計書のモダナイゼーション.pdf
yosshi_
13
6.5k
KubeCon2019_NA_Recap__NATS_.pdf
yosshi_
0
230
Other Decks in Technology
See All in Technology
AIに書かせて、プラットフォームで縛る ― EKSプラットフォームで実践した責任境界と権限設計
elmodev09
1
1.1k
Argo CDとAtlantisで実現するインフラ管理のセルフサービス化──小規模SREチームで支えるプラットフォーム
cassius7
0
260
[2026 Oracle Technical Deep Dive] AI時代のデータベース基盤をどう選ぶ? Exadata Database Serviceの選択肢と使い分け (2026年9月17日開催)
oracle4engineer
PRO
0
100
大阪オフィスに Unitree Go2 がやってきたので Physical AI やってみた
dafujii
0
210
20260929_AmazonGuardDutyの検出通知メールにAWS DevOpsAgentの調査結果を追加する
yhana
1
400
私の推しは「聞いてから進む」AIです -AI-DLCに一人でアプリを作らせた話
yama3133
0
150
2026-09-26 Platform Engineering Kaigi 2026 インフラとアプリの境界線と委譲の設計 / Drawing the Infra and App Line
masasuzu
0
550
ビジネスを止めない技術的負債の返済のための戦略とその手法 - 技術的負債と向き合う / Complexity and Simplicity
soudai
PRO
2
340
10年欲しかった音楽管理アプリを、AIと一緒に作りはじめた
judau
1
200
人にやさしく、AIにやさしく、書き手を選ばないIaCのガードレール再考 / Rethinking IaC Guardrails for Humans and AI Alike
kohbis
5
2k
3人で1000GPU超を統合運用する?マルチクラウド&オンプレを跨ぐ、構築と運用のリアル!
kazukun0716
2
800
Lambda MicroVMsは常駐サーバーの代わりに なるか? Kiro Crew を動かして検証してみた / Kiro Crew on Lambda MicroVMs
k_adachi_01
2
340
Featured
See All Featured
Designing Dashboards & Data Visualisations in Web Apps
destraynor
232
55k
Leo the Paperboy
mayatellez
10
2.3k
The State of eCommerce SEO: How to Win in Today's Products SERPs - #SEOweek
aleyda
2
12k
The SEO identity crisis: Don't let AI make you average
varn
0
570
Git: the NoSQL Database
bkeepers
PRO
432
67k
Mobile First: as difficult as doing things right
swwweet
225
10k
The World Runs on Bad Software
bkeepers
PRO
72
12k
Music & Morning Musume
bryan
48
7.4k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
18k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
123
22k
[RailsConf 2023] Rails as a piece of cake
palkan
59
7k
Dominate Local Search Results - an insider guide to GBP, reviews, and Local SEO
greggifford
PRO
0
350
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完全ガイド