Pod 的存储之volume


大家如果细心的话,会发现把nginx服务pod内的默认页面改了,但当重启pod后,这个页面又恢复成nginx容器初始的状态了,所以这里要和大家说的是,在没有配置持久化存储前,任何新增的数据在pod发生重启时都是无法保留的,而在K8s上,Pod的生命周期可能是很短,它们会被频繁地销毁和创建,自然在容器销毁时,里面运行时新增的数据,如修改的配置及日志文件等也会被清除。

容器磁盘上的文件的生命周期是短暂的,这就使得在容器中运行重要应用时会出现一些问题。首先,当容器崩溃时,kubelet 会重启它,但是容器中的文件将丢失——容器以干净的状态(镜像最初的状态)重新启动。其次,在Pod 中同时运...

Read more

Pod 的存储之Secret


一、Secret 存在意义

Secret 解决了密码、token、密钥等敏感数据的配置问题,而不需要把这些敏感数据暴露到镜像或者 Pod Spec中。Secret 可以以 Volume 或者环境变量的方式使用。

Secret 有三种类型:

Service Account : 用来访问 Kubernetes API,由 Kubernetes 自动创建,并且会自动挂载到 Pod 的/run/secrets/kubernetes.io/serviceaccount 目录中。

Opaque:base64 编码格式的Secret,用来存储密码、密钥等

kubernetes.io/dockercon...

Read more

Pod 的存储之Configmap


一、Configmap介绍

ConfigMap 功能在 Kubernetes1.2 版本中引入,许多应用程序会从配置文件、命令行参数或环境变量中读取配置信息。ConfigMap API 给我们提供了向容器中注入配置信息的机制,ConfigMap 可以被用来保存单个属性,也可以用来保存整个配置文件或者 JSON 二进制大对象。

1、使用目录创建

mkdir configmap-test
# 在我们的 configmap-test 文件夹下有两个文件分别为: test-1 与 test-2 里面的内容分别为:

cat test-1 

enemies=aliens
lives=3
enem...

Read more

Ingress


1、介绍

在前面文章中已经提到,Service对集群之外暴露服务的主要方式有两种:NodePort和LoadBalancer,但是这两种方式,都有一定的缺点:

NodePort方式的缺点是会占用很多集群机器的端口,那么当集群服务变多的时候,这个缺点就愈发明显。

LB方式的缺点是每个service需要一个LB,浪费、麻烦,并且需要kubernetes之外设备的支持。

基于这种现状,kubernetes提供了Ingress资源对象,Ingress只需要一个NodePort或者一个LB就可以满足暴露多个Service的需求。工作机制大致如下图表示:

图片

在Kubernetes中,Ingress是...

Read more

Service 的应用


ClusterIP

clusterIP 主要在每个 node 节点使用 ipvs,将发向 clusterIP 对应端口的数据,转发到 kube-proxy 中。然后 kube-proxy 自己内部实现有负载均衡的方法,并可以查询到这个 service 下对应 pod 的地址和端口,进而把数据转发给对应的 pod 的地址和端口。

74.png

为了实现图上的功能,主要需要以下几个组件的协同工作:

  • apiserver 用户通过kubectl命令向apiserver发送创建service的命令,apiserver接收到请求后将数据存储到etcd中。
  • kube-proxy kubernetes的每个节点中...

Read more

Job 与 Cronjob


一、Job

Job 负责批处理任务,即仅执行一次的任务,它保证批处理任务的一个或多个 Pod 成功结束。

特殊说明

1、spec.template 格式同 Pod

2、RestartPolicy 仅支持 Never 或 OnFailure

3、单个 Pod 时,默认 Pod 成功运行后 Job 即结束

4、spec.completions 标志 Job 结束需要成功运行的 Pod 个数,默认为 1

5、spec.parallelism 标志并行运行的 Pod 的个数,默认为 1

6、spec.activeDeadlineSeconds 标志失败 Pod 的重试最大时间,超过这个时间不会...

Read more

资源控制器之DaemonSet


DaemonSet 确保全部(或者一些) Node上运行一个 Pod 的副本,当有 Node 加入集群时,也会为他们新增一个 Pod,当有 Node 从集群移除时,这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod 。

DaemonSet 通过在集群中的每个节点上运行至少一个 Pod 来提供了一个更本地化的服务或功能。这在需要在每个节点上执行特定任务的情况下非常有用,比如节点监控或日志收集。

61.png

DaemonSet 应用示例:

vim daemonset.yaml

apiVersion: apps/v1
kind: DaemonSet
metadata:
 ...

Read more

Deployment


无状态服务deployment

Deployment 为 Pod 和 ReplicaSet 提供了一个声明式定义(declarative)方法,用来替代以前的ReplicationController 来方便的管理应用。典型的应用场景包括:

  • 定义 Deployment 来创建 Pod 和 ReplicaSet

  • 滚动升级和回滚应用

  • 扩容和缩容

49.png

Deployment 应用示例:

vim deploy.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  selector...

Read more

资源控制器之RS


RC (ReplicationController )主要的作用就是用来确保容器应用的副本数始终保持在用户定义的副本数 。即如果有容器异常退出,会自动创建新的 Pod 来替代;而如果异常多出来的容器也会自动回收(已经成为过去时)。

Kubernetes 官方建议使用 RS(ReplicaSet ) 替代 RC (ReplicationController ) 进行部署,RS 跟 RC 没有本质的不同,只是名字不一样,并且 RS 支持集合式的 selector。

48.png

RS 用示例:

vim rs.yaml

apiVersion: apps/v1
kind: ReplicaSet
metad...

Read more

Pod 的资源控制器类型


一、Pod 的资源控制器类型

Pod 我们可以分为两类,一种属于自主式 Pod ,还有一种属于控制器管理的 Pod 。

什么是控制器呢?简单来说,控制器就好比是影视剧里面的剧本,演员会根据剧本所写的内容来针对不同的角色进行演绎,而我们的控制器就好比是剧本,Kubernetes 会根据我们所定义的规则,或者是按照我们写好的 “剧本” 来完成创建我们的 Pod 。

控制器类型

1.ReplicationController 与 ReplicaSet

Replicationcontroller 副本控制器 (RC) 用来确保容器应用的副本数始终保持在用户定义的副本数,即如果有容器异常退出,会...

Read more