目录

• API概述
• Pod管理
• 删除Pod
• Pod添加服务，ClusterIP进行内部访问
• 修改service服务，ClusterIP改为NodePort，供外部访问
• Pod扩容/缩容
• Pod版本更新/回滚

 

 

一、API 对象

    API对象:也就是k8s的资源对象，是K8s集群中的管理操作单元。K8s集群系统每支持一项新功能，引入一项新技
    术，一定会新引入对应的API对象，支持对该功能的管理操作。
        API对象3大类属性：
            metadata（元数据）：元数据是用来标识API对象的，每个对象都至少有3个元数据：namespace，name和uid;除此以外还有各种各样的标签labels用来标识和匹配不同的对象
            spec（规范）：spec 是必需的，它描述了对象的期望状态（Desired State），希望对象所具有的特征
            status（状态）：status 描述了对象的 实际状态（Actual State），它是由 Kubernetes 系统提供和更新的。
    API对象使用kubectl 工具的三种管理方式：
        命令式命令：直接使用命令行方式直接操作资源对象，格式：kubectl commands
        命令式对象配置 ：使用对象配置文件进行对资源的操作，格式：kubectl commands -f <filename|url>
        声明式对象配置：与命令式对象配置类似，但是不直接使用配置文件，而是声明配置文件的路径，系统自动调用配置文件，格式： kubectl commands -f <directory>/
    Label（标签）：Label 是识别 Kubernetes 对象的标签，以 key/value 的方式附加到对象上（key 最长不
    能超过 63 字节，value 可以为空，也可以是不超过 253 字节的字符串）。
        Label 不提供唯一性，并且实际上经常是很多对象（如 Pods）都使用相同的 label 来标志具体的应用。Label 定义好后其他对象可以使用 Label Selector 来选择一组相同 label 的对象（比如ReplicaSet 和 Service 用 label 来选择一组 Pod）。
        Label Selector 支持以下几种方式：
            等式：如 app=nginx 和 env!=production
            集合：如 env in (production, qa)
            多个 label（它们之间是 AND 关系）：如 app=nginx,env=test
    Annotations（注解）：Annotations 是以 key/value 形式附加于对象的注解。不同于 Labels 用于标志和选择对象，Annotations 则是用来记录一些附加信息，用来辅助应用部署、安全策略以及调度策略等。
    对象分类：
        POD：基础资源，包含一个以上的容器
        控制器：Replication Controller、ReplicaSet、Deployment、DaemonSet、StatefulSet、Job、CronJob
        服务发现：service、ingress
        身份与权限控制：Service Account、Network Policy、kubernetes-network-policy-recipes、Security Context、RBAC
        存储配置、Secret、ConfigMap、Volume、Persistent Volume、Local Volume、Storage Class
        API扩展：应用扩展定义自定义API对象

POD

    Pod：是 Kubernetes 应用程序的基本执行单元，即它是 Kubernetes 对象模型中创建或部署的最小和最简单的单元。Pod 表示在集群上运行的进程
    一个Pod封装一个应用容器（也可以有多个容器），存储资源、一个独立的网络IP以及管理控制容器运行方式的策略选项
    副本：每个 Pod 表示运行给定应用程序的单个实例。如果希望横向扩展应用程序（例如，运行多个实例），则应该使用多个 Pod，每个应用实例使用一个 Pod ，这种相同的Pod应用实例就是副本。通常使用一个称为控制器的抽象来创建和管理一组副本 Pod。
    Pod 具有 初始容器 和 应用容器。初始容器会在启动应用容器之前运行并完成
        初始容器（init Pod）：应用容器运行前必须先运行完成的一个或多个初始化容器。
            初始化容器必须在应用容器启动前运行完成。
            初始化容器的运行顺序：一个初始化容器必须在下一个初始化容器开始前运行完成。
            指定容器为 Init 容器，需要在 Pod 的 spec 中添加 initContainers 字段
        应用容器：相对初始化容器而言，是在pod中运行工作的容器
    Pod 为其组成容器提供了两种共享资源：网络和存储
        网络：每个 Pod 分配一个唯一的 IP 地址。 Pod 中的每个容器共享网络命名空间，包括 IP 地址和网络端口。 Pod 内的容器 可以使用 localhost 互相通信。 当 Pod 中的容器与 Pod 之外 的实体通信时，它们必须协调如何使用共享的网络资源（例如端口）
        存储：一个 Pod 可以指定一组共享存储卷。 Pod 中的所有容器都可以访问共享卷，允许这些容器共享数据。 卷还允许 Pod 中的持久数据保留下来，以防其中的容器需要重新启动。
 

 

二、pod管理

创建pod应用

创建pod有两种方式 ：命令创建、和文件创建 （k8s和的docker相比k8s的操作步骤更加的繁琐所以一般都使用文件的方式来实现的）

• 用命令的方式来创建pod

 

1、用命令的方式来创建pod

[kubeadm@server1 ～]$ kubectl run nginx --image=nginx --replicas=3 --record
# run 创建一个pod 名称为nginx 使用镜像nginx 副本数为3
#--record 命令方式最好添加，可以记录命令内容
kubectl run --generator=deployment/apps.v1 is DEPRECATED and will be removed in a future version. Use kubectl run --generator=run-pod/v1 or kubectl create instead.
deployment.apps/nginx created
[kubeadm@server1 ~]$
[kubeadm@server1 ~]$ kubectl get pod
NAME                     READY   STATUS    RESTARTS   AGE
nginx-6db489d4b7-c6xxf   1/1     Running   0          91m
nginx-6db489d4b7-dnpgp   1/1     Running   0          91m
nginx-6db489d4b7-zdrqv   1/1     Running   0          91m
[kubeadm@server1 ~]$
[kubeadm@server1 ~]$

 

1.1、查看副本的创建信息

 

1.2、创建副本是从私有仓库拉取信息

 

1.3、在网页上查看私有仓库镜像被拉取的信息

 

 

2、在server1查看镜像被拉取的情况

 

 

2.1、一个pod中可以创建多个镜像的副本

[kubeadm@server1 ~]$ kubectl run game2048 --image=game2048 --replicas=3 --record   ##创建镜像为game2048的3个pod副本
kubectl run --generator=deployment/apps.v1 is DEPRECATED and will be removed in a future version. Use kubectl run --generator=run-pod/v1 or kubectl create instead.
deployment.apps/game2048 created    
[kubeadm@server1 ~]$

[kubeadm@server1 ~]$ kubectl get pod      ##查看pod副本
NAME                       READY   STATUS    RESTARTS   AGE
game2048-9b587cc77-424fw   1/1     Running   0          5m8s
game2048-9b587cc77-h8brf   1/1     Running   0          5m7s
game2048-9b587cc77-kgq8t   1/1     Running   0          5m7s
nginx-6db489d4b7-c6xxf     1/1     Running   0          170m
nginx-6db489d4b7-dnpgp     1/1     Running   0          170m
nginx-6db489d4b7-zdrqv     1/1     Running   0          170m
[kubeadm@server1 ~]$


[kubeadm@server1 ~]$ kubectl describe pod game2048-9b587cc77-424fw    查看pod副本的详细信息 
Name:         game2048-9b587cc77-424fw
Namespace:    default
Priority:     0
Node:         server4/172.25.6.4
Start Time:   Mon, 24 Feb 2020 09:20:58 -0500
Labels:       pod-template-hash=9b587cc77
              run=game2048
Annotations:  <none>
Status:       Running
IP:           10.244.1.7
IPs:
  IP:           10.244.1.7
Controlled By:  ReplicaSet/game2048-9b587cc77
Containers:
  game2048:
    Container ID:   docker://58da26333de27c1b483890f60f7e27915ab0e62929dafdc69e03367f41e9844e
    Image:          game2048
    Image ID:       docker-pullable://game2048@sha256:8a34fb9cb168c420604b6e5d32ca6d412cb0d533a826b313b190535c03fe9390
    Port:           <none>
    Host Port:      <none>
    State:          Running
      Started:      Mon, 24 Feb 2020 09:25:45 -0500
    Ready:          True
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-ddbmj (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             True
  ContainersReady   True
  PodScheduled      True
Volumes:
  default-token-ddbmj:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-ddbmj
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type     Reason                  Age        From               Message
  ----     ------                  ----       ----               -------
  Normal   Scheduled               <unknown>  default-scheduler  Successfully assigned default/game2048-9b587cc77-424fw to server4
  Warning  FailedCreatePodSandBox  4m34s      kubelet, server4   Failed to create pod sandbox: rpc error: code = Unknown desc = failed to start sandbox container for pod "game2048-9b587cc77-424fw": operation timeout: context deadline exceeded
  Normal   SandboxChanged          4m31s      kubelet, server4   Pod sandbox changed, it will be killed and re-created.
  Normal   Pulling                 3m44s      kubelet, server4   Pulling image "game2048"
  Normal   Pulled                  2m2s       kubelet, server4   Successfully pulled image "game2048"
  Normal   Created                 2m1s       kubelet, server4   Created container game2048
  Normal   Started                 2m         kubelet, server4   Started container game2048

 

 

三、删除Pod

1. 自动生成的pod，会默认使用控制器RS，RS控制器会自动生成一个新的pod，保持开始设定的副本数
2.如果不像pod自动修复，可在开始部署pod的时候，添加参数--restart=Never，pod就不会修复了，但是要求副本数为1
3.或者直接通过deployment删除生成的控制器，便可以销毁pod，但是同时销毁了所有pod

• 删除Pod副本
• 彻底删除pod副本

 

1、删除Pod副本

 

1.2、因为有pod管理文件

kubectl get -o yaml    

 

2、彻底删pod副本（删除控制器）

[kubeadm@server1 ~]$ kubectl  get deployments.apps     ##pod的所对应镜像 以及每个镜像对应的副本个数 
NAME       READY   UP-TO-DATE   AVAILABLE   AGE
game2048   3/3     3            3           35m
nginx      3/3     3            3           3h20m

[kubeadm@server1 ~]$ kubectl delete deployments.apps  game2048   ##彻底删除game2048镜像 
deployment.apps "game2048" deleted

[kubeadm@server1 ~]$ kubectl  get deployments.apps                ##重新进行查看
NAME    READY   UP-TO-DATE   AVAILABLE   AGE
nginx   3/3     3            3           3h21m
[kubeadm@server1 ~]$
[

 

 

四、Pod添加服务，ClusterIP进行内部访问

服务：service是一个抽象概念，定义了一个服务的多个pod逻辑合集和访问pod的策略，一般把service称为微服务

   1、 Pod仅仅是建立使用资源， 需要通过service的方式，添加一个访问策略
   2、 ClusterIP，提供了一个pod内部访问的IP地址，类似集群的VIP
   3、port是ClusterIP的访问端口，target-port则是pod中容器开放的端口，这样服务才能访问pod中的容器
   4、endpoints，暴露出pod的IP地址信息和端口

• 创建一个service提供内部访问的ip地址
• 测试

1、创建一个service提供内部访问的ip地址

[kubeadm@server1 ~]$ kubectl expose --help   ##查看创建service的规则
[kubeadm@node1 pod]$ kubectl expose deployment nginx --port=80 --target-port=80
service/nginx exposed  #使用命令expose加载一个service给名为nginx的pod

 

1.1、查看service的配置信息

 

1.2、查看service管理节点暴露的信息

 

2、测试：

创建一个pod，在同一网络段下，访问nginx服务，可以通过IP地址，也可通过nginx域名访问

1、在各个节点的pod副本中写入nginx默认发布目录的信息

[kubeadm@server1 ~]$ kubectl run test -it --image=busybox --restart=Never     ##用来测试可以访问nginx镜像的页面信息
If you don't see a command prompt, try pressing enter.
/ #
/ # wget -O - -q http://nginx
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>                              ##nginx默认的发布页面信息
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>
/ #


[kubeadm@server1 ~]$ kubectl exec -it nginx-6db489d4b7-c6xxf bash    ##拉取一个bash
root@nginx-6db489d4b7-c6xxf:/#
root@nginx-6db489d4b7-c6xxf:/#
root@nginx-6db489d4b7-c6xxf:/# cd /usr/share/nginx/html/              ##进入到nginx默认的发布目录中
root@nginx-6db489d4b7-c6xxf:/usr/share/nginx/html#
root@nginx-6db489d4b7-c6xxf:/usr/share/nginx/html# ls
50x.html  index.html
root@nginx-6db489d4b7-c6xxf:/usr/share/nginx/html#
root@nginx-6db489d4b7-c6xxf:/usr/share/nginx/html# echo pod1 > index.html   ##将测试的内容写其中
root@nginx-6db489d4b7-c6xxf:/usr/share/nginx/html#
root@nginx-6db489d4b7-c6xxf:/usr/share/nginx/html# exit
exit
[kubeadm@server1 ~]$ kubectl exec -it nginx-6db489d4b7-dnpgp bash
root@nginx-6db489d4b7-dnpgp:/#
root@nginx-6db489d4b7-dnpgp:/# cd /usr/share/nginx/html/
root@nginx-6db489d4b7-dnpgp:/usr/share/nginx/html#
root@nginx-6db489d4b7-dnpgp:/usr/share/nginx/html# ls
50x.html  index.html
root@nginx-6db489d4b7-dnpgp:/usr/share/nginx/html# echo pod2 > index.html
root@nginx-6db489d4b7-dnpgp:/usr/share/nginx/html#
root@nginx-6db489d4b7-dnpgp:/usr/share/nginx/html# exit
exit
[kubeadm@server1 ~]$

 

2.2、对http：//nginx进行访问

（访问会随机分配给后边的3个服务端）

[kubeadm@server1 ~]$ kubectl run test -it --image=busybox --restart=Never
If you don't see a command prompt, try pressing enter.

/ # wget -O - -q http://nginx
pod3
/ #
/ # wget -O - -q http://nginx
pod2
/ #
/ # wget -O - -q http://nginx
pod1
/ #
/ # wget -O - -q http://nginx/ # wget -O - -q http://10.96.9.159
pod2
/ # wget -O - -q http://10.96.9.159
pod3
/ # wget -O - -q http://10.96.9.159
pod3
/ # wget -O - -q http://10.96.9.159
pod3
/ # wget -O - -q http://10.96.9.159
pod2
/ # wget -O - -q http://10.96.9.159                     ##访问是随机分配的 
pod1

（访问是随机分配到后端的3个服务）

 

五、修改service服务，ClusterIP改为NodePort，供外部访问

ClusterIP是k8s的内部访问方式，而NodePort，可以提供外部访问

    1、NodePort，是在ClusterIP基础上，为service在每个节点node（也就是每台机器）上绑定一个端口，这样就可以通过           

    2、NodeIP：NodePort来访问服务了
    3、 NodePort默认端口范围30000-32767，随机产生
    4、NodeIP，每个几点的IP地址，如果是多网卡的机器，随机绑定服务已存在情况下，通过kubectl edit svc 服务名进行修改，将   type：ClusterIP改为type：NodePort即可
    5、重写服务命令，添加参数--type=NodePort

• 暴露端口信息
• 查看对外暴露的端口信息
• 测试

 

1、暴露端口信息

[kubeadm@server1 ~]$ kubectl edit svc nginx               ##暴露端口信息命令
# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: v1
kind: Service
metadata:
  creationTimestamp: "2020-02-24T15:06:12Z"
  labels:
    run: nginx
  name: nginx
  namespace: default
  resourceVersion: "248876"
  selfLink: /api/v1/namespaces/default/services/nginx
  uid: 3eb1f682-2c8f-48a3-9ac3-5fe9656fb146
spec:
  clusterIP: 10.96.9.159
  externalTrafficPolicy: Cluster
  ports:
  - nodePort: 31641
    port: 80


 run: nginx
  sessionAffinity: None
  type: NodePort
status:
    protocol: TCP
    targetPort: 80
  selector:

对外暴露端口、

 

2、查看对外暴露的端口信息

[kubeadm@server1 ~]$ kubectl describe svc nginx
Name:                     nginx
Namespace:                default
Labels:                   run=nginx
Annotations:              <none>
Selector:                 run=nginx
Type:                     NodePort
IP:                       10.96.9.159
Port:                     <unset>  80/TCP
TargetPort:               80/TCP
NodePort:                 <unset>  31641/TCP             ##对外暴露的端口信息
Endpoints:                10.244.0.4:80,10.244.1.6:80,10.244.2.6:80    ##三个后端服务的IP
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>
[kubeadm@server1 ~]$

 

3、测试：

在网页上输入：172.25.6.1：31641

 

六、 Pod扩容/缩容

使用命令scale，通过控制副本数，进行扩容、缩容

• 扩容
• 缩容

1、扩容：

[kubeadm@server1 ~]$ kubectl scale deployment nginx --replicas=6     ##将副本的个数扩容为6个 

 

1.2、查看扩容的运作机制

 

1.3查看扩容的镜像来源

 

2、缩容：

[kubeadm@server1 ~]$ kubectl scale deployment nginx --replicas=3     ##将副本的个数扩容为6个 

（缩容是把之前的运行时间比较长的副本回收掉）

 

 

七、Pod版本更新/回滚

• 更新，更新并不是在原有pod基础上直接更新，实际上是删除原有pod再次以新版本创建新的pod

[kubeadm@server1 ~]$ kubectl set image --help      查看镜像更戏更新的帮助 

、

 

在私有仓库中拉取镜像是遇到的问题

[root@reg ~]# docker load -i nginx-1.16.0.tar
open /var/lib/docker/tmp/docker-import-430766644/nginx-1.16.0/json: no such file or directory         ##出现报错
[root@reg ~]#

解决：
[root@reg ~]# cat nginx-1.16.0.tar | docker import - nginx-1.16.0.tar
sha256:3c9ea201aa940934f02fec7db26d404fae82e28f7653ecda0c87201f58d086f5
[root@reg ~]#
[root@reg ~]# docker images
REPOSITORY                               TAG                        IMAGE ID            CREATED             SIZE
nginx-1.16.0.tar                         latest                     3c9ea201aa94        3 seconds ago       6.2MB
<none>                                   <none>                     290897de2dcc        2 minutes ago       6.2MB
portainer/portainer                      latest                     10383f5b5720        7 days ago          78.6MB
reg.westos.org/library/portainer         latest                     10383f5b5720        7 days ago          78.6MB
haproxy                                  latest                     c39185c07cdd        11 days ago         92.5MB
reg.westos.org/library/haproxy           latest                     c39185c07cdd        11 days ago         92.5MB
docker                                   latest                     6512892b5768        11 days ago         224MB
<none>                                   <none>                     2073e0bcb60e        3 weeks ago         127MB
busybox                                  latest                     6d5fcfe5ff17        2 months ago        1.22MB

 

 

1、更新：

[kubeadm@server1 ~]$ kubectl get pod
NAME                                      READY   STATUS    RESTARTS   AGE
nginx-6db489d4b7-8zzhg                    1/1     Running   0          18s
nginx-6db489d4b7-fchxc                    1/1     Running   0          18s
nginx-6db489d4b7-rscsc                    1/1     Running   0          18s
#查看pod信息，主要pod号码
[kubeadm@server1 ~]$ kubectl describe pod nginx-6db489d4b7-8zzhg| grep -i image
    Image:          nginx
    Image ID:       docker-pullable://nginx@sha256:600bff7fb36d7992512f8c07abd50aac08db8f17c94e3c83e47d53435a1a6f7c
  Normal  Pulling    17s   kubelet, server3     Pulling image "nginx"
  Normal  Pulled     16s   kubelet, server3     Successfully pulled image "nginx"
#原版本nginx后面没有版本号
[kubeadm@server1 ~]$ kubectl set image deploy/nginx nginx=nginx:1.16
deployment.apps/nginx image updated
#进行更新
[kubeadm@server1 ~$ kubectl get pod
NAME                                      READY   STATUS    RESTARTS   AGE
nginx-85997df679-mppcj                    1/1     Running   0          19s
nginx-85997df679-qfg4k                    1/1     Running   0          16s
nginx-85997df679-qpscx                    1/1     Running   0          21s
#Pod是重新新创建的，通过生成的号码和时间可以看出
[kubeadm@server1 ~]$ kubectl describe pod nginx-85997df679-mppcj| grep -i image
    Image:          nginx:1.16
    Image ID:       docker-pullable://nginx@sha256:5f281748501a5ad9f5d657fc6067ac6187d62be2a811c460deee1504cabddc51
  Normal  Pulling    4m5s   kubelet, node3     Pulling image "nginx:1.16"
  Normal  Pulled     4m5s   kubelet, node3     Successfully pulled image "nginx:1.16"  #版本已更新为1.16 

 

2、回滚，回滚实际是通过查看创建历史记录，通过记录的命令，重新创建pod

[kubeadm@server1 ~]$ kubectl rollout history deployment nginx
deployment.apps/nginx 
REVISION  CHANGE-CAUSE
1         kubectl run nginx --image=nginx --replicas=3 --record=true
2         kubectl run nginx --image=nginx --replicas=3 --record=true
#因为仅操作了2次，可以看出记录1便是最初的版本                
[kubeadm@server1 ～]$ kubectl rollout undo deployment nginx --to-revision=1
deployment.apps/nginx rolled back
#通过记录回滚上一个版本，实际重新运行了一遍命令
[kubeadm@server1 ～]$ kubectl get pod
NAME                                      READY   STATUS    RESTARTS   AGE
nginx-6db489d4b7-lpmxr                    1/1     Running   0          74s
nginx-6db489d4b7-s9vb2                    1/1     Running   0          71s
nginx-6db489d4b7-xgk5t                    1/1     Running   0          78s
#pod的ID再一次发生变化，意味着重新建立的
[kubeadm@server1 ~]$ kubectl describe pod nginx-6db489d4b7-lpmxr| grep -i image
    Image:          nginx
    Image ID:       docker-pullable://nginx@sha256:600bff7fb36d7992512f8c07abd50aac08db8f17c94e3c83e47d53435a1a6f7c
  Normal  Pulling    50s   kubelet, server2     Pulling image "nginx"
  Normal  Pulled     50s   kubelet, server2     Successfully pulled image "nginx" #版本回到以前的状态