手机版
你好,游客 登录 注册 搜索
背景:
阅读新闻

自建 Kubernetes 上运行容器

[日期:2020-04-09] 来源:cnblogs.com/galvin007  作者:galvin007 [字体: ]

编写配置文件

Kubernetes 跟 Docker 等很多项目最大的不同,就在于它不推荐你使用命令行的方式直接运行容器(虽然 Kubernetes 项目也支持这种方式,比如:kubectl run),而是希望你用 YAML 文件的方式,即:把容器的定义、参数、配置,统统记录在一个 YAML 文件中,然后用这样一句指令把它运行起来:

$ kubectl create -f 我的配置文件

Yaml文件示例:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80
  • 像这样的一个 YAML 文件,对应到 Kubernetes 中,就是一个 API Object(API 对象)。当你为这个对象的各个字段填好值并提交给 Kubernetes 之后,Kubernetes 就会负责创建出这些对象所定义的容器或者其他类型的 API 资源。
  • 这个 YAML 文件中的 Kind 字段,指定了这个 API 对象的类型(Type),是一个 Deployment。Deployment,是一个定义多副本应用(即多个副本 Pod)的对象
  • 这个 YAML 文件中,定义的 Pod 副本个数 (spec.replicas) 是:2。
  • Pod 模版(spec.template),这个模版描述了创建的 Pod 的细节。在上面的例子这个 Pod 里只有一个容器,这个容器的镜像(spec.containers.image)是 nginx:1.7.9,这个容器监听端口(containerPort)是 80。
  • 这样使用一种 API 对象(Deployment)管理另一种 API 对象(Pod)的方法,在 Kubernetes 中,叫作“控制器”模式(controller pattern)
  • 一个 Kubernetes 的 API 对象的定义,大多可以分为 Metadata 和 Spec 两个部分。前者存放的是这个对象的元数据,对所有 API 对象来说,这一部分的字段和格式基本上是一样的;而后者存放的,则是属于这个对象独有的定义,用来描述它所要表达的功能。
[root@k8s ~]# kubectl apply -f nginx-deployment.yaml --namespace=kube-system
deployment.apps/nginx-deployment created
[root@k8s ~]# kubectl get pods -l app=nginx
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-54f57cf6bf-jpgq4   0/1     Pending   0          86m
nginx-deployment-54f57cf6bf-rrmbq   0/1     Pending   0          86m

或者
[root@k8s ~]# kubectl get pods -n kube-system

解决 pending 状态:
检查:
[root@k8s ~]# kubectl -n kube-system describe pod nginx-deployment-54f57cf6bf-rg8td
……
……
Events:
  Type     Reason            Age                From               Message
  ----     ------            ----               ----               -------
  Warning  FailedScheduling  5s (x17 over 22m)  default-scheduler  0/1 nodes are available: 1 node(s) had taints that the pod didn't tolerate.

查看节点的 Taints(kubectl describe node <node_name>)
Taints:   node-role.kubernetes.io/master:NoSchedule

解决方案:

  • 在 Pod 的.yaml 文件中的 spec 部分,加入 tolerations 字段即可
  • 或者 kubectl taint nodes --all node-role.kubernetes.io/master-

在“node-role.kubernetes.io/master”这个键后面加上了一个短横线“-”,这个格式就意味着移除所有以“node-role.kubernetes.io/master”为键的 Taint。

[root@k8s ~]# kubectl taint nodes --all node-role.kubernetes.io/master-
node/instance-010oj085 untainted

再次查看状态(在命令行中,所有 key-value 格式的参数,都使用“=”而非“:”表示)

[root@k8s ~]# kubectl get pods -l app=nginx
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-54f57cf6bf-jpgq4   1/1     Running   0          148m
nginx-deployment-54f57cf6bf-rrmbq   1/1     Running   0          148m

查看 describe 的 Event 事件:

……
Events:
  Type     Reason            Age                 From                        Message
  ----     ------            ----                ----                        -------
  Warning  FailedScheduling  10m (x39 over 65m)  default-scheduler           0/1 nodes are available: 1 node(s) had taints that the pod didn't tolerate.
  Normal   Pulling           5m41s               kubelet, instance-010oj085  Pulling image "nginx:1.7.9"
  Normal   Pulled            4m37s               kubelet, instance-010oj085  Successfully pulled image "nginx:1.7.9"
  Normal   Created           4m37s               kubelet, instance-010oj085  Created container nginx
  Normal   Started           4m37s               kubelet, instance-010oj085  Started container nginx

镜像服务升级

1. 修改 YAML 文件

2. 执行命令
# 修改nginx-deployment.yaml的内容
kubectl apply -f nginx-deployment.yaml

当应用本身发生变化时,开发人员和运维人员可以依靠容器镜像来进行同步;当应用部署参数发生变化时,这些 YAML 文件就是他们相互沟通和信任的媒介。

删除 Nginx Deployment

$ kubectl delete -f nginx-deployment.yaml

总结

  • Kubernetes 里“最小”的 API 对象是 Pod。Pod 可以等价为一个应用,所以,Pod 可以由多个紧密协作的容器组成。
  • 在 Kubernetes 中,我们经常会看到它通过一种 API 对象来管理另一种 API 对象,比如 Deployment 和 Pod 之间的关系;而由于 Pod 是“最小”的对象,所以它往往都是被其他对象控制的。这种组合方式,正是 Kubernetes 进行容器编排的重要模式。
  • 像这样的 Kubernetes API 对象,往往由 Metadata 和 Spec 两部分组成,其中 Metadata 里的 Labels 字段是 Kubernetes 过滤对象的主要手段。
  • 在这些字段里面,容器想要使用的数据卷,也就是 Volume,正是 Pod 的 Spec 字段的一部分。而 Pod 里的每个容器,则需要显式的声明自己要挂载哪个 Volume。
linux
本文评论   查看全部评论 (0)
表情: 表情 姓名: 字数

       

评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留言中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款