给k8s集群中的node节点加标签

1.增加节点标签 备注 =：代表增加标签

kubectl label nodes node3 node-role.kubernetes.io/node3=

故障1

[preflight] Some fatal errors occurred:
        [ERROR FileContent--proc-sys-net-bridge-bridge-nf-call-iptables]: /proc/sys/net/bridge/bridge-nf-call-iptables contents are not set to 1
        [ERROR FileContent--proc-sys-net-ipv4-ip_forward]: /proc/sys/net/ipv4/ip_forward contents are not set to 1
[preflight] If you know what you are doing, you can make a check non-fatal with `--ignore-preflight-errors=...`
error execution phase preflight

6.4 Service Account

Service Account 也是一种账号，但它并不是给Kubernetes集群的用户（系统管理员、运维人员、租户用户等）用的，而是给运行在Pod里的进程用的。它为Pod里的进程提供了必须的身份证明。

在正常情况下，为了确保Kubernetes集群的安全，API Server 都会对客户端进行身份认证，认证失败的客户端无法进行API 调用，此外，在Pod 中访问Kubernetes API Server 服务时，是以Service 方式访问名为 Kubernetes 的这个服务的，而Kubernetes 服务又只在HTTPS 安全端口 443 上提供。

Secret的主要作用是保管私密数据，比如密码、OAuth Tokens、SSH Keys 等信息。将这些私密信息放在Secret对象中比直接放在Pod或Docker Image中更安全，也便便于使用和分发。
secrets.yaml

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  password: dmFsdWUtMg0K
  username: dmFsdWUtMQ0K

为了更精细的控制Pod对资源的使用方式，kubernetes 从1.4 版本引入了PodSecurityPolicy资源对象对Pod的安全策略进行管理。并在 1.10 版本升级了Beta 版，到 1.14 时趋于成熟。

6.6.1 PodSecurityPolicy 的工作机制

若想启用 PodSecurityPolicy机制，则需要在 Kube-apiserver 服务的启动参数 --enable-admission-plugins 中进行设置

--enable-admission-plugins=PodSecurityPolicy

7.1 Kubernetes网络模型

Kubernetes 网络模型设计的一个基础原则是：每个Pod都拥有一个独立的IP地址，并假定所有Pod都在一个可以直接连通的、扁平的网络空间中。所有不管它们是否运行在同一个Node(宿主机)中，都要求它们可以直接通过对方的IP进行访问。设计这个原则的原因是，用户不需要额外考虑如何建立Pod之间的连接，也不需要考虑如何将容器端口映射到主机端口的等问题。

实际上，在Kubernetes的世界里，IP 是以Pod为单位进行分配的。一个Pod内部的所有容器共享一个网络堆栈(相当于一个网络命令空间，它们的IP地址、网络设备、配置等都是共享的)。按照这个网络原则抽象出来的每个Pod都设置一个IP地址的模型也被称作IP-per-Pod模型。IP-per-Pod的方案可以很好的利用现有的各种域名解析和发现机制。

7.2 Docker 网络基础

Docker 本身的技术依赖于近年来Linux内核虚拟化技术的发展，所有Docker对Linux内核的特性有很强的依赖。Docker使用到的与Linux网络有关的主要技术有：网络命名空间(Network Namespace)、Vnet设备对、网桥、iptables和路由。

7.2.1 网络命名空间

为了支持网络协议栈的多个实例，Linux在网络栈中引入了命名空间，这些独立的协议栈被隔离到不同的命名空间中。处于不同命名空间中的网络栈是完全隔离的，彼此无法通信。
在Linux 的网络命名空间中可以有自己独立的路由表及独立的iptables 设置来提供包转发、NAT及IP 包过滤等功能。
为了隔离出独立的协议栈，需要纳入命名空间的元素有进程、套接字、网络设备等。

目录

configMap的yaml 配置

kubectl create cm squid

简介

• pod 是容器服务的最小单位
• pod 可以由1个或者多个容器组合而成，同属于一个Pod的多个容器应用之间访问时仅需要通过localhost 就可以通信。

静态pod

静态pod 是由 kubelet 进行管理的仅存在一特定的Node上的Podcast。不能通过API Server进行管理。无法与ReplicationController、Deployment或者DaemonSet进行关联，并且kubelet无法对它们进行健康检查

创建静态Pod 有两种方式：配置文件方式和HTTP方式。

Init Container(初始化容器)

在很多应用场景中，应用在启动之前都需要进行如下初始化操作。

• 等待其他关联组件正确运行（例如数据库或某个后台服务）
• 基于环境变量或配置模板生成配置文件。
• 从远程数据库获取本地所需配置，或者将自身注册到某个中央数据库中
• 下载相关依赖包，或者对系统进行一些预配置操作。

init container(初始化容器)用于在启动应用容器（app container） 之前启动一个或多个初始化容器，完成应用容器所需的预置条件，如图：