[toc]

kubernetes 笔记


CI: 持续集成
CD: 持续交付,Delivery
CD: 持续部署,Deployment

kubernetes的releases版本

kubernetes 自动装箱、自我修复、自动实现水平扩展
自动实现服务发现和负载均衡,自动发布和回滚
密钥和配置集中化管理、存储编排(动态供给)
任务批处理

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
master/node 
master: API Sserver,Scheduler, Controller-Manager
node: kubelet, docker(容器引擎), kube-proxy
Pod, Label, Label Selector
Label: key=value
Label: Selector:
Pod:
自主式Pod
控制器管理的Pod
ReplicationController
ReplicaSet
Deployment
StateFulSet(有状态副本集)
DaemonSet
Job,Ctonjob
AddOns: 附加组件
HPA
HorizontalPodAutoscaler

Master 节点: 整个k8s集群的司令部
核心组件: api_server 负责接收并处理请求
schechuler 调度容器的创建请求
控制器管理器: 确保控制器是健康状态的
k8s 并不直接调度容器,而调度的是pod。pod对容器做为封装;

服务的自动发现功能,就是把自己信息注册上去;
NMT: 一般开放给外部访问的只有N,而N 在集群内其实是也是客户端;
在一个大的集群中,只把有特殊需求的,开放给客户端;
LBaaS: 负载均衡及服务;

多种通信
同一个Pod内的多个容器间通信:lo
各Pod之间的通信 Overlay Network,叠加网络通信(二层叠加,三层叠加)
Pod与Service之间的通信

1
2
3
4
CNI插件体系:容器网络接口
flannel: 网络配置
calico: 网络配置,网络策略
canel: 网络配置,网络策略

客户端–> API server
user: username, uid
group:
extra:

环境:

1
2
3
4
master: etcd: 10.180.66.11
node1: 10.180.66.12
node2: 10.180.66.13
注意这三台服务器需要时间同步

前提:

1
2
3
4
5
1、基于主机名通信: /etc/hosts;
2、时间同步;
3、关闭firewalld和iptables.service;

OS: CentOS 7.3.1611, Extras仓库中;

安装配置步骤:

1
2
3
4
5
6
7
8
9
10
11
1、etcd cluster,仅Master节点;
2、flannel,集群的所有节点;
3、配置k8s的master:仅master节点;
kubernetes-master
启动的服务:
kube-apiserver,kub-scheduler,kube-controller-manager
4、配置k8s的各Node节点;
kubernetes-node
先设定启动docker服务;
启动的k8s的服务:
kube-proxy,kubelet

kubeadm

1
2
3
4
5
1、master, nodes:安装kubelet,kubeadm,docker
2、master: kubeadm init
3、nodes: kubeadm join
https://github.com/kubernetes/kubeadm/blob/master/docs/design/design_v1.10.md
无论server 还是node 一般服务
1
2
3
4
5
6
7
8
9
10
11
master:
# cd /etc/yum.repos.d/
# wget https://mirrors.aliyun.com/docker-ce/linux/centos-ce.repo
# vim kubernetes.repo
[kubernetes]
name=Kubernetes Repo
baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kuberentes-el7-x86_64/
gpgcheck=1
pgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg
enabled=1
# yum -y install docker-ce kubelet kubeadm kubectl

补充:
清华大学mirrors地址
阿里云k8s地址


提供网络功能
RESTful
GET, PUT, DELETE, POST, …
kubectl run, get, edit, …
资源:对象
工作负载性资源对象 workload: Pod,ReplicaSet, Deployment, StatefulSet, DaemonSet, Job, Cronjob, …
服务发现及服务均衡: Service, Ingerss, …
配置与存储: Volume,CSI
ConfigMap,Secret,
DownwardAPI,
集群级资源:
Namespace,Node,Role,ClusterRole,RoleBinding, ClusterRoleBinding
无数据型资源:
HPA,PodTemplate,LimitRange
创建资源的方法:
apiserver仅接收JSON格式的资源定义;
yaml格式提供配置清单,apiserver可自动将其转为json格式,而后再提交;

大部分资源的配置清单:
apiversion:group/version;
$ kubectl api-versions
kind:资源类别
metadata:元数据
name必需是唯一的
namespace
labels
annotations
每个资源的引用PATH
/api/GROUP/VERSION/namspace/NAMESAPCE/TYPE/NAME
spec:期望的状态,disired state
status: 当前状态,current state,本字段由kubernetes集群维护;
资源配置清单:
自主式Pod资源
资源的清单格式:
一级字段: apiVersion(group/version),kind,metadata(name,namespace,lables,annotations,…)spec,status(只读)
Pod资源:
spec.container<[]object>

- name <string>
- image <string>
  imagePullPloicy <string>
    Always(下载), Never(不下载), IfNotPresent(本地不存在镜像则下载)

修改镜像中的默认应用:
command,args
https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/

liveness probe:存活状态检测


Image Entrypoint Image Cmd Container command Container args Command run
[/ep-1] [foo bar] \ \ [ep-1 foo bar]
[/ep-1] [foo bar] [/ep-2] \ [ep-2]
[/ep-1] [foo bar] \ [zoo boo] [ep-1 zoo boo]
[/ep-1] [foo bar] [/ep-2] [zoo boo] [ep-2 zoo boo]

标签:
key=value
key: 字母、数字、_、-、.
value: 可以为空,只能字母或数字开头及结尾,中间可使用
标签选择器:
等值关系:=,==,!=
集合关系:
KEY in (VALUE1,VALUE2,…)
KEY notin (VALUE1,VALUE2,…)
KEY 存在这个键就可以
!KEY 不存在这个键的资源

1
# kubectl get pods -l "release notin (canary,beta,alpha)"

许多资源支持内嵌字段定义其使用的标签选择器:
matchLables: 直接给定键值
matchLables: 基于给定的表达式来定义使用的标签选择器,{key:”KEY”,operator:”OPERATOR”, value:[VAL1,VAL2,…]}
操作符:
IN, NotIN:vlaues字段的值必须为空列表;
Exists, NotExists:values字段的值必须为空列表;


nodeSelector <map[string]string>
节点标签选择器,
nodeName
annotations:
与label不同的地方在于, 它不能用于挑选资源对象,仅用于为对象提供”元数据”。
Pod的生命周期
状态:Pending(挂起),已经创建,但未找到运行它的节点;
Running;
Failed;
Succeede;
Unknown
Pod生命周期中的重要行为:
实始化容器
容器探测:
liveness
readliness
restartPolicy:
Always, OnFailure, Never. Default to Always.

探针类型有三种:
ExecAction、 TCPSocketAction、 HTTPGetAction

Pod控制器:
ReplicationController:
ReplicaSet: 代用户创建指定数量的Pod副本,多退少补,滚动更新;新一代的ReplicationController
Deployment: 建构在ReplicaSet之上的,流动更新,回滚,声明式配置;
DemonSet:
Job:
CronJob:
StatefulSet
TRR: Third Party Resources, 1.2+, 1.7
CDR: Custom Defined Resources, 1.8+
Operator:
一个坏的脚本在k8s集群中,很有可能导致整个k8s集群岩掉;

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: myapp
namespace: default
spec:
replicas: 2
relector:
matchLabels:
app: myapp
replease: canary
template:
metadata:
name: myapp-pod
labels:
app: myapp
replease: canary
environment:qa
spec:
contrainers:
- name: myapp-container
image: ikuberentes/myapp:v1
ports:
- name: http
containerPort: 80
# kubectl create -f rs-demo.yaml

Helm: 外壳 类似于redhat系统上的yum管理器一样

Service
工作模式:userspace, iptables, ipvs
userspace: 1.1-
iptables: 1.10-
ipvs: 1.11+
类型:
ExternalName, CluseterIP, NodePort, and LoadBalancer
资源记录:
SVC_NAME.NS_NAME.DOMAIN.LTD.
svc.cluster.local.
redis.default.svc.custer.local.

NodePort:client –> NodeIP:NodePort –>ClusterIP:ServciePort –> PodIP:containerPort
LoadBalancer
ExternelName
FQDN
CNAME –> FQDN
No ClusterIP: Headless Service
ServiceName –> PodIP

解决方案
多组nginx server 对应多个pod;
多个url 映射多个pod;

配置容器化应用的方式:

1、 自定义命令行参数;
args: []

2、 把配置文件直接焙进镜像;

3、 环境变量
(1) Cloud Native的应用程序一般可以直接 通过环境变量加载配置;
(2) 通过entrypoint脚本来预处理变量为配置文件中的配置信息;

4、 存储卷

CoreOS: operator
StatefulSet:

1、稳定且惟一的网络标识符;
2、稳定且持久的存储;
3、有序、平滑地部署和扩展;
4、有序、平滑地删除和终止;
5、有序的滚动更新;

三个组件: headless service、 StatefulSet 、 volumeClaimTemplate
pod_name.service_name.ns_name.svc.cluster.local
myapp-0.myapp.default.svc.cluster.local

API
Request path
http://172.20.0.70:6443/apls/apps/v1/namespaces/default/deployment/myapp-deploy/

HTTP request verb:
get, post, pub, delete
API request verb:
get, list, create, update, patch, watch, redirect, delete, deletecollection

Resource:
Subresource:
Namespace
API group

Object URL:
/apis///namespaces/<NAMESPACE_NAME>/<KIND/[OBJECT_ID]>

role:
operation
objects
rolebinding:
user account OR service account
role

clusterrole, clusterrolebinding

role 授权: get * ; get pod ; get deployment;

授权插件: Node, ABAC, RBAC, Webhook(基于httpd的回调机制)
RBAC: Role-based AC ‘
角色(role)
许可(permission)

当用户权限 rolebinding 绑定到 clusterrolebinding 时,clusterrolebinding 会被降权为rolebinding;

spec.serviceAccountName
rolebinding
serviceaccount
role

Kubernetes:认证、授权
API server:
subject –> action –> object
认证: token,tls,user/password
账号:UserAccount, ServiceAccount
授权:RBAC
role,rolebinding
clusterrole,clusterrolebinding
subject:
user
group
serviceaccount
object:
resource group
resource
non-resource url
action:get,list,watch,patch,delete,deletecollection…

Dashboard
1、部署

1
kubectl apply -f https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml

2、将Service 改为NodePort

1
kubectl patch svc kubernetes-dashboard -p '{"spec":{"type":"NodePort"}}' -n kube-system

3、 认证:
认证时的账号必须为ServiceAccount: 被dashboard pod拿来由kubernetes进行认证的;
token:
(1) 创建ServiceAccount,根据其管理目标,使用rolebinding或clusterrolebinding 绑定至合理role或clusterrole;
(2) 获取到此ServiceAccount的secret,查看secret的详细信息,其中就有token;

kubeconfig:把ServiceAccount的token封装为kubeconfig文件
(1) 创建ServiceAccount,根据其管理目标,使用rolebinding或clusterrolebinding 绑定至合理role或clusterrole;
(2)

1
2
kubectl get secret | awk '/^ServiceAccount/{print $1}'
DEF_NS_ADMIN_TOKEN=$(kubectl get secret SERVCIEACCOUNT_SERRET_NAME -o jsonpath={.data.token} | base64 -d )

(3)生成kubeconfig 文件

1
2
3
4
kubectl config set-cluster --kuberconfig=/PATH/TO/SOMEFILE
kubectl config set-credentials NAME --token=$KUBE_TOKEN --kubeconfig=/PATH/TO/SOMEFILE
kubectl config set-context
kubectl config use-context

kubernetes集群的管理方式
1、命令式: create, run, expose, delete, edit, …
2、命令式配置文件:create -f /PATH/TO/RESOURCE_CONFIGURATION_FILE, delete -f , replace -f
3、声明式配置文件: apply -f,path,

docker 常用的四种网络模型 bridge/joined/open/none

Kubernetes网络通信:
(1)容器间通信: 同一个Pod内的多个容器间的通信,lo
(2)Pod通信: Pod IP <--> Pod IP
(3)Pod与Service通信:PodIP <--> ClusterIP
(4)Service与集群外部客户端的通信
CNI: Container Network Interface
flanner
calico
canel
kube-router

解决方案:
虚拟网桥
多路复用: MacVLAN
硬件交换: SR-IOV
kubelet, /etc/cni/net.d/
flannel:
支持多种后端:
VxLAN
(1)vxlan
(2)Directrouting
host-gw: Host Gateway
UDP
flannel的配置参数
Network: flannel使用的CIDR格式的网络地址,用于为Pod的配置网络功能;
master:10.244.0.0/24
node01:10.244.1.0/24

node255:10.244.255.0/24
SubneteLen:把Network切分子网供各节点使用时,使用多长的掩码进行切分,默认为28位;
SubnetMin:10.244.10.0/24 开始
SubnetMax:10.244.100.0/24 结束
Backend:vxlan, host-gw, udp
vxlan:
网络策略:
名称空间:
拒绝所有出站,入站;
放行所有出站目标本名称空间内的所有Pod;

调度器:
预选策略:
CheckNodeCondition
GeneralPredicates:
HostName: 检查Pod对象是否定义了pod.spec.hostname
PodFitsHostPorts:pods.spec.containers.ports.hostPort
MatchNodeSelector:pod.spec.nodeSelector
PodFitsResources:检查Pod的资源需求是否能被节点所满足;
NoDiskConflict:检查Pod依赖的存储卷是否能满足需求;
PodToleratesNodeTaints:检查Pod的specl.tolerations可容容忍的污点是否完全包含节点上的污点;
PodToleratesNodeNoExecuteTaints: 对应的行为是默认不检查的;
CheckNodeLabelPresence: 检查节点指定标签的存在性;
CheckServiceAffinity: 亲和性,将同一Service的Pod尽可能放在一块;
MaxEBSVolumeCount
MaxGCEPDVolumeCount
MaxAzureDiskVolumeCount
CheckVolumeBinding
NoVolumeZoneConflict
CheckNodeMemoryPressure: 检查内存节点是否存在压力;
CheckNodePIDPressure: 检查PID数量是否过多;
CheckNodeDiskPressure: 检查磁盘压力是否过大;
MatchInterPodAffity: 检查节点是否满pod足亲和性与反亲和性
优选函数
LeastRequested:(cpu((capacity-sum(requested))10/capacity)+memory((capacity-sum(requested))10/capacity))
BalancedResourceAllocation: CPU和内存资源被占用率相近的胜出;
NodePreferAvoidPods:节点注解信息”scheduler.alpha.kubernetes.io/perferAvoidPods”
TaintToleration: 将Pod对象的spec.tolerations列表项与节点的 taints列表项进行匹配度检查,匹配条目越多,得分越低;
SeletorSpreading:与当前Pod对象同属的标签选择器选择适配的其它选择其Pod对象所在的节点,越多的表示越低,否则越高;
NodeAffinity:基于节点亲和性的;
InterPodAffinity:遍历Pod对象的亲和性条目,并将能匹配到给定节点的条目的权重相加,结果值越大的,表示越高;

MostRequested:跟LeastRequested正好相反;
NodeLabel:标签越多,得分越高;
ImageLocality: 镜像越多,得分越高,根据满足当前Pod对象需求的已有镜像体积大小之和;

1
kubectl describe nodes node node01.ssjinyao.com

节点选择器:nodeSelector, nodeName
节点亲和调度: nodeAffinity

taint的effect定义对Pod排斥效果:
NoSchedule: 仅影响调度过程,对现存的Pod对象不产生影响;
NoExecute: 即影响调度过程,也影响现存的Pod对象;不容忍的Pod对象将被驱逐;
PreferNoSchedule:不能容忍被调度过来,但是实在没有别的节点运行,也可被调度,是NoSchedule的柔性版;

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp-deploy
namespace: default
spec:
replicas: 3
selector:
matchLabels:
app: myapp
release: canary
template:
metadata:
labels:
app:myapp
release:canary
spec:
containers:
- name: myapp
image: ikubernetes/myapp:v2
ports:
- name: myapp
image: ikubernetes/myapp: v2
ports:
- name: http
containerPort: 80
tolerations:
- key: "node-type"
operator: "Equal"
value: "production"
effect: "NoSchedule"

容器的资源需求,资源限制
requests: 需求,最低保障;
limits: 限制,最高消耗区间,硬限制;
CPU:
1颗逻辑CPU
1=1000微核心,millicores
500m=0.5CPU
内存:
E、P、T、G、M、K
Ei、Pi、Ti、Gi、Mi、Ki
QoS:
Guranteed: 每个容器同时设置CPU和内存的requests和limits;
cpu.limits=cpu.requests
memory.limits=memory.request
Burstable:至少一个容器设置CPU或者内存资源的requests属性;
BestEffort:没有任何一个容器设置了requests或limits属性;最低优先级别;
资源指标:metrics-server
自定义指标:prometheus,k8s-prometheus-adapter
新一代架架构:
核心指标流水线: 由kubelet、metrics-server以及由API server 提供的api组成;CPU累积使用率、内存实时使用率、Pod的资源占用率及容器的磁盘占用率;
监控流水线:用于从系统收集各种指标数据并提供终端用户、存储系统以及HPA,它们包含核心指标及许多非核心指标。非核心指标本身不能被k8s所解析,
metrics-server:API-server
Helm:
核心术语:
Chart: 一个helm程序包的;
Repository: Charts仓库,https/http服务器;
Release: 特定的Chart部署于目标集群上的一个实例;
Chart –> Config –> Release
程序架构:
helm:客户端,管理本地的Chart仓库,管理Chart,与Tiller服务器交互,发送Chart,实例安装、查询、卸载等操作;
Tiller: 服务端,可以运行在kubernetes之上,也可以运行在kubernetes之外、接收helm发来的Charts与Config,合并生成release;
RBAC配置文件示例:
https://github.com/helm/helm/blob/master/docs/rbac.md
官方可用的Chart列表:
https://hub.kubeapps.com
helm常用命令:
release管理

1
2
3
4
5
6
7
8
9
10
# helm search jenkins
# helm inspect jenkins
# helm list
# helm install
# helm delete
# helm upgrade
# helm rollback
# helm history # release的部署历史;
# helm status # 获取release状态信息;
# helm install --name redis -f ./values.yaml stable/redis

chart管理

1
2
3
4
5
6
# helm create
# helm fetch
# helm get
# helm inspect
# helm package 打包chart 文件
# helm verify
1
2
3
4
5
6
7
# helm lint ../myapp  # 检查语法错语
# helm package myapp/
# helm delete --purge mapp3
# helm delete --purge mapp2
# helm delete --purge mapp1
# helm repo add --help
# helm repo list

Chart –> helm,tiller service
Chart –> Config –>Release
Config:values.yaml

ELK: E:elasticsearch L:logstash K: kibana
日志收集的组件(Logstash、Filebeat、Fluentd)

当pod出现挂了的情况,查看pod日志时不方便查看。因此,应该将日志提前放到一个存储中。kubernetes集群应提供一个日志收集器。
完整的kubernetes 集群 (kubdns| kubcurl ,ingress controller,heapster| metrics-server prometheus, dashboard)
四大组件组成部分,另外附加附件efk;

/var/log –> /var/log/containers/
k8s系统关键组件:
Core Infrastructure –> Network(SDN) Storage (Provisioning Congfiguration ) –> Kubernetes Cluster –> Containerzed Worload (image registry)
额外的系统:Logging Monitoring
硬件及负载、软件及负载:LoadBalancer
存储位置:Artifact factory
构建自动化:Build Automation (CI,CD)
自动化发布:Rlease Automation

评论