乐趣区

关于kubernetes:最详细的-K8S-学习笔记总结2021最新版建议收藏

jiezi

尽管 Docker 曾经很弱小了，然而在理论应用上还是有诸多不便，比方集群治理、资源调度、文件治理等等。那么在这样一个百花齐放的容器时代涌现出了很多解决方案，比方 Mesos、Swarm、Kubernetes 等等，其中谷歌开源的 Kubernetes 是作为老大哥的存在。

kubernetes 曾经成为容器编排畛域的王者，它是基于容器的集群编排引擎，具备扩大集群、滚动降级回滚、弹性伸缩、主动治愈、服务发现等多种个性能力。

kubernetes 介绍

Kubernetes 解决的外围问题

  • 服务发现和负载平衡

    • Kubernetes 能够应用 DNS 名称或本人的 IP 地址公开容器，如果到容器的流量很大，Kubernetes 能够负载平衡并调配网络流量，从而使部署稳固。

  • 存储编排

    • Kubernetes 容许您主动挂载您抉择的存储系统，例如本地存储、公共云提供商等。

  • 主动部署和回滚

    • 您能够应用 Kubernetes 形容已部署容器的所需状态，它能够以受控的速率将理论状态更改为所需状态。例如，您能够自动化 Kubernetes 来为您的部署创立新容器，删除现有容器并将它们的所有资源用于新容器。

  • 主动二进制打包

    • Kubernetes 容许您指定每个容器所需 CPU 和内存（RAM）。当容器指定了资源申请时，Kubernetes 能够做出更好的决策来治理容器的资源。

  • 自我修复

    • Kubernetes 重新启动失败的容器、替换容器、杀死不响应用户定义的运行状况查看的容器，并且在筹备好服务之前不将其通告给客户端。

  • 密钥与配置管理

    • Kubernetes 容许您存储和治理敏感信息，例如明码、OAuth 令牌和 ssh 密钥。您能够在不重建容器镜像的状况下部署和更新密钥和应用程序配置，也无需在堆栈配置中裸露密钥。

Kubernetes 的呈现不仅主宰了容器编排的市场，更扭转了过来的运维形式，不仅将开发与运维之间边界变得更加含糊，而且让 DevOps 这一角色变得更加清晰，每一个软件工程师都能够通过 Kubernetes 来定义服务之间的拓扑关系、线上的节点个数、资源使用量并且可能疾速实现程度扩容、蓝绿部署等在过来简单的运维操作。

常识图谱

次要介绍学习一些什么常识

软件架构

传统的客户端服务端架构

  • 架构阐明

Kubernetes 遵循十分传统的客户端 / 服务端的架构模式，客户端能够通过 RESTful 接口或者间接应用 kubectl 与 Kubernetes 集群进行通信，这两者在实际上并没有太多的区别，后者也只是对 Kubernetes 提供的 RESTful API 进行封装并提供进去。每一个 Kubernetes 集群都是由一组 Master 节点和一系列的 Worker 节点组成，其中 Master 节点次要负责存储集群的状态并为 Kubernetes 对象调配和调度资源。

  • 主节点服务 – Master 架构

作为治理集群状态的 Master 节点，它次要负责接管客户端的申请，安顿容器的执行并且运行管制循环，将集群的状态向指标状态进行迁徙。Master 节点外部由上面三个组件形成：

API Server: 负责解决来自用户的申请，其次要作用就是对外提供 RESTful 的接口，包含用于查看集群状态的读申请以及扭转集群状态的写申请，也是惟一一个与 etcd 集群通信的组件。

etcd: 是兼具一致性和高可用性的键值数据库，能够作为保留 Kubernetes 所有集群数据的后盾数据库。

Scheduler: 主节点上的组件，该组件监督那些新创建的未指定运行节点的 Pod，并抉择节点让 Pod 在下面运行。调度决策思考的因素包含单个 Pod 和 Pod 汇合的资源需要、硬件 / 软件 / 策略束缚、亲和性和反亲和性标准、数据地位、工作负载间的烦扰和最初时限。

controller-manager: 在主节点上运行控制器的组件，从逻辑上讲，每个控制器都是一个独自的过程，然而为了升高复杂性，它们都被编译到同一个可执行文件，并在一个过程中运行。这些控制器包含：节点控制器(负责在节点呈现故障时进行告诉和响应)、正本控制器(负责为零碎中的每个正本控制器对象保护正确数量的 Pod)、端点控制器(填充端点 Endpoints 对象，即退出 Service 与 Pod))、服务帐户和令牌控制器(为新的命名空间创立默认帐户和 API 拜访令牌)。

  • 工作节点 – Node 架构

其余的 Worker 节点实现就绝对比较简单了，它次要由 kubelet 和 kube-proxy 两局部组成。

kubelet: 是工作节点执行操作的 agent，负责具体的容器生命周期治理，依据从数据库中获取的信息来治理容器，并上报 pod 运行状态等。

kube-proxy: 是一个简略的网络拜访代理，同时也是一个 Load Balancer。它负责将拜访到某个服务的申请具体调配给工作节点上同一类标签的 Pod。kube-proxy 本质就是通过操作防火墙规定 (iptables 或者 ipvs) 来实现 Pod 的映射。

Container Runtime: 容器运行环境是负责运行容器的软件，Kubernetes 反对多个容器运行环境: Docker、containerd、cri-o、rktlet 以及任何实现 Kubernetes CRI(容器运行环境接口)。

组件阐明

次要介绍对于 K8s 的一些基本概念

次要由以下几个外围组件组成：

  • apiserver

    • 所有服务拜访的惟一入口，提供认证、受权、访问控制、API 注册和发现等机制

  • controller manager

    • 负责保护集群的状态，比方正本冀望数量、故障检测、主动扩大、滚动更新等

  • scheduler

    • 负责资源的调度，依照预约的调度策略将 Pod 调度到相应的机器上

  • etcd

    • 键值对数据库，保留了整个集群的状态

  • kubelet

    • 负责保护容器的生命周期，同时也负责 Volume 和网络的治理

  • kube-proxy

    • 负责为 Service 提供 cluster 外部的服务发现和负载平衡

  • Container runtime

    • 负责镜像治理以及 Pod 和容器的真正运行

除了外围组件，还有一些举荐的插件：

  • CoreDNS

    • 能够为集群中的 SVC 创立一个域名 IP 的对应关系解析的 DNS 服务

  • Dashboard

    • 给 K8s 集群提供了一个 B/S 架构的拜访入口

  • Ingress Controller

    • 官网只可能实现四层的网络代理，而 Ingress 能够实现七层的代理

  • Prometheus

    • 给 K8s 集群提供资源监控的能力

  • Federation

    • 提供一个能够跨集群核心多 K8s 的对立治理性能，提供跨可用区的集群

以上内容参考链接: https://www.escapelife.site/p…

装置

装置 v1.16.0 版本，居然胜利了。记录在此，防止后来者踩坑。

本篇文章，装置大步骤如下：

  • 装置 docker-ce 18.09.9（所有机器）
  • 设置 k8s 环境前置条件（所有机器）
  • 装置 k8s v1.16.0 master 治理节点
  • 装置 k8s v1.16.0 node 工作节点
  • 装置 flannel（master）

具体装置步骤参考：CentOS 搭建 K8S，一次性胜利，珍藏了！
集群装置教程请参考：全网最新、最具体基于 V1.20 版本，无坑部署最小化 K8S 集群教程

Pod 实现原理

Pod 就是最小并且最简略的 Kubernetes 对象

Pod、Service、Volume 和 Namespace 是 Kubernetes 集群中四大根本对象，它们可能示意零碎中部署的利用、工作负载、网络和磁盘资源，独特定义了集群的状态。Kubernetes 中很多其余的资源其实只对这些根本的对象进行了组合。

  • Pod -> 集群中的根本单元
  • Service -> 解决如何拜访 Pod 外面服务的问题
  • Volume -> 集群中的存储卷
  • Namespace -> 命名空间为集群提供虚构的隔离作用

具体介绍请参考：Kubernetes 之 Pod 实现原理

Harbor 仓库

Kuternetes 企业级 Docker 公有仓库 Harbor 工具。
Harbor 的每个组件都是以 Docker 容器的模式构建的，应用 Docker Compose 来对它进行部署。用于部署 Harbor 的 Docker Compose 模板位于 /Deployer/docker-compose.yml 中，其由 5 个容器组成，这几个容器通过 Docker link 的模式连贯在一起，在容器之间通过容器名字相互拜访。对终端用户而言，只须要裸露 Proxy(即 Nginx) 的服务端口即可。

  • Proxy

    • 由 Nginx 服务器形成的反向代理

  • Registry

    • 由 Docker 官网的开源官网的开源 Registry 镜像形成的容器实例

  • UI

    • 即架构中的 core services 服务，形成此容器的代码是 Harbor 我的项目的主体

  • MySQL

    • 由官网 MySQL 镜像形成的数据库容器

  • Log

    • 运行着 rsyslogd 的容器，通过 log-driver 的模式收集其余容器的日志

具体介绍与搭建步骤请参考：企业级环境中基于 Harbor 搭建

YAML 语法

YAML 是一种十分简洁 / 弱小 / 专门用来写配置文件的语言！

YAML 全称是”YAML Ain’t a Markup Language”的递归缩写，该语言的设计参考了 JSON / XML 和 SDL 等语言, 强调以数据为核心，简洁易读，编写简略。

YAML 语法个性

学过编程的人了解起来应该非常容易

语法特点
  • 大小写敏感
  • 通过缩进示意层级关系
  • 禁止应用 tab 缩进，只能应用空格键
  • 缩进的空格数目不重要，只有雷同层级左对齐
  • 应用 #示意正文

举荐给大家一篇文章：Kubernetes 之 YAML 语法，这篇文章介绍的十分具体，有很多例子阐明。

资源清单

K8S 中所有的内容都形象为了资源，资源实例化之后就叫做对象。

在 Kubernetes 零碎中，Kubernetes 对象是长久化的实体，Kubernetes 应用这些实体去示意整个集群的状态。特地地，它们形容了如下信息：

  • 哪些容器化利用在运行，以及在哪个 Node 上
  • 能够被利用应用的资源
  • 对于利用运行时体现的策略，比方重启策略、降级策略，以及容错策略

Kubernetes 对象是“目标性记录”—— 一旦创建对象，Kubernetes 零碎将继续工作以确保对象存在。通过创建对象，实质上是在告知 Kubernetes 零碎，所须要的集群工作负载看起来是什么样子的，这就是 Kubernetes 集群的冀望状态。

Kubernetes 之资源清单具体介绍看这里

资源控制器

Kubernetes 资源控制器配置文件的编写是学习 K8S 的重中之重！

资源配额控制器确保了指定的资源对象始终不会超过配置的资源，可能无效的升高整个零碎宕机的机率，加强零碎的鲁棒性，对整个集群的稳定性有十分重要的作用。

Kubernetes 资源控制器使用指南手册

服务发现

Kubernetes 中为了实现服务实例间的负载平衡和不同服务间的服务发现，发明了 Service 对象，同时又为从集群内部拜访集群创立了 Ingress 对象。

Kubernetes 之服务发现

Ingress 服务

咱们都晓得传统的 SVC 只反对四层下面的代码，而对于七层上的代码而无能为力。比方：咱们应用 K8S 集群对外提供 HTTPS 的服务，为了不便和便捷，咱们须要在对外的 Nginx 服务下面配置 SSL 加密，然而将申请发送给后端服务的时候，进行证书卸载的操作，后续都是用 HTTP 的协定进行解决。而面对此问题，K8S 中给出了应用 Ingress (K8S 在 1.11 版本中推出了)来进行解决。

更多具体内容请参阅：Kubernetes 之 Ingress 服务，介绍对于 Ingress 服务的装置形式，配置对于 Ingress 服务的 HTTP 代理拜访，介绍 Ingress 服务的 BasicAuth 认证形式，介绍 Ingress 的进行规定重写的形式。

数据存储

在之前的文章中，咱们曾经晓得了很多 K8S 中的组件了，包含资源控制器等。在资源控制器中，咱们说到了 StatefulSet 这个控制器组件，其专门为了有状态服务而生的，而对应的存储要寄存到哪里呢？

介绍 K8S 中常见的存储机制能够让咱们所应用的：Kubernetes 之数据存储

集群调度

有这样一个需要，就是集群中多台服务的配置是不统一的。这就导致资源分配并不是平均的，比方咱们须要有些服务节点用来运行计算密集型的服务，而有些服务节点来运行须要大量内存的服务。而在 k8s 中当然也配置了相干服务来解决上述的问题，那就是 Scheduler。

Scheduler 是 kubernetes 的调度器，次要的工作是把定义的 Pod 调配到集群的节点上。听起来非常简单，但有很多要思考的问题：

  • 偏心

    • 如何保障每个节点都能被分配资源

  • 资源高效利用

    • 集群所有资源最大化被应用

  • 效率

    • 调度的性能要好，可能尽快地对大批量的 Pod 实现调度工作

  • 灵便

    • 容许用户依据本人的需要管制调度的逻辑

Scheduler 是作为独自的程序运行的，启动之后会始终坚挺 API Server，获取 PodSpec.NodeName 为空的 Pod，对每个 Pod 都会创立一个 binding，表明该 Pod 应该放到哪个节点上。

具体的介绍请参考：Kubernetes 之集群调度

kubectl 使用指南

kubectl 是 Kubernetes 自带的客户端，能够用它来间接操作 Kubernetes 集群。

日常在应用 Kubernetes 的过程中，kubectl 工具可能是最罕用的工具了，所以当咱们破费大量的工夫去钻研和学习 Kuernetes 的时候，那么咱们就十分有必要去理解下如何高效的应用它了。

从用户角度来说，kubectl 就是管制 Kubernetes 的驾驶舱，它容许你执行所有可能的 Kubernetes 操作；从技术角度来看，kubectl 就是 Kubernetes API 的一个客户端而已。

Kubernetes API 是一个 HTTP REST API 服务，该 API 服务才是 Kubernetes 的真正用到的用户接口，所以 Kubernetes 通过该 API 进行理论的管制。这也就意味着每个 Kubernetes 的操作都会通过 API 端点裸露进来，当然也就能够通过对这些 API 端口进行 HTTP 申请来执行相应的操作。所以，kubectl 最次要的工作就是执行 Kubernetes API 的 HTTP 申请。

工具应用参数

get       #显示一个或多个资源
describe  #显示资源详情
create    #从文件或规范输出创立资源
update   #从文件或规范输出更新资源
delete   #通过文件名、规范输出、资源名或者 label 删除资源
log       #输入 pod 中一个容器的日志
rolling-update  #对指定的 RC 执行滚动降级
exec  #在容器外部执行命令
port-forward #将本地端口转发到 Pod
proxy   #为 Kubernetes API server 启动代理服务器
run     #在集群中应用指定镜像启动容器
expose   #将 SVC 或 pod 裸露为新的 kubernetes service
label     #更新资源的 label
config   #批改 kubernetes 配置文件
cluster-info #显示集群信息
api-versions #以”组 / 版本”的格局输入服务端反对的 API 版本
version       #输入服务端和客户端的版本信息
help         #显示各个命令的帮忙信息
ingress-nginx  #治理 ingress 服务的插件(官网装置和应用形式)

应用相干配置

# Kubectl 主动补全
$ source <(kubectl completion zsh)
$ source <(kubectl completion bash)

# 显示合并后的 kubeconfig 配置
$ kubectl config view

# 获取 pod 和 svc 的文档
$ kubectl explain pods,svc

创立资源对象

分步骤创立
# yaml
kubectl create -f xxx-rc.yaml
kubectl create -f xxx-service.yaml

# json
kubectl create -f ./pod.json
cat pod.json | kubectl create -f -

# yaml2json
kubectl create -f docker-registry.yaml --edit -o json
一次性创立
kubectl create -f xxx-service.yaml -f xxx-rc.yaml
依据目录下所有的 yaml 文件定义内容进行创立
kubectl create -f < 目录 >
应用 url 来创立资源
kubectl create -f https://git.io/vPieo

查看资源对象

查看所有 Node 或 Namespace 对象
kubectl get nodes
kubectl get namespace
查看所有 Pod 对象
# 查看子命令帮忙信息
kubectl get --help

# 列出默认 namespace 中的所有 pod
kubectl get pods

# 列出指定 namespace 中的所有 pod
kubectl get pods --namespace=test

# 列出所有 namespace 中的所有 pod
kubectl get pods --all-namespaces

# 列出所有 pod 并显示详细信息
kubectl get pods -o wide
kubectl get replicationcontroller web
kubectl get -k dir/
kubectl get -f pod.yaml -o json
kubectl get rc/web service/frontend pods/web-pod-13je7
kubectl get pods/app-prod-78998bf7c6-ttp9g --namespace=test -o wide
kubectl get -o template pod/web-pod-13je7 --template={{.status.phase}}

# 列出该 namespace 中的所有 pod 包含未初始化的
kubectl get pods,rc,services --include-uninitialized
查看所有 RC 对象
kubectl get rc
查看所有 Deployment 对象
# 查看全副 deployment
kubectl get deployment

# 列出指定 deployment
kubectl get deployment my-app
查看所有 Service 对象
kubectl get svc
kubectl get service
查看不同 Namespace 下的 Pod 对象
kubectl get pods -n default
kubectl get pods --all-namespace

查看资源形容

显示 Pod 详细信息
kubectl describe pods/nginx
kubectl describe pods my-pod
kubectl describe -f pod.json
查看 Node 详细信息
kubectl describe nodes c1
查看 RC 关联的 Pod 信息
kubectl describe pods <rc-name>

更新修补资源

滚动更新
# 滚动更新 pod frontend-v1
kubectl rolling-update frontend-v1 -f frontend-v2.json

# 更新资源名称并更新镜像
kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2

# 更新 frontend pod 中的镜像
kubectl rolling-update frontend --image=image:v2

# 退出已存在的进行中的滚动更新
kubectl rolling-update frontend-v1 frontend-v2 --rollback

# 强制替换; 删除后从新创立资源; 服务会中断
kubectl replace --force -f ./pod.json

# 增加标签
kubectl label pods my-pod new-label=awesome

# 增加注解
kubectl annotate pods my-pod icon-url=http://goo.gl/XXBTWq
修补资源
# 局部更新节点
kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}'

# 更新容器镜像；spec.containers[*].name 是必须的，因为这是合并的关键字
kubectl patch pod valid-pod -p \
    '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}'
Scale 资源
# Scale a replicaset named 'foo' to 3
kubectl scale --replicas=3 rs/foo

# Scale a resource specified in "foo.yaml" to 3
kubectl scale --replicas=3 -f foo.yaml

# If the deployment named mysql's current size is 2, scale mysql to 3
kubectl scale --current-replicas=2 --replicas=3 deployment/mysql

# Scale multiple replication controllers
kubectl scale --replicas=5 rc/foo rc/bar rc/baz

删除资源对象

基于 xxx.yaml 文件删除 Pod 对象
# yaml 文件名字依照你创立时的文件统一
kubectl delete -f xxx.yaml
删除包含某个 label 的 pod 对象
kubectl delete pods -l name=<label-name>
删除包含某个 label 的 service 对象
kubectl delete services -l name=<label-name>
删除包含某个 label 的 pod 和 service 对象
kubectl delete pods,services -l name=<label-name>
删除所有 pod/services 对象
kubectl delete pods --all
kubectl delete service --all
kubectl delete deployment --all

编辑资源文件

在编辑器中编辑任何 API 资源

# 编辑名为 docker-registry 的 service
kubectl edit svc/docker-registry

间接执行命令

在寄主机上，不进入容器间接执行命令

执行 pod 的 date 命令，默认应用 pod 的第一个容器执行
kubectl exec mypod -- date
kubectl exec mypod --namespace=test -- date
指定 pod 中某个容器执行 date 命令
kubectl exec mypod -c ruby-container -- date
进入某个容器
kubectl exec mypod -c ruby-container -it -- bash

查看容器日志

间接查看日志
# 不实时刷新 kubectl logs mypod
kubectl logs mypod --namespace=test
查看日志实时刷新
kubectl logs -f mypod -c ruby-container

管理工具

Kubernetes 正在一直放慢在云原生环境的利用，但如何以对立、平安的形式对运行于任何中央的 Kubernetes 集群进行治理面临着挑战，而无效的管理工具可能大大降低治理的难度。

K9s

k9s 是基于终端的资源仪表板。它只有一个命令行界面。无论在 Kubernetes 仪表板 Web UI 上做什么，都能够在终端应用 K9s 仪表板工具进行雷同的操作。k9s 继续关注 Kubernetes 集群，并提供命令以应用集群上定义的资源。

具体介绍：Kubernetes 集群管理工具 K9S

举荐：轻松治理 Kubernetes 集群的 7 个工具

生产环境最佳实际

应用 Kubernetes 的一些策略，在安全性、监控、网络、治理、存储、容器生命周期治理和平台抉择方面利用最佳实际。上面让咱们来看看 Kubernetes 的一些生产最佳实际。在生产中运行 Kubernetes 并不容易; 有以下几个方面须要留神。

是否应用存活探针和就绪探针进行健康检查？

治理大型分布式系统可能会很简单，特地是当呈现问题时，咱们无奈及时失去告诉。为了确保利用实例失常工作，设置 Kubernetes 健康检查至关重要。

通过创立自定义运行健康检查，能够无效防止分布式系统中僵尸服务运行，具体能够依据环境和须要对其进行调整。

就绪探针的目标是让 Kubernetes 晓得该利用是否曾经筹备好为流量服务。Kubernetes 将始终确保准备就绪探针通过之后开始调配服务，将流量发送到 Pod。

Liveness- 存活探针

你怎么晓得你的应用程序是活的还是死的? 存活探针能够让你做到这一点。如果你的利用死了，Kubernetes 会移除旧的 Pod 并用新 Pod 替换它。

Resource Management- 资源管理

为单个容器指定资源申请和限度是一个很好的实际。另一个好的实际是将 Kubernetes 环境划分为不同团队、部门、应用程序和客户机的独立名称空间。

Kubernetes 资源应用状况

Kubernetes 资源应用指的是容器 /pod 在生产中所应用的资源数量。

因而，亲密关注 pods 的资源应用状况是十分重要的。一个显著的起因是老本，因为越高的资源利用证实越少的资源节约。

Resource utilization 资源利用率

Ops 团队通常心愿优化和最大化 pods 耗费的资源百分比。资源应用状况是 Kubernetes 环境理论优化水平的指标之一。

您能够认为优化后的 Kubernetes 环境中运行的容器的均匀 CPU 等资源利用率是最优的。

启用 RBAC

RBAC 代表基于角色的访问控制。它是一种用于限度零碎 / 网络上的用户和应用程序的拜访和准入的办法。他们从 Kubernetes 1.8 版本引入了 RBAC。应用 rbac.authorization.k8s RBAC 用于创立受权策略。

在 Kubernetes 中，RBAC 用于受权，应用 RBAC，您将可能授予用户、帐户、增加 / 删除权限、设置规定等权限。因而，它基本上为 Kubernetes 集群增加了额定的平安层。RBAC 限度谁能够拜访您的生产环境和集群。

集群置备和负载平衡

生产级 Kubernetes 基础设施通常须要思考某些要害方面，例如高可用性、多主机、多 etcd Kubernetes 集群等。此类集群的配置通常波及到 Terraform 或 Ansible 等工具。一旦集群都设置好了，并且为运行应用程序创立了 pods，这些 pods 就装备了负载平衡器; 这些负载均衡器将流量路由到服务。开源的 Kubernetes 我的项目并不是默认的负载平衡器; 因而，它须要与 NGINX Ingress controller 与 HAProxy 或 ELB 等工具集成，或任何其余工具，扩充 Kubernetes 的 Ingress 插件，以提供负载平衡能力。

给 Kubernetes 对象增加标签

标签就像附加到对象上的键 / 值对，比方 pods。标签是用来标识对象的属性的，这些属性对用户来说是重要的和有意义的。

在生产中应用 Kubernetes 时，不能漠视的一个重要问题是标签; 标签容许批量查问和操作 Kubernetes 对象。标签的非凡之处在于，它们还能够用于辨认 Kubernetes 对象并将其组织成组。这样做的最佳用例之一是依据 pod 所属的应用程序对它们进行分组。在这里，团队能够构建并领有任意数量的标签约定。

配置网络策略

应用 Kubernetes 时，设置网络策略至关重要。网络策略只不过是一个对象，它使你可能明确地申明和决定哪些流量是容许的，哪些是不容许的。这样，Kubernetes 将可能阻止所有其余不想要的和不合乎规定的流量。在咱们的集群中定义和限度网络流量是强烈推荐的根本且必要的安全措施之一。

Kubernetes 中的每个网络策略都定义了一个如上所述的受权连贯列表。无论何时创立任何网络策略，它所援用的所有 pod 都有资格建设或承受列出的连贯。简略地说，网络策略基本上就是受权和容许连贯的白名单——一个连贯，无论它是到还是从 pod，只有在利用于 pod 的至多一个网络策略容许的状况下才被容许。

集群监控和日志记录

在应用 Kubernetes 时，监控部署是至关重要的。确保配置、性能和流量放弃平安更是重要。如果不进行日志记录和监控，就不可能诊断出产生的问题。为了确保合规性，监督和日志记录变得十分重要。在进行监督时，有必要在体系结构的每一层上设置日志记录性能。生成的日志将帮忙咱们启用平安工具、审计性能和剖析性能。

从无状态应用程序开始

运行无状态利用要比运行有状态利用简略得多，但随着 Kubernetes 运营商的一直增长，这种想法正在扭转。对于刚接触 Kubernetes 的团队来说，倡议首先应用无状态应用程序。

倡议应用无状态后端，这样开发团队就能够确保不存在长时间运行的连贯，从而减少了扩大的难度。应用无状态，开发人员还能够更无效地、零停机部署应用程序。人们普遍认为，无状态应用程序能够不便地依据业务须要进行迁徙和扩大。

边启动主动扩缩容

Kubernetes 有三种用于部署的主动伸缩性能: 程度 pod 主动伸缩 (HPA)、垂直 pod 主动伸缩(VPA) 和集群主动伸缩。

程度 pod autoscaler 依据感知到的 CPU 利用率主动扩大 deployment、replicationcontroller, replicaset, statefulset 的数量。

Vertical pod autoscaling 为 CPU 和内存申请和限度举荐适合的值，它能够自动更新这些值。

Cluster Autoscaler 扩大和放大工作节点池的大小。它依据以后的利用率调整 Kubernetes 集群的大小。

管制镜像拉取起源

管制在集群中运行所有容器的镜像源。如果您容许您的 Pod 从公共资源中拉取镜像，您就不晓得其中真正运行的是什么。

如果从受信赖的注册表中提取它们，则能够在注册表上利用策略以提取平安和通过认证的镜像。

继续学习

一直评估应用程序的状态和设置，以学习和改良。例如，回顾容器的历史内存应用状况能够得出这样的论断: 咱们能够调配更少的内存，在长期内节省成本。

爱护重要服务

应用 Pod 优先级，您能够决定设置不同服务运行的重要性。例如，为了更好的稳定性，你须要确保 RabbitMQ pod 比你的利用 pod 更重要。或者你的入口控制器 pods 比数据处理 pods 更重要，以放弃服务对用户可用。

零停机工夫

通过在 HA 中运行所有服务，反对集群和服务的零停机降级。这也将保障您的客户取得更高的可用性。

应用 pod 反亲和性来确保在不同的节点上调度一个 pod 的多个正本，从而通过打算中的和计划外的集群节点停机来确保服务可用性。

应用 pod Disruptions 策略，不惜一切代价确保您有最低的 Pod 正本数量!

打算失败

硬件最终会失败，软件最终会运行。–（迈克尔·哈顿）

论断

家喻户晓，Kubernetes 实际上曾经成为 DevOps 畛域的编排平台规范。Kubernetes 从可用性、可伸缩性、安全性、弹性、资源管理和监控的角度来应答生产环境产生的风暴。因为许多公司都在生产中应用 Kubernetes，因而必须遵循下面提到的最佳实际，以顺利和牢靠地扩大应用程序。

内容起源：https://my.oschina.net/u/1787…

介绍 5 款顶级 Kubernetes 日志监控工具

对于新装置的 Kubernetes，经常出现的一个问题是 Service 没有失常工作。如果您曾经运行了 Deployment 并创立了一个 Service，然而当您尝试拜访它时没有失去响应，心愿这份文档（全网最具体的 K8s Service 不能拜访排查流程）能帮忙您找出问题所在。

Kubernetes 常见问题总结

如何删除不统一状态下的 rc,deployment,service

在某些状况下, 常常发现 kubectl 过程挂起景象, 而后在 get 时候发现删了一半, 而另外的删除不了

[root@k8s-master ~]# kubectl get -f fluentd-elasticsearch/
NAME DESIRED CURRENT READY AGE
rc/elasticsearch-logging-v1 0 2 2 15h

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
deploy/kibana-logging 0 1 1 1 15h
Error from server (NotFound): services "elasticsearch-logging" not found
Error from server (NotFound): daemonsets.extensions "fluentd-es-v1.22" not found
Error from server (NotFound): services "kibana-logging" not found

删除这些 deployment,service 或者 rc 命令如下:

kubectl delete deployment kibana-logging -n kube-system --cascade=false

kubectl delete deployment kibana-logging -n kube-system  --ignore-not-found

delete rc elasticsearch-logging-v1 -n kube-system --force now --grace-period=0

删除不了后如何重置 etcd

rm -rf /var/lib/etcd/*

删除后从新 reboot master 结点。

reset etcd 后须要从新设置网络

etcdctl mk /atomic.io/network/config '{"Network":"192.168.0.0/16"}'

启动 apiserver 失败

每次启动都是报如下问题：

start request repeated too quickly for kube-apiserver.service

但其实不是启动频率问题, 须要查看, /var/log/messages, 在我的状况中是因为开启 ServiceAccount 后找不到 ca.crt 等文件, 导致启动出错。

May 21 07:56:41 k8s-master kube-apiserver: Flag --port has been deprecated, see --insecure-port instead.
May 21 07:56:41 k8s-master kube-apiserver: F0521 07:56:41.692480 4299 universal_validation.go:104] Validate server run options failed: unable to load client CA file: open /var/run/kubernetes/ca.crt: no such file or directory
May 21 07:56:41 k8s-master systemd: kube-apiserver.service: main process exited, code=exited, status=255/n/a
May 21 07:56:41 k8s-master systemd: Failed to start Kubernetes API Server.
May 21 07:56:41 k8s-master systemd: Unit kube-apiserver.service entered failed state.
May 21 07:56:41 k8s-master systemd: kube-apiserver.service failed.
May 21 07:56:41 k8s-master systemd: kube-apiserver.service holdoff time over, scheduling restart.
May 21 07:56:41 k8s-master systemd: start request repeated too quickly for kube-apiserver.service
May 21 07:56:41 k8s-master systemd: Failed to start Kubernetes API Server.

在部署 fluentd 等日志组件的时候, 很多问题都是因为须要开启 ServiceAccount 选项须要配置平安导致, 所以说到底还是须要配置好 ServiceAccount.

呈现 Permission denied 状况

在配置 fluentd 时候呈现 cannot create /var/log/fluentd.log: Permission denied 谬误, 这是因为没有关掉 SElinux 平安导致。

能够在 /etc/selinux/config 中将 SELINUX=enforcing 设置成 disabled, 而后 reboot

基于 ServiceAccount 的配置

首先生成各种须要的 keys,k8s-master 需替换成 master 的主机名.

openssl genrsa -out ca.key 2048
openssl req -x509 -new -nodes -key ca.key -subj "/CN=k8s-master" -days 10000 -out ca.crt
openssl genrsa -out server.key 2048

echo subjectAltName=IP:10.254.0.1 > extfile.cnf

#ip 由下述命令决定

#kubectl get services --all-namespaces |grep 'default'|grep 'kubernetes'|grep '443'|awk '{print $3}'

openssl req -new -key server.key -subj "/CN=k8s-master" -out server.csr

openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -extfile extfile.cnf -out server.crt -days 10000

如果批改 /etc/kubernetes/apiserver 的配置文件参数的话, 通过 systemctl start kube-apiserver 启动失败, 出错信息为:

Validate server run options failed: unable to load client CA file: open /root/keys/ca.crt: permission denied

但能够通过命令行启动 API Server

/usr/bin/kube-apiserver --logtostderr=true --v=0 --etcd-servers=http://k8s-master:2379 --address=0.0.0.0 --port=8080 --kubelet-port=10250 --allow-privileged=true --service-cluster-ip-range=10.254.0.0/16 --admission-control=ServiceAccount --insecure-bind-address=0.0.0.0 --client-ca-file=/root/keys/ca.crt --tls-cert-file=/root/keys/server.crt --tls-private-key-file=/root/keys/server.key --basic-auth-file=/root/keys/basic_auth.csv --secure-port=443 &>> /var/log/kubernetes/kube-apiserver.log &

命令行启动 Controller-manager

/usr/bin/kube-controller-manager --logtostderr=true --v=0 --master=http://k8s-master:8080 --root-ca-file=/root/keys/ca.crt --service-account-private-key-file=/root/keys/server.key & >>/var/log/kubernetes/kube-controller-manage.log

ETCD 启动不起来 - 问题 <1>

etcd 是 kubernetes 集群的 zookeeper 过程，简直所有的 service 都依赖于 etcd 的启动，比方 flanneld,apiserver,docker….. 在启动 etcd 是报错日志如下：

May 24 13:39:09 k8s-master systemd: Stopped Flanneld overlay address etcd agent.
May 24 13:39:28 k8s-master systemd: Starting Etcd Server...
May 24 13:39:28 k8s-master etcd: recognized and used environment variable ETCD_ADVERTISE_CLIENT_URLS=http://etcd:2379,http://etcd:4001
May 24 13:39:28 k8s-master etcd: recognized environment variable ETCD_NAME, but unused: shadowed by corresponding flag
May 24 13:39:28 k8s-master etcd: recognized environment variable ETCD_DATA_DIR, but unused: shadowed by corresponding flag
May 24 13:39:28 k8s-master etcd: recognized environment variable ETCD_LISTEN_CLIENT_URLS, but unused: shadowed by corresponding flag
May 24 13:39:28 k8s-master etcd: etcd Version: 3.1.3
May 24 13:39:28 k8s-master etcd: Git SHA: 21fdcc6
May 24 13:39:28 k8s-master etcd: Go Version: go1.7.4
May 24 13:39:28 k8s-master etcd: Go OS/Arch: linux/amd64
May 24 13:39:28 k8s-master etcd: setting maximum number of CPUs to 1, total number of available CPUs is 1
May 24 13:39:28 k8s-master etcd: the server is already initialized as member before, starting as etcd member...
May 24 13:39:28 k8s-master etcd: listening for peers on http://localhost:2380
May 24 13:39:28 k8s-master etcd: listening for client requests on 0.0.0.0:2379
May 24 13:39:28 k8s-master etcd: listening for client requests on 0.0.0.0:4001
May 24 13:39:28 k8s-master etcd: recovered store from snapshot at index 140014
May 24 13:39:28 k8s-master etcd: name = master
May 24 13:39:28 k8s-master etcd: data dir = /var/lib/etcd/default.etcd
May 24 13:39:28 k8s-master etcd: member dir = /var/lib/etcd/default.etcd/member
May 24 13:39:28 k8s-master etcd: heartbeat = 100ms
May 24 13:39:28 k8s-master etcd: election = 1000ms
May 24 13:39:28 k8s-master etcd: snapshot count = 10000
May 24 13:39:28 k8s-master etcd: advertise client URLs = http://etcd:2379,http://etcd:4001
May 24 13:39:28 k8s-master etcd: ignored file 0000000000000001-0000000000012700.wal.broken in wal
May 24 13:39:29 k8s-master etcd: restarting member 8e9e05c52164694d in cluster cdf818194e3a8c32 at commit index 148905
May 24 13:39:29 k8s-master etcd: 8e9e05c52164694d became follower at term 12
May 24 13:39:29 k8s-master etcd: newRaft 8e9e05c52164694d [peers: [8e9e05c52164694d], term: 12, commit: 148905, applied: 140014, lastindex: 148905, lastterm: 12]
May 24 13:39:29 k8s-master etcd: enabled capabilities for version 3.1
May 24 13:39:29 k8s-master etcd: added member 8e9e05c52164694d [http://localhost:2380] to cluster cdf818194e3a8c32 from store
May 24 13:39:29 k8s-master etcd: set the cluster version to 3.1 from store
May 24 13:39:29 k8s-master etcd: starting server... [version: 3.1.3, cluster version: 3.1]
May 24 13:39:29 k8s-master etcd: raft save state and entries error: open /var/lib/etcd/default.etcd/member/wal/0.tmp: is a directory
May 24 13:39:29 k8s-master systemd: etcd.service: main process exited, code=exited, status=1/FAILURE
May 24 13:39:29 k8s-master systemd: Failed to start Etcd Server.
May 24 13:39:29 k8s-master systemd: Unit etcd.service entered failed state.
May 24 13:39:29 k8s-master systemd: etcd.service failed.
May 24 13:39:29 k8s-master systemd: etcd.service holdoff time over, scheduling restart.

外围语句：

raft save state and entries error: open /var/lib/etcd/default.etcd/member/wal/0.tmp: is a directory

进入相干目录，删除 0.tmp, 而后就能够启动啦!

ETCD 启动不起来 - 超时问题 <2>

问题背景：以后部署了 3 个 etcd 节点，忽然有一天 3 台集群全副停电宕机了。重新启动之后发现 K8S 集群是能够失常应用的，然而查看了一遍组件之后，发现有一个节点的 etcd 启动不了。

通过一遍探查，发现工夫不精确，通过以下命令 ntpdate ntp.aliyun.com 从新将工夫调整正确，重新启动 etcd，发现还是起不来，报错如下：

Mar 05 14:27:15 k8s-node2 etcd[3248]: etcd Version: 3.3.13
Mar 05 14:27:15 k8s-node2 etcd[3248]: Git SHA: 98d3084
Mar 05 14:27:15 k8s-node2 etcd[3248]: Go Version: go1.10.8
Mar 05 14:27:15 k8s-node2 etcd[3248]: Go OS/Arch: linux/amd64
Mar 05 14:27:15 k8s-node2 etcd[3248]: setting maximum number of CPUs to 4, total number of available CPUs is 4
Mar 05 14:27:15 k8s-node2 etcd[3248]: the server is already initialized as member before, starting as etcd member
...
Mar 05 14:27:15 k8s-node2 etcd[3248]: peerTLS: cert = /opt/etcd/ssl/server.pem, key = /opt/etcd/ssl/server-key.pe
m, ca = , trusted-ca = /opt/etcd/ssl/ca.pem, client-cert-auth = false, crl-file =
Mar 05 14:27:15 k8s-node2 etcd[3248]: listening for peers on https://192.168.25.226:2380
Mar 05 14:27:15 k8s-node2 etcd[3248]: The scheme of client url http://127.0.0.1:2379 is HTTP while peer key/cert
files are presented. Ignored key/cert files.
Mar 05 14:27:15 k8s-node2 etcd[3248]: listening for client requests on 127.0.0.1:2379
Mar 05 14:27:15 k8s-node2 etcd[3248]: listening for client requests on 192.168.25.226:2379
Mar 05 14:27:15 k8s-node2 etcd[3248]: member 9c166b8b7cb6ecb8 has already been bootstrapped
Mar 05 14:27:15 k8s-node2 systemd[1]: etcd.service: main process exited, code=exited, status=1/FAILURE
Mar 05 14:27:15 k8s-node2 systemd[1]: Failed to start Etcd Server.
Mar 05 14:27:15 k8s-node2 systemd[1]: Unit etcd.service entered failed state.
Mar 05 14:27:15 k8s-node2 systemd[1]: etcd.service failed.
Mar 05 14:27:15 k8s-node2 systemd[1]: etcd.service failed.
Mar 05 14:27:15 k8s-node2 systemd[1]: etcd.service holdoff time over, scheduling restart.
Mar 05 14:27:15 k8s-node2 systemd[1]: Starting Etcd Server...
Mar 05 14:27:15 k8s-node2 etcd[3258]: recognized environment variable ETCD_NAME, but unused: shadowed by correspo
nding flag
Mar 05 14:27:15 k8s-node2 etcd[3258]: recognized environment variable ETCD_DATA_DIR, but unused: shadowed by corr
esponding flag
Mar 05 14:27:15 k8s-node2 etcd[3258]: recognized environment variable ETCD_LISTEN_PEER_URLS, but unused: shadowed
 by corresponding flag
Mar 05 14:27:15 k8s-node2 etcd[3258]: recognized environment variable ETCD_LISTEN_CLIENT_URLS, but unused: shadow
ed by corresponding flag
Mar 05 14:27:15 k8s-node2 etcd[3258]: recognized environment variable ETCD_INITIAL_ADVERTISE_PEER_URLS, but unuse
d: shadowed by corresponding flag
Mar 05 14:27:15 k8s-node2 etcd[3258]: recognized environment variable ETCD_ADVERTISE_CLIENT_URLS, but unused: sha
dowed by corresponding flag
Mar 05 14:27:15 k8s-node2 etcd[3258]: recognized environment variable ETCD_INITIAL_CLUSTER, but unused: shadowed
by corresponding flag
Mar 05 14:27:15 k8s-node2 etcd[3258]: recognized environment variable ETCD_INITIAL_CLUSTER_TOKEN, but unused: sha
dowed by corresponding flag
Mar 05 14:27:15 k8s-node2 etcd[3258]: recognized environment variable ETCD_INITIAL_CLUSTER_STATE, but unused: sha
dowed by corresponding flag

解决办法：

查看日志发现并没有特地显著的谬误，依据教训来讲，etcd 节点坏掉一个其实对集群没有大的影响，这时集群曾经能够失常应用了，然而这个坏掉的 etcd 节点并没有启动，解决办法如下：

进入 etcd 的数据存储目录进行备份 备份原有数据：

cd /var/lib/etcd/default.etcd/member/
cp *  /data/bak/

删除这个目录下的所有数据文件

rm -rf /var/lib/etcd/default.etcd/member/*

进行另外两台 etcd 节点，因为 etcd 节点启动时须要所有节点一起启动，启动胜利后即可应用。

#master 节点
systemctl stop etcd
systemctl restart etcd

#node1 节点
systemctl stop etcd
systemctl restart etcd

#node2 节点
systemctl stop etcd
systemctl restart etcd

CentOS 下配置主机互信

在每台服务器须要建设主机互信的用户名执行以下命令生成公钥 / 密钥，默认回车即可

ssh-keygen -t rsa

能够看到生成个公钥的文件。

互传公钥，第一次须要输出明码，之后就 OK 了。

ssh-copy-id -i /root/.ssh/id_rsa.pub root@192.168.199.132 (-p 2222)

-p 端口 默认端口不加 -p，如果更改过端口，就得加上 -p. 能够看到是在.ssh/ 下生成了个 authorized_keys 的文件，记录了能登陆这台服务器的其余服务器的公钥。

测试看是否能登陆：

ssh 192.168.199.132 (-p 2222)

CentOS 主机名的批改

hostnamectl set-hostname k8s-master1

Virtualbox 实现 CentOS 复制和粘贴性能

如果不装置或者不输入，能够将 update 批改成 install 再运行。

yum install update
yum update kernel
yum update kernel-devel
yum install kernel-headers
yum install gcc
yum install gcc make

运行完后

sh VBoxLinuxAdditions.run

删除 Pod 始终处于 Terminating 状态

能够通过上面命令强制删除

kubectl delete pod NAME --grace-period=0 --force

删除 namespace 始终处于 Terminating 状态

能够通过以下脚本强制删除

[root@k8s-master1 k8s]# cat delete-ns.sh
#!/bin/bash
set -e

useage(){
    echo "useage:"
    echo "delns.sh NAMESPACE"
}

if [$# -lt 1];then
    useage
    exit
fi

NAMESPACE=$1
JSONFILE=${NAMESPACE}.json
kubectl get ns "${NAMESPACE}" -o json > "${JSONFILE}"
vi "${JSONFILE}"
curl -k -H "Content-Type: application/json" -X PUT --data-binary @"${JSONFLE}" \
    http://127.0.0.1:8001/api/v1/namespaces/"${NAMESPACE}"/finalize

容器蕴含无效的 CPU/ 内存 requests 且没有指定 limits 可能会呈现什么问题？

上面咱们创立一个对应的容器，该容器只有 requests 设定，然而没有 limits 设定，

- name: busybox-cnt02
    image: busybox
    command: ["/bin/sh"]
    args: ["-c", "while true; do echo hello from cnt02; sleep 10;done"]
    resources:
      requests:
        memory: "100Mi"
        cpu: "100m"

这个容器创立进去会有什么问题呢？

其实对于失常的环境来说没有什么问题，然而对于资源型 pod 来说，如果有的容器没有设定 limit 限度，资源会被其余的 pod 抢占走，可能会造成容器利用失败的状况。能够通过 limitrange 策略来去匹配，让 pod 主动设定，前提是要提前配置好 limitrange 规定。

起源：https://www.cnblogs.com/passz…

Kubernetes 上对应用程序进行故障排除的 6 个技巧 举荐给大家，日常排错必备。分享一份阿里云外部超全 K8s 实战手册，收费下载！

面试题

一个指标：容器操作；两地三核心；四层服务发现；五种 Pod 共享资源；六个 CNI 罕用插件；七层负载平衡；八种隔离维度；九个网络模型准则；十类 IP 地址；百级产品线；千级物理机；万级容器；相如无亿，k8s 有亿：亿级日服务人次。

一个指标：容器操作

Kubernetes（k8s）是自动化容器操作的开源平台。这些容器操作包含：部署、调度和节点集群间扩大。

具体性能：

  • 自动化容器部署和复制。

  • 实时弹性膨胀容器规模。

  • 容器编排成组，并提供容器间的负载平衡。

  • 调度：容器在哪个机器上运行。

组成：

  • kubectl：客户端命令行工具，作为整个零碎的操作入口。

  • kube-apiserver：以 REST API 服务模式提供接口，作为整个零碎的管制入口。

  • kube-controller-manager：执行整个零碎的后台任务，包含节点状态情况、Pod 个数、Pods 和 Service 的关联等。

  • kube-scheduler：负责节点资源管理，接管来自 kube-apiserver 创立 Pods 工作，并调配到某个节点。

  • etcd：负责节点间的服务发现和配置共享。

  • kube-proxy：运行在每个计算节点上，负责 Pod 网络代理。定时从 etcd 获取到 service 信息来做相应的策略。

  • kubelet：运行在每个计算节点上，作为 agent，接管调配该节点的 Pods 工作及治理容器，周期性获取容器状态，反馈给 kube-apiserver。

  • DNS：一个可选的 DNS 服务，用于为每个 Service 对象创立 DNS 记录，这样所有的 Pod 就能够通过 DNS 拜访服务了。

上面是 k8s 的架构拓扑图：

两地三核心

两地三核心包含本地生产核心、本地灾备核心、异地灾备核心。

两地三核心要解决的一个重要问题就是数据一致性问题。

k8s 应用 etcd 组件作为一个高可用、强一致性的服务发现存储仓库。用于配置共享和服务发现。

它作为一个受到 Zookeeper 和 doozer 启发而催生的我的项目。除了领有他们的所有性能之外，还领有以下 4 个特点：

  • 简略：基于 HTTP+JSON 的 API 让你用 curl 命令就能够轻松应用。

  • 平安：可选 SSL 客户认证机制。

  • 疾速：每个实例每秒反对一千次写操作。

  • 可信：应用 Raft 算法充沛实现了分布式。

四层服务发现

先一张图解释一下网络七层协定：

k8s 提供了两种形式进行服务发现：

  • 环境变量：当创立一个 Pod 的时候，kubelet 会在该 Pod 中注入集群内所有 Service 的相干环境变量。须要留神的是，要想一个 Pod 中注入某个 Service 的环境变量，则必须 Service 要先比该 Pod 创立。这一点，简直使得这种形式进行服务发现不可用。比方，一个 ServiceName 为 redis-master 的 Service，对应的 ClusterIP:Port 为 10.0.0.11:6379，则对应的环境变量为：

  • DNS：能够通过 cluster add-on 的形式轻松的创立 KubeDNS 来对集群内的 Service 进行服务发现。

以上两种形式，一个是基于 TCP，DNS 基于 UDP，它们都是建设在四层协定之上。

五种 Pod 共享资源

Pod 是 k8s 最根本的操作单元，蕴含一个或多个严密相干的容器。

一个 Pod 能够被一个容器化的环境看作应用层的“逻辑宿主机”；一个 Pod 中的多个容器利用通常是严密耦合的，Pod 在 Node 上被创立、启动或者销毁；每个 Pod 里运行着一个非凡的被称之为 Volume 挂载卷，因而他们之间通信和数据交换更为高效。在设计时咱们能够充分利用这一个性将一组密切相关的服务过程放入同一个 Pod 中。

同一个 Pod 里的容器之间仅需通过 localhost 就能相互通信。

一个 Pod 中的利用容器共享五种资源：

  • PID 命名空间：Pod 中的不同应用程序能够看到其余应用程序的过程 ID。

  • 网络命名空间：Pod 中的多个容器可能拜访同一个 IP 和端口范畴。

  • IPC 命名空间：Pod 中的多个容器可能应用 SystemV IPC 或 POSIX 音讯队列进行通信。

  • UTS 命名空间：Pod 中的多个容器共享一个主机名。

  • Volumes（共享存储卷）：Pod 中的各个容器能够拜访在 Pod 级别定义的 Volumes。

Pod 的生命周期通过 Replication Controller 来治理；通过模板进行定义，而后调配到一个 Node 上运行，在 Pod 所蕴含容器运行完结后，Pod 完结。

Kubernetes 为 Pod 设计了一套独特的网络配置，包含为每个 Pod 调配一个 IP 地址，应用 Pod 名作为容器间通信的主机名等。

六个 CNI 罕用插件

CNI（Container Network Interface）容器网络接口是 Linux 容器网络配置的一组规范和库，用户须要依据这些规范和库来开发本人的容器网络插件。CNI 只专一解决容器网络连接和容器销毁时的资源开释，提供一套框架。所以 CNI 能够反对大量不同的网络模式，并且容易实现。

上面用一张图示意六个 CNI 罕用插件：

七层负载平衡

提负载平衡就不得不先提服务器之间的通信。

IDC（Internet Data Center）也可称数据中心、机房，用来搁置服务器。IDC 网络是服务器间通信的桥梁。

上图里画了很多网络设备，它们都是干啥用的呢？

路由器、交换机、MGW/NAT 都是网络设备，依照性能、内外网划分不同的角色。

  • 内网接入交换机：也称为 TOR（top of rack），是服务器接入网络的设施。每台内网接入交换机下联 40-48 台服务器，应用一个掩码为 /24 的网段作为服务器内网网段。
  • 内网外围交换机：负责 IDC 内各内网接入交换机的流量转发及跨 IDC 流量转发。
  • MGW/NAT：MGW 即 LVS 用来做负载平衡，NAT 用于内网设施拜访外网时做地址转换。

  • 外网外围路由器：通过动态互联运营商或 BGP 互联美团对立外网平台。

先说说各层负载平衡：

  • 二层负载平衡：基于 MAC 地址的二层负载平衡。
  • 三层负载平衡：基于 IP 地址的负载平衡。
  • 四层负载平衡：基于 IP+ 端口 的负载平衡。

  • 七层负载平衡：基于 URL 等应用层信息的负载平衡。

这里用一张图来说说四层和七层负载平衡的区别：

下面四层服务发现讲的次要是 k8s 原生的 kube-proxy 形式。k8s 对于服务的裸露次要是通过 NodePort 形式，通过绑定 minion 主机的某个端口，而后进行 Pod 的申请转发和负载平衡，但这种形式有上面的缺点：

  • Service 可能有很多个，如果每个都绑定一个 Node 主机端口的话，主机须要凋谢外围的端口进行服务调用，管理混乱。

  • 无奈利用很多公司要求的防火墙规定。

现实的形式是通过一个内部的负载均衡器，绑定固定的端口，比方 80；而后依据域名或者服务名向前面的 Service IP 转发。

Nginx 很好的解决了这个需要，但问题是如果有的新的服务退出，如何去批改并且加载这些 Nginx 配置？

Kubernetes 给出的计划就是 Ingress。这是一个基于七层的计划。

八种隔离维度

k8s 集群调度这边须要对下面从上到下、从粗粒度到细粒度的隔离做相应的调度策略。

九个网络模型准则

k8s 网络模型要合乎四个根底准则、三个网络要求准则、一个架构准则、一个 IP 准则。

每个 Pod 都领有一个独立的 IP 地址，而且假设所有 Pod 都在一个能够间接连通的、扁平的网络空间中，不论是否运行在同一 Node 上都能够通过 Pod 的 IP 来拜访。

k8s 中的 Pod 的 IP 是最小粒度 IP。同一个 Pod 内所有的容器共享一个网络堆栈，该模型称为 IP-per-Pod 模型。

  • Pod 由 docker0 理论调配的 IP。

  • Pod 外部看到的 IP 地址和端口与内部保持一致。

  • 同一个 Pod 内的不同容器共享网络，能够通过 localhost 来拜访对方的端口，相似同一个虚拟机内不同的过程。

IP-per-Pod 模型从端口调配、域名解析、服务发现、负载平衡、利用配置等角度看，Pod 能够看做是一台独立的虚拟机或物理机。

  • 所有容器都能够不必 NAT 的形式同别的容器通信。

  • 所有节点都能够在不同 NAT 形式下同所有容器通信，反之亦然。

  • 容器的地址和他人看到的地址是同一个地址。

要合乎上面的架构：

由上图架构引申进去 IP 概念从集群内部到集群外部：

十类 IP 地址

大家都晓得 IP 地址分为 ABCDE 类，另外还有五类非凡用处的 IP。

第一类

A 类：1.0.0.0-1226.255.255.255，默认子网掩码 /8，即 255.0.0.0。B 类：128.0.0.0-191.255.255.255，默认子网掩码 /16，即 255.255.0.0。C 类：192.0.0.0-223.255.255.255，默认子网掩码 /24，即 255.255.255.0。D 类：224.0.0.0-239.255.255.255，个别用于组播。E 类：240.0.0.0-255.255.255.255(其中 255.255.255.255 为全网播送地址)。E 类地址个别用于钻研用处。

第二类

0.0.0.0
严格来说，0.0.0.0 曾经不是一个真正意义上的 IP 地址了。它示意的是这样一个汇合：所有不分明的主机和目标网络。这里的不分明是指在本机的路由表里没有特定条目指明如何达到。作为缺省路由。127.0.0.1 本机地址。

第三类

224.0.0.1 组播地址。如果你的主机开启了 IRDP（internet 路由发现，应用组播性能），那么你的主机路由表中应该有这样一条路由。

第四类

169.254.x.x
应用了 DHCP 性能主动获取了 IP 的主机，DHCP 服务器产生故障，或响应工夫太长而超出了一个零碎规定的工夫，零碎会为你调配这样一个 IP，代表网络不能失常运行。

第五类

10.xxx、172.16.x.x~172.31.x.x、192.168.x.x 公有地址。大量用于企业外部。保留这样的地址是为了防止亦或是哪个接入公网时引起地址凌乱。

链接：blog.csdn.net/huakai_sun/article/details/82378856

采纳 jenkins pipeline 实现主动构建并部署至 k8s
10 个小技巧进步 Kubernetes 容器效率
[Kubernetes 常见运维技巧总结

](https://mp.weixin.qq.com/s?__…

退出移动版