Snowball's Note

发表于 Waline： 阅读次数： 本文字数： 7.2k 阅读时长 ≈ 7 分钟

持久卷

Persistent Volume（PV）描述的是持久化存储数据卷。主要定义一个持久化存储在宿主机上的目录。
持久卷不属于任何命名空间，它跟节点一样是集群层面的资源。
通常情况下，会先在kubernetes集群里创建PV对象，比如定义一个NFS类型的PV:

1
2
3
4
5
6
7
8
9
10
11
12
13
apiVersion: v1
kind: PersistentVolume
metadata:
  name: nginx-pv-nfs
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteMany
  storageClassName: manual
  nfs:
    server: 172.21.0.5
    path: "/pk1yjy13/"

注意

  • RWO即ReadWriteOnce，允许单个节点挂载读写。
  • ROX即ReadOnlyMany，允许多个节点挂载只读。
  • RWX即ReadWriteMany，允许多个节点挂载读写。
阅读全文 »

发表于 Waline： 阅读次数： 本文字数： 3.8k 阅读时长 ≈ 3 分钟

部署前的准备

  • 需要保证每个节点都有自己独立的公网IP
  • kubeadm将apiServer服务暴露至公网
  • 由于Node节点加入集群的时候被登记的INTERNAL-IP是节点内网IP，这样Master节点在和Node节点通信的时候会直接访问Node的内网IP，所以需要做iptables的NAT转发。
阅读全文 »

发表于 Waline： 阅读次数： 本文字数： 14k 阅读时长 ≈ 12 分钟

服务

kubernetes服务是为一组功能相同的pod提供单一不变的接入点资源。当一个服务存在时，它的IP和端口不会改变。客户端通过IP地址和端口号建立连接。连接会被路由到提供该服务的任意一个pod。

通过这种方式，客户端不需要知道提供服务pod的ip和端口信息，这样这些pod可以在集群中随时被创建和删除。

假如有前端web服务器和后端数据库服务器，有很多pod提供前端服务，而中有一个pod提供后台数据库服务。需要解决两个问题才能发挥系统作用

  • 外部客户无须关心服务器数量而连接到前端Pod上。
  • 前端的pod需要连接后端的数据库。由于数据库运行在pod上，他可能会在集群中随时重启而移动，导致IP地址随时变动。当后端数据库被移动时，不必为前端pod重新配置。
阅读全文 »

发表于 Waline： 阅读次数： 本文字数： 7.4k 阅读时长 ≈ 7 分钟

了解Secret

为了存储与分发此类信息,Kubemetes提供了一种称为Secret的单独资源对象。Secret结构与ConfigMap类似,均是键/值对的映射。Secret的使用方法也与ConfigMap相同,可以

将Secret条目作为环境变量传递给容器

将Secret条目暴露为卷中的文件

Kubernetes通过仅仅将Secret分发到需要访问Secret的pod所在的机器节点来保障其安全性。另外,Secret只会存储在节点的内存中,永不写入物理存储,这样从节点上删除Secret时就不需要擦除磁盘了。

对于主节点本身(尤其是etcd),Secret通常以非加密形式存储,这就需要保障主节点的安全从而确保存储在Secret中的敏感数据的安全性。这种保障不仅仅是对etcd存储的安全性保障,同样包括防止未授权用户对API服务器的访问,这是因为任何人都能通过创建pod并将Secret挂载来获得此类敏感数据。

从Secret与ConfigMap中做出正确选择是势在必行的,选择依据相对简单:

·采用ConfigMap存储非敏感的文本配置数据。 采用Secret存储天生敏感的数据,通过键来引用,如果一个配置文件同时包含敏感与非敏感数据,该文件应该被存储在Secret中。

默认令牌Secret

对任意一个pod使用命令kubectl describe pod,输出往往包含如下信息:

1
2
3
default-token-6nw87:
Type:        Secret (a volume populated by a Secret)
SecretName:  default-token-6nw87
阅读全文 »
0%