k8s入门学习总结（上篇），学完后可以马上手上使用
k8s学习kube-proxy 负责实现k8s网络流量路由，负载均衡的网络模型 ，监控集群中所有服务端点 endpoint自己的节点上编排这个网络。
k8s学习总结
- 基础概念
- k8s架构
- 标签与注释
- 主要特性（kind）
基础概念
kubernetes是一个创建，部署和管理分布式应用程序的平台
官方文档： https://kubernetes.io/zh-cn/docs/home/
K8s做容器编排 何为编排？
简单的理解就是，例如想部署一个程序，需要3核10G内存，告诉k8s
k8s会在集群中（很多计算机） 找到一个最合适运行容器的地方
如果容器进程奔溃了，还要自动的修复撒
K8S的作用
- 部署应用程序
- 动态的扩容缩容 （可伸缩）
- 出现故障时的自愈 （高可用）
- 不停机的滚动升级和回滚
K8S的组成
K8S的主要组件
- Kubernetes API Server
- Etcd 集群存储
- Kubernetes Controller Manager
- Kubernetes Scheduler 调度器
k8s架构
k8s架构
1 隐式&动态分组 （基于标签和标签查询或标签选择器实现）
label是k8s中一个重要的配置项
2 模块化后的 API驱动的交互
让模块可以被轻易替换
组件
k8s 整体架构分为 master + node
Master
master指 K8S集群中的master节点，此节点主要作用就是来控制调度集群
Node
在Kubernetes中，除了Master节点之外，其他的节点都称为Node。与Master节点不同，Node才是Kubernetes中的承担主要计算功能的工作节点。
Node可以是一台物理机，也可以是一台虚拟机
Master 相关组件
Master节点上一般运行以下组件：
- Etcd
- API服务器（Kubernetes API Server）
- 调度器 （Kubernetes Scheduler ）
- 控制器 （Kubernetes Controller Manager）
Etcd
Etcd是Kubernetes集群中的一个十分重要的组件，用于保存集群所有的网络配置和对象的状态信息
mainfest
Kubernetes API Server
Kubernetes API Server 的 进 程 名 为 kube-apiserver 。Kubernetes API Server提供了Kubernetes各类资源对象的增、删、改、查的HTTP Rest接口，是整个系统的数据总线和数据中心。
Kubernetes API Server提供了集群管理的REST API接口，包括认证授权、数据校验以及集群状态变更，提供了其他模块之间的数据交互和通信的枢纽，是资源配额控制的入口，拥有完备的集群安全机制。
k8s中所有的东西都是通过RESTful资源来表示的，每一个k8s对象都位于一个唯一的HTTP路径上
Kubernetes API 接收到创建对象请求后先处理，然后保存到etcd中
API 请求头都Content-Type application/json
kubectl proxy
更多详情学习 见《K8s-OpenAPI学习总结》
Kubernetes Scheduler
Kubernetes Scheduler的作用是根据特定的调度算法Pod调度到指定的工作节点（Node）上，这一过程也叫绑定（Bind）。
Scheduler的输入为需要调度的Pod和可以被调度的节点（Node）的信息，输出为调度算法选择的Node，并将该Pod绑定到这个Node
Kubernetes Controller Manager
Controller Manager作为集群内部的管理控制中心，负责集群内的 Node 、 Pod 副 本 、 服 务 端 点 （ Endpoint ） 、 命 名 空 间
（ Namespace ） 、 服 务 账 号 （ ServiceAccount ） 、 资 源 配 额（ResourceQuota）的管理。当某个Node意外宕机时，Controller
Manager会及时发现，并执行自动化修复流程，确保集群始终处于预期的工作状态
Node 相关组件
Node节点上一般运行以下组件：
- kubelet
- kube-proxy
kubelet & kube-proxy 也会运行在master节点上
Kubelet
每个Node节点都会启动kubelet进程，用来处理Master节点下发到本节点的任务
Kubelet的一个重要职责就是负责监听API Server新分配的任务。每当其监听到一个任务时，Kubelet就会负责执行该任务，并维护与控
制平面之间的一个通信频道，准备将执行结果反馈回去。
Kubelet会在API Server上注册节点信息，定期向Master汇报节点资源使用情况，并通过cAdvisor监控容器和节点资源以把Kubelet理解成是一个代理进程，是Node上的Pod管家。
kube-proxy （kubernetes代理）
kube-proxy 运 行 在 所 有 Node 节 点 上 ， 它 监 听 每 个 节 点 上Kubernetes API中定义的服务变化情况，创建路由规则来进行服务负载均衡。
kube-proxy 负责实现k8s网络流量路由，负载均衡的网络模型 ，监控集群中所有服务端点 endpoint
自己的节点上编排这个网络 。（kube-proxy需要部署在集群的每一个节点上）
kube-proxy会作为特权容器运行，负责关联虚拟服务IP地址的连接
kube-proxy大多数情况下，只是控制每个节点上的iptables规则
将发往某个服务IP的流量重定向到任意后备端点IP
运行在集群中的每个工作节点，负责本地集群网络
其他组件
证书
使用kubeadm安装k8s集群的时候会 默认生成自己的证书颁发机构（Certificate Authority 即CA）和秘钥
然后使用CA创建各种证书
**API服务器（Kubernetes API Server）**会使用证书来保护入站请求，验证用户，发送出站请求
所有公钥基础设施（Public Key Infrastructure PKI）保存在 /etc/kubernetes/pki
使用kubeadm创建集群时使用已有的证书 （kubeadm init之前把证书密码放在 /etc/kubernetes/pki下）
这样就使用自签名证书
使用cfssl工具（CloudFlare 旗下的cfssl工具） 创建证书
配置文件
- admin.conf
- controller-manager.conf
- kubelet.conf
- manifests
- pki
- scheduler.conf
- ~/.kube/config
~/.kube/config
此配置文件主要是做身份认证，记录认证的详细信息
kubectl 默认使用此文件，但可以在配置文件中指定环境变量的方式切换config文件
export KUBECONFIG=/xxx/xx/mykubeconfig
使用kubectl config 命令可以添加用户身份认证
kubectl config set-credentials cluster-admin --username=admin --password=sss
标签与注释
在k8s中标签是一个重要的概念，标签完成了隐式&动态分组 （基于标签和标签查询或标签选择器实现）
标签可以提供对象的标识元数据，可以用来对各种对象Kind(例如 service pod deployment)进行分组，查看和操作
生产环境大规模部署时通常是以一个单实例开始
一旦稳定则成倍增加单实例，从而变成一组对象，k8s使用标签来标识一组对象
标签的创建，更新，使用
标签的查询
kubectl get在查询**任意 【资源】或【对象】**的时候都可以戴上–show-labels参数用于展示标签
kubectl get 【资源】--show-labels
kubectl get 【资源】【对象】 --show-labels
例如
kubectl get service --show-labels
kubectl get pods saas-task-server-55c5769b67-wcdlg --show-labels
kubectl get在查询任意 【资源】或【对象】的时候都可以戴上 -l 或 --selector 【标签】查询对应标签的【资源】或【对象】
例如：
kubectl get pods -l ppp=xxx-ffff 查询标签ppp=xxx-ffff的pod
kubectl get pods -l ppp 查询带有ppp为key的标签
kubectl get pods -l '!ppp' 查询不包含ppp为key的标签
多个标签使用逗号分割
kubectl get pods --selector="team=jimliu-person-team,xxx=yy"
标签的创建
标签的创建方式有两种
- 在yaml maifest文件中配置
- 使用kubect label 命令
1 在yaml maifest文件中配置
这里使用pod maifest yaml文件为例子
apiVersion: v1
kind: Pod
metadata:
name: order-service
labels:
app: order-service
type: service-dep
team: jimliu-person-team
msg: test
2 使用kubect label 命令创建
kubectl label 【资源】【对象】 ppp=xxx 给pod添加新的标
kubectl label 【资源】【对象】 ppp=xxx --overwrite 更新现有的标签 需要加上--overwrite
例如
kubectl label pod mytest-88xzl ppp=xxx-jim
kubectl label pod mytest-88xzl ppp=xxx-jim --overwrite
给节点配置标签
kubectl label node ubuntu-server-2 cpu=good
标签的使用
可以使用**–selector** 来筛选过滤标签
标签操作符如下
-
key=value key被设置为value
-
key!=value key未被设置为value
-
key in (value1 value2) key是value1 或value2
-
key notin (value1 value2) key不是value1 或value2
-
key 存在key
-
!key 不存在key
例如
kubectl get pods --selector=“app!=user-service”
kubectl get pods --selector=“app=user-service”
kubectl get pods --selector=“app in (“user-service”,“order-service”)”
kubectl get pods --selector=“app notin (“user-service”,“order-service”)”
更多时候都是在 对象yaml maifest文件中配置标签选择器
在yaml中使用标签
yaml中使用selector 属性来配置选择的标签
Service 与 ReplicationController yaml中使用spec:selector
spec:
selector:
# 指定服务的pod对应的label
app: myapp
Job、 Deployment、 ReplicaSet 和 DaemonSet yaml中使用spec:selector
selector:
# 使用matchLabels 标签
matchLabels:
# 指定的pod对应的label
app: myapp
# 使用表达式配置
matchExpressions:
- {key: tier, operator: In, values: [cache]}
- {key: environment, operator: NotIn, values: [dev]}
Pod Deployment 可以指定pod部署对应标签的node spec:nodeSelector
spec:
#选择节点标签
nodeSelector:
cpu: "good"
注解的使用
注解为对象附加任意的非标识的元数据。客户端程序（例如工具和库）能够获取这些元数据信息。
注解不用于标识和选择对象。 注解中的元数据，可以很小，也可以很大，可以是结构化的，也可以是非结构化的，能够包含标签不允许的字符
注解更多的作用是起一个辅助作用，便于了解对象，实践上不参与对象的活动
metadata:
annotations:
"key1" : "value1"
"key2" : "value2"
官方资料 https://kubernetes.io/zh-cn/docs/concepts/overview/working-with-objects/annotations/
名字空间 Namespace
名字空间（Namespace） 提供一种机制，将同一集群中的资源划分为相互隔离的组，逻辑上彼此隔离(不同的团队有自己的namespace 保证一定的安全性)。 同一名字空间内的资源名称要唯一，但跨名字空间时没有这个要求。
名字空间作用域仅针对带有名字空间的对象（Kind），例如 Deployment、Service 等， 这种作用域对集群访问的对象不适用，例如 StorageClass、Node、PersistentVolume 等。
名字空间适用于存在很多跨多个团队或项目的用户的场景。对于只有几到几十个用户的集群可以不需要创建或考虑名字空间。*
Kubernetes 启动时会创建四个初始名字空间：
-
default：Kubernetes 包含这个名字空间，以便于你无需创建新的名字空间即可开始使用新集群。
-
kube-node-lease 该名字空间包含用于与各个节点关联的 Lease（租约）对象。 节点租约允许 kubelet 发送心跳， 由此控制面能够检测到节点故障。
-
kube-public 所有的客户端（包括未经身份验证的客户端）都可以读取该名字空间。 该名字空间主要预留为集群使用，以便某些资源需要在整个集群中可见可读。 该名字空间的公共属性只是一种约定而非要求。
-
kube-system 该名字空间用于 Kubernetes 系统创建的对象
kubectl get namespaces
kubectl get namesapce
kubectl get ns # 三个操作等效
kubectl get ns --show-labels # 显示namespace的label
kubectl describe ns default
创建 Namespace
创建Namespace有两种方式
-
1 使用kubectl create ns
-
2 使用yaml 配置文件
kubectl create ns 【自定义命名空间】
kubectl create ns jeffzhang
建议使用yml创建命名空间 见《/yaml/namespace.yml》
kubectl apply -f namespace.yml
删除Namespace 直接使用 kubectl delete ns 【自定义命名空间】
使用 namespace
只需要在 pod , deployment, service 等yml配置文件中的 metadata:中定义namespace即可
apiVersion: apps/v1
kind: Deployment
metadata:
name: springboot2
namespace: xxx #指定部署的namespace
labels:
app: springboot2
team: dev-2
后续对deployment service pod等操作 都戴上 -n 【命名空间名称】
kubectl get service -n 【命名空间名称】
kubectl delete deployment 【xxx】 -n 【命名空间名称】
主要特性（kind）
本章探讨 k8s中的主要特性（kind）
查看当前K8s支持的所有kind
kubectl api-resources -o wide --namespaced=true
Pod
Pod 是 kubernetes最小工作单元, 例如 docker中的最小单元是容器。
每个Pod中都可以包含一个或者多个容器Pod内部的容器是共享一套linux命名空间的 （IPC PID NET …）隔离，这些容器可以分为两类:
-
用户程序所在的容器，数量可以有多个
-
Pause容器，这是每个Pod都会有的一个根容器
Pause容器作用有两个：
1 可以以它为依据，评估整个Pod的健康状态（pause容器 pid =1 起到类似init进程的作用 回收僵尸进行）
2 可以在根容器上设置Ip地址，Pod里的其他容器会加入到这个pause对应的网络空间，以实现Pod内部的网路通信 。 Pod的之间的通讯采用虚拟二层网络技术来实现（vxlan）
容器必须运行在pod中，一个pod运行一个或多个容器 注意粒度
Pod中的每个容器都共享Pod的整个网络命名空间——IP地址、localhost适配器、端口范围、路由表等。
一个Pod中可以运行多个容器 但不建议这样做 pod是可以扩容的，如果pod中有数据库 数据源也被扩容了
Pod中的容器如何可以分开运行在不同的机器上没有影响则 一个pod运行一个容器
由于每个Pod都获取到其可路由的IP地址，因此Pod网络上的每个Pod都可以与其他Pod进行直接通信
Pod的生命周期
用户定义一个YAML格式的清单文件，并将其POST到API Server。一旦发送成功，清单文件中的内容就
被作为一条意图记录（a record of intent）——即“期望状态”（desired state）——持久化记录在集群存储中，
然后Pod被调度到一个健康的、有充足资源的节点上。
一旦完成调度，就会进入等待状态（pending state），此时节点会下载镜像并启动容器。
在所有资源就绪前，Pod的状态都保持在等待状态。
一切就绪后，Pod进入运行状态（running state）。在完成所有任务后，会停止并进入成功状态（succeeded state）。
创建Pod
- 1 使用命令创建
- 2 使用 yml Manifest文件
使用命令创建
kubectl run order-service --image=registry.cn-hangzhou.aliyuncs.com/jimliu/order-service:latest
使用命令创建Pod 实际上是通过Deployment ReplicaSet创建的Pod
删除的时候需要删除Deployment
kubectl delete deployments order-service
使用 yml Manifest文件
Pod yaml Manifest文件见 /yaml/pod.yaml
创建单独的Pod
kubectl apply -f pod.yaml
单独的Pod只能在集群内部访问
可以查看pod 的详细信息
kubectl describe pods 【pod名称】
kubectl describe pods order-service
删除Pod时不会立即杀死Pod。此时pod处于Terminating状态（不能接收新的请求），有30秒宽限期，让Pod执行完所有活动的请求
其他Pod操作 类似docker
查看日志
kubectl logs -f 【pod名称】
进入Pod
kubectl exec -it 【pod名称】 bash
Pod的健康检查
支持三种方式
- HTTP
- TcpSocket
- exec (执行脚本)
只有Pod就绪了k8s集群才会向其发送流量，可以有效的避免无效流量的影响
Pod的资源限制
在yaml 文件中添加 resources配置
resources:
requests:
cpu: "500m"
memory: "128Mi"
Pod的数据卷
可以利用数据卷实现Pod数据持久化
支持
- hostPath
- nfs
因为Pod可以部署多个容器，所以需要spec.volumes定义出所有可以访问的卷，然后再容器中定义volumeMounts数组 定义各个容器使用的卷
使用卷时, 在 .spec.volumes 字段中设置为 Pod 提供的卷，并在 .spec.containers[*].volumeMounts 字段中声明卷在容器中的挂载位置
Pod 数据集配置 yaml Manifest文件见/yaml/pod.yaml
官方配置说明： https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/
关于Pod的一些常用命令
kubectl get pods 查看默认命名空间下的pod
kubectl get pods -o wide 查看默认命名空间下的pod 内容更加相信
kubectl get pods -n kube-system -o wide 查看指定命名空间下的pod 内容更加相信
登陆pod内部
类似 docker exec -it k8s也可以登陆到pod内部查看
kubectl exec -it 【pod名字】 /bin/bash
查看pod日志
类似 docker logs -f k8s也可以查看pod日志
kubectl logs -f 【pod名字】
Service & Endpoints
K8s中服务的发现基于 service 这个kind
Service引入的原理：
Pod的IP地址是不可靠的。在某个Pod失效之后，它会被一个拥有新的IP的Pod代替。Deployment扩容也会引入拥有新IP的Pod；而缩容则会删除Pod。这会导致大量的IP流失，因而Pod的IP地址是不可靠的
Service为Pod 提供负载均衡，Service有自己的IP和端口
Service 通过 label 关联对应的 Pod （Service自己并不直接匹配后端Pod的标签，而是由Endpoint匹配）
Servcie 生命周期不跟 Pod 绑定，不会因为 Pod 重建改变 IP
提供了负载均衡功能，自动转发流量到不同 Pod
可对集群外部提供访问端口
集群内部可通过服务名字访问
Service有一下功能
- 1 自己的IP地址
- 2 K8s集群DNS中的DNS名称
- 3 负载均衡规则 将流量代理到Pod
Service的创建
创建Service有两种方式
- 使用 kebectl expose
- 使用 service yaml maifest文件配置
详情见：(/yaml/service.yaml)
使用 kubectl delete service 【service名称】 删除service
Service的 type类型
使用type配置service的类型 主要有以下三种：
- ClusterIP 默认的，仅在集群内可用，及使用主机ip是无法访问到应用的
- NodePort 暴露端口到节点，提供了集群外部访问的入口，及使用主机ip+nodePort端口号可以访问集群内应用**（注意：端口范围固定 30000 ~ 32767）**
- LoadBalancer 需要负载均衡器（通常都需要云服务商提供）会额外生成一个 IP 对外服务 (一般情况无法使用)
Service中的nodePort，targetPort，port的区别和意义
1、port：8080
k8s中的服务之间访问的端口，集群内其他容器需要通过8081端口访问该服务，外部机器不能访问通过该端口访问该服务
2、targetPort：8080
容器的端口（最根本的端口入口），也就是没上k8s之前该服务使用的端口
3、nodePort：31000
k8s集群外部机器可访问的端口，那么其他机器就可以通过浏览器访问 ClientIP(k8s集群内任一机器ip)://:31000 访问到该服务
Service 与 Endpoints的关系
创建Service的时候会自动创建一个同名的Endpoint资源**（注意service需要配置spec:selector才会自动创建）**,每一个Servie都有一个Endpoints资源。
因为Service自己并不直接匹配后端Pod的标签，而是由Endpoint匹配的。这个匹配过程是由Endpoint控制器来完成的。
Service对象借助Endpoint资源来观察和跟踪其后段端点，Endpoint对象会根据Service标签选择器筛选出来的后端端点的IP地址分别保存在subsets.address字段和subsets.notReadyAddress字段中，它通过API-Server持续动态跟踪每个端点的状态变化，并及时反应到端点IP所属的字段
Service通过Selector和Pod建立关联，K8s会根据Service关联到的PodIP信息组合成一个Endpoint，若Service定义中没有Selector字段，Service被创建时Endpoint Controller不会自动创建Endpoint；
官方资料： https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/
Endpoints不仅可以配置为集群内的Pod 也可配置为集群外的服务
以下例子Endpoints 配置为一个集群外的服务 (/yaml/service-out.yaml)
集群外的一个机器(1.117.218.253)上部署一个java项目
k8s上创建一个service
未使用selector标签选择器创建的service是没有自动创建endpoint的
配置一个endpoint 注意名字要和service的名字一致 (/yaml/endpoint.yaml)
测试成功
由此可见service主要是负责集群内部的负载均衡，endpoint才是真正的后端服务
修改默认的service nodePort范围
默认的nodePort范围是30000 ~ 32767 这个范围不利于我们应用的部署
可以通过修改kube-apiserver.yaml配置文件来修改 service nodePort 端口范围
kube-apiserver.yaml 存在于master节点上 （集群创建完成后自动创建此文件）
vi /etc/kubernetes/manifests/kube-apiserver.yaml
添加
--service-node-port-range=1000-60000
保存文件后k8s会自动重启kube-apiserver （k8s会自动监控文件变化）
ReplicaSet
ReplicaSet的作用是创建和管理Pod的副本集合，如果只创建Pod的话不利于快速扩容
ReplicaSet 的目的是维护一组在任何时候都处于运行状态的 Pod 副本的稳定集合。 因此，它通常用来保证给定数量的、完全相同的 Pod 的可用性。
ReplicaSet代表集群内单个可扩展的微服务，每个由ReplicaSet控制器创建的Pod都是完全同类的
ReplicaSet面向的是【无状态的服务】
ReplicaSet 可以创建Pod 并管理pod，大多数情况下可以使用Deployment代替ReplicaSet
官方资料 https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/replicaset/
创建 更新 删除 ReplicaSet
创建ReplicaSet 建议使用 ReplicaSet yaml maifest
配置文件见 /yaml/replicaset.yaml 此文件是包含Pod信息的
使用 kubectl apply -f replicaset.yaml 创建 更新 ReplicaSet
例如要扩容或缩容 直接修改replicaset.yaml 再执行kubectl apply -f
删除一个pod后会马上创建一个Pod 保证Pod的数量是ReplicaSet spec:replicas: 中指定的数量
replicaset-withtemplate.yaml
spec:
# 按你的实际情况修改副本数
replicas: 3
只有删除ReplicaSet才能删除Pod
kubectl delete rs 【对象】
kubectl delete rs order-service-replicaset
查看 ReplicaSet
可以使用kubectl get命令查看 ReplicaSet
ReplicaSet 的简写是rs
kubectl get rs 查看所有 ReplicaSet
kubectl get rs 【ReplicaSet名称】
kubectl describe rs order-service-replicaset
ReplicaSet实现了快速的故障转移同时实现了可伸缩性
DaemonSet
DaemonSet的作用是在k8s集群中的每个node节点上部署Pod
DaemonSet保证pod的副本可以在k8s集群的一组节点上运行，
特别适合配置那些作为守护进程的Pod 例如日志收集，监控代理这些Pod必须在每个节点上运行
注意ReplicaSet与DaemonSet类似 但ReplicaSet会随机选择节点，可能一个Pod会在同一个节点上部署多个
创建 更新 删除 DaemonSet
创建DaemonSet 建议使用 DaemonSet yaml maifest
配置文件见 /yaml/daemonset.yaml 此文件是包含Pod信息的
kubectl apply -f daemonset.yaml
DaemonSet会在每个节点上部署Pod
删除DaemonSet可以使用以下命令
- kubectl delete ds order-service-ds
- kubectl delete -f daemonset.yaml
查看 DaemonSet
使用以下命令查看DaemonSet
kubectl get ds
kubectl describe ds order-service-ds
Job & ScheduledJobs
处理一次性的功能
官方文档：https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/job/
待深入探究
ConfigMap
ConfigMap用于提供工作负载的配置信息,使用 ConfigMap将配置数据和应用程序代码分开
ConfigMap的作用是定义一个小型的文件系统，作为一组变量用于为容器定义环境变量或命令
注意： ConfigMap在运行前就已经和Pod结合了，这样只需要修改ConfigMap就可以在其他应用中重用容器镜像和Pod
ConfigMap 在设计上不是用来保存大量数据的。在 ConfigMap 中保存的数据不可超过 1 MiB。如果你需要保存超出此尺寸限制的数据，你可能希望考虑挂载存储卷 或者使用独立的数据库或者文件服务
官方资料： https://kubernetes.io/zh-cn/docs/concepts/configuration/configmap/
创建 查看 修改 ConfigMap
创建ConfigMap 建议使用 ConfigMap yaml maifest
配置文件见 /yaml/configmap.yaml
kubectl apply -f configmap.yaml 创建 更新 ConfigMap 都可以使用kubectl apply -f
使用kubectl get cm （cm 是ConfigMap 简写）查看默认命名空间下的ConfigMap
使用kubectl describe cm 【ConfigMap名称】查看详情
使用 ConfigMap
本例子使用 my-docker-demo-sp-order 中的接口
@RequestMapping(value="/getEnv",produces="text/plain;version=0.0.4;charset=utf-8")
public String getEnv() {
Map<String,String> map = System.getenv();
StringBuilder sb = new StringBuilder();
for(String key : map.keySet()){
sb.append("## " + key + " : " + map.get(key) + "\n");
}
return sb.toString();
}
以上代码可以获取环境变量配置
使用 configmap.yaml创建 ConfigMap
使用 pod-config.yaml创建 Pod
配置见/yaml configmap.yaml pod-config.yaml
env:
# 定义环境变量
- name: PLAYER_INITIAL_LIVES # 请注意这里和 ConfigMap 中的键名是不一样的
valueFrom:
configMapKeyRef:
# name配置为存在的ConfigMap （见configmap.yaml）
name: my-config-map
# 需要取值的key 注意这个key就是ConfigMap中配置的 （见configmap.yaml）
key: player_initial_lives
volumes:
# 你可以在 Pod 级别设置卷，然后将其挂载到 Pod 内的容器中
- name: config
configMap:
# 提供你想要挂载的 ConfigMap 的名字
name: my-config-map
# 来自 ConfigMap 的一组键，将被创建为文件
items:
- key: "game.properties"
path: "game.properties"
- key: "user-interface.properties"
path: "user-interface.properties"
Pod配置中关键是使用 valueFrom:configMapKeyRef 配置环境变量数据来源于ConfigMap
执行
kubectl apply -f configmap.yaml
kubectl apply -f pod-config.yaml
访问Pod中的接口 可以看到环境变量已经加入
进入容器可以看到ConfigMap 中的配置文件也成功挂载
更新 ConfigMap 只需要修改yaml maifest文件后 再执行kubectl apply -f 就可以了
登录到容器内部 查看挂载的配置
注意：以环境变量方式使用的 ConfigMap 数据不会被自动更新。 更新这些数据需要重新启动 Pod
Secret
Secret 是一种包含少量敏感信息例如密码、令牌或密钥的对象。 这样的信息可能会被放在 Pod 规约中或者镜像中。 使用 Secret 意味着你不需要在应用程序代码中包含机密数据。
由于创建 Secret 可以独立于使用它们的 Pod， 因此在创建、查看和编辑 Pod 的工作流程中暴露 Secret（及其数据）的风险较小。 Kubernetes 和在集群中运行的应用程序也可以对 Secret 采取额外的预防措施， 例如避免将机密数据写入非易失性存储。
Secret 类似于 ConfigMap 但专门用于保存机密数据
官方资料： https://kubernetes.io/zh-cn/docs/concepts/configuration/secret/
创建 Secret
创建 Secret 有以下几种可选方式：
- 使用 kubectl
- 使用yaml配置文件
- 使用 Kustomize 工具 https://kubernetes.io/zh-cn/docs/tasks/configmap-secret/managing-secret-using-kustomize/
这里 主要测试前两种创建Secret 的方式
使用 kubectl命令行 创建 Secret
使用 kubectl create secret generic 【自定Secret名称】创建
使用--from-literal 配置字面数据
注意--from-literal后面是key=value各式
kubectl create secret generic mysqlaccount --from-literal=username=admin --from-literal=password='123456'
kubectl get secret 查看secret 默认名字空间
kubectl describe secret mysqlaccount
kubectl get secret mysqlaccount -o jsonpath='{.data}' | xargs echo 输出secret中的data
echo 'YWRtaW4=' | base64 --decode | xargs echo 解码data
也可使用–from-file= 方式从文件中指定数据源
使用--from-file 配置数量来源文件
kubectl create secret generic redisaccount --from-file=./name.txt --from-file=./pass.txt
默认Key键名为文件名。也可以通过 --from-file=[key=]source
kubectl create secret generic redisaccount --from-file=username=./name.txt --from-file=password=./pass.txt
kubectl describe secret redisaccount
kubectl get secret redisaccount -o jsonpath='{.data}' | xargs echo 输出secret中的data
echo 'MTIzCg==' | base64 --decode | xargs echo 解码data
使用yaml配置文件 创建 Secret
配置文件见 /yaml/secret.yaml
注意事项：
- 1 内容需要使用base64编码
- 2 内容中不要出现\n换行符
Secret有三种类型：
-
Opaque：使用base64编码存储信息，可以通过base64 --decode解码获得原始数据，因此安全性弱。
-
kubernetes.io/dockerconfigjson：用于存储docker registry的认证信息。
-
kubernetes.io/service-account-token：用于被 serviceaccount 引用。serviceaccout 创建时 Kubernetes 会默认创建对应的 secret。Pod 如果使用了 serviceaccount，对应的 secret 会自动挂载到 Pod 的 /run/secrets/kubernetes.io/serviceaccount 目录中。
使用 echo 将数据base64
例如
echo -n ‘12345678’ | base64
一个最简的Secret yaml
apiVersion: v1
kind: Secret
metadata:
name: appaccount
# 指定类型
type: Opaque
data:
username: cm9vdA==
password: MTIzNDU2Nzg=
kubectl apply -f secret.yaml
修改 secret 的方式可以使用
- kubectl edit secret
- kubectl apply -f
使用 Secret
使用Secret类似ConfigMap 配置见 /yaml/pod-secret.yaml
env:
# 环境变量的名称
- name: SECRET_USERNAME
valueFrom:
secretKeyRef:
# Secret的名称 见 secret.yaml 中name的配置
name: appaccount
# 见 secret.yaml 中data的配置
key: username
optional: false # 此值为默认值；意味着 "appaccount"必须存在且包含名为 "username" 的主键
volumeMounts:
- name: secret
mountPath: "/data/service/logs"
readOnly: true
volumes:
- name: secret
secret:
secretName: appaccount
optional: false # 默认设置，意味着 "mysqlaccount" 必须已经存在
使用 Secret 保存Docker 仓库登录信息
kubectl create secret docker-registry 【secret名称】
例如
kubectl create secret docker-registry myaliyunsecret
--docker-server=registry.cn-hangzhou.aliyuncs.com
--docker-username=liuyijiang3430@qq.com --docker-password=xxxx
--docker-email=liuyijiang3430@qq.com
**Pod配置文件中加入 imagePullSecrets **
imagePullSecrets:
- name: myaliyunsecret
containers:
- name: goods-service-runtime #容器名称(自定义)
image: registry.cn-hangzhou.aliyuncs.com/jimliu/goods-service:2.3.3
这样拉取镜像的时候就可以使用配置的secret
Deployment
Deployment 发布程序 版本控制
Deployment控制器是工作在ReplicaSet之上的，Deployment通过控制ReplicaSet来控制pod，并不是直接控制pod。
Deployment 用来部署项目创建后会创建一个 ReplicaSet
创建 更新 删除 Deployment
有两种方式创建Deployment
- 1 kubectl run
- 2 使用yaml配置文件的方式
kubectl run 会自动创建Deployment
kubectl run order-service --image=registry.cn-hangzhou.aliyuncs.com/jimliu/order-service
yaml配置文件的方式
kubectl apply -f deployment.yaml
更新deployment
apply -f deployment.yaml 也可以更新 deployment
删除 deployment
kubectl delete deployment 【deployment名称】
kubectl delete -f deployment.yaml
扩容与缩容 Deployment
使用 kubectl scale 实现对Deployment 的扩容缩容
kubectl scale deployments order-service-dp --replicas=3
kubectl scale {deployment | rc} ["部署名称"]
如果应用是使用deployment部署的使用
kubectl scale deployment nginx-deployment --replicas=3
如果应用是使用Replication Controller部署的使用
kubectl scale rc nginx-deployment --replicas=3
--replicas=代表部署几个应用
Deployment 版本控制
在日常开发过程中可能会遇到需要回退到某个版本的情况 使用关键配置 –record
kubectl apply -f deploy.yml --record
--record 参数： K8S会维护Deployment的版本历史记录
查看deployment的版本
kubectl rollout history deploy goods-service
可以查看每次部署对应的版本信息
kubectl rollout undo deployment goods-service --to-revision=1
回滚到某个版本
Deployment 部署策略
Deployment 提供了两种更新策略
- Recreate策略
- RollingUpdate策略
Recreate策略
会导致站点的停机，Recreate策略适合：**不面向用户，可接受少了停机时间**
RollingUpdate策略
使用RollingUpdate 可以让服务在接受用户流量的情况下，部署新的版本不出现停机
RollingUpdate一次更新少量Pod,逐步推进，直到所有Pod都运行新的版本
strategy:
rollingUpdate:
maxSurge: 1 #指定为100%的时候就相当蓝绿发布
maxUnavailable: 1 #指定滚动更新时间内可用的最大Pod数
type: RollingUpdate
K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容
更多推荐
6
0- 0
已为社区贡献1条内容
所有评论(0)