在之前的文章 通过 Service 访问 Pod 集群 中,学习了两种方法做 pod 负载,分别是 ClusterIP
和 NodePort
,也提到了 LoadBalancer
,仅仅是提了一嘴。
在正常的生产环境中,当使用了 NodePort
类型暴露服务时,每台集群节点的 nodeport 端口都能够去访问,
使用 kubectl 命令时,最烦人的就是频繁的切换命名空间了,查看什么资源都得加命名空间,每次敲命令在习惯也会很烦。今天在网上看到一篇文章,很有用,可以记住上一次使用 kubectl 时操作的命名空间。
在实际的生产环境中遇到了这样的问题:集群中有大量 k8s 节点,在部署应用时,需要拉取私有仓库(harbor/registry)的私有项目镜像,也就是节点必须 docker login
之后才可以正常拉取到镜像。但是也不可能每个节点都这样去做,或者写脚本把用户密码明文暴露,显然是不合适的
需要将镜像仓库的认证凭据(域名/ip,用户名,密码)保存在 k8s 中
相信大家在使用 kubeadm init
时,会发现在 /etc/kubernetes/pki
目录下生成一大堆证书文件;还有一些 k8s 插件在部署时,会创建 RBAC,这些都是为了 kubernetes 的安全而产生的。
- Authentication(鉴权):鉴定访问集群的身份
- Authorization(授权):在确认身份的基础上,给定符合身份的权限
- Admission Control(准入控制):安检
在前面的学习中,发现做的例子都是 Deployment ,且大部分使用 web 应用去做示例,为什么不用 mysql 类似数据库来做示例呢。
在 LNMP 架构中,应该了解过动静分离,也就是动态数据和静态数据,是以是否需要去访问数据库去进行读写数据来区分的。
Kubernetes 同样也区分了有状态应用和无状态应用,之前常用的 Deployment 就是为无状态应用而使用的。本文中提到的 StatefulSet 就是为有状态应用使用的。
创建 nfs 的 storageClass 请跳到 Kubernetes–StorageClass(二),因为 本文中的 NFS 仓库中的项目有点 bug ,对于新版 k8s 无法解决。不信邪你可以试试
在之前的文章 Kubernetes的数据管理 一文中,介绍了一些 volume 以及 PV 、 PVC 的使用方法,也被称为 静态 PV 供给,因为 PVC 是建立在 PV 的前提下,必须手动创建 PV ,再去创建 PVC 去匹配 PV 获取存储资源。
以上说到的方法中,对于大量 pod 的场景来说,维护成本相当大,对于运维人员也是不友好的。所以 k8s 支持了 PV 的动态供给 — StroageClass
。也就是使用了 StorageClass
之后,不需要单独创建 PV,只需要创建 PVC ,就会根据 PVC 的申请自动创建一个 PV,也被称为 动态 PV 供给
1 / 4