差分

==| [[Docker]] | [[KubernetesDocker コマンド]]==| [[Dockerネットワーク]] | [[WSL]] | [[MicroK8s]] | [[Multipass]] | ==[https://kubernetes.io/ja/ Kubernetes]==

==minikube=[https://kubernetes.io/ja/docs/reference/kubectl/cheatsheet/ チートシート]===*[https://githubkubernetes.comio/ja/docs/reference/kubectl/cheatsheet/ チートシート]===コンポーネント構成===*https://kubernetes.io/docs/concepts/overview/components/*https://www.slideshare.net/yokawasa/minikubeistio-114360124 から引用[[File:kubernetes_component.png|600px]] ===宣言的なコードによる管理===*ローカル開発や学習、テスト用のシンプルな[[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にアプリケーションをデプロイするときは、#マスターにアプリケーションコンテナを起動するように指示#マスターはコンテナがクラスターのノードで実行されるようにスケジュール#ノードは、マスターが公開しているKubernetes APIを使用してマスターと通信##エンドユーザーは、Kubernetes APIを直接使用して対話することもできます    ====Kubernetes とリソース====*Kubernetesでは、リソースを登録することで、コンテナの実行やロードバランサの作成が非同期に行われる ==Workloadsリソース==*クラスタ上にコンテナを起動するために利用する*内部的に利用されているものをのぞき、直接操作するものとしては、以下のリソースがある**Pod**ReplicationController**ReplicaSet*シングルノードクラスタで、インストールには、ローカルマシンにハイパーバイザーがインストールされていること*Deployment*VT*DaemonSet**StatefulSet**Job**CronJob===Pod===*Workloadsリソースの最小単位*一つ以上のコンテナから構成され、ネットワーク的に隔離されておらず、IPアドレスを共有する*2つのコンテナが入ったPoｄを作成した場合、同一IPアドレスを持ち、お互い、localhostで通信できる*多くの場合は、1つのPodに1つのコンテナを含めるが、補助するサブコンテナを複数含めることもある ==Discovery ＆ LBリソース==*コンテナサービスディスカバリやクラスタの外部からもアクセス可能なエンドポイントなどを提供する*利用者が直接利用するものとしては、Service と Ingress があり、Serviceは複数タイプが用意されている*Service{| class="wikitable"|-! scope="col"| Service! 内容|-| ClusterIP| |-| ExternalIP （ClusterIPの一種)| |-| NodePort| |-| LoadBalancer| |-| Headless （None)| |-| ExternalName| |-| None-Selector| |-x/AMD|}*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-v Value のデータ構造を持ち保存データが機密か一般化によって使い分ける*Secret*ConfigMap*PersistentVolumeClaim ==Cluster リソース==*クラスタ自体の振る舞いを定義*Node*Namespace*PersistentVolume*ResourceQuote*ServiceAccount*Role*ClusterRole*RoleBinding*ClusterRoleBinding*NetworkPolicy ==Metadataリソース==*クラスタ内の他のリソースの動作を制御する*LimitRange*HorizontalPodAutoscaler*PodDisruptionBudget*CustomResourceDefinition==[[Minikube]]==*[[Minikube]] ==[[仮想化MicroK8s]]がBIOSで有効化されていること。==*[[MicroK8s]]==[[Kubectl]]==*[[Kubectl]] ==[https://kubernetes.io/ja/docs/setupconcepts/overview/working-with-objects/namespaces/ Namespace]==*Kubernetesは、同一の物理クラスター上で複数の仮想クラスターの動作をサポートします。 この仮想クラスターをNamespaceと呼びます*作成:kubectl create namespace <名称>*削除:kubectl delete namespace <名称><pre>$ kubectl create namespace samplenamespace/learningsample created$ kubectl get namespacesNAME STATUS AGEkube-system Active 66dkube-public Active 66dkube-node-environmentlease Active 66ddefault Active 66dsample Active 4s</pre> ==[https://kubernetes.io/ja/docs/concepts/workloads/minikubepods/ Minikubeを使用してローカル環境でKubernetesを動かす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を作る際に、コンテナが異なるマシンに配置されても正常に動作するかという点が判断基準 ===インストール設定===*設定を行う箇所は、clusters,contexts,users*[[YAML]] もしくは JSONフォーマット*直接編集するだけでなく、kubectlから変更も可能*https://kubernetes.io/docs/tasksreference/generated/kubernetes-api/v1.19/#pod-v1-core<pre>apiVersion: v1clusters:- cluster: certificate-authority: /home/piroto/.minikube/ca.crt server: https://192.168.39.214:8443 name: minikubecontexts:- context: cluster: minikube user: minikube name: minikubecurrent-context: minikubekind: Configpreferences: {}users:- name: minikube user: client-certificate: /home/piroto/.minikube/profiles/toolsminikube/installclient.crt client-key: /home/piroto/.minikube/profiles/minikube/client.key</pre>===マニフェストとリソースの作成===*sample-pod.yaml<pre>apiVersion: v1kind: Podmetadata: name: sample-podspec: containers: - name: nginx-container image: nginx:1.12</pre>====実行====*apply　コマンドを利用すると、存在しなければ生成、更新があれば更新、変更なければ何もしないという挙動<pre>$ kubectl create -f sample-pod.yaml pod/sample-pod created</pre>*確認<pre>$ kubectl get podNAME READY STATUS RESTARTS AGEsample-pod 1/1 Running 0 42s</pre> <pre>$ kubectl apply -f sample-pod.yaml pod/sample-pod configured</pre> ===アノテーションとラベル===*各リソースに対してアノテーションとラベルというメタデータを付与することができる{| class="wikitable"!名称!概要|-|アノテーション|システムコンポーネントが使用するメタデータ.アノテーションを元に処理するシステムコンポーネントが存在しない場合は単なるメモ|-|ラベル|リソース管理に利用するメターデータ.リソースを分別するための情報|}*ユーザーがアノテーションを付与せず作成したリソースでも、下記のように様々なアノテーションが付与される<pre>$ kubectl get deployments -o yaml hello-minikubeapiVersion: apps/v1kind: Deploymentmetadata: annotations: deployment.kubernetes.io/revision: "1" creationTimestamp: "2020-08-22T08:02:54Z" :</pre>*アノテーションとラベルをマニフェストに追記<pre>apiVersion: v1kind: Podmetadata: name: sample-pod annotations: annotation1: val1 annotation2: val2 labels: label1: lab1 label2: lab2spec: containers: - name: nginx-container image: nginx:1.19</pre> *表示の拡張<pre>$ kubectl get pod --output wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESsample-pod 1/1 Running 2 24h 172.17.0.3 minikube <none> <none></pre>*ダッシュボードに表示された[[File:Kubernetes_label.png|600px]] ====Podの削除====<pre>$ kubectl delete -f sample-pod.yaml pod "sample-pod" deleted</pre>===2つのコンテナを内包したPod===*マニフェスト sample-2pod.yaml<pre>apiVersion: v1kind: Podmetadata: name: sample-2podspec: containers: - name: nginx-container image: nginx:1.19 - name: radis-container image: redis:6.0.7</pre>*適用<pre>$ kubectl apply -f sample-2pod.yaml pod/sample-2pod created</pre>*結果確認<pre>$ kubectl get pod --output wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESsample-2pod 2/2 Running 0 7m40s 172.17.0.6 minikube <none> <none>sample-pod 1/1 Running 2 2d 172.17.0.3 minikube <none> <none></pre> ===コンテナへのログインとコマンド実行===*-t 疑似端末（TTY)を生成し、-i 標準入力をコンテナに渡す* /bin/bashコマンドを実行する<pre>$ kubectl exec sample-pod -i -t -- /bin/bashroot@sample-pod:/# </pre>

====Ubuntu + 仮想環境==[https://kubernetes.io/ja/docs/concepts/workloads/controllers/replicaset/ ReplicaSet]==*[https://wwwkubernetes.typeaio/ja/docs/concepts/workloads/controllers/replicaset/*Podのレプリカを作成するリソース*レプリカ数=3でスケールさせたReplicaSet<pre>apiVersion: apps/v1kind: ReplicaSetmetadata: name: sample-rsspec: replicas: 3 selector: matchLabels: app: sample-app template: metadata: labels: app: sample-app spec: containers: - name: nginx-container image: nginx:1.info19 ports: - containerPort: 80</blog/indexpre>＊作成<pre>$ kubectl apply -f sample-rs.yaml replicaset.phpapps/2020sample-rs created</08pre>*確認**Podが3つ起動していることが確認できる<pre>$ kubectl get pods --output wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESsample-2pod 2/222 Running 0 26h 172.17.0.6 minikube <none> <none>sample-pod 1/ubuntu1 Running 2 3d2h 172.17.0.3 minikube <none> <none>sample-kvmrs-bridge9gxzs 1/1 Running 0 3m14s 172.17.0.7 minikube <none> <none>sample-rs-networknsn86 1/ Ubuntu 仮想環境(KVM)構築1 Running 0 3m14s 172.17.0.9 minikube <none> <none>sample-rs-wcjsv 1/1 Running 0 3m14s 172.17.0.8 minikube <none> <none></pre>*ダッシュボードで確認[[File:kubernetes_replicaset.png|600px]]

==[https://kubernetes.io/ja/docs/concepts/workloads/controllers/deployment/ Deployment]==入手====*https://kubernetes.io/ja/docs/concepts/workloads/controllers/deployment/*複数のReplicaSetを管理することで、ローリングアップデートやロールバックを実現するリソース*Kubernetesで最も推奨されるコンテナの起動方法*1つのコンテナでもDeploymentを使用すべき*Deploymentは新しいバージョンのリリースを管理する仕組み*デプロイされたアプリケーションをバージョンをまたいで表現する**Pod単体では自動で再起動されないし、ReplicaSetでは、ローリングアップデートが利用できない**PodもReplicaSetも変更されないコンテナイメージを取り扱うために作られている*フロー*#新しいReplicaSetを作成*#新しいReplicaSetのPod数を徐々に増やす*#古いReplicaSetのPod数を徐々に減らす*#上記を繰り返す*#古いReplicaSetのレプリカ数を0で保つ<pre>apiVersion: apps/v1kind: Deploymentmetadata: name: sample-deployspec: replicas: 3 selector: matchLabels: app: sample-app template: metadata: labels: app: sample-app spec: containers: - name: nginx-container image: nginx:1.19 ports: - containerPort: 80</pre>*作成

$ curl kubectl apply -Lo minikube https://storagef sample-deploy.googleapisyaml deployment.comapps/minikube/releases/latest/minikube-linuxsample-amd64$ sudo +x minkubers created

$ sudo install minikube /usr/local/binkubectl get replicaset --output wideNAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTORsample-deploy-5cc5cfccd7 3 3 3 2m34s nginx-container nginx:1.19 app=sample-app,pod-template-hash=5cc5cfccd7

===利用=======ローカルクラスタの作成====*ローカル仮想マシンを作成*[[Kubernetes]]を設定*kubectlを設定 &gt; minikube start*VirtualBox[[File:0753_minikube.png|400px]]*Ubuntu+KVMダッシュボード[[File:Minikube_kvmkubernetes_deployment.png|400px600px]]

==[https://kubernetes.io/ja/docs/concepts/workloads/controllers/daemonset/ DaemonSet]==停止==== &gt; minikube stop*https://kubernetes.io/ja/docs/concepts/workloads/controllers/daemonset/*ReplicaSetでは、Podの数が一致するとも確実に配置されるとも保証されない====クラスタを削除====*DaemonSetは、ReplicaSetの特殊な形、各ノードにPodを一つづつ配置するリソース &gt; minikube delete*各ノード上で必ず動作させたいプロセスのために利用することが多い

<pre>apiVersion: apps/v1kind: DaemonSetmetadata: name: sample-dsspec: selector: matchLabels: app: sample-app template: metadata: labels: app: sample-app spec: containers: - name: nginx-container image: nginx:1.19</pre>*作成<pre>$ kubectl apply -f sample-ds.yaml daemonset.apps/sample-ds created</pre>*確認<pre>$ kubectl get daemonset --output wideNAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE CONTAINERS IMAGES SELECTORsample-ds 1 1 1 1 1 <none> 98s nginx-container nginx:1.19 app=sample-app</pre> ==[[Kubernetes]https://kubernetes.io/ja/docs/concepts/workloads/controllers/statefulset/ StatefulSet]クライアント==*公式なクライアントは、kubectlhttps://kubernetes.io/ja/docs/concepts/workloads/controllers/statefulset/*データベースなどステートフルなワークロードに対応するためのリソース*ReplicaSetの特殊な形**作成されるPodのサフィックスは数字のインデックスが付与*kubectlを使用してクラスターと対話できるようになります*データを永続化する仕組みを持つ**Pod名が変わらない<pre>apiVersion: apps/v1kind: StatefulSetmetadata: name: webspec: selector: matchLabels: app: sample-app serviceName: sample-stateful replicas: 3 template: metadata: labels: app: sample-app spec: terminationGracePeriodSeconds: 10 containers: - name: nginx image: nginx:1.19 ports: - containerPort: 80 name: web volumeMounts: - name: www mountPath: /usr/share/nginx/html volumeClaimTemplates: - metadata: name: www spec: accessModes: - ReadWriteOnce resources: requests: storage: 1G</pre>*[[Kubernetes]] APIと連携するコマンドラインツール作成<pre>$ kubectl apply -f sample-stateful.yaml statefulset.apps/web created</pre>*minikube から利用する場合確認<pre> &gt; minikube $ kubectl versionget statefulset --output wideNAME READY AGE CONTAINERS IMAGESweb 0/3 2m19s nginx nginx:1.19</pre><q>running "VolumeBinding" filter plugin for pod "web-0": pod has unbound immediate PersistentVolumeClaims</q>*https://qiita.com/silverbirder/items/d3522237b28703a9adb6*PersistentVolumeは、データを永続的に保存しておく場所のリソース。マネージドサービスを利用すると、デフォルトでPresistentVolumeが用意されている*PersistentVolumeClaimsは、「PresistentVolumeを使わせて」というリソース*PresistentVolumeのnameを指定し、applyすることで、初めてマウントができる

$ curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectlget pv$ sudo chmod +x No resources found in default namespace./kubectl$ sudo install kubectl /usr/local/bin

==[https://kubernetes.io/ja/docs/concepts/storage/persistent-volumes/ 永続ボリューム(PersistentVolume)]=ダッシュボード=*https://kubernetes.io/ja/docs/concepts/storage/persistent-volumes/*ストレージが何から提供されているか、どのように消費されているかをユーザーと管理者から抽象化するAPIを提供===PersistentVolume(PV)===*ストレージクラスを使って管理者もしくは動的にプロビジョニングされるクラスターのストレージの一部*Nodeと同じようにクラスターリソースの一部*PVを使う個別のPodとは独立したライフサイクルを持っている===PersistentVolumeClaim(PVC)===*ユーザーによって要求されるストレージ*Podと似ています。PodはNodeリソースを消費し、PVCはPVリソースを消費します*クレームは特定のサイズやアクセスモード(例えば、1ノードからのみ読み書きマウントができるモードや、複数ノードから読み込み専用マウントができるモードなどです)を要求することができます===実例===*https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/====index.htmlをノード上に生成====<pre>$ minikube ssh$ sudo mkdir /mnt/data$ sudo sh -c "echo 'Hello from kubernetes storage' > /mnt/data/index.html"$ cat /mnt/data/index.htmlHello from kubernetes storage</pre>====PersistentVolumeの生成====*ホストパスのPersistentVolumeを作成*Kubernetesは単一クラスターで、ホストパスを開発とテストでサポートする*ホストパスPersistentVolumeは、ファイルやディレクトリをネットワークアタッチストレージをエミュレートしたものとして使用する*プロダクションのクラスターでは、ホストパスは使用すべきでなく、クラスタ管理者により、用意されたネットワークリソース（Google Compute Engine persistenｔ disk) などを使用する*クラスタ管理者は、StorageClassesも動的プロビジョニングに使用することができる*ホストパスPersistentVolumeの例<pre>apiVersion: v1kind: PersistentVolumemetadata: name: sample-pv labels: type: localspec: storageClassName: manual capacity: storage: 1Gi accessModes: - ReadWriteOnce hostPath: path: "/mnt/data"</pre>*生成

$ minikube dashboardkubectl apply -f sample-pv.yaml persistentvolume/sample-pv created</pre>*確認<pre>$ kubectl get pv --output wideNAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE VOLUMEMODEsample-pv 1Gi RWO Retain Available manual 12s Filesystem</pre>====PersistentVolumeClaimの作成====<pre>apiVersion: v1kind: PersistentVolumeClaimmetadata: name: sample-pvcspec: storageClassName: manual accessModes: - ReadWriteOnce resources: requests: storage: 1Gi</pre>*生成<pre>$ kubectl apply -f sample-pvc.yaml persistentvolumeclaim/sample-pvc created</pre>*確認<pre>$ kubectl get pvc --output wideNAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE VOLUMEMODEsample-pvc Bound sample-pv 1Gi RWO manual 52s Filesystem

==[[Docker]]=Kubernetes Deploymentを作る=*[[Docker]]*[[Docker コマンド]]*[[Docker ネットワーク]]===Dockerデーモンの再利用によるローカルイメージの使用===*単純なHTTPサーバーであるechoserverという既存のイメージを使用して、Kubernetes Deploymentを作る[https://kubernetes.io/ja/docs/setup/learning-environment/minikube/#docker%E3%83%87%E3%83%BC%E3%83%A2%E3%83%B3%E3%81%AE%E5%86%8D%E5%88%A9%E7%94%A8%E3%81%AB%E3%82%88%E3%82%8B%E3%83%AD%E3%83%BC%E3%82%AB%E3%83%AB%E3%82%A4%E3%83%A1%E3%83%BC%E3%82%B8%E3%81%AE%E4%BD%BF%E7%94%A8 Dockerデーモンの再利用によるローカルイメージの使用]*Mac/LinuxのホストでDockerデーモンを操作できるようにするには、minikube docker-envを実行*MinikubeのVM内のDockerデーモンと通信しているホストのMac/LinuxマシンのコマンドラインでDockerを使用できるようになる<pre>$ minikube docker-portを使用して8080番ポートで公開envexport DOCKER_TLS_VERIFY="1"export DOCKER_HOST="tcp://192.168.39.214:2376"export DOCKER_CERT_PATH="/home/piroto/.minikube/certs"export MINIKUBE_ACTIVE_DOCKERD="minikube"

===クラスタのステータス===# To point your shell to minikube's docker-daemon, run: &gt;# eval $(minikube kubectl version-p minikube docker-env)</pre> <pre>$ docker ps Client VersionGot permission denied while trying to connect to the Docker daemon socket at unix: version///var/run/docker.Info{Majorsock:"1", MinorGet http:"15", [[Git]]Version:"//%2Fvar%2Frun%2Fdocker.sock/v1.15.0", [[Git]]Commit:"e8462b5b5dc2584fdcd18e6bcfe9f1e4d970a529", [[Git]]TreeState:"clean", BuildDate:"2019-06-19T16:40/containers/json:16Z", GoVersion:"go1dial unix /var/run/docker.12.5", Compilersock:"gc", Platformconnect:"windowspermission denied</amd64"}pre> Server Version*https: version//tech.Info{Major:"1", Minor:"15", [[Git]]Version:"v1librastudio.15co.0", [[Git]]Commit:"e8462b5b5dc2584fdcd18e6bcfe9f1e4d970a529", [[Git]]TreeState:"clean", BuildDate:"2019jp/entry/index.php/2018/07/14/post-1924/<pre>$ sudo groupadd docker$ sudo gpasswd -06a `id -19T16:32:14Z", GoVersion:"go1un` docker$ sudo chgrp docker /var/run/docker.12.5", Compiler:"gc", Platform:"linuxsock </amd64"}pre>

*クラスタを構成しているコンポーネントを確認<pre> &gt; minikube kubectl get componentstatuses　$ docker ps NAME CONTAINER ID IMAGE COMMAND CREATED STATUS MESSAGE E[[R]][[R]]O[[R]] controller-manager Healthy ok scheduler Healthy ok PORTS NAMES etcd-0 Healthy {"health":"true"}</pre>

====ワーカーノードの表示====*kubectl get nodes &gt; minikube kubectl get nodes NAME STATUS [[R]]OLES AGE VE[[R]]SION minikube [[R]]eady master 36m v1https://hub.15docker.0com/

====ノードの詳細情報==Tips==*kubectl describe nodes [ノード名[WSL|WSL2でKubernetes/Dockerを動かす]]

==kubectlコマンド=クイックスタート====Namespace==*https://kubernetes.io/ja/docs/setup/learning-environment/minikube/<pre>piroto@jinmu:~$ kubectl get nodeNAME STATUS ROLES AGE VERSIONminikube Ready master 14m v1.18.3piroto@jinmu:~$ kubectl create deployment hello-minikube --image=k8s.gcr.io/echoserver:1.10deployment.apps/hello-minikube created*クラスタ内のオブジェクトを構造化piroto@jinmu:~$ kubectl get pod*kubectlはデフォルトではdefaultというNamespaceとやり取りNAME READY STATUS RESTARTS AGE*hello-minikube-64b64df8c9-namespace で指定できる42s98 0/1 ContainerCreating 0 11spiroto@jinmu:~$ kubectl expose deployment hello-minikube --type=NodePort --port==Context===8080*デフォルトのNamespaceを恒久的に変更したい場合service/hello-minikube exposed*piroto@jinmu:~$HOMEminikube service hello-minikube --urlhttp://192.168.39.kube238:30523</config に保存されるpre>*ローカル環境のクラスターについて詳細を確認するには、出力から得たURLをブラウザー上でコピーアンドペースト===[[File:Kubernetesquick start 01.png|600px]] APIオブジェクトの参照*Service,Deploymentの削除、クラスター停止、クラスター削除<pre>piroto@jinmu:~$ kubectl delete services hello-minikubeservice "hello-minikube" deletedpiroto@jinmu:~$ kubectl delete deployment hello-minikubedeployment.apps "hello-minikube" deletedpiroto@jinmu:~$ minikube stop ノード "minikube" を停止しています... 1台のノードが停止しました。piroto@jinmu:~$ minikube delete kvm2 の「minikube」を削除しています... クラスタ "minikube" の全てのトレースを削除しました。</pre>===NodeでHello　World===*[[Kubernetes]]上にあるものは、すべてRESTFulリソースであらわされるhttps://kubernetes.io/ja/docs/tutorials/hello-minikube/