前言

今天来聊聊 Flannel，Flannel 是 Kubernetes 默认网络组件，再聊 Flannel 时，我们得先明白一个叫 CNI 东东，CNI 是什么？能有什么用？下文会做出解释。

CNI 简单介绍

CNI（Container Network Interface）是 CNCF 旗下的一个项目，由一组用于配置Linux容器网络接口的规范和库组成，同时还包含了一些插件。CNI 仅关心容器创建时的网络分配和当容器被删除时释放网络资源。Kubernetes 中已经内置了 CNI。

Container Runtime 在创建容器时，先创建好 network namespace，然后调用CNI插件为这个 network namespace 配置网络，其后再启动容器内的进程。CNI 已成为 CNCF 一员，成为 CNCF 主推的网络模型。

CNI 项目地址 https://github.com/containernetworking/cni

• 作者：haohao
• 链接：https://qhh.me/2019/09/07/%E5%9F%BA%E4%BA%8E-Kubernetes-%E7%9A%84-7-%E5%A4%A7-DevOps-%E5%85%B3%E9%94%AE%E5%AE%9E%E8%B7%B5/

前言

本文主要介绍 DevOps 的 7 大关键实践在 Kubernetes 平台下如何落地，结合我们目前基于 Kubernetes 平台的 DevOps 实践谈谈是如何贯彻相关理念的，这里不会对其具体实现细节进行深入讲解，只做一个大致的概括的描述，分享下已有的实践，具体实践细节有时间了会单独整理一篇文章分享。

• 作者：haohao
• 链接：https://qhh.me/2019/08/26/%E4%BB%8E-Docker-%E5%88%B0-Kubernetes-%E6%97%A5%E5%BF%97%E7%AE%A1%E7%90%86%E6%9C%BA%E5%88%B6%E8%AF%A6%E8%A7%A3/

前言

在容器化时代，容器应用的日志管理和传统应用存在很大的区别，为了顺应容器化应用，Docker 和 Kubernetes 提供了一套完美的日志解决方案。本文从 Docker 到 Kubernetes 逐步介绍在容器化时代日志的管理机制，以及在 Kubernetes 平台下有哪些最佳的日志收集方案。涉及到的话题有 Docker 日志管理机制、Kubernetes 日志管理机制、Kubernetes 集群日志收集方案。本文结构如下：

• Docker 日志管理机制
  • Docker 的日志种类
  • 基于日志驱动（loging driver）的日志管理机制
  • Docker 日志驱动（loging driver）配置
  • Docker 默认的日志驱动 json-file
• Kubernetes 日志管理机制
  • 应用 Pod 日志
  • Kuberntes 集群组件日志
• Kubernetes 集群日志收集方案
  • 节点级日志代理方案
  • sidecar 容器方案
  • 应用程序直接将日志传输到日志平台

• 作者：kaliarch
• 链接：https://juejin.im/post/5e02fb1f518825123b1aa341

一 概述

背景：近期k8s应用中etcd的功能存在一些困惑，对其进行来单独的学习，能更深入理解k8s中的的一些特性。

1.1 etcd简介

etcd是CoreOS团队于2013年6月发起的开源项目，它的目标是构建一个高可用的分布式键值(key-value)数据库。etcd内部采用raft协议作为一致性算法，etcd基于Go语言实现。

前言

Istio 架构又换了，从 1.5 开始，把控制平面的所有组件组合并成一个单体结构叫 istiod，对于运维部署来说省去很大麻烦。Mixer 组件被移除，新版本的 HTTP 遥测默认基于 in-proxy Stats filter，同时可使用 WebAssembly 开发 in-proxy 扩展。

下面展示 Istio 架构图前世与今生：

发布徽标

• 作者：XuChao
• 链接：https://xuchao918.github.io/2020/03/18/Kubernetes%E8%8A%82%E7%82%B9%E9%A2%91%E7%B9%81NotReady/

一.环境概述

• Kubernetes版本：1.12.6
• Docker版本：17.06.2-ce-3
• 操作系统版本：CentOS 7.4.1708

二.问题现象

1.钉钉收到Pod容器运行状态异常和服务接口超时监控告警，查看到K8s Worker节点频繁处于NotReady状态，如重启Kubelet和节点恢复正常一会后又变成NotReady。

2.容器大部分处于Exit状态，Pod大部分处于Pending、Unknown等状态。
这里说一下，Pod处于Pending、Unknown等状态代表什么含义，前者基本上是scheduler失败的问题如节点资源不足等，后者则是Pod所在的节点有问题如kublet和其他K8s组件通信异常等。

前言

下面是 16 道 Kubernetes 面试题。非标准答案，如有错误地方请指出。目的是帮助大家温习K8S。

题目 与 非标准答案

一、k8s集群规模，使用的版本及部署方式，master节点跑了什么组件，每个组件作用？

k8s集群规模：个人推荐 K8S 集群规模不要超过千台节点

k8s使用版本：比最新版本低一个版本（例：目前最新是1.17版本，生产推荐使用 1.16版本）

k8s部署方式：个人推荐使用 kubeadm 和 二进制 部署

K8S Master 节点一般跑了： ETCD、ApiServer、Controller Manager、Scheduler

• 作者：乐章
• 链接：https://www.cnblogs.com/zhangxingeng/p/11236968.html

一、简介

1、了解Docker的前生LXC

LXC为Linux Container的简写。可以提供轻量级的虚拟化，以便隔离进程和资源，而且不需要提供指令解释机制以及全虚拟化的其他复杂性。相当于C++中的NameSpace。容器有效地将由单个操作系统管理的资源划分到孤立的组中，以更好地在孤立的组之间平衡有冲突的资源使用需求。

与传统虚拟化技术相比，它的优势在于：

（1）与宿主机使用同一个内核，性能损耗小；

（2）不需要指令级模拟；

（3）不需要即时(Just-in-time)编译；

（4）容器可以在CPU核心的本地运行指令，不需要任何专门的解释机制；

（5）避免了准虚拟化和系统调用替换中的复杂性；

（6）轻量级隔离，在隔离的同时还提供共享机制，以实现容器与宿主机的资源共享。

总结：Linux Container是一种轻量级的虚拟化的手段。

前言

Kubernetes中的调度是将待处理的pod绑定到节点的过程，由Kubernetes的一个名为kube-scheduler的组件执行。调度程序的决定，无论是否可以或不能调度容器，都由其可配置策略指导，该策略包括一组规则，称为谓词和优先级。调度程序的决定受到其在第一次调度时出现新pod时的Kubernetes集群视图的影响。由于Kubernetes集群非常动态且状态随时间而变化，因此可能需要将已经运行的pod重新调试到其它节点上，已达到节点使用资源平衡。