クラウドネイティブのKubernetesリソース管理、名前空間、ポッド、ラベル、デプロイ、サービスの基本的な使用

リソース管理の概要

●Kubernetesの本質はクラスタシステムであり、ユーザーはクラスタ内にさまざまなサービスをデプロイできます。いわゆるデプロイメントサービスは、実際にはKubernetesクラスターでコンテナーを1つずつ実行し、コンテナーで指定されたプログラムを実行します。
Kubernetesの最小の管理単位はコンテナではなくポッドであるため、コンテナはポッドにのみ配置できます。Kubernetesは通常、ポッドを直接管理するのではなく、ポッドコントローラを介してポッドを管理します。
●ポッドがサービスを提供した後、ポッド内のサービスにアクセスする方法を検討する必要があります。Kubernetesは、この機能を実装するためのサービスリソースを提供します。
●もちろん、ポッド内のプログラムのデータを保持する必要がある場合、Kubernetesはさまざまなストレージシステムも提供します。

必須のオブジェクト管理:アクティブなオブジェクトのみを操作でき、監査、追跡、使用はできません

命令型オブジェクトの構成:プロジェクトが大きい場合、構成ファイルが多く、操作が面倒です

名前空間

  • 名前空間はkubernetesシステムで非常に重要なリソースであり、その主な機能は多套系统的资源隔离またはを実装すること多租户的资源隔离です。

  • デフォルトでは、kubernetesクラスター内のすべてのポッドに相互にアクセスできます。ただし、実際には、2つのポッドが相互にアクセスすることを許可したくない場合があるため、2つのポッドを異なる名前空間に分割できます。Kubernetesは、クラスター内のリソースを異なる名前空間に割り当てて、異なるグループ内のリソースの分離された使用と管理を容易にすることで、論理的な「グループ」を形成できます。

  • kubernetesの承認メカニズムを介して、さまざまな名前空間をさまざまなテナントに渡して管理できるため、マルチテナントリソースの分離が実現します。このとき、kubernetesのリソース割り当てメカニズムを組み合わせて、CPU使用率、メモリ使用率など、さまざまなテナントが占有できるリソースを制限して、テナントが利用できるリソースを管理することもできます。

 クラスターが開始された後、kubernetesはデフォルトでいくつかの名前空間を作成します

kubectl get namespace #View
default:名前空間が指定されていないすべてのオブジェクトは、デフォルトの名前空間に割り当てられます。
kube-node-lease:v1.13で導入されたクラスターノード間のハートビートメンテナンス。
kube-public:この名前空間のリソースには、すべてのユーザー(認証されていないユーザーを含む)がアクセスできます。
kube-system:kubernetesシステムによって作成されたすべてのリソースはこの名前空間にあります

ポッド

  • ポッドは、kubernetesクラスター内の最小の管理単位です。プログラムを実行するには、プログラムをコンテナーにデプロイする必要があり、コンテナーはポッドに存在する必要があります。

  • ポッドはコンテナのカプセル化と考えることができ、1つまたは複数のコンテナがポッド内に存在できます。

kubernetesがクラスターを開始すると、クラスター内の各コンポーネントもポッドモードで実行されます。ポッドモードは、次のコマンドで表示できます。

kubectl get pods -n kube-system

主にポッドコントローラを介してポッドを作成して実行します

kubectl run (Pod的名称) [参数]  没有单独运行
# --image 指定Pod的镜像
# --port 指定端口
# --namespace 指定namespace
kubectl run nginx --image=nginx:1.17.1 --port=80 --namespace=dev
查询所有Pod的基本信息
kubectl get pods -n dev
查看Pod的详细信息
kubectl describe pod nginx -n dev
访问Nginx的Pod
kubectl get pods -n dev -o wide
curl 10.244.2.7:80  #ip加端口
删除Nginx的Pod
kubectl delete pod nginx -n dev

命令型オブジェクトの構成、新しいpod-nginx.yamlを作成します

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  namespace: dev
spec:
  containers:
  - image: nginx:1.17.1
    imagePullPolicy: IfNotPresent
    name: pod
    ports: 
    - name: nginx-port
      containerPort: 80
      protocol: TCP

作成および削除コマンドを実行します

kubectl create -f pod-nginx.yaml
kubectl delete -f pod-nginx.yaml

ラベル

ラベルはkubernetesの重要な概念です。その役割は、リソースに識別子を追加して、それらを区別して選択することです。

ラベルの特徴:

  • ラベルは、ノード、ポッド、サービスなど、キー/値のキーと値のペアの形式でさまざまなオブジェクトに添付されます。
  • リソースオブジェクトは任意の数のラベルを定義でき、同じラベルを任意の数のリソースオブジェクトに追加できます。
  • ラベルは通常、リソースオブジェクトが定義されたときに決定されます。もちろん、オブジェクトの作成後に動的に追加または削除することもできます。
  • リソースの多次元グループ化は、バージョンラベル、環境ラベルなどのリソースの割り当て、スケジューリング、構成、および展開を柔軟かつ便利に管理するために、ラベルを介して実現できます。

タグリソース

kubectl label pod xxx key=value [-n 命名空间]
为Nginx的Pod打上标签
kubectl label pod nginx version=1.0 -n dev
更新资源的标签
kubectl label pod xxx key=value [-n 命名空间] --overwrite
kubectl label pod nginx version=2.0 -n dev --overwrite
显示Nginx的Pod的标签
kubectl get pod nginx -n dev --show-labels
筛选标签
kubectl get pod -l version=2.0 -n dev --show-labels
删除标签
kubectl label pod nginx version- -n dev

命令型オブジェクト構成

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  namespace: dev
  labels:
    version: "3.0"
    env: "test"        
spec:
  containers:
  - image: nginx:1.17.1
    imagePullPolicy: IfNotPresent
    name: pod
    ports: 
    - name: nginx-port
      containerPort: 80
      protocol: TCP

作成および削除コマンドを実行します

kubectl create -f pod-nginx.yaml
kubectl delete -f pod-nginx.yaml

展開

  • kubernetesでは、Podが最小のコントロールユニットですが、kubernetesがPodを直接、通常はPodコントローラーを介して制御することはめったにありません。

  • Podコントローラーは、Podリソースが期待される状態を満たしていることを確認するために、Pod管理に使用されます。Podリソースに障害が発生すると、Podを再起動または再構築しようとし、新しく作成されたIPアドレスは元のIPアドレスとは異なります。

デプロイメントがポッドを作成すると、ポッドにラベルが付けられ、ラベルセレクターを介して管理するポッドが選択されます。

#创建2个pod管理nginx命名空间为dev
kubectl run nginx --image=nginx:1.17.1 --replicas=2 --port=80 --namespace dev
#查看
kubectl get deployment,pods -n dev
#查看nginx详细描述
kubectl describe deploy nginx -n dev
#查看标签
kubectl get pods -n dev --show-lables
#删除
kubectl delete deploy nginx -n dev

命令型オブジェクトの構成、deploy-nginx.yamlを作成します

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  namespace: dev
#副本数  选择器
spec:
  replicas: 3
  selector:
    matchLabels:
      run: nginx
  #pod模板    
  template:
    metadata:
      labels:
        run: nginx
    spec:
      containers:
      - image: nginx:1.17.1
        name: nginx
        ports:
        - containerPort: 80
          protocol: TCP
#执行创建和删除命令
kubectl create -f deploy-nginx.yaml
kubectl delete -f deploy-nginx.yaml
#查看创建的Pod
kubectl get pods [-n 命名空间]
#查看名称为dev的namespace下通过deployment创建的3个Pod
kubectl get pods -n dev
#查看deployment的信息
kubectl get deployment [-n 命名空间]
kubectl get deployment -n dev
kubectl describe deployment nginx -n dev
#删除deployment
kubectl delete deployment nginx -n dev

サービス

  • Deploymentを使用してポッドのグループを作成し、高可用性のサービスを提供することができました。各ポッドには個別のポッドIPアドレスが割り当てられますが、次の問題があります。

  • ポッドが再構築されると、ポッドのIPが変更されます。
  • ポッドのIPは、クラスター内に表示され、外部からアクセスできない仮想IPのみです。

サービスは、同じ種類の外部アクセスインターフェイスのポッドのグループと見なすことができます。サービスの助けを借りて、アプリケーションはサービス検出と負荷分散を簡単に実現できます。

#暴露Service
kubectl expose deployment xxx --name=服务名 --type=ClusterIP --port=暴露的端口 --target-port=指向集群中的Pod的端口 [-n 命名空间]
# 新建时借助pod控制器找到对应的pod
#暴露名为test的namespace下的名为nginx的deployment,并设置服务名为svc-nginx1
kubectl expose deployment nginx --name=svc-nginx1 --type=ClusterIP --port=80 --target-port=80 -n test
#查看Service
kubectl get service -n test
#访问
curl 对应集群ip

クラスタの外部からアクセス可能なサービスを再作成します

kubectl expose deployment xxx --name=服务名 --type=NodePort --port=暴露的端口 --target-port=指向集群中的Pod的端口 [-n 命名空间]
# 会产生一个外部也可以访问的Service
kubectl expose deploy nginx --name=svc-nginx2 --type=NodePort --port=80 --target-port=80 -n test
#查看名为test的命名空间的所有Service
kubectl get service -n test
#浏览器访问 查出来的ip与端口号
#删除服务
kubectl delete service svc-nginx1 -n test

オブジェクト構成メソッド、新しいsvc-nginx.yamlを作成します

apiVersion: v1
kind: Service
metadata:
  name: svc-nginx
  namespace: dev
spec:
  clusterIP: 10.109.179.231
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    run: nginx
  type: ClusterIP
执行创建和删除命令
kubectl  create  -f  svc-nginx.yaml
kubectl  delete  -f  svc-nginx.yaml

おすすめ

転載: blog.csdn.net/weixin_52210557/article/details/123810185