云原生|kubernetes 你真的学废了吗---实战k8s 二（命令行创建各类资源）

这里特别注意，不要搞错了，是nginx1，因为前面的pod里的label是nginx1。

zsk_john

1197人浏览 · 2022-09-15 23:00:41

zsk_john · 2022-09-15 23:00:41 发布

前言：

kubernetes的资源种类非常多，但常用的也就十来种吧，比如，pod，service，configMap，serviceaccount，deployment，secret，statefulset，StorageClass等等，总的来说学习难度还是不大的。但创建资源的流程你真的知道吗？下面就来介绍一哈资源创建的标准流程吧。

一，

命令行和资源清单文件（通常也叫模板文件）的关系

命令行指的是kubectl 客户端命令，直接通过apiserver调用创建各类资源。命令行方式创建资源具有简单，快速的特点，但缺点也是很大的：命令执行完了，如果有问题，不好回溯，也基本是没有保存，很多细节方面的问题也无法通过命令行书写，比如，pod调度，node亲和性，pod亲和性或者需要写的命令非常长。

资源清单文件是对资源的精细化描述，并且通常的资源清单文件是yaml格式文件，易读，易理解。但，也是有一个比较大的缺点：编写难度非常高。

那么，命令行其实是基础，就想象成一个房子的地基吧，可以快速的生成资源清单文件（命令行可以转换成资源清单文件），这样的话，先命令生成文件，然后在此文件基础上进行细节的修改就可以达到我们想要的功能啦（降低资源清单文件编写难度了）。

下面将会写一些示例，来说明一个科学的资源创建的流程。

二，

RC/RS和service资源的创建

创建一个pod，该pod使用nginx，能够对外提供服务。

（1）

命令行创建一个pod，此pod不运行，仅仅生成资源清单文件

--dry-run表示不实际运行pod，如果不加此参数将会有非常多的冗余信息，-o表示输出，yaml表示输出格式为yaml，当然，json格式也可以。如果不想看到警告W0915 11:17:31.171659 24955 helpers.go:535] ，那么修改成--dry-run=client 即可。

[root@master ~]# k run nginx --image=nginx:1.18 --dry-run -o yaml >nginx.yaml
W0915 11:17:31.171659   24955 helpers.go:535] --dry-run is deprecated and can be replaced with --dry-run=client.

[root@master ~]# cat nginx.yaml 
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: nginx
  name: nginx
spec:
  containers:
  - image: nginx:1.18
    name: nginx
    resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}

OK，命令行生成的资源清单文件已经生成，该有的基本结构都有了。

（2）

命令行多参：打标签，pod的重启策略，暴露端口，资源限制设置

[root@master ~]#  k run nginx --image=nginx:1.18 --dry-run=client --restart=Never --labels="app=nginx1" --port=1234 --limits='cpu=200m,memory=512Mi' -o yaml >nginx.yaml

[root@master ~]# cat nginx.yaml 
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    app: nginx1
  name: nginx
spec:
  containers:
  - image: nginx:1.18
    name: nginx
    ports:
    - containerPort: 1234
    resources:
      limits:
        cpu: 200m
        memory: 512Mi
  dnsPolicy: ClusterFirst
  restartPolicy: Never
status: {}

（3）

service的资源清单文件生成

现在如果执行以上yaml文件，只能集群内看到nginx的首页，如果想暴露给同网段内使用，需要编辑一个service文件，采用nodepod模式暴露（第一种命令）：

[root@master ~]# kubectl expose pod nginx   --port=38080 --target-port=80  --type=NodePort --dry-run=client -o yaml >service-nginx.yaml

service文件内容（第一种方式的service）：

[root@master ~]# cat service-nginx.yaml 
apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  labels:
    app: nginx1
  name: nginx
spec:
  ports:
  - port: 38080
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx1
  type: NodePort
status:
  loadBalancer: {}

这里特别注意，不要搞错了，是nginx1，因为前面的pod里的label是nginx1（第二种命令）：

[root@master logs]# k create svc  nodeport nginx1 --tcp=38080:80 -o yaml --dry-run=client >service-nginx2.yaml

service文件内容（第二种方式的service）：

[root@master logs]# cat service-nginx2.yaml 
apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  labels:
    app: nginx1
  name: nginx1
spec:
  ports:
  - name: 38080-80
    port: 38080
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx1
  type: NodePort
status:
  loadBalancer: {}

kubernetes的网络逻辑是这样的：镜像nginx：1.18启动的服务端口是80，映射到38080，kube-proxy代理38080端口到30068端口，

I0915 09:18:41.192677    1200 proxier.go:812] Stale udp service kube-system/coredns:dns -> 10.0.0.2
I0915 14:11:25.049350    1200 service.go:379] Adding new service port "default/nginx:" at 10.0.0.107:38080/TCP
I0915 14:11:25.096252    1200 proxier.go:1655] Opened local port "nodePort for default/nginx:" (:30634/tcp)
I0915 14:12:53.039292    1200 service.go:404] Removing service port "default/nginx:"
I0915 14:12:56.347842    1200 service.go:379] Adding new service port "default/nginx:" at 10.0.0.3:38080/TCP
I0915 14:12:56.399977    1200 proxier.go:1655] Opened local port "nodePort for default/nginx:" (:30068/tcp)

执行以上文件，此时任意节点ip:30068就可以访问到pod所启动的nginx镜像的首页啦：

本例中，labels app=nginx1和前面的pod里的label是相呼应的。

[root@master ~]# k describe svc nginx1
Name:                     nginx1
Namespace:                default
Labels:                   app=nginx1
Annotations:              Selector:  app=nginx1
Type:                     NodePort
IP:                       10.0.0.89
Port:                     38080-80  38080/TCP
TargetPort:               80/TCP
NodePort:                 38080-80  32602/TCP
Endpoints:                10.244.0.22:80
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

三，

deployment资源的创建

k create deploy tomcat --image=bitnami/tomcat    --dry-run  -o yaml >tomcat.yaml

deployment控制器比较复杂，一般只是使用命令行创建一个基本的模板文件，然后在此基础上修改，一个deployment大体包括以下几个主要部分：

apiversion，kind，metadata，spec，status这五个模块，其中的status可以没有。

[root@master ~]# kubectl explain deploy
KIND:     Deployment
VERSION:  apps/v1

DESCRIPTION:
     Deployment enables declarative updates for Pods and ReplicaSets.

FIELDS:
   apiVersion	<string>
     APIVersion defines the versioned schema of this representation of an
     object. Servers should convert recognized schemas to the latest internal
     value, and may reject unrecognized values. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources

   kind	<string>
     Kind is a string value representing the REST resource this object
     represents. Servers may infer this from the endpoint the client submits
     requests to. Cannot be updated. In CamelCase. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

   metadata	<Object>
     Standard object metadata.

   spec	<Object>
     Specification of the desired behavior of the Deployment.

   status	<Object>
     Most recently observed status of the Deployment.

查询子模块

例如spec：

[root@master ~]# kubectl explain deploy.spec
KIND:     Deployment
VERSION:  apps/v1

RESOURCE: spec <Object>

DESCRIPTION:
     Specification of the desired behavior of the Deployment.

     DeploymentSpec is the specification of the desired behavior of the
     Deployment.

FIELDS:
   minReadySeconds	<integer>
     Minimum number of seconds for which a newly created pod should be ready
     without any of its container crashing, for it to be considered available.
     Defaults to 0 (pod will be considered available as soon as it is ready)
略略略。。。。。。。。。。。。。。。。。。。

主要的还是根据以上explain（解释说明）来填充yaml文件，那么，这个yaml文件是根据层级来确定模块的，比如，我想查询import的拉取规则如何定义：

[root@master ~]# kubectl explain deploy.spec.template.spec.containers.imagePullPolicy
KIND:     Deployment
VERSION:  apps/v1

FIELD:    imagePullPolicy <string>

DESCRIPTION:
     Image pull policy. One of Always, Never, IfNotPresent. Defaults to Always
     if :latest tag is specified, or IfNotPresent otherwise. Cannot be updated.
     More info:
     https://kubernetes.io/docs/concepts/containers/images#updating-images

OK，上面的说明就非常清楚了， One of Always, Never, IfNotPresent，三种拉取规则。

如何玩转编写资源清单文件，路子我提供了，大家可以试一试哦。

K8S/Kubernetes

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐

【深度】阿里巴巴万级规模 K8s 集群全局高可用体系之美

作者 | 韩堂、柘远、沉醉来源 | 阿里巴巴云原生公众号前言台湾作家林清玄在接受记者采访的时候，如此评价自己 30 多年写作生涯：“第一个十年我才华横溢，‘贼光闪现’，令周边黯然失色；第二个十年，我终于‘宝光现形’，不再去抢风头，反而与身边的美丽相得益彰；进入第三个十年，繁华落尽见真醇，我进入了‘醇光初现’的阶段，真正体味到了境界之美”。长夜有穷，真水无香。领略过了 K8s“身在江

K8S/Kubernetes

如何基于 K8s 构建下一代 DevOps 平台？

作者 | 孙健波（天元）导读：当前云原生 DevOps 体系现状如何？面临哪些挑战？如何通过 OAM 解决云原生 DevOps 场景下的诸多问题？云原生开发应用模型 OAM(Open Application Model) 社区核心成员孙健波将为大家一一解答，并分享如何基于 OAM 和 Kubernetes 打造无限能力的下一代 DevOps 平台。什么是 DevOps？为什么基于 Kub