动手学习Kubernetes #21

wmenjoy · 2020-02-14T13:23:01Z

使用kubectl + yaml配置部署docker

定义deployment.tpl

apiVersion: apps/v1
kind: Deployment
metadata:
  name: %%work.name%%
  labels:
    app.kubernetes.io/name: %%work.name%%
    app.kubernetes.io/env: %%work.env%%
spec:
  replicas: %%work.replicaCount%%
  selector:
    matchLabels:
      app.kubernetes.io/name: %%work.name%%
      app.kubernetes.io/env: %%work.env%%
  template:
    metadata:
      labels:
        app.kubernetes.io/name: %%work.name%%
        app.kubernetes.io/env: %%work.env%%
    spec:
      containers:
        - name: %%work.name%%
          image: %%work.image.repository%%:%%work.image.version%%
          imagePullPolicy: IfNotPresent
          ports:
            - name: http
              containerPort: 80
              protocol: TCP
          livenessProbe:
            httpGet:
              path: /
              port: http
          readinessProbe:
            httpGet:
              path: /
              port: http
          resources:
            limits:
              cpu: %%work.limit.cpu%%
              memory: %%work.limit.memory%%
            requests:
              cpu: %%work.limit.cpu%%
              memory: %%work.limit.memory%%

deployment的生成脚本

#!/bin/bash
 
ARGS=`getopt -o n:c:i:v:e:f:l:c:m --long name:,env:,replicaCount:,image:,version:,file:,:templateFile,cpu:,memory:,limitCPU:,limitMemory:,requestCPU:,requestMemory: -n 'mkdeployment.sh' -- "$@"`
 
 
if [ $? != 0 ]; then
   echo "参数错误 ./mkservice.sh -n $name"
   exit 1
fi
 
# echo $ARGS
eval set -- "$ARGS"
 
while true
do
  case "$1" in
      -n|--name)
        name=$2
        shift 2
        ;;
      -e|--env)
        env=$2
        shift 2
        ;;
      -f|--file)
        outFile=$2
        shift 2
        ;;
      -l|--templateFile)
        templateFile=$2
        shift 2
        ;;
      -c|--replicaCount)
        replicaCount=$2
        shift 2
        ;;
      -i|--image)
        image=$2
        shift 2
        ;;
      -v|--version)
        version=$2
        shift 2
        ;;
      -c|--cpu)
        cpu=$2
        shift 2
        ;;
      -m|--memory)
        memory=$2
        shift 2
        ;;
      --limitCPU)
        limitCPU=$2
        shift 2
        ;;
      --limitMemory)
        limitMemory=$2
        shift 2
        ;;
      --requestCPU)
        requestCPU=$2
        shift 2
        ;;
      --requestMemory)
        requestMemory=$2
        shift 2
        ;;
      --)
        shift
        break
        ;;
      *)
        echo "error"
        exit 1
        ;;
  esac
done
 
if [  "$#" -gt 0 ]; then
  echo "使用了多余的参数，请检查"
  for arg in $@
  do
    echo "processing $arg"
  done
  exit 1
fi
 
 
[ -z "$name" ] && echo "name 不能为空" && exit 1;
[ -z "$image" ] && echo "image 参数不能为空" && exit 1;
env=${env:-test}
replicaCount=${replicaCount:-1}
version=${version:-latest}
 
[ -z "$cpu" ] && cpu=100m
[ -z "$memory" ] && memory=256Mi
 
[ -z "$requestCPU" -a ! -z "$cpu" ] && requestCPU=$cpu
[ -z "$requestMemory" -a ! -z "$memory" ] && requestMemory=$memory
 
[ -z "$limitCPU" ] && limitCPU=$requestCPU
[ -z "$limitMemory" ] && limitMemory=$requestMemory
 
 
cDir=$(cd $(dirname .);pwd)
[ -z "$outFile" ] && outputFile=$cDir/deployment.yaml
[ -z "$templateFile" ] &&  templateFile=$cDir/deployment.tpl


sed "s#%%work.name%%#$name#g; s#%%work.env%%#$env#g;s/%%work.replicaCount%%/$replicaCount/g;s#%%work.image.repository%%#$image#g;s/%%work.image.version%%/$version/g;s/%%work.limit.cpu%%/$limitCpu/g;s/%%work.limit.memory%%/$limitMemory/g;s/%%work.request.cpu%%/$requestCpu/g;s/%%work.request.memory%%/$requestMemory/g;" $templateFile > $outputFile

定义service.tpl

apiVersion: v1
kind: Service
metadata:
  name: %%worker.service.name%%
  labels:
    app.kubernetes.io/name: %%work.name%%
    app.kubernetes.io/env: %%work.env%%
spec:
  type: %%worker.service.type%%
  ports:
    - port: %%worker.service.port%%
      targetPort: http
      protocol: TCP
      name: http
  selector:
    app.kubernetes.io/name: %%work.name%%
    app.kubernetes.io/env: %%work.env%%

生成service.yaml的脚本

!/bin/bash
 
ARGS=`getopt -o n:s:t:p:e:f:l --long name:,env:,serviceName:,serviceType:,port:,file:,:templateFile -n 'mkservice.sh' -- "$@"`
 
if [ $? != 0 ]; then
   echo "参数错误 ./mkservice.sh -n $name"
   exit 1
fi
 
# echo $ARGS
eval set -- "$ARGS"
 
while true
do
  case "$1" in
      -n|--name)
        name=$2
        shift 2
        ;;
      -e|--env)
        env=$2
        shift 2
        ;;
      -f|--file)
        outFile=$2
        shift 2
        ;;
      -l|--templateFile)
        templateFile=$2
        shift 2
        ;;
      -s|--serviceName)
        serviceName=$2
        shift 2
        ;;
      -t|--serviceType)
        serviceType=$2
        shift 2
        ;;
      -p|--port)
        port=$2
        shift 2
        ;;
      --)
        shift
        break
        ;;
      *)
        echo "error"
        exit 1
        ;;
  esac
done
 
if [  "$#" -gt 0 ]; then
  echo "使用了多余的参数，请检查"
  for arg in $@
  do
    echo "processing $arg"
  done
  exit 1
fi
 
[ -z "$name" ] && echo "name 不能为空" && exit 1;
 
env=${env:-test}
 
[ -z "$serviceName" ] && serviceName=$name-service
type=${serviceType:-ClusterIP}
port=${port:-80}
 
cDir=$(cd $(dirname .);pwd)
 
 
echo "$name $serviceName, $port, $env, $serviceType"
 
[ -z "$outFile" ] && outputFile=$cDir/service.yaml
[ -z "$templateFile" ] &&  templateFile=$cDir/service.tpl
 
sed "s#%%work.name%%#$name#g; s#%%work.env%%#$env#g;;s/%%worker.service.type%%/$type/g;s/%%worker.service.port%%/$port/g;s/%%worker.service.name%%/$serviceName/g;" $templateFile > $outputFile

脚本使用

依赖属性，通过发版平台来定义

appName=
env=test
replicaCount=2
image=
version=
outputDir=
scriptDir=
servicePort=

参数传递，通过环境变量

#!/bin/bash
mkdir -p $outputDir
$scriptDir/mkdeployments.sh --name $appName --image $image --version $version --templateFile $scriptDir/deployment.tpl --file $outputDir/deployment.yaml --env $env --replicaCount 2
$scriptDir/mkservice.sh --name $appName --env $env --templateFile $scriptDir/service.tpl --file $outputDir/service.yaml --port=$servicePort
kubectl apply -f $outputDir

wmenjoy · 2020-02-14T13:44:54Z

K8S 如何调试日志：

查看pod日志

$ kubectl logs zookeeper-1
## 可以通过--previous 参数查看之前的pod日志
$ kubectl logs zookeeper-1 --previous
## minikube 也有 minikube logs的日志

查看pod的生命周期的事件

## 命令 kubectl describe pod podname
$ kubectl describe pod bedoss-deploy-5767f7b56b-6ld27
Name:         bedoss-deploy-5767f7b56b-6ld27
Namespace:    default
Priority:     0
Node:         minikube/192.168.99.103
Start Time:   Thu, 13 Feb 2020 17:27:20 +0800
Labels:       app=myapp
              env=test
              pod-template-hash=5767f7b56b
              release=stabel
Annotations:  <none>
Status:       Running
IP:           172.17.0.2
IPs:
  IP:           172.17.0.2
Controlled By:  ReplicaSet/bedoss-deploy-5767f7b56b
Containers:
  myapp:
    Container ID:   docker://199a7789a43503c3b062fb25653af520e9559f52fec33f75773730fa340b89d3
    Image:          nginx:latest
    Image ID:       docker-pullable://nginx@sha256:ad5552c786f128e389a0263104ae39f3d3c7895579d45ae716f528185b36bc6f
    Port:           80/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Thu, 13 Feb 2020 17:35:45 +0800
    Last State:     Terminated
      Reason:       Completed
      Exit Code:    0
      Started:      Thu, 13 Feb 2020 17:27:21 +0800
      Finished:     Thu, 13 Feb 2020 17:33:50 +0800
    Ready:          True
    Restart Count:  1
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-p8z8j (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             True
  ContainersReady   True
  PodScheduled      True
Volumes:
  default-token-p8z8j:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-p8z8j
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:          <none>

查看pod重启的原因

依然通过describe 命令 Containers.[*].Last State 一节

$ kubectl describe pod podname
Name:       kafka-1 
...

Containers:
  kafka:
    State:      Running
       Started:     Sat, 08 Apr 2017 02:29:04 +0000
    Last State:     Terminated
       Reason:      OOMKilled
      Exit Code:    0
       Started:     Fri, 07 Apr 2017 11:06:56 +0000
      Finished:     Sat, 08 Apr 2017 02:29:04 +0000
    Ready:      True
   Restart Count:   1

比如，上节可以看到Container因为内存太多，被OOMKilled了

查看k8s的资源使用

需要安装heapster

# 查看使用最多的node
$ kubectl top nodes
# 查看使用最多的pods
$ kubectl top pods
# 查看节点的资源使用情况
$ kubectl describe nodes | grep -A 2 -e "^\\s*CPU Requests"

摘除某个pod进行debug

使用label机制，对Pod进行标记。在Service定义中，我们添加 status: serving字段。当需要摘下某个Pod做Debug，而又不影响整个服务，可以：

$ kubectl get pods --selector="status=serving"
$ kubectl label pods webserver-rc-lxag2 --overwrite status=debuging

此时kubelet就会把这个Pod从Service的后端列表中删掉。等到Debug完，想恢复？再改回去就好了：

$ kubectl label pods webserver-rc-lxag2 --overwrite status=serving

k8s 进入容器进行调试

格式

kubectl exec -it <podName> -c <containerName> -n <namespace> -- shell comand

比如

#适用于当前pod只有一个容器
kubectl exec -it superset-3fpnq -- /bin/bash    
#适用于当前pod只有一个容器 --container or -c 参数
kubectl exec -it superset-3fpnq --container main-app -- /bin/bash

kubernates 工具

Library to watch and follow kubernetes resources in CI/CD deploy
Log viewer for kubernetes with live tail for multiple pods, powerful filters, highlighters and bookmarks | Overview

参考

wmenjoy · 2020-02-17T02:48:09Z

Kubernates 部署

Setting up a private Helm chart repository on GitHub | by Jasiek Petryk | Medium
Comparison between Helm and Kustomize for Kubernetes yaml management | by Masato Naka | Medium
Using Makefiles And Envsubst As An Alternative To Helm And Ksonnet

运维工具

安装工具 Kops：The easiest way to get a production grade Kubernetes cluster up and running.
Kind, Cilium, MetalLB, and still no kube-proxy | by Charles-Edouard Brétéché | Jan, 2022 | Medium

CI/CD

(2) Kubernetes Architect on Twitter: "Learn how to use, build and deploy custom Tasks for Cloud-Native CI/CD on Kubernetes with Tekton Pipelines Read more https://t.co/616YQDL1k2" / Twitter

运维操作

pod 操作

强制删除

kubectl delete pod typhon-server-docker-8575667448-nmfk8 --grace-period=0 --force

回滚

记录历史 --record

kubectl  apply -f **** --record

查看当前状态

kubectl rollout status deployment/demo -w

查看历史

kubectl rollout history deployment/demo

回滚到指定版本

# --to-revision不写，默认回到上一个版本
kubectl rollout undo deployment/demo --to-revision=1

扩容

Aliyun autoscaler : contains autoscaling-related components for Kubernetes.

k8s 部署策略

参考部署策略

灰度测试

这里的场景局限于部署层面的灰度，Istio 层面的暂不考虑

基于原生的方案基本就是 1 个 Service + 2 个 Deployment 通过 Label 控制

                       +------------+
                       |            | <Label>
                       |   Service  |        app:test
                       |            |
                       +------------+



    +------------+                        +------------+
    |            |<Label>                |            | <Label>
    | Deployment |        app:test        | Deployment |        app:test
    |            |        timestamp:v1    |            |        timestamp:v2
    +------------+                        +------------+

平台层面做灰度的话，灰度期间严格限制操作，支持撤销和全量灰度的选项。考虑到要兼顾滚动更新，如果不想再实现一遍业务逻辑的话，可以按照当前副本数百分比和灰度上限来控制灰度 Deployment 的副本数。实际全量灰度的时候还是更新现有的 Deployment，删除当前灰度的 Deployment，这样实际更新的时候还是可以做到滚动机制，也是一种灰度方式。

定时部署代码

参考[kubernetes-cronhpa-controller]

迁移

velero :迁移工具

调度

keel-hq/keel: Kubernetes Operator to automate Helm, DaemonSet, StatefulSet & Deployment updates

Node Affinity 与 Taint and Tolerations

Application Deployment Engine

RIO: Application Deployment Engine for k8s

参考

wmenjoy · 2020-02-24T01:58:53Z

Kubernetes 证书

介绍

证书

集群相关证书类型

client certificate：用于服务端认证客户端,例如etcdctl、etcd proxy、fleetctl、docker客户端
server certificate: 服务端使用，客户端以此验证服务端身份,例如docker服务端、kube-apiserver
peer certificate: 双向证书，用于etcd集群成员间通信

根据认证对象可以将证书分成三类：服务器证书server cert，客户端证书client cert，对等证书peer cert(表示既是server cert又是client cert)，在kubernetes 集群中需要的证书种类如下：

etcd 节点需要标识自己服务的server cert，也需要client cert与etcd集群其他节点交互，当然可以分别指定2个证书，也可以使用一个对等证书
master 节点需要标识 apiserver服务的server cert，也需要client cert连接etcd集群，这里也使用一个对等证书
kubectl calico kube-proxy 只需要client cert，因此证书请求中 hosts 字段可以为空
kubelet证书比较特殊，不是手动生成，它由node节点TLS BootStrap向apiserver请求，由master节点的controller-manager 自动签发，包含一个client cert 和一个server cert

工具

CFSSL是CloudFlare开源的一款PKI/TLS工具。 CFSSL 包含一个命令行工具和一个用于签名，验证并且捆绑TLS证书的 HTTP API 服务。使用Go语言编写。

Github 地址： https://github.com/cloudflare/cfssl

官网地址： https://pkg.cfssl.org/

安装

curl -s -L -o /bin/cfssl https://pkg.cfssl.org/R1.2/cfssl_linux-amd64
curl -s -L -o /bin/cfssljson https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64
curl -s -L -o /bin/cfssl-certinfo https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64
chmod +x /bin/cfssl*

使用例子

参考

wmenjoy · 2020-02-24T02:29:31Z

kubernates 监控

介绍

Heapster

Heapster是Kubernetes旗下的一个项目，Heapster是一个收集者，并不是采集

1.Heapster可以收集Node节点上的cAdvisor数据：CPU、内存、网络和磁盘
2.将每个Node上的cAdvisor的数据进行汇总
3.按照kubernetes的资源类型来集合资源，比如Pod、Namespace
4.默认的metric数据聚合时间间隔是1分钟。还可以把数据导入到第三方工具ElasticSearch、InfluxDB、Kafka、Graphite
5.展示：Grafana或Google Cloud Monitoring

heapster已经被官方废弃（k8s 1.11版本中，HPA已经不再从hepaster获取数据）

CPU内存、HPA指标：改为metrics-server
基础监控：集成到prometheus中，kubelet将metric信息暴露成prometheus需要的格式，使用Prometheus Operator
事件监控：集成到heptiolabs/eventrouter

架构图

报警

Prometheus Aler:开源的运维告警中心消息转发系统,支持主流的监控系统Prometheus,日志系统Graylog和数据可视化系统Grafana发出的预警消息,支持钉钉,微信,华为云短信,腾讯云短信,腾讯云电话,阿里云短信,阿里云电话等
prymitive/karma: Alert dashboard for Prometheus Alertmanager

Event

kubernetes/kube-state-metrics: Add-on agent to generate and expose cluster-level metrics.

监控工具

SigNoz/signoz: SigNoz helps developers monitor their applications & troubleshoot problems, an open-source alternative to DataDog, NewRelic, etc. 🔥 🖥
2、abahmed/kwatch: monitor & detect crashes in your Kubernetes(K8s) cluster instantly

node检测

参考node problem detector
Prometheus exporter for hardware and os metrics:Prometheus exporter for hardware and OS metrics exposed by *NIX kernels, written in Go with pluggable metric collectors.
cloudflare/sciuro: Alertmanager to Kubernetes Node conditions bridge

变更管理

watch-proxy:sits in your Kubernetes cluster and watches resources you care about, then tells you when they are created, changed or deleted.

理解kubernates

octant:is a tool for developers to understand how applications run on a Kubernetes cluster
2.sonobuoy:is a diagnostic tool that makes it easier to understand the state of a Kubernetes cluster by running a set of Kubernetes conformance tests and other plugins in an accessible and non-destructive manner
3.Crash-Diagnostics:a tool to help investigate, analyze, and troubleshoot unresponsive or crashed Kubernetes clusters.

wmenjoy · 2020-02-24T03:19:19Z

新特性

1.8新特性

wmenjoy · 2020-02-24T06:07:58Z

Kubernates 对外提供服务

介绍

K8s对外提供服务，提供了NodePort, LoadBalance, Ingress
ClusterIP：默认方式。根据是否生成ClusterIP又可分为普通Service和Headless Service两类：
普通Service：通过为Kubernetes的Service分配一个集群内部可访问的固定虚拟IP（Cluster IP），实现集群内的访问。为最常见的方式。
Headless Service：该服务不会分配Cluster IP，也不通过kube-proxy做反向代理和负载均衡。而是通过DNS提供稳定的网络ID来访问，DNS会将headless service的后端直接解析为podIP列表。主要供StatefulSet使用。
NodePort：除了使用Cluster IP之外，还通过将service的port映射到集群内每个节点的相同一个端口，实现通过nodeIP:nodePort从集群外访问服务。
LoadBalancer：和nodePort类似，不过除了使用一个Cluster IP和nodePort之外，还会向所使用的公有云申请一个负载均衡器(负载均衡器后端映射到各节点的nodePort)，实现从集群外通过LB访问服务。
ExternalName：是 Service 的特例。此模式主要面向运行在集群外部的服务，通过它可以将外部服务映射进k8s集群，且具备k8s内服务的一些特征（如具备namespace等属性），来为集群内部提供服务。此模式要求kube-dns的版本为1.7或以上。这种模式和前三种模式（除headless service）最大的不同是重定向依赖的是dns层次，而不是通过kube-proxy。

功能

Metallb:贫苦 K8S 用户的负载均衡支持
Traefik: 一个为了让部署微服务更加便捷而诞生的现代HTTP反向代理、负载均衡工具。它支持多种后台(Docker, Swarm, Kubernetes, Marathon, Mesos, Consul, Etcd, Zookeeper, BoltDB, Rest API, file…) 来自动化、动态的应用它的配置文件设置。
mergeable-ingress-types:跨域名的ingress支持
inlets/inlets-operator: Add public LoadBalancers to your local Kubernetes clusters

Ingress

Ingress Builder
Why and How of Kubernetes Ingress (and Networking) | by getenroute.io/yastack.io | ITNEXT

构建隧道

访问外部服务

Kubernetes Access External Services | by ManagedKube | Medium

Ingress

网络整断

kakao/network-node-manager: network-node-manager is a kubernetes controller that controls the network configuration of a node to resolve network issues of kubernetes.

网络调试

Connect services across Kubernetes clusters using Teleproxy | by Alexandre Viau | Flare Systems | Medium

原理

dns

ori-edge/k8s_gateway: A CoreDNS plugin to resolve all types of external Kubernetes resources

vpn

Guide: Setting up a Tailscale VPN on Kubernetes
fatedier/frp: A fast reverse proxy to help you expose a local server behind a NAT or firewall to the internet.

参考

wmenjoy · 2020-02-24T06:10:34Z

Kubernetes网络

CNI

首先我们介绍一下什么是 CNI，它的全称是 Container Network Interface，即容器网络的 API 接口。

它是 K8s 中标准的一个调用网络实现的接口。Kubelet 通过这个标准的 API 来调用不同的网络插件以实现不同的网络配置方式，实现了这个接口的就是 CNI 插件，它实现了一系列的 CNI API 接口。常见的 CNI 插件包括 Calico、flannel、Terway、Weave Net 以及 Contiv。

如何使用CNI

K8s 通过 CNI 配置文件来决定使用什么 CNI。

基本的使用方法为：

首先在每个结点上配置 CNI 配置文件(/etc/cni/net.d/xxnet.conf)，其中 xxnet.conf 是某一个网络配置文件的名称；

安装 CNI 配置文件中所对应的二进制插件；

在这个节点上创建 Pod 之后，Kubelet 就会根据 CNI 配置文件执行前两步所安装的 CNI 插件；

上步执行完之后，Pod 的网络就配置完成了。

CNI 插件

Overlay 模式的典型特征是容器独立于主机的 IP 段，这个 IP 段进行跨主机网络通信时是通过在主机之间创建隧道的方式，将整个容器网段的包全都封装成底层的物理网络中主机之间的包。该方式的好处在于它不依赖于底层网络；

路由模式中主机和容器也分属不同的网段，它与 Overlay 模式的主要区别在于它的跨主机通信是通过路由打通，无需在不同主机之间做一个隧道封包。但路由打通就需要部分依赖于底层网络，比如说要求底层网络有二层可达的一个能力；

Underlay 模式中容器和宿主机位于同一层网络，两者拥有相同的地位。容器之间网络的打通主要依靠于底层网络。因此该模式是强依赖于底层能力的。

那个插件适合我

网络策略

1、VxLan
2、BGP
3、IPIP

多CNI适配插件

k8snetworkplumbingwg/multus-cni: A CNI meta-plugin for multi-homed pods in Kubernetes

网络解决方案

antrea:Antrea is a Kubernetes networking solution intended to be Kubernetes native. It operates at Layer3/4 to provide networking and security services for a Kubernetes cluster, leveraging Open vSwitch as the networking data plane.

DNS

kubernetes中使用dns来访问服务

网络

pod 内部
同主机pod之间
不同主机pod之间

ipvs和iptables

Comparing kube-proxy modes: iptables or IPVS? – Project Calico

参考

wmenjoy · 2020-02-24T06:29:11Z

Kubectl 操作docker

覆盖EntryPoint和CMD

Define a Command and Arguments for a Container

apiVersion: v1
kind: Pod
metadata:
  name: command-demo
  labels:
    purpose: demonstrate-command
spec:
  containers:
  - name: command-demo-container
    image: debian
    command: ["printenv"]
    args: ["HOSTNAME", "KUBERNETES_PORT"]
  restartPolicy: OnFailure

Description	Docker field name	Kubernetes field name
The command run by the container	Entrypoint	command
The arguments passed to the command	Cmd 女名女子名	args

功能覆盖对照表：

mage 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]

参考

wmenjoy · 2020-02-24T07:17:48Z

kubernetes Service

概念

　　Service是Kubernetes的核心资源类型之一，Service资源基于标签选择器将一组Pod定义成一个逻辑组合，并通过自己的IP地址和端口调度代理请求到组内的Pod对象，如下图所示，它向客户端隐藏了真是的，处理用户请求的Pod资源，使得从客户端上看，就像是由Service直接处理并响应一样

service 做了什么？

暴露pod
2.它还可以在多个Pod间负载均衡

原理

是宿主机的kube-proxy生成的iptables规则，及kube-dns生成的DNS记录

参考

wmenjoy · 2020-02-24T07:18:56Z

Kubernetes 概念和术语

参考

wmenjoy · 2020-02-24T07:59:49Z

Kubernetes Sidecars

example

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  shareProcessNamespace: true
  containers:
  - name: nginx
    image: nginx
  - name: shell
    image: busybox
    securityContext:
      capabilities:
        add:
        - SYS_PTRACE
    stdin: true
    tty: true

shareProcessNamespace: 容许不同的pod之间能够看到相互的进程
SYS_PTRACE: 容许发送 SIGHUP 信号到其他pod进程。同时可以通过/proc/$pid/root 访问其他的进程
当然也可以通过公用磁盘卷来完成共享

参考

wmenjoy · 2020-02-24T08:04:10Z

Kubernates 安全

安全框架

astrolabe:Data protection framework for complex applications

参考

wmenjoy · 2020-02-24T08:15:24Z

wmenjoy · 2020-02-24T08:21:47Z

Kubernetes 迁移

资源

Stash: kubernates有状态服务迁移工具

wmenjoy · 2020-02-24T08:32:55Z

Kubernates Operater

wmenjoy · 2020-02-27T05:26:09Z

Kubernates 管理

root磁盘不够，docker镜像丢失了

k8s 在磁盘不够的时候，默认会自动清理镜像

磁盘容量足够，但是k8s仍然有好多处于evicted

如何修改docker和k8s相关数据到volume

k8s会检查nodefs和imagefs, 其中imagefs 检测 /var/lib/docker所在的磁盘符， nodefs，检测/var/lib/kublet所在的盘符， nodefs 可以通过使用kubectl --root-dir来完成

node status's Ready,SchedulingDisabled

kubectl uncordon

磁盘容量规划

参考

wmenjoy · 2020-02-28T02:22:33Z

Kuberenetes Event

参考

kube-eventer

wmenjoy · 2020-02-28T02:54:35Z

kubernetes 排错

pod 排错

pod排错方法

查看配置是否正确

kubectl get pod <pod-name> -o yaml

查看 Pod 的事件

kubectl describe pod <pod-name>

查看pod 日志

kubectl logs <pod-name> [-c <container-name>]

常见pod 异常状态处理

pod 一直处理Pending状态
pod 一直处理waiting状态
pod处于ImagePullBackOff状态
pod一直处于crashLoopBack
pod 处于Error状态
pod 处于Terminating 或者 Unkown状态
pod行为异常
修改静态pod 后Manifest 后未自动重建

service 排错

Replication Controllers排错

参考

wmenjoy · 2020-02-28T03:32:40Z

Kubernetes Kubelet

介绍

kubelet 是运行在每个节点上的主要的“节点代理”，它按照 PodSpec 中的描述工作。 PodSpec 是用来描述一个 pod 的 YAML 或者 JSON 对象。kubelet 通过各种机制（主要通过 apiserver ）获取一组 PodSpec 并保证在这些 PodSpec 中描述的容器健康运行。kubelet 不管理不是由 Kubernetes 创建的容器。

除了来自 apiserver 的 PodSpec ，还有 3 种方式可以将容器清单提供给 kubelet 。

文件：在命令行指定的一个路径，在这个路径下的文件将被周期性的监视更新，默认监视周期是 20 秒并可以通过参数配置。

HTTP端点：在命令行指定的一个HTTP端点，该端点每 20 秒被检查一次并且可以通过参数配置检查周期。

HTTP服务：kubelet 还可以监听 HTTP 服务并响应一个简单的 API 来创建一个新的清单。

参考

wmenjoy · 2020-03-04T06:45:35Z

Kubectl

介绍

什么是kubectl ?

kubectl是Kubernetes API的客户端, 可以和kubernetes API Server沟通,完成对kubernetes的相关操作

常用命令

命令	说明
run	在集群上运行一个镜像
create	使用文件或者标准输入的方式创建一个资源
delete	使用文件或者标准输入以及资源名称或者标签选择器来删除某个资源
version	显示客户端和服务器侧版本信息
api-versions	以group/version的格式显示服务器侧所支持的API版本
explain	显示资源文档信息
get	取得确认对象信息列表
describe	取得确认对象的详细信息
logs	取得pod中容器的log信息
exec	在容器中执行一条命令
cp	从容器考出或向容器考入文件
attach	Attach到一个运行中的容器上
edit	编辑服务器侧资源
replace	使用文件名或者标准输入资源
patch	部分更新资源相关信息
apply	使用文件或者标准输入更改配置信息
scale	重新设定Deployment/ReplicaSet/RC/Job的size
autoscale	Deployment/ReplicaSet/RC的自动扩展设定
cordon	设定node不可使用
uncordon	设定node可以使用
drain	设定node进入维护模式

内部原理

kubernate的内部组成

Kubernetes由一系列独立组件构成，这些组件会在集群的节点上作为单独的进程运行。一些组件运行在master节点，一些组件运行在worker节点，每个组件都有其特定功能。

在master节点上，有以下重要组件：

存储后端：存储资源定义（通常使用etcd）

API Server：提供Kubernetes API并管理存储后端

Controller manager：确保资源状态与规范相匹配

Scheduler：将Pod调度到worker节点

在worker节点上最重要的组件为：

Kubelet：在worker节点上管理容器的执行

理解kubectl 基本操作原理

假如执行下面的语句

kubectl create -f replicaset.yaml

kubectl向_create ReplicaSet API端点_发出了HTTP POST请求, 发送replicaset资源的定义，然后API Server 保存相关定义

后台Controller Manager 中的ReplicaSet Controller 会扫描 RelicaSet资源的变化，然后去创建三个pod资源

这时候scheduler 会监控woker中未分配的pod，然后选择合适的worker节点，存储相对应的信息到pod定义中

然后对应woker的kubelet会扫描对应pod资源的变化

去获取pod的定义，调用容器runtime，来运行容器，最终我们看到

kubernetes 基本工作原理

1、kuberetes的所有组件都是资源，后端存储（etcd）维护了资源的状态
2、对资源的操作，必须通过API来完成
3、其他组件也是通过API来监控资源的变化，然后出发响应的操作的

使用技巧

1. 自动补全

2. 迅速查看资源规范

官方文档位于1.13 doc, 但是会十分繁琐，kubectl explain命令专门用于解决这个问题，基本格式如下

kubectl explain resource\[.field\] [--recursive] # 默认命令展示一层 recursive可以显示所有级别

如果不确定有哪些资源，使用

kubectl api-resources

使用例子

kubectl explain deployments.spec
# or
kubectl explain deployment.spec
# or
kubectl explain deploy.spec

3. 自定义列输出格式

4. 轻松在集群和命名空间之间切换

5. 时候用自动生成的别名保存输入

6. 使用插件扩展kubectl

插件介绍

kubepug:一个 kubectl 插件，可以在集群升级之前对集群进行扫描，如果有集群中存在着在目标版本中废弃或者删除的资源，则会给出相应的警告。
kind
kubectl-tree:该插件提供 K8s 资源对象的归属关系，通过 K8s 对象的 ownerReferencesfield 可以知道某个对象的 owner，以此能够花痴一个对象的 owner ref 的族谱。
predatorray/kubectl-tmux-exec: A kubectl plugin to control multiple pods simultaneously using Tmux

kubectl 替代工具

Kubelive:一款小工具，可以实时交互式的方式去查看和操作 K8s 的资源对象，目前支持 Pod 关联的对象。需要nodejs

参考

wmenjoy · 2020-03-04T07:25:40Z

kubernetes 存储

CSI

Persist Volumes

Persist Volume Declare

持久化存储

Longhorn: Cloud-Native distributed block storage built on and for Kubernetes. open source by rancher

问题

k8s pv,pvc无法删除问题
[CentOS / RHEL 7 : Configuring an NFS server and NFS client]( https://www.thegeekdiary.com/centos-rhel-7-configuring-an-nfs-server-and-nfs-client）

NFS

存储选项查看

Kubestr

glusfer

kadalu/kadalu: A lightweight Persistent storage solution for Kubernetes / OpenShift using GlusterFS in background.

性能检测

Using Fio to Tell Whether Your Storage is Fast Enough for Etcd | IBM

存储容量限制

真棒！3 种方法限制 Pod 磁盘容量，瞬间豁然开朗_云原生实验室-CSDN博客

参考

wmenjoy · 2020-03-04T07:27:51Z

Service Mesh

参考

wmenjoy · 2020-03-04T07:42:56Z

Config Map

介绍

Container技术(例如Docker)提供了三种简易方式来为运行在container中的应用提供configuration:

为container传递command-line arguments
为container设置不同的environment variables
将configuration file以Volume的形式挂在container上
Kubernetes也提供了两种Resources为container提供configuration:
ConfigMap: 用于存储配置信息
Secret: 用于存储敏感信息

为容器设置环境变量

设置configmap的所有Entry

spec:
  containers:
  - image: some-image
    envFrom:
    - prefix: CONFIG_
      configMapRef:
        name: my-config-map

设置configmap中的一个Entry

apiVersion: v1
kind: Pod
metadata:
  name: fortune-args-from-configmap
spec:
  containers:
  - image: luksa/fortune:args
    env:
    - name: INTERVAL
      valueFrom:
        configMapKeyRef:
          name: fortune-config
          key: sleep-interval
    args: ["$(INTERVAL)"]

问题

configmap的文件是只读，不可写和执行
Deployment和Configmap是松耦合。程序不能很好的感知configmap的变化
没有版本管理

解决办法：gopaddle-io/configurator: Synchronize ConfigMaps & Secrets across Deployment Rollouts
Strange things you never knew about Kubernetes ConfigMaps on day one – gopaddle blog

watcher

Working with kubernetes configmaps, part 2: Watchers | by Sandy Cash | ITNEXT

参考

wmenjoy · 2020-03-04T07:58:50Z

Operators

controller在 k8s中的作用

Operator框架

Exploring Kubernetes Operator Pattern

参考

wmenjoy · 2020-03-04T08:08:09Z

HPA

介绍

它根据Pod当前系统的负载来自动水平扩容，如果系统负载超过预定值，就开始增加Pod的个数，如果低于某个值，就自动减少Pod的个数。目前Kubernetes的HPA只能根据CPU等资源使用情况去度量系统的负载。HPA会根据监测到的CPU/内存利用率（资源指标），或基于第三方指标应用程序（如Prometheus等）提供的自定义指标，自动调整副本控制器、部署或者副本集合的pods数量（定义最小和最大pods数）。HPA是一种控制回路，它的周期由Kubernetes的controller manager 的--horizontal-pod-autoscaler-sync-period标志控制

操作

在一般情况下HPA是由kubectl来提供支持的。可以使用kubectl进行创建、管理和删除：

创建HPA

直接使用命令行创建

kubectl autoscale deployment hello-world –min=2 --man=5 –-cpu-percent=50

使用yaml 创建

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: lykops-hpa
  labels:
    software: apache
    project: lykops
    app: hpa
    version: v1
spec:
  scaleTargetRef:
    apiVersion: v1
    kind: Deployment
    name: lykops-hpa-deploy
    #这里只能为这三项
  minReplicas: 1
  maxReplicas: 10
  targetCPUUtilizationPercentage: 5

获取hpa信息

# 基本信息: 
kubectl get hpa hello-worl
# 细节描述 
kubectl describe hpa hello-world

删除hpa

kubectl delete hpa hello-world

参考

wmenjoy · 2020-03-09T06:10:59Z

Prob 健康监测

pod的生命周期

参考Pod Lifecycle官方文档，Pod的LifeCycle定义如下

状态	描述
Pending	正在创建 Pod，但是 Pod 中的容器还没有全部被创建完成，这其中也包含集群为容器创建网络，或者下载镜像的过程。
Running	Pod 内所有的容器都已经被创建，且至少一个容器正在处于运行状态、正在启动状态或者重启状态。
Succeeded	Pod 中所以容器都执行成功后退出，并且没有处于重启的容器。
Failed	Pod 中所以容器都已退出，但是至少还有一个容器退出时为失败状态。
Unknown	由于一些原因，Pod 的状态无法获取，通常是与 Pod 通信时出错导致的。

pod 创建流程如下

① 用户通过kubectl客户端提交Pod Spec给API Server。
② API Server尝试将Pod对象的相关信息存储到etcd中，等待写入操作完成，API Server返回确认信息到客户端。
③ API Server开始反映etcd中的状态变化。
④ 所有的Kubernetes组件通过"watch"机制跟踪检查API Server上的相关信息变动。
⑤ kube-scheduler（调度器）通过其"watcher"检测到API Server创建了新的Pod对象但是没有绑定到任何工作节点。
⑥ kube-scheduler为Pod对象挑选一个工作节点并将结果信息更新到API Server。
⑦ 调度结果新消息由API Server更新到etcd，并且API Server也开始反馈该Pod对象的调度结果。
⑧ Pod被调度到目标工作节点上的kubelet尝试在当前节点上调用docker engine进行启动容器，并将容器的状态结果返回到API Server。
⑨ API Server将Pod信息存储到etcd系统中。
⑩ 在etcd确认写入操作完成，API Server将确认信息发送到相关的kubelet。

Pod Conditions

每一个Pod都有一个PodStatus，是通过一个PodCondtions数组，来表示Pod的状态，每一个PodCondition有6个可能的字段

字段值	描述
lastProbeTime	表示这个condition上次探测的时间
lastTransitionTime	表示pod上一次状态变化的时间
message	描述pod状态转化的详情，人类可读的
reason	表示pod状态转化的唯一的、一个单词的、驼峰表示法的理由
status	True, False, Unknown
type	PodScheduled: 这个pod已经被调度到一个node Ready:表示这个pod已经可以结束请求，可以被加入到服务的负载均衡列表里 Initialized: 所有的Init Containers已经启动成功了 ContainersReady: 所有的容器已经就绪

Pod重启策略

名称	描述
Always	只要容器失效退出就重新启动容器。
OnFailure	当容器以非正常退出后重新启动容器。
Never	无论容器状态如何，都不重新启动容器。

如果 restartpolicy 没有设置，那么默认值是 Always。RC 和 DaemonSet 必须指定重启策略为 Always。

Pod 常见状态转换场景

Pod中的容器数	Pod状态	发生事件	Always	OnFailure	Never
包含一个容器	Running	容器成功退出	Running	Succeeded	Succeeded
包含一个容器	Running	容器失败退出	Running	Running	Failed
包含两个容器	Running	1个容器失败退出	Running	Running	Running
包含两个容器	Running	容器内存溢出挂掉	Running	Running	Failed

Pod的Liveness和Readiness探针

探针介绍

kublet负责管理pod的生命周期，在创建Pod的时候负责初始化Init Containers，创建业务Containers,在主程序刚刚启动的时候可以指定一个post start 主程序启动开始后执行一些操作，在主程序结束前可以指定一个 pre stop 表示主程序结束前执行的一些操作。在pod创建完成后提供了两类定时探针Liveness P探针和Readiness 探针如下图

此外还有个特殊的 Startup 探针

Liveness 探针

用于判断容器是否存活（running状态）。
如果LivenessProbe探针探测到容器非健康，则kubelet将杀掉该容器，并根据容器的重启策略做相应处理。
如果容器不包含LivenessProbe探针，则kubelet认为该探针的返回值永远为“success”。

Liveness探针用来指示容器是否正在运行。如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其重启策略的影响。如果容器不提供存活探针，则默认状态为 Success。Kubelet使用liveness probe（存活探针）来确定何时重启容器。例如，当应用程序处于运行状态但无法做进一步操作，liveness探针将捕获到deadlock，重启处于该状态下的容器，使应用程序在存在bug的情况下依然能够继续运行下去。

Readiness 探针

用于判断容器是否启动完成（read状态），可以接受请求。
如果Readness探针检测失败，则Pod的状态将被修改。Endpoint Controller将从Service的Endpoint中删除包含该容器所在Pod的Endpoint。

Readiness探针指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与 Pod 匹配的所有 Service 的端点中删除该 Pod 的 IP 地址。初始延迟之前的就绪状态默认为 Failure。如果容器不提供就绪探针，则默认状态为 Success。Kubelet使用readiness probe（就绪探针）来确定容器是否已经就绪可以接受流量。只有当Pod中的容器都处于就绪状态时kubelet才会认定该Pod处于就绪状态。该信号的作用是控制哪些Pod应该作为service的后端。如果Pod处于非就绪状态，那么它们将会被从service的load balancer中移除。

Startup 探针

Startup探针用来显示应用是否已经启动。如果Startup 探针提供了，那么其他的探针在startup成功之前，是被禁止的，如果Startup探针失败，kubelet会kill掉Pod，然后具体操作，参考Pod的
重启策略，如果容器不提供Startup探针，那么默认认为是Success

Pod探针的探测方式和结果

探针支持以下集中探测方式

动作	描述
ExecAction	在容器中执行指定的命令，如果执行成功，退出码为 0 则探测成功。
HTTPGetAction	通过容器的IP地址、端口号及路径调用 HTTP Get方法，如果响应的状态码大于等于200且小于400，则认为容器健康。
TCPSocketAction	通过容器的 IP 地址和端口号执行 TCP 检查，如果能够建立 TCP 连接，则表明容器健康。

对应的探测结果有三种

状态	描述
成功	容器通过了诊断。
失败	容器未通过诊断。
未知	诊断失败，因此不会采取任何行动。

liveness探针使用示例

使用exec方式

apiVersion: v1
kind: Pod
metadata:
  name: liveness-exec
  labels:
    app: liveness
spec:
  containers:
  - name: liveness
    image: busybox
    args:                       #创建测试探针探测的文件
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    livenessProbe:
      initialDelaySeconds: 10   #延迟检测时间
      periodSeconds: 5          #检测时间间隔
      exec:
        command:
        - cat
        - /tmp/healthy

http get例子

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - args:
    - /server
    image: k8s.gcr.io/liveness
    livenessProbe:
      httpGet:
        # when "host" is not defined, "PodIP" will be used
        # host: my-host
        # when "scheme" is not defined, "HTTP" scheme will be used. Only "HTTP" and "HTTPS" are allowed
        # scheme: HTTPS
        path: /healthz
        port: 8080
        httpHeaders:
        - name: X-Custom-Header
          value: Awesome
      initialDelaySeconds: 15
      timeoutSeconds: 1
    name: liveness

tcp例子

apiVersion: v1
kind: Pod
metadata:
  name: liveness-tcp
  labels:
    app: liveness
spec:
  containers:
  - name: liveness
    image: nginx
    livenessProbe:
      initialDelaySeconds: 15
      periodSeconds: 20
      tcpSocket:
        port: 80

readiness 探针使用例子

基本和liveness探针使用一样，这里不再详述

apiVersion: v1
kind: Pod
metadata:
  name: springboot
  labels:
    app: springboot
spec:
  containers:
  - name: springboot
    image: mydlqclub/springboot-helloworld:0.0.1
    ports:
    - name: server
      containerPort: 8080
    - name: management
      containerPort: 8081
    readinessProbe:
      initialDelaySeconds: 20   
      periodSeconds: 5          
      timeoutSeconds: 10   
      httpGet:
        scheme: HTTP
        port: 8081
        path: /actuator/health