| ページ一覧 | ブログ | twitter |　 書式 | 書式(表) |

MyMemoWiki

「Kubernetes」の版間の差分

提供: MyMemoWiki
ナビゲーションに移動 検索に移動
168行目: 168行目:
  
 
==[https://kubernetes.io/ja/docs/concepts/overview/working-with-objects/namespaces/ Namespace]==
 
==[https://kubernetes.io/ja/docs/concepts/overview/working-with-objects/namespaces/ Namespace]==
 +
*Kubernetesは、同一の物理クラスター上で複数の仮想クラスターの動作をサポートします。 この仮想クラスターをNamespaceと呼びます
 +
*作成:kubectl create namespace <名称>
 +
*削除:kubectl delete namespace <名称>
 +
<pre>
 +
$ kubectl create namespace sample
 +
namespace/sample created
 +
$ kubectl get namespaces
 +
NAME              STATUS  AGE
 +
kube-system      Active  66d
 +
kube-public      Active  66d
 +
kube-node-lease  Active  66d
 +
default          Active  66d
 +
sample            Active  4s
 +
</pre>
 +
 
==[https://kubernetes.io/ja/docs/concepts/workloads/pods/ Pod]==
 
==[https://kubernetes.io/ja/docs/concepts/workloads/pods/ Pod]==
 
*https://kubernetes.io/ja/docs/concepts/workloads/pods/
 
*https://kubernetes.io/ja/docs/concepts/workloads/pods/

2021年1月21日 (木) 15:26時点における版

| Docker | Docker コマンド | Docker ネットワーク | WSL | MicroK8s | Multipass |

目次

Kubernetes

4873118409.09.MZZZZZZZ.jpg link

B07HFS7TDT.09.MZZZZZZZ.jpg link

  • https://kubernetes.io/ja/
  • コンテナ化されたアプリケーションのデプロイ、スケーリングなどの管理を自動化するプラットフォーム（コンテナオーケストレーションエンジン)
  • https://knowledge.sakura.ad.jp/20955/
  • 信頼性が高くスケーラブルな分散システムを上手に構築してデプロイするために必要なソフトウェアを提供
  • 分散システムとは、異なるマシンで動作するAPIを実装する部品の集まり
  • マネージドKubernetesサービス(KaaS:Kubernates-as-a-Service)

チートシート

コンポーネント構成

Kubernetes component.png

宣言的なコードによる管理

  • YAMLやJSONの宣言的なマニフェストで、コンテナやリソースを管理できる

スケーリング/オートスケーリング

  • コンテナクラスタを形成して、複数のKubernetes Nodeを管理できる

スケジューリング

  • コンテナを Kubernetes Nodeにデプロイする際に、どのNodeに配置するかを決定するスケジューリングというステップがある
  • コンテナのワークロードの特徴、Kubernetes Nodeの性能差を意識してスケジューリングを行うことができる

リソース管理

  • コンテナ配置に特別指定がない場合、自動スケジューリングが行われるため、管理する必要がない
  • オートスケール機能により、Kubernetesクラスタの、Kubernetes Nodeの増減も自動で行われる

セルフヒーリング

  • 標準でコンテナのプロセス管理を行っており、プロセス停止を検知すると、再度コンテナのスケジュールを行うことで自動的にコンテナを再デプロイする
  • プロセス監視以外にも、HTTP・TCPや、シェルスクリプトによるヘルスチェックも可能

サービスディスカバリーとロードバランシング

  • ロードバランシング機能（Service)を持っており、事前に指定した条件に合致するコンテナ群に対してルーティングを行う機能を提供する
  • コンテナスケール時や、障害時のサービスへの追加、切り離しも自動で行うため、エンドポイント管理をKubernetesに任せることが可能
  • コンテナを使用したシステム構築では、マイクロサービスアーキテクチャ採用が一般的、マイクロサービスが相互参照するために、サービスディスカバリー機能が有用
  • マイクロサービスを定義されたマニフェストを元にシステム全体を連携させることが可能

データ管理

  • バックエンドのデータ管理にetcdを利用している

基礎

  • Kubernetes は、Kubernetes Master と Kubernetes Node の２種類のノードからから成り立っている
  • Kubernetes Master は、APIエンドポイントの提供コンテナのスケジューリング、コンテナのスケーリングなどを担う
  • Kubernetes Node は、Docker ホストに相当し実際にコンテナが稼働するノード
  • Kubernetes クラスタを操作するには、kubectl と YAML か JSON 形式のマニフェストファイルを用いて、Kuebrnetes Masterにリソースの登録を行う
  • kubectlは、マニフェストファイルの情報を元にKubernetes MasterのAPIにリクエストを送り、Kubernetesの操作を行う
  • Kubernetes の API は一般的な RESTful API として実装されている

構成

クラスタ

  • Kubernetesクラスターは以下の2種類のリソースで構成
    • マスターがクラスターを管理する、マスターはクラスターの管理を担当
    • ノードがアプリケーションを動かすワーカーとなる、ノードは、Kubernetesクラスターのワーカーマシンとして機能するVMまたは物理マシン

Kubelet=

  • 各ノードにはKubeletがあり、これはノードを管理し、Kubernetesマスターと通信するためのエージェント

デプロイ

Kubernetesにアプリケーションをデプロイするときは、

  1. マスターにアプリケーションコンテナを起動するように指示
  2. マスターはコンテナがクラスターのノードで実行されるようにスケジュール
  3. ノードは、マスターが公開しているKubernetes APIを使用してマスターと通信
    1. エンドユーザーは、Kubernetes APIを直接使用して対話することもできます



Kubernetes とリソース

  • Kubernetesでは、リソースを登録することで、コンテナの実行やロードバランサの作成が非同期に行われる

Workloadsリソース

  • クラスタ上にコンテナを起動するために利用する
  • 内部的に利用されているものをのぞき、直接操作するものとしては、以下のリソースがある
    • Pod
    • ReplicationController
    • ReplicaSet
    • Deployment
    • DaemonSet
    • StatefulSet
    • Job
    • CronJob

Pod

  • Workloadsリソースの最小単位
  • 一つ以上のコンテナから構成され、ネットワーク的に隔離されておらず、IPアドレスを共有する
  • 2つのコンテナが入ったPoｄを作成した場合、同一IPアドレスを持ち、お互い、localhostで通信できる
  • 多くの場合は、1つのPodに1つのコンテナを含めるが、補助するサブコンテナを複数含めることもある

Discovery ＆ LBリソース

  • コンテナサービスディスカバリやクラスタの外部からもアクセス可能なエンドポイントなどを提供する
  • 利用者が直接利用するものとしては、Service と Ingress があり、Serviceは複数タイプが用意されている
  • Service
Service 内容
ClusterIP
ExternalIP （ClusterIPの一種)
NodePort
LoadBalancer
Headless （None)
ExternalName
None-Selector
  • Ingress

KubernetesクラスタのネットワークとService

Kubernetesが構成するネットワーク

  • Pod内には複数のコンテナを内包できるが、同じPodであれば、同一IPが割り振られている
  • 同一Podコンテナへ通信を行う場合は、localhostあてに通信を行い、Podのコンテナから別Podコンテナへ通信を行う場合には、PodのIPアドレス宛に通信を行う
  • Kubernetesクラスタは、クラスタを構成するとノードにPodのための内部ネットワークを自動的に構成する
  • 基本的にはノードごとに異なるネットワークセグメントを互いに通信できるよう構成する
  • このような内部ネットワークが自動構成されるため、PodはServiceを利用しなくてもPod間通信を行うことが可能

Serviceを利用することによるメリット

  • Podあてトラフィックのロードバランシング
  • サービスディスカバリとクラスタ内DNS
  • これらは、上記のどのService　Typeからも利用できる

Pod宛トラフィックのロードバランシング

  • Serviceは、複数のPodにロードバランシングを行う
  • Serviceを利用すると、各PodのIPを毎回調べたり、宛先を設定するなど独自に実現しなくても、自動的に構成することができる
  • Serviceは、ロードバランシングのエンドポイントも提供する
    • 外部ロードバランサーが払い出す仮想IP（Virtual IPアドレス)、クラスタ内のみで利用可能な仮想IPアドレス(ClusterIP)など

Config & Storage リソース

  • 設定や機密データをコンテナに埋め込んだり、永続ボリュームを提供する
  • Secret と ConfigMap は Key-Value のデータ構造を持ち保存データが機密か一般化によって使い分ける
  • Secret
  • ConfigMap
  • PersistentVolumeClaim

Cluster リソース

  • クラスタ自体の振る舞いを定義
  • Node
  • Namespace
  • PersistentVolume
  • ResourceQuote
  • ServiceAccount
  • Role
  • ClusterRole
  • RoleBinding
  • ClusterRoleBinding
  • NetworkPolicy

Metadataリソース

  • クラスタ内の他のリソースの動作を制御する
  • LimitRange
  • HorizontalPodAutoscaler
  • PodDisruptionBudget
  • CustomResourceDefinition

Minikube

MicroK8s

Kubectl

Namespace

  • Kubernetesは、同一の物理クラスター上で複数の仮想クラスターの動作をサポートします。 この仮想クラスターをNamespaceと呼びます
  • 作成:kubectl create namespace <名称>
  • 削除:kubectl delete namespace <名称>
  1. $ kubectl create namespace sample
  2. namespace/sample created
  3. $ kubectl get namespaces
  4. NAME              STATUS   AGE
  5. kube-system       Active   66d
  6. kube-public       Active   66d
  7. kube-node-lease   Active   66d
  8. default           Active   66d
  9. sample            Active   4s

Pod

  • https://kubernetes.io/ja/docs/concepts/workloads/pods/
  • 同じ実行環境上で動くアプリケーションコンテナとストレージボリュームの集まりのこと
  • Kubernetesクラスタ上では、コンテナではなくPodがデプロイの最小単位
  • 1つのPodないのコンテナは全て同じマシン上に配置される
  • 同じPod内のアプリケーションは、ネイティブなプロセス間通信チャネルで通信できるが、異なるPodのアプリケーションからは分離されている

Pod単位で考える

  • WordPressとMySQLを同じPodに入れれば良いと考えるのはアンチパターンの1つ
  • それぞれ別マシンで通信できればよく、WordPressとDBが同じ単位としてスケールする可能性も低い
  • WordPress自体はステートレスなため、負荷が増大した場合、WordPressのPodを増やしてスケールさせれば良い
  • 通常は、Podを作る際に、コンテナが異なるマシンに配置されても正常に動作するかという点が判断基準

設定

  1. apiVersion: v1
  2. clusters:
  3. - cluster:
  4.     certificate-authority: /home/piroto/.minikube/ca.crt
  5.     server: https://192.168.39.214:8443
  6.   name: minikube
  7. contexts:
  8. - context:
  9.     cluster: minikube
  10.     user: minikube
  11.   name: minikube
  12. current-context: minikube
  13. kind: Config
  14. preferences: {}
  15. users:
  16. - name: minikube
  17.   user:
  18.     client-certificate: /home/piroto/.minikube/profiles/minikube/client.crt
  19.     client-key: /home/piroto/.minikube/profiles/minikube/client.key

マニフェストとリソースの作成

  • sample-pod.yaml
  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4.   name: sample-pod
  5. spec:
  6.   containers:
  7.     - name: nginx-container
  8.       image: nginx:1.12

実行

  • apply　コマンドを利用すると、存在しなければ生成、更新があれば更新、変更なければ何もしないという挙動
  1. $ kubectl create -f sample-pod.yaml  
  2. pod/sample-pod created
  • 確認
  1. $ kubectl get pod
  2. NAME         READY   STATUS    RESTARTS   AGE
  3. sample-pod   1/1     Running   0          42s
  1. $ kubectl apply -f sample-pod.yaml 
  2. pod/sample-pod configured

アノテーションとラベル

  • 各リソースに対してアノテーションとラベルというメタデータを付与することができる
名称 概要
アノテーション システムコンポーネントが使用するメタデータ.アノテーションを元に処理するシステムコンポーネントが存在しない場合は単なるメモ
ラベル リソース管理に利用するメターデータ.リソースを分別するための情報
  • ユーザーがアノテーションを付与せず作成したリソースでも、下記のように様々なアノテーションが付与される
  1. $ kubectl get deployments -o yaml hello-minikube
  2. apiVersion: apps/v1
  3. kind: Deployment
  4. metadata:
  5.   annotations:
  6.     deployment.kubernetes.io/revision: "1"
  7.   creationTimestamp: "2020-08-22T08:02:54Z"
  8.          :
  • アノテーションとラベルをマニフェストに追記
  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4.   name: sample-pod
  5.   annotations:
  6.     annotation1: val1 
  7.     annotation2: val2
  8.   labels:
  9.     label1: lab1
  10.     label2: lab2
  11. spec:
  12.   containers:
  13.     - name: nginx-container
  14.       image: nginx:1.19
  • 表示の拡張
  1. $ kubectl get pod --output wide
  2. NAME         READY   STATUS    RESTARTS   AGE   IP           NODE       NOMINATED NODE   READINESS GATES
  3. sample-pod   1/1     Running   2          24h   172.17.0.3   minikube   <none>           <none>
  • ダッシュボードに表示された

Kubernetes label.png

Podの削除

  1. $ kubectl delete -f sample-pod.yaml 
  2. pod "sample-pod" deleted

2つのコンテナを内包したPod

  • マニフェスト sample-2pod.yaml
  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4.   name: sample-2pod
  5. spec:
  6.   containers:
  7.     - name: nginx-container
  8.       image: nginx:1.19
  9.     - name: radis-container
  10.       image: redis:6.0.7
  • 適用
  1. $ kubectl apply -f sample-2pod.yaml 
  2. pod/sample-2pod created
  • 結果確認
  1. $ kubectl get pod --output wide
  2. NAME          READY   STATUS    RESTARTS   AGE     IP           NODE       NOMINATED NODE   READINESS GATES
  3. sample-2pod   2/2     Running   0          7m40s   172.17.0.6   minikube   <none>           <none>
  4. sample-pod    1/1     Running   2          2d      172.17.0.3   minikube   <none>           <none>

コンテナへのログインとコマンド実行

  • -t 疑似端末（TTY)を生成し、-i 標準入力をコンテナに渡す
  • /bin/bashコマンドを実行する
  1. $ kubectl exec sample-pod -i -t -- /bin/bash
  2. root@sample-pod:/#

ReplicaSet

  1. apiVersion: apps/v1
  2. kind: ReplicaSet
  3. metadata:
  4.   name: sample-rs
  5. spec:
  6.   replicas: 3
  7.   selector:
  8.     matchLabels:
  9.       app: sample-app
  10.   template:
  11.     metadata:
  12.       labels:
  13.         app: sample-app
  14.     spec:
  15.       containers:
  16.         - name: nginx-container
  17.           image: nginx:1.19
  18.           ports:    
  19.            - containerPort: 80

＊作成 

  1. $ kubectl apply -f sample-rs.yaml 
  2. replicaset.apps/sample-rs created
  • 確認
    • Podが3つ起動していることが確認できる
  1. $ kubectl get pods --output wide
  2. NAME              READY   STATUS    RESTARTS   AGE     IP           NODE       NOMINATED NODE   READINESS GATES
  3. sample-2pod       2/2     Running   0          26h     172.17.0.6   minikube   <none>           <none>
  4. sample-pod        1/1     Running   2          3d2h    172.17.0.3   minikube   <none>           <none>
  5. sample-rs-9gxzs   1/1     Running   0          3m14s   172.17.0.7   minikube   <none>           <none>
  6. sample-rs-nsn86   1/1     Running   0          3m14s   172.17.0.9   minikube   <none>           <none>
  7. sample-rs-wcjsv   1/1     Running   0          3m14s   172.17.0.8   minikube   <none>           <none>
  • ダッシュボードで確認

Kubernetes replicaset.png

Deployment

  • https://kubernetes.io/ja/docs/concepts/workloads/controllers/deployment/
  • 複数のReplicaSetを管理することで、ローリングアップデートやロールバックを実現するリソース
  • Kubernetesで最も推奨されるコンテナの起動方法
  • 1つのコンテナでもDeploymentを使用すべき
  • Deploymentは新しいバージョンのリリースを管理する仕組み
  • デプロイされたアプリケーションをバージョンをまたいで表現する
    • Pod単体では自動で再起動されないし、ReplicaSetでは、ローリングアップデートが利用できない
    • PodもReplicaSetも変更されないコンテナイメージを取り扱うために作られている
  • フロー
    1. 新しいReplicaSetを作成
    2. 新しいReplicaSetのPod数を徐々に増やす
    3. 古いReplicaSetのPod数を徐々に減らす
    4. 上記を繰り返す
    5. 古いReplicaSetのレプリカ数を0で保つ
  1. apiVersion: apps/v1
  2. kind: Deployment
  3. metadata:
  4.   name: sample-deploy
  5. spec:
  6.   replicas: 3
  7.   selector:
  8.     matchLabels:
  9.       app: sample-app
  10.   template:
  11.     metadata:
  12.       labels:
  13.         app: sample-app
  14.     spec:
  15.       containers:
  16.         - name: nginx-container
  17.           image: nginx:1.19
  18.           ports:
  19.            - containerPort: 80
  • 作成
  1. $ kubectl apply -f sample-deploy.yaml 
  2. deployment.apps/sample-rs created
  • 確認(Pod)
  1. $ kubectl get pod --output wide
  2. NAME                             READY   STATUS    RESTARTS   AGE   IP           NODE       NOMINATED NODE   READINESS GATES
  3. sample-deploy-5cc5cfccd7-6vq65   1/1     Running   0          33s   172.17.0.6   minikube   <none>           <none>
  4. sample-deploy-5cc5cfccd7-qjtbx   1/1     Running   0          33s   172.17.0.7   minikube   <none>           <none>
  5. sample-deploy-5cc5cfccd7-szcx5   1/1     Running   0          33s   172.17.0.3   minikube   <none>           <none>
  • 確認(ReplicaSet)
  1. $ kubectl get replicaset --output wide
  2. NAME                       DESIRED   CURRENT   READY   AGE     CONTAINERS        IMAGES       SELECTOR
  3. sample-deploy-5cc5cfccd7   3         3         3       2m34s   nginx-container   nginx:1.19   app=sample-app,pod-template-hash=5cc5cfccd7
  • ダッシュボード

Kubernetes deployment.png

DaemonSet

  • https://kubernetes.io/ja/docs/concepts/workloads/controllers/daemonset/
  • ReplicaSetでは、Podの数が一致するとも確実に配置されるとも保証されない
  • DaemonSetは、ReplicaSetの特殊な形、各ノードにPodを一つづつ配置するリソース
  • 各ノード上で必ず動作させたいプロセスのために利用することが多い
  1. apiVersion: apps/v1
  2. kind: DaemonSet
  3. metadata:
  4.   name: sample-ds
  5. spec:
  6.   selector:
  7.     matchLabels:
  8.       app: sample-app
  9.   template:
  10.     metadata:
  11.       labels:
  12.         app: sample-app
  13.     spec:
  14.       containers:
  15.         - name: nginx-container
  16.           image: nginx:1.19
  • 作成
  1. $ kubectl apply -f sample-ds.yaml 
  2. daemonset.apps/sample-ds created
  • 確認
  1. $ kubectl get daemonset --output wide
  2. NAME        DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE   CONTAINERS        IMAGES       SELECTOR
  3. sample-ds   1         1         1       1            1           <none>          98s   nginx-container   nginx:1.19   app=sample-app

StatefulSet

  1. apiVersion: apps/v1
  2. kind: StatefulSet
  3. metadata:
  4.   name: web
  5. spec:
  6.   selector:
  7.     matchLabels:
  8.       app: sample-app
  9.   serviceName: sample-stateful 
  10.   replicas: 3 
  11.   template:
  12.     metadata:
  13.       labels:
  14.         app: sample-app
  15.     spec:
  16.       terminationGracePeriodSeconds: 10
  17.       containers:
  18.       - name: nginx
  19.         image: nginx:1.19
  20.         ports:
  21.         - containerPort: 80
  22.           name: web
  23.         volumeMounts:
  24.         - name: www
  25.           mountPath: /usr/share/nginx/html
  26.   volumeClaimTemplates:
  27.   - metadata:
  28.       name: www
  29.     spec:
  30.       accessModes: 
  31.       - ReadWriteOnce
  32.       resources:
  33.         requests:
  34.           storage: 1G
  • 作成
  1. $ kubectl apply -f sample-stateful.yaml 
  2. statefulset.apps/web created
  • 確認
  1. $ kubectl get statefulset --output wide
  2. NAME   READY   AGE     CONTAINERS   IMAGES
  3. web    0/3     2m19s   nginx        nginx:1.19

running "VolumeBinding" filter plugin for pod "web-0": pod has unbound immediate PersistentVolumeClaims

  • https://qiita.com/silverbirder/items/d3522237b28703a9adb6
  • PersistentVolumeは、データを永続的に保存しておく場所のリソース。マネージドサービスを利用すると、デフォルトでPresistentVolumeが用意されている
  • PersistentVolumeClaimsは、「PresistentVolumeを使わせて」というリソース
  • PresistentVolumeのnameを指定し、applyすることで、初めてマウントができる
  1. $ kubectl get pv
  2. No resources found in default namespace.

永続ボリューム(PersistentVolume)

PersistentVolume(PV)

  • ストレージクラスを使って管理者もしくは動的にプロビジョニングされるクラスターのストレージの一部
  • Nodeと同じようにクラスターリソースの一部
  • PVを使う個別のPodとは独立したライフサイクルを持っている

PersistentVolumeClaim(PVC)

  • ユーザーによって要求されるストレージ
  • Podと似ています。PodはNodeリソースを消費し、PVCはPVリソースを消費します
  • クレームは特定のサイズやアクセスモード(例えば、1ノードからのみ読み書きマウントができるモードや、複数ノードから読み込み専用マウントができるモードなどです)を要求することができます

実例

index.htmlをノード上に生成

  1. $ minikube ssh
  2. $ sudo mkdir /mnt/data
  3. $ sudo sh -c "echo 'Hello from kubernetes storage' > /mnt/data/index.html"
  4. $ cat /mnt/data/index.html
  5. Hello from kubernetes storage

PersistentVolumeの生成

  • ホストパスのPersistentVolumeを作成
  • Kubernetesは単一クラスターで、ホストパスを開発とテストでサポートする
  • ホストパスPersistentVolumeは、ファイルやディレクトリをネットワークアタッチストレージをエミュレートしたものとして使用する
  • プロダクションのクラスターでは、ホストパスは使用すべきでなく、クラスタ管理者により、用意されたネットワークリソース（Google Compute Engine persistenｔ disk) などを使用する
  • クラスタ管理者は、StorageClassesも動的プロビジョニングに使用することができる
  • ホストパスPersistentVolumeの例
  1. apiVersion: v1
  2. kind: PersistentVolume
  3. metadata:
  4.   name: sample-pv
  5.   labels:
  6.     type: local
  7. spec:
  8.   storageClassName: manual
  9.   capacity:
  10.     storage: 1Gi
  11.   accessModes:
  12.     - ReadWriteOnce
  13.   hostPath:
  14.     path: "/mnt/data"
  • 生成
  1. $ kubectl apply -f sample-pv.yaml 
  2. persistentvolume/sample-pv created
  • 確認
  1. $ kubectl get pv --output wide
  2. NAME        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE   VOLUMEMODE
  3. sample-pv   1Gi        RWO            Retain           Available           manual                  12s   Filesystem

PersistentVolumeClaimの作成

  1. apiVersion: v1
  2. kind: PersistentVolumeClaim
  3. metadata:
  4.   name: sample-pvc
  5. spec:
  6.   storageClassName: manual
  7.   accessModes:
  8.     - ReadWriteOnce
  9.   resources:
  10.     requests:
  11.       storage: 1Gi
  • 生成
  1. $ kubectl apply -f sample-pvc.yaml 
  2. persistentvolumeclaim/sample-pvc created
  • 確認
  1. $ kubectl get pvc --output wide
  2. NAME         STATUS    VOLUME      CAPACITY   ACCESS MODES   STORAGECLASS       AGE   VOLUMEMODE
  3. sample-pvc   Bound     sample-pv   1Gi        RWO            manual             52s   Filesystem

Docker

Dockerデーモンの再利用によるローカルイメージの使用

  1. $ minikube docker-env
  2. export DOCKER_TLS_VERIFY="1"
  3. export DOCKER_HOST="tcp://192.168.39.214:2376"
  4. export DOCKER_CERT_PATH="/home/piroto/.minikube/certs"
  5. export MINIKUBE_ACTIVE_DOCKERD="minikube"
  6.  
  7. # To point your shell to minikube's docker-daemon, run:
  8. # eval $(minikube -p minikube docker-env)
  1. $ docker ps
  2. Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get http://%2Fvar%2Frun%2Fdocker.sock/v1.40/containers/json: dial unix /var/run/docker.sock: connect: permission denied
  1. $ sudo groupadd docker
  2. $ sudo gpasswd -a `id -un` docker
  3. $ sudo chgrp docker /var/run/docker.sock 
  1. $ docker ps
  2. CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

https://hub.docker.com/

Tips


クイックスタート

  1. piroto@jinmu:~$ kubectl get node
  2. NAME       STATUS   ROLES    AGE   VERSION
  3. minikube   Ready    master   14m   v1.18.3
  4. piroto@jinmu:~$ kubectl create deployment hello-minikube --image=k8s.gcr.io/echoserver:1.10
  5. deployment.apps/hello-minikube created
  6. piroto@jinmu:~$ kubectl get pod
  7. NAME                              READY   STATUS              RESTARTS   AGE
  8. hello-minikube-64b64df8c9-42s98   0/1     ContainerCreating   0          11s
  9. piroto@jinmu:~$ kubectl expose deployment hello-minikube --type=NodePort --port=8080
  10. service/hello-minikube exposed
  11. piroto@jinmu:~$ minikube service hello-minikube --url
  12. http://192.168.39.238:30523
  • ローカル環境のクラスターについて詳細を確認するには、出力から得たURLをブラウザー上でコピーアンドペースト

Kubernetes quick start 01.png

  • Service,Deploymentの削除、クラスター停止、クラスター削除
  1. piroto@jinmu:~$ kubectl delete services hello-minikube
  2. service "hello-minikube" deleted
  3. piroto@jinmu:~$ kubectl delete deployment hello-minikube
  4. deployment.apps "hello-minikube" deleted
  5. piroto@jinmu:~$ minikube stop
  6.  ノード "minikube" を停止しています...
  7.  1台のノードが停止しました。
  8. piroto@jinmu:~$ minikube delete
  9.  kvm2 の「minikube」を削除しています...
  10.  クラスタ "minikube" の全てのトレースを削除しました。

NodeでHello　World

「https://www.typea.info/tips_/index.php?title=Kubernetes&oldid=31558」から取得

© 2006 矢木浩人