苜蓿0809
苜蓿0809

Kubernetes 学习笔记

Kubernetes 学习笔记

1. Kubernetes介绍

本章主要介绍应用程序在服务器上部署方式的演变以及Kubernetes的概念、组件和工作原理。

1.1 应用部署方式的演变

在部署应用的方式上，主要经历了三个时代：

  • 传统部署： 互联网早期，会直接将应用程序部署在物理机上

有点：简单，不需要其它技术参与

缺点：不能为应用程序定义资源使用边界，很难合理分配计算资源，而程序直接容易产生影响。

  • 虚拟化部署：可以在一台物理机上运行多台虚拟机，每个虚拟机都是一个独立的环境

优点：程序环境不会相互影响，提供一定程度的安全性

缺点：增加了操作系统，浪费了资源

  • 容器化部署

优点：

可以保证每个容器拥有自己的文件系统、CPU、内存、进程空间等

运行应用程序所需的资源都被容器包装，并和地层基础框架解耦

容器化的应用程序可以跨云服务商、跨Linux操作系统发行版本部署

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hE9Y58Qa-1680596600514)(file://E:\OneDrive\ebook\kubernetes\Kubernetes-20230301\2023-03-03-16-19-52-image.png?msec=1680573118594)]

为了管理容器，就产生了容器编排软件：

  • Swarm Docker自己的容器编排软件

  • Mesos Apache的一个资源统一管理软件，需要和Marathon结合使用

  • Kubernetes Google开源的容器编排软件

1.2 Kubernetes简介

Kubernetes是一个全新的基于容器技术的分布式架构领先方案，是谷歌严格保密十几年的密码武器**Borg**系统的一个开源版本，与2014年9月发布第一个版本，2015年7月发布第一个正式版本。

Kubernetes本质是一组服务器集群，它可以在集群的每个节点上运行特定的程序，来对节点中的容器进行管理。它的目的就是实现资源管理的自动化，主要提供以下功能：

  • 自我修复：一旦某一个容器崩溃，能够在1秒左右迅速启动新的容器；

  • 弹性伸缩：可以根据需要，自动对集群中正在运行的容器数量进行调整；

  • 服务发现：服务可以通过自动发现的形式找到它所依赖的服务；

  • 负载均衡：如果一个服务起了多个容器，能够自动实现请求的负载均衡；

  • 版本回款：如果发现发布的程序版本有问题，可以立即回退到原来的版本；

  • 存储编排：可以根据容器自身的需求自动创建存储卷；

1.3 Kubernetes组件

一个Kubernetes集群主要是由控制节点（Master）和工作节点（Node）组成，每个节点都会安装不同的组件。

Master 集群的控制平面，负责集群的决策

ApiServer: 资源操作的统一入口，接收用户输入的命令，提供认证、授权、API注册和发现等机制。

Scheduler: 负责集群资源调度，按照预定的资源调度策略将Pod调度到对应的Node节点上。

ControllerManager：负责维护集群的状态，比如程序部署安排、故障检测、自动扩展、滚动更新等。

Etcd：负责存储集群中各种资源对象信息。

Node 集群的数据平面，负责为容器提供运行环境

Kubelet: 负责维护集群的生命周期，即通过控制Docker来创建、更新、销毁容器。

KubeProxy: 负责提供集群内部的服务发现和负载均衡。

Docker: 负责节点上容器的各种操作。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-x6UrfVfh-1680596600515)(file://E:\OneDrive\ebook\kubernetes\Kubernetes-20230301\2023-03-03-16-52-08-image.png?msec=1680573118589)]

下面以部署一个Nginx服务来说明Kubernetes系统各个组件调用的关系：

1）首先要明确，一旦kubernetes启动之后，master和node都会将自身的信息存储在etcd数据库中；

2）一个nginx服务起的安全请求会首先被发送到master节点的apiServer组件；

3）apiServer组件会调用Scheduler组件来决定到底应该把服务安装到哪个node节点上；

4）apiServer调用controller-manager去调度node节点安装nginx服务；

5）kuberlet接收到指令后，会通知docker，然后由docker来启动一个nginx的pod，pod是kubernetes操作的最小单元，容器必须跑在pod中；

6）一个nginx服务就行了，如果需要访问nginx，就需要通过kube-proxy来对pod产生访问的代理，这样外界就可以访问集群中的nginx服务了。

1.4 Kubernetes概念

Master：集群控制节点，每个集群中需要至少有一个master节点负载集群的管控；

Node：工作负载节点，由master分配容器到这些node节点上，然后node节点上的docker负责容器的运行；

Controller：控制器，通过它来实现对pod的管理，比如启动pod，停止pod，伸缩pod等；

Pod：Kubernetes的最小控制单元，容器都是运行在Pod中，一个Pod中可以运行一个或者多个容器。

Service：Pod对外服务的统一入口

Label：标签，用来对Pod进行分类，同一类Pod会拥有相同的标签

NameSpace：命名空间，用来隔离Pod的运行环境

2. 集群环境搭建

本章主要介绍如何搭建kubernetes集群

2.1 集群规划

2.1.1 集群类型

Kubernetes集群大体上分为两类：一主多从和多主多从。

  • 一主多从：一台Master节点和多台Node节点，搭建简单，单机故障风险，适合于测试环境

  • 多主多从：多台Master节点和多台Node节点，搭建满分，安全性高，适合于生成环境

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1wwjMait-1680596600515)(file://E:\OneDrive\ebook\kubernetes\Kubernetes-20230301\2023-03-03-17-23-49-image.png?msec=1680573118486)]

2.1.2 安装方式

Kubernetes目前有多种集群安装方式，目前主流的方式有minikube、kubeadm、二进制包。

  • minikube：一个用于快速搭建单节点Kubernetes的工具

  • kubeadm：一个快速搭建kubernetes集群的工具

  • 二进制包：从官网下载每个组件的二进制包，依此安装（对于理解Kubernetes组件有帮助），推荐用于生成环境。

2.2 环境搭建

2.2.1 环境准备

一主二从

主机规划

作用 IP地址 操作系统 配置
Master 192.168.1.111 CentOS 7 CPU: 2核，内存: 2G，硬盘：50G
Node1 192.168.1.114 CentOS 7 CPU: 2核，内存: 2G，硬盘：50G
Node2 192.168.1.115 CentOS 7 CPU: 2核，内存: 2G，硬盘：50G

配置信息

配置项 配置值 说明
Service网段 10.96.0.0/12 不要和宿主机在同一个网段
Pod网段 10.244.0.0/16 不要和宿主机在同一个网段

一主二从，需要三台CentOS服务器，在每台服务器中分别安装docker-19., kubeadm-1.23.0, kubectl-1.23.0, kubelet-1.23.0。

多主多从

TODO~~

2.2.2 环境配置

  1. 操作系统要求

要求CentOS版本在7.5或以上

cat /etc/redhat-relase

CentOS Linux Release 7.5.1804(Core)

推荐Linux内核在4.0+

uname -r

  1. 主机名解析

在/etc/hosts中配置每台服务器的域名

192.168.1.111 node1

192.168.1.114 node4

192.168.1.114 node5

  1. 时间同步
yum install ntpdate -y
ntpdate time.windows.com
  1. 关闭firewalld服务

关闭防火墙

systemctl stop firewalld

禁止开机启动

systemctl disable firewalld
  1. 关闭iptables服务

关闭iptables

systemctl stop iptables

禁止开机启动

systemctl disable iptables
  1. 禁用selinux

查看selinux状态

getenforce # Disabled表示停止，Enabled表示启用

临时关闭

setenforce 0

永久停止

vim /etc/selinux/config

# 修改
SELINUX=disabled

永久停止方式二

sed -i 's/enforcing/disabled/' /etc/selinux/config # 永久
  1. 禁用swap分区
vim /etc/fstab

# 注释掉，修改完需要重启Linux
#/dev/mapper/centos-swap swap swap defaults 0 0

禁用swap分区方式二

swapoff -a # 临时
sed -ri 's/.*swap.*/#&/' /etc/fstab # 永久
  1. 修改Linux内核参数

将桥接的IPv4流量传递到iptables的链

vim /etc/sysctl.d/k8s.conf
# 添加内容如下
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1

重新加载配置

sysctl --system

加载网桥过滤模块

modprobe br_netfilter

查看网桥过滤模块是否加载成功

lsmod | grep br_netfilter

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-iR8vWyte-1680596600516)(file://E:\OneDrive\ebook\kubernetes\Kubernetes-20230301\2023-03-03-20-01-24-image.png?msec=1680573118399)]

  1. 配置ipvs功能

在kubernetes中的service既可以做反向代理，又可以做负载均衡。

代理有两种模式，一种是基于iptables的，另一种基于ipvs。ipvs的性能要高一些，使用ipvs需要安装ipvs模块

1）安装ipset和ipvs

yum install -y ipset ipvsadm

2）添加需要加载的模块写入脚本

cat <<EOF > /etc/sysconfig/modules/ipvs.modules
#!/bin/bash
modprobe -- ip_vs
modprobe -- ip_vs_rr
modprobe -- ip_vs_wrr
modprobe -- ip_vs_sh
#modprobe -- nf_conntrack_ipv4
modprobe -- nf_conntrack
EOF

3）为脚本添加执行权限

chmod +x /etc/sysconfig/modules/ipvs.modules

4）执行脚本

/bin/bash /etc/sysconfig/modules/ipvs.modules

5）查看模块是否加载成功

lsmod | grep -e ip_vs -e nf_conntrack # 注意：低内核版本这里是nf_conntrack_ipv4

nf_conntrack_netlink 40960 0
nfnetlink 16384 4 nf_conntrack_netlink,nf_tables,ip_set
ip_vs_ftp 16384 0
nf_nat 32768 4 nf_nat_ipv6,nf_nat_ipv4,xt_nat,ip_vs_ftp
ip_vs_sed 16384 0
ip_vs_nq 16384 0
ip_vs_fo 16384 0
ip_vs_sh 16384 0
ip_vs_dh 16384 0
ip_vs_lblcr 16384 0
ip_vs_lblc 16384 0
ip_vs_wrr 16384 0
ip_vs_rr 16384 0
ip_vs_wlc 16384 0
ip_vs_lc 16384 0
ip_vs 151552 24 ip_vs_wlc,ip_vs_rr,ip_vs_dh,ip_vs_lblcr,ip_vs_sh,ip_vs_fo,ip_vs_nq,ip_vs_lblc,ip_vs_wrr,ip_vs_lc,ip_vs_sed,ip_vs_ftp
nf_conntrack 143360 9 xt_conntrack,nf_nat,ip6t_MASQUERADE,nf_nat_ipv6,ipt_MASQUERADE,nf_nat_ipv4,xt_nat,nf_conntrack_netlink,ip_vs
nf_defrag_ipv6 20480 1 nf_conntrack
nf_defrag_ipv4 16384 1 nf_conntrack
libcrc32c 16384 4 nf_conntrack,nf_nat,xfs,ip_vs

6）修改master节点模式为ipvs

# 在master节点执行如下命令
kubectl edit configmap kube-proxy -n kube-system

修改如下mode值为"ipvs"

ipvs:
excludeCIDRs: null
minSyncPeriod: 0s
scheduler: “”
strictARP: false
syncPeriod: 0s
tcpFinTimeout: 0s
tcpTimeout: 0s
udpTimeout: 0s
kind: KubeProxyConfiguration
metricsBindAddress: “”
mode: “ipvs” # 这里修改为 ipvs

7）删除所有kube-proxy的pod

kubectl get pod -n kube-system | grep kube-proxy | awk '{system(" kubectl delete pod "$1" -n kube-system")}'

8）校验kube-proxy是否ipvs模式

kubectl logs kube-proxy-xxx -n kube-system # 检查是否日志出现Using ipvs Proxier
  1. 重启
reboot

2.2.3 安装Docker

1）切换镜像源
wget https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo -0/etc/yum . repos .d/docker-ce .repo
2）查看当前镜像源中支持的docker版本
yum list docker-ce --showduplicates
3）安装特定版本的docker-ce
# 必须指定--setopt=obsoletes=0，否则yum会自动安装更高版本
yum install --setopt=obsoletes=0 docker-ce-18.06.3.ce-3.el7 -y
4）添加一个配置文件
# Docker在默认情况下使用的Cgroup Driver为cgroupfs,而kubernetes推荐使用systemd来代替cgroupfs
mkdir /etc/docker
cat <<EOF > /etc/docker/daemon.json
exec-opts": ["native .cgroupdriver=systemd"] ."registry-mirrors": ["https ://kn8t2bca.mirror .aliyuncs.com"]
EOF

2.2.4 安装K8s组件

由于kubenetes的镜像在国外，速度比较慢，所以切换成国内的镜像源

1）编辑/etc/yum.repos.d/kubernetes.repo，添加内容如下：

vim /etc/yum.repos.d/kubernetes.repo
# 添加内容如下
[kubernetes]
name=Kubernetes
baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/
enabled=1
gpgcheck=0
repo_gpgcheck=0
gpgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg

2）安装kubeadm, kubectl, kubelet

yum install kubeadm-1.23.0 kubectl-1.23.0 kubelet-1.23.0 -y

3）配置kubelet

vim /etc/sysconfig/kubelet

添加内容如下

KUBELET_CGROUP_ARGS=“–cgroup-driver=systemd”

#配置Service的代理为ipvs,如果未配置会自动降级

KUBE_PROXY_MODE=“ipvs”

配置cgroup

vim /etc/sysconfig/kubelet

添加内容如下

KUBELET_EXTRA_ARGS=“–cgroup-driver=systemd --pod-infra-container-image=registry.cn-hangzhou.aliyuncs.com/google_containers/pause-amd64:3.2”

4）设置开机自启动

systemctl enable kubelet

2.2.5 集群初始化

下面操作只需要在master节点执行

1）初始化集群

kubeadm init \
--image-repository registry.aliyuncs.com/google_containers \
--service-cidr=10.96.0.0/12 \
--pod-network-cidr=10.244.0.0/16 \
--apiserver-advertise-address=192.168.1.111

如果不能初始化，需要检查是否因为从k8s.gcr.io拉不下来镜像，如果镜像无法拉取下来，才采用如下方法解决：

准备集群镜像

使用kubeadm安装kubernetes集群需要从官网镜像仓库k8s.gcr.io拉取组件的镜像，k8s.gcr.io在国内无法访问，但可以从阿里云的镜像仓库拉取，只不过名字不一样而已。因此可以从阿里云的镜像仓库把镜像拉下来，然后使用打标签的形式，把它换成k8s.gcr.io/$imageName，最后在把阿里云的镜像删除即可。

1）查看镜像

kubeadm config images list

2）拉取镜像

images=(
    kube-apiserver:v1.23.0
    kube-controller-manager:v1.23.0
    kube-scheduler:v1.23.0
    kube-proxy:v1.23.0
    pause:3.2
    etcd:3.4.13-0
    coredns:1.7.0
)
for imageName in ${images[@]}; do
    docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/$imageName
    docker tag registry.cn-hangzhou.aliyuncs.com/google_containers/$imageName k8s.gcr.io/$imageName

    docker rmi registry.cn-hangzhou.aliyuncs.com/google_containers/$imageName
done

初始化成功之后会在控制台看到如下信息

Your Kubernetes control-plane has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown ( i d − u ) : (id -u): (id−u):(id -g) $HOME/.kube/config

Alternatively, if you are the root user, you can run:

export KUBECONFIG=/etc/kubernetes/admin.conf

You should now deploy a pod network to the cluster.
Run “kubectl apply -f [podnetwork].yaml” with one of the options listed at:
https://kubernetes.io/docs/concepts/cluster-administration/addons/

Then you can join any number of worker nodes by running the following on each as root:

kubeadm join 192.168.1.111:6443 --token d5o7uf.yb2c7uqm90x9ubur
–discovery-token-ca-cert-hash sha256:e60c8c8d039166b80a054df762431c6218e2efd9b435db4ccc905ff4c911f144

2）创建必要文件

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
echo 'export KUBECONFIG=$HOME/.kube/config' >> $HOME/.bashrc
source $HOME/.bashrc

3）在master节点部署CNI网络插件

Kubenetes支持多种网络插件，比如flannel, calico, canal等，任选一种即可。

安装flannel

下面操作依旧在master节点上执行，插件使用Daemon控制器，会在每个节点执行

wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

安装flannel插件

kubectl apply -f kube-flannel.yml

注意：kube-flannel.yml中的有一个网段地址 10.244.0.0/16对应的是初始化集群时的Pod网段地址，需要一致，否则会无法访问；

4）将node节点加入集群

下面操作只需要在node节点执行

在node4, node5分别执行一下脚本将其加入集群

kubeadm join 192.168.1.111:6443 --token d5o7uf.yb2c7uqm90x9ubur \
        --discovery-token-ca-cert-hash sha256:e60c8c8d039166b80a054df762431c6218e2efd9b435db4ccc905ff4c911f144

过一会查看集群状态

kubectl get nodes

NAME STATUS ROLES AGE VERSION

node1 Ready control-plane,master 37m v1.23.0

node4 Ready 35m v1.23.0

node5 Ready 35m v1.23.0

2.2.6 卸载Kubernetes

如果安装过程中发生错误，需要卸载，执行以下脚本卸载

#!/bin/bash
kubeadm reset -f

modprobe -r ipip
lsmod

rm -rf $HOME/.kube
rm -rf ~/.kube/
rm -rf /etc/kubernetes/
rm -rf /etc/systemd/system/kubelet.service.d
rm -rf /etc/systemd/system/kubelet.service
rm -rf /usr/bin/kube*
rm -rf /etc/cni
rm -rf /opt/cni
rm -rf /var/lib/etcd
rm -rf /var/etcd

yum remove -y kubeadm kubectl kubelet kubernetes-cni cri-tools socat

reboot

2.3 集群测试

2.3.1 部署Nginx

1）部署nginx

kubectl create deployment deploy-nginx --image=nginx:1.18.0

2）暴露端口

kubectl expose deployment deploy-nginx --port=80 --type=NodePort

3）查看pod

kubectl get pod
# 结果如下
NAME                        READY   STATUS    RESTARTS   AGE   IP            NODE    NOMINATED NODE   READINESS GATES
pod-nginx-volume-hostpath   1/1     Running   0          99m   172.16.0.43   node4   <none>           <none>
pod-nginx-volume-nfs        1/1     Running   0          56m   172.16.0.44   node4   <none>           <none>

4）查看Service

kubectl get svc
# 结果如下
NAME           TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
deploy-nginx   NodePort    10.110.151.20   <none>        80:30574/TCP   32s
kubernetes     ClusterIP   10.96.0.1       <none>        443/TCP        33m

5）在浏览器中访问

service暴漏的端口是30574，在master节点访问页面如下：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-IK86u2dJ-1680596600516)(file://E:\OneDrive\ebook\kubernetes\Kubernetes-20230301\explorer-visit.png?msec=1680573118400)]

创建失败，通过kubectl describe deployment nginx查看发现报以下错误： loadFlannelSubnetEnv failed: open /run/flannel/subnet.env: no such file or directory。解决办法：分别在master, 所有node节点上创建文件如下：

vim /run/flannel/subnet.env

# service network
FLANNEL_NETWORK=10.96.0.0/12
# pod network
FLANNEL_SUBNET=10.244.0.0/16
FLANNEL_MTU=1450
FLANNEL_IPMASQ=true

注意：通过以上方式不能根据解决问题，当服务器重启后subnet.env文件又会丢失，根据解决办法是重新初始化时加上–pod-network-cidr=10.244.0.0/16参数

kubeadm init --image-repository registry.aliyuncs.com/google_containers --pod-network-cidr=172.16.0.1/12

3 资源管理

3.1 资源管理介绍

在Kubernetes中，所有的内容都抽象为资源，用户需要操作资源来管理Kubernetes。

Kubernetes的最小管理单元是pod而不是容器，容器放在pod中，Kubernetes一般也不会直接管理pod，而是通过pod控制器管理pod。

Pod提供的服务通过Service来访问；Pod中的数据持久化，通过存储系统来实现。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-RLUtafcQ-1680596600517)(file://E:\OneDrive\ebook\kubernetes\Kubernetes-20230301\3.1-1.png?msec=1680573118676)]

3.2 资源管理方式

  • 命令式对象管理：直接使用命令操作kubernetes资源

    kubectl run nginx-pod --image=nginx:1.17.1 --port=80

  • 命令式对象配置：通过命令配置和配置文件操作kubernetes资源

    kubectl create/patch -f nginx-pod.yaml

  • 声明式对象配置：通过apply命令和配置文件操作kubernetes资源

    kubectl apply -f nginx-pod.yaml

类型 操作对象 适用环境 优点 缺点
命令式对象管理 对象 测试 简单 只能操作活动对象，无法审计、跟踪
命令式对象配置 文件 开发 可以审计、跟踪 项目大时、配置文件多，操作麻烦
声明式对象配置 目录 开发 支持目录操作 意外情况下难以调试

3.2.1 命令式对象管理

kubectl命令

kubectl是kubernetes集群命令行工具，通过它能够对集群本身进行管理，并能够在集群上进行容器化应用的安装部署。

语法：kubectl [command] [type] [name] [flags]

command：指定要对资源进行的操作，如：create, get, delete

type：指定资源类型，如：pod，deployment，service

name：指定资源名称（资源名称区分大小写）

flages：指定额外的可选参数

示例：

1）查看所有pod

kubectl get pod

2）查看某个pod

kubectl get pod pod_name

3）查看某个pod，以yaml格式展示

kubectl get pod pod_name -o yaml

命令

通过kubectl --help可以查看都有哪些命令

命令分类 命令 翻译 命令作用
基本命令 create 创建 创建一个资源
edit
get
patch 更新 更新一个资源
delete 删除
explain 解释 展示资源文档
运行和调试 run 运行 在集群中运行一个指定的镜像
expose 暴露 暴漏资源为service
describe 描述 显示资源内部信息
logs 日志 输出容器在pod中的日志
attach 缠绕 进入运行中的容器
exec 执行 执行容器中的一个命令
cp 复制 在pod外复制文件
rollout 首次展示 管理资源发布
scale 规模 扩（缩）pod的数量
autoscale 自动调整 自动调整pod的数量
高级命令 apply rc
label 标签
其它命令 cluster-info 集群信息 显示集群信息
version 版本 显示当前Server和Client的版本

资源类型

查看所有资源类型

kubectl api-resources
资源分类 资源名称 缩写 资源作用
集群级别资源 nodes no 集群组成部分
namespace ns 隔离pod
pods po 装在容器
pod资源控制器 replicationcontrollers rc 控制pod资源
replicasets rc 控制pod资源
jobs 控制pod资源
cronjobs cj 控制pod资源
statefulsets
服务发现资源 services
ingress
存储资源 volumattachments
persistentvolumes pv 存储
persistentvolumeclaims pvc 存储
配置资源 configmaps cm 配置
secrets

表格不完整，待补充

3.2.2 命令式对象配置

命令式对象配置就是使用命令配合配置文件一起操作kubenetes资源。

示例：kubectl create/patch -f nginx-pod.yaml

1)创建一个nginx-pod.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: dev
---
apiVersion: v1
kind: Pod
metadata: 
  name: nginx-pod
  namespace: dev
spec:
  containers:
  - name: nginx-containers
    image: nginx-1.18.0

2)执行create命令，创建资源

kubectl create -f nginx-pod.yaml

[root@node1 k8s-test]# kubectl create -f nginx-pod.yaml
namespace/dev created
pod/nginx-pod created

此时会发现创建了命名空间 dev, 在该命名空间下创建一个pod nginx-pod。

3)查看资源

kubectl get -f nginx-pod.yaml

[root@node1 k8s-test]# kubectl get -f nginx-pod.yaml
NAME STATUS AGE
namespace/dev Active 3m1s

NAME READY STATUS RESTARTS AGE
pod/nginx-pod 1/1 Running 0 3m

4)删除资源

kubectl delete -f nginx-pod.yaml

总结：命令式对象配置的方式操作资源，可以简单认为：命令 + yaml配置文件（里面是命令需要的各种参数）

3.2.3 声明式对象配置

声明式对象配置和命令式对象配置很相似，只有一个命令apply，只用于创建和更新资源。

kubectl apply -f nginx-pod.yaml

[root@node1 k8s-test]# kubectl apply -f nginx-pod.yaml
namespace/dev created
pod/nginx-pod created

如果再次运行，提示如下：

[root@node1 k8s-test]# kubectl apply -f nginx-pod.yaml
namespace/dev unchanged
pod/nginx-pod unchanged

如果修改了nginx-pod.yaml，运行提示如下：

[root@node1 k8s-test]# kubectl apply -f nginx-pod.yaml
namespace/dev unchanged
pod/nginx-pod configured

总结：声明式对象配置就是使用apply描述一个资源的最终状态（在yaml中定义的状态）

使用apply操作资源：

如果资源不存在，就创建，相当于kubectl create

如果资源已存在，就更新，相当于kubectl patch

3.2.4 node节点kubectl

kubectl的运行是需要进行配置的，它的配置文件是$HOME/.kube，如果想要在node节点上运行此命令，需要将master节点上的.kube文件复制到node节点上，即在master节点上执行：

scp -r $HOME/.kube node4:$HOME/

4 Pod

4.1 Pod详解

4.2.1 Pod结构

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-F1yXtvcH-1680596600518)(file://E:\OneDrive\ebook\kubernetes\Kubernetes-20230301\pod.png?msec=1680573118400)]

每个pod中包含一个或多个容器，这些容器分为两类：

  • 用户容器

  • Pause容器，每个Pod都会有的一个根容器

    • 评估Pod的健康状态

    • 可以在根容器设置IP地址，其它容器共享该IP实现Pod内的网络通信

    这是pod的内部通讯，pod之间的通讯采用虚拟二层网络技术来实现，当前用的Flannel

4.2.2 Pod定义

Pod的资源清单

apiVersion: v1 # 必须，版本号
kind: Pod # 必须，资源类型
metadata: # 必须，元数据
  name: string # 必须，Pod名称
  namespace: string # Pod所属命名空间，默认为"default"
  labels: # 自定义标签列表
    - name: string 
  spec: # 必须，pod中的详细定义
    containers: # 必选，pod中容器列表
      - name: string # 必须，容器名称
        image: string # 必选，容器镜像名称
        imagePullPolicy: [ Always|Never|IfNotPresent ]
        command: [string] # 容器的启动列表命令，如不指定，使用打包时使用的启动命令
        args: [string] # 容器的启动命令参数列表
        workingDir: string # 容器的工作目录
        volumnMounts: # 挂载到容器内部的存储卷配置
          - name: string # 引用pod定义的共享存储卷的名称，需要volumes[]部分定义的卷名
            mountPath: string # 存储卷在容器内mount的绝对路径，应少于512字符
            readOnly: boolean # 是否为只读模式
        ports: # 需要暴露的端口库号列表
          - name: string # 端口的名称
            containerPort: int # 容器需要监听的端口号
            hostPort: int # 容器所在主机需要监听的端口，默认与container相同
            protocol: string # 端口协议，支持TCP和UDP，默认TCP
        env: # 容器运行前需要设置的环境变量列表
          - name: string # 环境变量名称
            value: string # 环境变量的值
        resources: # 资源限制和请求设置
          limits: # 资源限制的设置
            cpu: string # cpu的限制，单位为core数，将用于docker run --cpu-shares参数
            memory: string # 内存请求，容器启动的初始可用数量
        lifecycle: # 生命周期函数
          postStart: # 容器启动时立即执行此钩子，如果执行失败，会根据重启策略进行重启
          preStop: # 容器终止前执行此钩子，无论结构如何，容器都会终止
        livenessProbe: # 对pod内各容器健康检测的设置，当探测无响应几次后自动重启该容器
          exec: # 都容器内检查方式设置为exec方式
            command: [string] # exec方式需要指定的命令或脚本
          httpGet: # 对pod内容器健康检查方式设置为HttpGet，需要制定path, port
            path: # string
            port: # string 
            host: string
            scheme: string
            HttpHeaders: string
              - name: string
                value: string
            tcpSocket: #对pod内各容器健康检查方式设置为tcpSocket方式
              port: number
            initialDelaySeconds: 0 # 容器启动后首测探测的时间
            timeoutSeconds: 0 # 对容器健康检查探测等待响应的超时时间，单位秒，默认1秒
            periodSeconds: 0 # 对容器监控检查的定期探测时间设置，默认秒，默认10一次
            successThreshold: 0
            failureThreshold: 0
            securityContext:
              privileged: false
       restartPolicy: [Always|Never|OnFailure] # pod重启策略
       nodeName: > # 设置NodeName表示将pod调度到指定的名称的node节点上
       nodeSelector: object # 设置NodeSelector表示将该pod调度到包含这个label的node上
       imagePullSecrets: # Pull镜像时使用secret名称，以key: secretkey格式指定
         - name: string
       hostNetwork: false # 是否使用主机网络模式，默认false, 如果设置为true，表示使用宿主机网络
       volumes: # 在该pod上定义共享存储卷列表
         - name: string # 共享卷名称（volumes类型有很多种）
           emptyDir: {} # 类型为emptyDir的存储卷，与pod同生命周期的一个临时目录。为空值
           hostPath: string # 类型为hostPath的存储卷，表示挂载pod所在宿主机的目录
             path: string # pod所在宿主机的目录，将被用于同期中mount目录
           secret: # 类型为secret的存储卷，挂载集群与定义的secret对象到容器内部
             scretname: string
             items:
               - key: string
                 path: string
           configMap: # 类型为configMap的存储卷，挂载预定义的configMap对象到容器内部
              name: string
              items:
                - key: string
                  path: string

可以使用命令查看每种资源的可配置项

kubectl explain 资源类型 # 查看某种资料可配置的一级属性

kubectl explain 资源类型.属性 # 查看属性的子属性

在kubernetes中，基本所有资源的一级属性都是一样的，主要包含5部分：

  • apiVersion 版本，由kubernetes内部定义，版本号必须可以用kubectl api-versions查询到

  • kind 类型，由kubernetes内部定义，可以使用kubectl api-resources查询到

  • metadata 元数据，主要是资源标识和说明，常用的有name, namespace, labels等

  • spec 描述，对各种资源的详细描述（这是配置最重要的一部分）

  • status 状态，不需要定义，由kubernetes自动生成；

    spec的子属性

  • containers <[]Object> 容器列表，用于定义容器的详细信息；

  • nodeName 根据nodeName的值，将Pod调度到指定的Node节点上；

  • nodeSelecor 根据nodeSelector中定义的信息选择将该Pod调度到包含这些label的Node上

  • hostNetwork 是否使用主机网络模式，默认false；true表示使用宿主机网络；

  • volumes <[] Object> 存储卷，用于定义Pod上面挂的存储信息；

  • restartPolicy 重启策略，表示Pod在遇到故障的时候的处理策略；

Kubenetes在集群启动之后，集群中的各个组件都是以pod方式运行的。可以通过命令查看：

kubectl get pods -n kubesystem

4.2.3 Pod配置

创建并运行

kubernetes没有提供单独的pod命令，都是通过pod控制器来实现的。

命令格式： kube run pod控制器名称 [参数] （试验有问题，没有创建pod控制器）

参数：

–image 指定的pod镜像

–port 指定的端口

–namespace 指定的命名空间

示例：

创建pod：使用命令kubectl run nginx --image=nginx:1.18.0 --port=80 -n dev创建pod后，教程创建的pod名称自动添加了随机串，试验没有

删除pod：使用命令 kubectl delete pods nginx -n dev 删除pod，试验可以删除成功，教程删除后又自动创建了一个

nginx-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  namespace: dev
spec:
  containers:
  - name: pod # 容器名称    
    image: nginx:1.18.0 # 容器镜像
    imagePullPolicy: IfNotPresent # 镜像拉取策略
    command: <[]string> # 容器的启动命令列表，如不指定，使用打包时使用的命令
    args: <[]string> # 容器的启动命令需要的参数列表
    evn: <[]string> # 容器环境变量的配置    
    ports:
    - name: nginx-port
      containerPort: 80
      protocol: TCP
      resources: > # 资源限制和资源请求设置

运行

[root@node1 k8s-pod]# vim pod-nginx.yaml 
会直接创建pod, 而不是创建pod控制器

[root@node1 k8s-pod]# vim pod-nginx.yaml

4.2.4 镜像策略

imagePullPolicy，用于设置镜像拉取策略，有三种策略

  • Always 总是从远程仓库拉取

  • IfNotPresent 本地有则使用本地镜像，否则从远程仓库拉取

  • Never 只是用本地镜像，从不去远程仓库拉取

默认值说明

如果镜像tag为具体版本号，默认策略是IfNotPresent

如果镜像tag为:latest（最新版本），默认策略是Always

4.2.5 启动命令

command <[]string> # 容器启动的命令列表，如不指定，使用打包时使用的启动命令

args <[]string> #

apiVersion: v1
kind: Pod
metadata:
  name: busybox-pod
  namespace: dev
spec:
  containers:
    - name: busybox
      image: busybox:1.30
      command: ["/bin/bash","-c","touch /tmp/hello.txt;while true;do /bin/echo $(data + %T) >> /tmp/hello.txt; sleep 3; done;"]

“/bin/bash” 使用sh执行命令, “-c” 以管理员方式运行

进入容器：

kubectl exec pod名称 -n 命名空间 -it -c 容器名称 执行命令

kubectl exec busybox -n dev -it -c busybox /bin/bash

特别说明：

command可以完成启动命令和传递参数，为什么还需要一个args选项用于传递参数？其实这跟docker有关系，kubernetes中的command, args两项其实是实现覆盖Dockerfile中EntryPoint的功能。

  1. 如果command和args均没有写，那么使用Dockerfile的配置；

  2. 如果有command，无args，Dockerfile的配置会忽略，执行command；

  3. 如果无command，有args，Dockerfile中的EntryPoint执行，使用args参数；

  4. 如果有command，有args，Dockerfile的配置会被忽略，执行command追加args；

4.2.6 环境变量

env <[]Object> 容器环境变量配置（不太推荐给容器配置环境变量，推荐将配置单独放在配置文件中）

apiVersion: v1
kind: Pod
metadata:
  name: busybox-pod
  namespace: dev
spec:
  containers:
    - name: busybox
      image: busybox:1.30
      command: ["/bin/bash","-c","touch /tmp/hello.txt;while true;do /bin/echo $(data + %T) >> /tmp/hello.txt; sleep 3; done;"]
    env: # 设置环境变量
      - name: "username"
        value: "admin"
      - name: "password"
      - value: "123456"

4.2.7 端口配置

ports <[]Object> 表示容器要暴露的端口号列表

prots:

name: # 端口名称，如果指定，必须保证name在pod中唯一

containerPort: # 容器需要监听的端口

hostPort: # 容器要在主机上公开的端口，如果设置，主机上只能运行容器的一个副本（一般省略）

hostIP: # 要将外部端口绑定主机的IP（一般省略）

protocol: # 端口协议，必须是TCP(默认)/STCP、UDP。

示例：

apiVersion: v1
kind: Pod
metadata:
  name: busybox-pod
  namespace: dev
spec:
  containers:
    - name: busybox
      image: busybox:1.30
      ports: # 容器暴露的端口
        - name: port-80 # 端口名称
          containerPort: 80 # 容器监听的端口 
          protocol: TCP # 协议

说明：要访问容器中的程序，需要使用:<容器端口> （和pod网络不通如何处理？）

4.2.8 资源配额

Kubernetes对CPU和内存进行配额的机制，主要通过resource选项实现。

  • limits: 用于限制运行时容器的最大占用资源，当容器占用资源超过limits时会被终止，并进行重启；

  • requests: 用于设置容器的最小资源，如果环境资源不够，容器将无法重启；

示例：

apiVersion: v1
kind: Pod
metadata:
  name: busybox-pod
  namespace: dev
spec:
  containers:
    - name: busybox
      image: busybox:1.30
      resources: # 资源配额
        limits: # 资源上线
          cpu: "2" # CPU最大核数
          memory: "10Gi" # 最大内存容量
        requests: # 请求最小资源
          cpu: "1" # CPU最小核数
          memory: "10Mi" # 最小内存容量

cpu: core数，可以为整数或小数

memory: 内存大小，可以使用Gi，Mi，G，M

4.3 Pod生命周期

将Pod对象从创建到终止这段时间叫做pod的生命周期；

  1. pod创建过程

  2. 运行初始化容器（init container）过程

  3. 运行主容器（main container，即：用户容器）过程

  • 容器启动后钩子（post start）

  • 容器终止前钩子（pre stop）

  • 容器存活性探测（liveness probe）

  • 容器就绪性探测（readiness probe）

  1. pod终止过程

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VGBg6L9P-1680596600519)(file://E:\OneDrive\ebook\kubernetes\Kubernetes-20230301\pod-lifecycle.png?msec=1680573118587)]

在整个生命周期中，Pod会出现5中状态：

  • 挂起（Pending）: apiserver已经创建了pod资源对象，但尚未被调度完成或仍处于镜像下载过程中；

  • 运行中（Running）：pod已经被调度到某节点，并且pod中的所有容器已经被kubectl创建完成；

  • 成功（Succeeded）：pod中的所有容器已经成功终止并且不会被重启（即容器启动成功之后运行完成任务后正常终止，之后不会被再次启动的容器）；

  • 失败（Failed）：所有容器都已经终止，但至少有一个容器终止失败，即容器返回了非0值的退出状态（该状态对应Succeeded状态）；

  • 未知（Unknow）：apiserver无法正常获取到pod对象的状态信息，通常由网络通讯失败所导致；

4.3.1 Pod创建

Pod的创建过程

  1. 用户通过kubectl或api客户端提交需要创建Pod的信息给apiServer；

  2. apiServer开始生成pod对象信息，并将信息存入etcd，然后返回确认信息至客户端；

  3. apiServer开始反应etcd中pod对象的变化，其它组件使用watch机制来跟踪检查apiServer的变化；

  4. scheduler发现有新的pod对象要创建，开始为pod分配主机并将结果信息更新至apiServer；

  5. node节点上的kubelet发现有pod调度过来，尝试调用docker启动容器，并将结果返回至apiServer；

  6. apiServer将收到的pod状态存入etcd；

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BQdg28Dl-1680596600519)(file://E:\OneDrive\ebook\kubernetes\Kubernetes-20230301\pod-create.png?msec=1680573118488)]

4.3.2 初始化容器

初始化容器是在pod的主容器启动之前要运行的容器，主要做一些容器的前置工作。

两大特征

  1. 初始化容器必须运行完成直结束，若某初始化容器运行失败，那么kubernetes需要重启它直至成功完成；

  2. 初始化容器必须按照定义的顺序执行，当且仅当一个成功之后，后面的一个才能运行；

应用场景

  • 提供主容器镜像中不具备的工具程序或自定义代码；

  • 初始化容器要先于应用容器串行启动并完成，因此可用于延后应用程序的启动直至其依赖的条件得到满足；

示例

假设要以容器来运行nginx，在运行nginx之前，要先要能够连上mysql和redis服务器。

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  namespace: dev
spec:
  containers:
    - name: main-container
      image: nginx:1.17.1
      ports:
        - name: nginx-port
          containerPort: 80
  initContainers:
    - name: test-mysql
      image: busybox:1.30
      command: ['sh', '-c', 'util ping 192.168.1.118 -c 1; do echo waiting for mysql...; sleep 2; done;']
    - name: test-redis
      image: busybox:1.30
      command: ['sh', '-c', 'util ping 192.168.1.117 -c 1; do echo waiting for redis...; sleep 2; done;']

4.3.3 运行主容器

钩子函数

Kubernetes在主容器创建之后和容器停止之前提供了两个钩子函数：

  1. postStart: 容器创建之后执行，如果失败会重启容器；

  2. preStop: 容器终止之前执行，执行完成之后容器会成功终止，在其完成之前会阻塞删除容器的操作；

钩子函数三种处理方式

  • exec命令: 在容器内执行一次命令
---
lifecycle:
  postStart: 
    exec:
      command:
        - cat
        - /tmp/healthy

说明：容器启动后执行命令 cat /tmp/healthy

示例1

apiVersion: v1
kind: Pod
metadata:
  name: pod-nginx-hook-exec 
  namespace: dev
  labels:
    user: wangke
spec:
  containers:
    - name: nginx
      image: nginx:1.18.0
      imagePullPolicy: Never 
      ports:
        - name: nginx-port
          containerPort: 80
          protocol: TCP
      lifecycle:
        postStart:
          exec:
            command: ["/bin/bash", "-c", "echo post start"]
        preStop:
          exec:
            command: ["/bin/bash", "-c", "echo pre stop"]
  • tcpSoket: 在当前容器尝试访问指定的socket
lifecycle:
  postStart:
    tcpSocket:
      port: 8080

说明：在容器启动之后连接8080端口

  • httpGet: 在容器启动之后，向url发起http请求
lifecycle:
  postStart:
    httpGet:
      scheme: HTTP # http or https
      host: 192.168.1.114
      port: 80
      path: /

说明：容器启动后向 http://192.168.1.114/ 发起http请求

容器探测

容器探测用于检测容器中的应用是否可以正常工作，是保障业务可用性的一种传统机制。如果经过探测，实例的状态不符合预期，那么kubenetes会把问题实例“摘除”，不承担业务流量。kubernetes提供两种探针实现容器探测，分别是：

  • liveness probes: 存活性探针，用于检测应用实例当前是否处于正常状态，如果不是，kubernetes会重启容器；存活性探针的作用在于决定是否重启容器；

  • readiness probes: 就绪性探针，用于检测应用实例当前是否可以接收请求，如果不能，kubernetes不会转发流量；就绪性探针的作用在于决定是否接收请求；

上面两种探针支撑三种探测模式：

  • Exec命令: 在容器内执行一次命令，如果命令执行的退出码为0，则表示应用正常

    livenessProbe:
  lifecycle:
    exec:
      command: ["/bin/bash", "-c", "echo Are you OK?"]
      initialDelaySeconds: > # 容器启动后多少秒执行第一次探测
      timeoutSeconds: > # 探测超时时间。默认1s, 最小1s
      periodSeconds: > # 执行探测的频率，默认10s, 最小1s
      failureThreshold: > # 连续探测多少次认为失败，默认3次，最少1次
      successThreshold: > # 连续探测多少次认为成功，默认1次

  • TcpSocket: 将会尝试访问容器的一个端口，如果能够建立连接，则认为应用正常

    livenessProbe:
  tcpSocket:
    port: 8080

  • HttpGet: 调用容器内Web应用的URL，返回状态码在200~399之间，则认为程序正常

    liveness:
  httpGet:
    schema: http
    host: 127.0.0.1
    port: 80
    path: /

    就绪探针

    TODO

    重启策略

    存活性探针探测出应用出现问题，就会对容器所在的pod进行重启，这其实是由重启策略决定的，pod有三种重启策略：

    三种重启策略

    1. Always: 容器失效时自动重启，默认值；

    2. OnFailure: 容器终止运行且退出码不为0时重启

    3. Never: 无论状态如何，从不重启

    重启策略适用于pod对象中的所有容器，首次需要启动的容器，将在其需要重启时立即重启，随后需要重启的操作将由kubernetes延时一段时间后执行，且反复重启的延长时间以次10s，20s，40s，80s，160s和300s递增。

    containers:
  - name: nginx
    image: nginx:1.18.0
restartPolicy: Never

4.3.4 Pod终止

Pod的终止过程

  1. 用户向apiServer发送删除pod的命令；

  2. apiServer中的pod对象信息会随着时间的推移而更新，过了宽限期内（默认30s），pod被视为dead；

  3. 将pod标记为terminating状态；

  4. kubelet在监听到pod对象转化为terminating状态的同时启动pod关闭过程；

  5. 端点控制器监控到pod对象的关闭行为时将其从所有匹配到此端点的service资源的端点列表中移除；

  6. 如果当前pod对象定义了preStop钩子处理器，则在其标记为terminating后即会以同步的方式启动执行；

  7. pod对象中的容器进程收到停止信号；

  8. 宽限期结束后，若pod中还存在仍在运行的进程，那么pod对象会收到立即终止的信号；

  9. Kubelet请求apiServer将此pod的资源宽限期设置为0从而完成删除操作，此时pod对于用户已经不可见；

4.3.5 批量删除

批量删除dev下Evicted的Pod

kubectl get pods -n dev | grep Evicted | awk '{print$1}' | xargs kubectl delete pods -n dev

4.4 Pod的调度

在默认情况下，Pod在哪个节点上运行是由Scheduler组件采用相关算法计算出来的，。但在实际情况下，我们想控制Pod运行在某个节点上，这就需要pod的调度机制。

四大类调度方法

  1. 自动调度：由Scheduler计算得出（默认）

  2. 定向调度：NodeName, NodeSelecor决定

  3. 亲和性调度：NodeAffinity, PodAffinity, PodAntiAffinity

  4. 污点（容忍）调度：Taints, Toleration

4.4.1 定向调度

利用Pod上声明的nodeName或者nodeSelector，依此将Pod调度到期望的Node节点上。如果该Node不存在也会强制调度，将会失败。

nodeName用于强制将Pod调度到指定Name的Node节点上，跳过Scheduler直接写入PodList。nodeName是pod的属性。

apiVersion: v1
kind: Pod
metadata:
  name: pod-nginx
  namespace: dev
  labels:
    user: wangke
spec:
  containers:
    - name: nginx
      image: nginx:1.18.0
      imagePullPolicy: IfNotPresent
      ports:
        - name: nginx-port
          containerPort: 80
          protocol: TCP
  nodeName: node4

nodeSelector用于将pod调度到指定标签的node节点上。它是通过label-selector机制实现的。在pod创建之前，会由scheduler使用MatchNodeSelector调度策略进行lael匹配，找出目标node，然后将pod调度到目标节点，该匹配规则是强制约束。

  1. 给node添加标签
kubectl label nodes node4 "name=node4"
kubectl label nodes node5 "name=node5"
  1. 指定nodeSelector创建pod
apiVersion: v1
kind: Pod
metadata:
  name: pod-nginx
  namespace: dev
  labels:
    user: wangke
spec:
  containers:
    - name: nginx
      image: nginx:1.18.0
      imagePullPolicy: IfNotPresent
      ports:
        - name: nginx-port
          containerPort: 80
          protocol: TCP
  nodeSelector:
    name: node4

4.4.2 亲和性调度

亲和性调度优先选择满足条件的node进行调度，如果没有，也可以调度到不满足的节点上，是调度更加灵活。

亲和度Affinity主要分为三类：

  1. nodeAffinity(node亲和性): 以node为目标，解决pod可以调度到哪些node；

  2. podAffinity(pod亲和性): 以pod为目标，解决pod可以和哪些已知pod部署在同一个拓扑域中的问题；

  3. podAntiAffinity(pod反亲和性): 以pod为目标，解决pod不能和哪些已知pod部署在同一个拓扑域中的问题；

关于亲和性和反亲和性的应用场景：

亲和性：如果两个应用频繁交互，那就有必要让两个应用尽可能的靠近，减少网络通讯问题；

反亲和性：当采用多副本部署时，有必要采用反亲和性让各应用实例打散在各node上，以提供服务的高可用；

NodeAffinity

pod.spec.affinity.nodeAffinity
requiredDuringSchedulingIgnoredDuringExecution Node节点必须满足指定的规则才可以，相当于硬限制
nodeSelectorItems 节点选择列表
matchFields 按节点字段列出的节点选择器要求列表

matchExceptions 按节点标签列出的节点选择器列表（推荐）

 key

 values

 operator 关系符，支持Exists, DoesNotExist, In, NotIn, Gt, Lt

preferredDuringSchedulingIgnoredDuringExecution 优先调度到指定的规制node，相当于软限制（倾向）

preference 一个节点选择器，与相应的权重相关联

 matchFileds 按节点字段列出的节点选择器要求列表

 matchExpressions 按节点标签列出的节点选择器要求列表（推荐）

 key

 values

 operator 关系符 支持In, NotIn, Exists, DoesNotExist, Gt, Lt

weight 倾向权重，在范围1-100

关系符的使用说明

- matchExpressions:
  - key: nodeenv # 匹配标签的key为nodeenv的节点
    operator: Exists
  - key: nodeenv # 匹配标签的key为nodeenv，且value是"xxx"或"yyy"的节点
    operator: In
    values: ["xxx", "yyy"]
  - key: nodeenv # 匹配标签的key为nodeenv，且values大于"xxx"的节点
    operator: Gt
    values: "xxx"

node亲和性调度-硬限制-1

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod-20230319-1
  namespace: dev
  labels:
    user: wangke
spec:
  containers:
    - name: nginx
      image: nginx:1.18.0
      imagePullPolicy: IfNotPresent
      ports:
        - name: nginx-port
          containerPort: 80
          protocol: TCP
  affinity:
   nodeAffinity:
     requiredDuringSchedulingIgnoredDuringExecution: # 硬限制
       nodeSelectorTerms:
         - matchExpressions: 
           - key: name
             operator: In
             values: ["node5"]

node亲和性调度-软限制

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod-20230319-2
  namespace: dev
  labels:
    user: wangke
spec:
  containers:
    - name: nginx
      image: nginx:1.18.0
      imagePullPolicy: IfNotPresent
      ports:
        - name: nginx-port
          containerPort: 80
          protocol: TCP
  affinity:
   nodeAffinity:
     preferredDuringSchedulingIgnoredDuringExecution: # 软限制
       - weight: 1
         preference:
           matchExpressions:
           - key: name
             operator: In
             values: ["node6"]

NodeAffinity规则设置的注意事项

  1. 如果同时定义了nodeSelector和nodeAffinity，那么必须两个条件都得到满足，pod才能够运行在指定的node上；

  2. 如果nodeAffinity指定了多个nodeSelector，那么只需要其中一个能够匹配成功即可；

  3. 如果一个nodeSelectorTerms中有多个matchExpressions，则一个节点必须满足所有的才能匹配成功；

  4. 如果一个pod所在node在pod运行期间标签发生了变化，不符合该pod的节点亲和性需求，则系统将忽略此变化；

PodAffinity

podAffinity以pod做为参考，实现让新创建的pod跟参照pod在一个区域。

podAffinity配置项

kubectl explain pod.spec.affinity.podAffinity

requiredDuringSchedulingIgnoredDuringExecution <[]Object> 硬限制

namespaces    指定参照pod的namespace

topologKey    指定调度作用域

labelSelector    标签选择器

    matchExpressions 按节点标签列出的节点选择器要求列表（推荐）

        key

        values

        operator 关系符 支持 In, NotIn, Exists, DoesNotExist

    matchLabels 指多个matchExpressions映射内容

preferredDuringSchedulingIgnoredDuringExecution <[]Object> 软限制

podAffinityTerm

    namespaces

    topologKey

    labelSeletor

        matchExpressions

            key

            values

            operator

        matchLabels

weight    倾向权重，在范围1-100

topologyKey用于指定调度的作用域：

如果指定为kubernetes.io/hostname，那就以node节点为区分范围

如果指定为beta.kubernetes.io/os，则以node的操作系统类型来区分

pod亲和性-硬限制

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod-20230319-4
  namespace: dev
  labels:
    user: wangke
spec:
  containers:
    - name: nginx
      image: nginx:1.18.0
      imagePullPolicy: IfNotPresent
      ports:
        - name: nginx-port
          containerPort: 80
          protocol: TCP
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution: # 硬限制
        - labelSelector:
            matchExpressions:
              - key: app 
                operator: In
                values: ["cust"] 
          topologyKey: kubernetes.io/hostname

PodAntiAffinity

PodAntiAffinity主要实现以运行pod为参照，让新创建的pod跟参照pod不在一个区域的功能。配置跟podAffinity一样。

pod反亲和性-硬约束

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod-20230319-5
  namespace: dev
  labels:
    user: wangke
spec:
  containers:
    - name: nginx
      image: nginx:1.18.0
      imagePullPolicy: IfNotPresent
      ports:
        - name: nginx-port
          containerPort: 80
          protocol: TCP
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution: # 硬限制
        - labelSelector:
            matchExpressions:
              - key: app
                operator: In
                values: ["cust"]
          topologyKey: kubernetes.io/hostname

4.4.3 污点和容忍

污点（Taints）

前面的调度方式都是站在pod角度上，通过在pod上添加属性，来确定pod是否要调度指定的node上。其实也可以站在node角度上，通过在node上添加污点属性，来决定是否运行pod调度过来。

node上添加污点之后就和pod存在一种互斥关系，进而拒绝pod调度进来，甚至可以将已经存在的pod驱逐出去。

污点的格式：key=value:effect，key和value是污点标签，effect描述污点的作用，支持三种选项：

  1. PreferNoSchedule: 尽量避免把pod调度到具有该污点的node上，除非没有其它节点可调度；

  2. NoSchedule: 不会把pod调度到该污点的node上，但不会影响当前node上已存在的pod；

  3. NoExecute: 不会把pod调度到该污点的node上，同时也会将node上已存在的pod驱离；

使用kubectl设置和去除污点的命令如下：

设置污点

kubectl taint nodes node4 key=value:effect

示例

kubectl taint nodes node4 tag=pns:PreferNoSchedule

去除污点

kubectl taint nodes node4 key:effect-

示例

kubectl taint nodes node4 tag:NoSchedule-

去除所有污点

kube ctl taint nodes node4 key-

提示：

使用kubeadm搭建集群，默认会给master节点添加一个污点，所以pod不会调度到master节点，Taints: node-role.kubernetes.io/master:NoSchedule

容忍（Toleration）

在node上添加污点可以用于拒绝pod调度上来，但是如果就是想将一个pod调度到一个有污点的node上，可以使用容忍。

污点是拒绝，容忍是忽略

apiVersion: v1
kind: Pod
metadata:
  name: pod-nginx-toleration
  namespace: dev
spec:
  containers:
    - name: nginx
      image: nginx:1.18.0
    tolerations: # 添加容忍
      - key: "tag" # 要容忍的污点key
        operation: "Equal" # 操作符；支持Equal和Exists(默认，即存在这个tag即可)
        value: "to" # 容忍污点的value
        effect: "NoExecute" # 添加容忍的规则，这里必须和标记污点规则相同，即匹配tag=to:NoExecute
        tolerationSeconds: 60000s # 容忍时间，当effect为NoSchedual是生效，表示pod在node上停留的时间

4.5 Label

Label的作用是在资源上添加标识，用来区分和选择资源。

Label的特点：

  • 一个Label会以key/value键值的形式附件到各种对象上，如Node, Pod, Service。

  • 一个资源对象可以定义任意数量的Label，同一个Label也可以被添加到任意数量的资源上。

  • Label通常在资源对象定义时确定，也可以在对象创建后动态的添加或删除。

    通过标签可以多维度分组，以便灵活，方便的进行资源分配、调度、配置、部署等工作。

版本标签：“version”: “release”, “version”: “stable”

环境标签：“environment”: “dev”

架构标签：“tier”: “frontend”

标签定义完毕之后，还要考虑标签的选择，使用Label Selector，即：

Label给某个资源对象定义标签

Label Selector用于查询和筛选有某些标签的资源对象

有两种Selector

  • 基本等式的Label Selector

    name = slave: 选择所有包含Label种key="name"且value="slave"的对象

  • 基于集合的Lable Selector

    name in (master, slave): 选择所有包含Label中的key="name"且value="master"或"slave"的对象

命令方式

1）给pod打标签

kubectl label pod nginx-pod version=1.0 -n dev

2）更新pod标签

kubectl label pod nginx-pod version=2.0 -n dev --overwrite

3）查看标签

kubectl get pod nginx-pod -n dev --show-labels

4）筛选标签

kubectl get pod -n dev -l version=2.0 --show-labels

5）根据标签查询pod

kubectl get pods -l “version=2.0” -n dev --show-labels

6）删除标签

kubectl label pod nginx-pod version- -n dev

4.6 Pod控制器

在Kubernetes中，Pod是最小的控制单元，但Kubernetes很少直接控制Pod，一般通过Pod控制器完成。Pod控制器用于管理Pod，确保Pod资源符合预期的状态，当Pod的资源出现故障的时候，会尝试进行重启或重建Pod。Deployment是Kubernetes众多控制器中的一种。

在Kubernetes中，按照pod的创建方式可以将其分为两类：

  1. 自助式pod：直接创建出来的pod，这种pod删除之后就没有了，不会重建；

  2. 控制器创建pod：通过控制器创建pod，这种pod删除之后还会自动重建；

控制器的类型：

  • ReplicationController: 比较原始的pod控制器，已经废弃，被ReplicaSet代替；

  • ReplicaSet: 保证指定数据量的pod运行，并支持pod数量变更，镜像版本变更；

  • Deployment: 通过控制ReplicaSet来控制pod，并支持滚动升级，版本回退；

  • Horizontal Pod Autoscaler: 可以根据集群负载自动调整pod数量，实现削峰填谷；

  • DaemonSet: 在集群中的指定Node上都运行一个副本，一般用于守护进程类的任务；

  • Job: 它创建出来的pod只要完成任务就立即退出，用于执行一次性任务；

  • Cronjob: 它创建出来的pod会周期性执行，用于执行周期性的任务；

  • StatefulSet: 关联有状态应用；

4.6.1 ReplicaSet(RS)

保证指定数据量的pod运行，它会持续监听这些pod的运行状态，一旦pod发生故障，就会重启或重建。同时它还支持对pod数据的扩缩容和版本镜像升级。

ReplicaSet的资源清单

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: pod-nginx
  namespace: dev
spec:
  replicas: 3 # 副本数量
  selector: # 选择器，指定该控制器管理哪些pod
    matchLabels: # 标签匹配规则
      app: pod-nginx
    matchExpressions: 
      - {key: app, operator: In, values: [pod-nginx]}
  template: # 模板，当副本数量不足时，会根据下面的模板来创建pod
    metadata:
      labels:
        app: pod-nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.18.0
          ports:
            - containerPort: 80

查看控制器

kubectl get rs -n dev -o wide

NAME       DESIRED   CURRENT   READY   AGE   CONTAINERS   IMAGES         SELECTOR
rs-nginx   3         3         3       68m   nginx        nginx:1.18.0   app=pod-nginx,app in (pod-nginx)

DESIRED 期望的

CURRENT 当前的

READY 准备好提供服务的

扩缩容

kubectl edit rs rs-nginx -n dev

使用以上命令编辑保存即可生效

或者使用下面命令方式

kubectl scale rs rs-nginx --replicas=6 -n dev

镜像升级

  1. 依然使用编辑命令

  2. 使用命令修改

kubectl set image rs rs-nginx nginx=nginx:1.20.2 -n dev

删除ReplicaSet

kubectl delete rs rs-nginx -n dev

在删除rs前，会将replicasclear调整为0，等待所有pod被删除后，再执行rs对象删除。

4.6.2 Deployment(deploy)

为了更好的解决服务编排问题，在Kubernetes v1.2版本，引入了Deployment，他通过ReplicaSet来间接管理pod。

  • 支持ReplicaSet所有功能

  • 支持发布停止、继续

  • 支持版本滚动升级、回退

命令格式 kubectl create deployment 名称 [参数]

参数

--image 指定pod镜像

--port    指定端口

--replicas    指定创建pod的数量

--namespace 指定命名空间

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-vGRNWuKO-1680596600520)(file://E:\OneDrive\ebook\kubernetes\Kubernetes-20230301\deployment.png?msec=1680573118481)]

Deployment通过标签关联到Pod，如上图的标签 env=dev

1）创建nginx的deployment

kubectl create deployment nginx-dep --image=nginx:1.18.0 --port=80 --replicas=2 -n dev

2）查看deployment

kubectl get deploy -n dev -o wide

3）通过配置文件创建deployment

nginx-deploy.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: pod-nginx-acc
  namespace: dev
spec:
  replicas: 3 # 副本数量
  revisionHistoryLimit: 3 # 保留历史版本，默认10
  paused: false # 暂停部署（是否创建出deployment后暂停创建pod），默认是false
  progressDeadlineSeconds: 600 # 部署超时时长()s，默认600
  strategy: # 策略
    type: RollingUpdate # 滚动更新
    rollingUpdate: # 滚动更新
      maxSurge: 30% # 最大额外可以存在的副本数，可以为百分比，也可以为整数
      maxUnavailable: 30% # 最大不可用状态的pod的最大值，可以为百分比，也可以为整数
  selector: # 选择器，通过它指定该控制器管理哪些pod
    matchLabels:
      app: nginx-acc
    matchExpressions: 
      - {key: app, operator: In, values: [nginx-acc]}
  template:
    metadata:
      labels:
        app: nginx-acc
    spec:
      containers:
        - name: nginx
          image: nginx:1.18.0
          ports:
          - containerPort: 80
            protocol: TCP

kubectl apply -f nginx-deploy.yaml

扩缩容

与replicaset的扩缩容相同

镜像策略

Deployment支持两种镜像更新策略：滚动更新（默认）和重建更新，可以通过strategy进行配置。

strategy指新的pod替换旧的pod的策略，支持两个属性：

type: 指定策略类型，可以取值RollingUpdate或Recreate

    RollingUpdate: 滚动更新，就是杀死一部分，旧启动一部分，在更新过程中存在两个版本的pod;

    Recreate: 在创建pod之前会杀掉所有已存在的pod；

    maxUnavailabel: 用来指定升级过程中不可用pod的最大数量，默认25%；

    maxSurge: 用来指定在升级过程中超过期望的pod的最大数量，默认25%；

重建更新

spec:
  strategy: # 策略
    type: Recreate

使用命令行升级镜像

kubectl set image deploy pod-nginx-acc nginx=nginx:1.22.1 -n dev

滚动更新

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%

观察镜像升级过程

kubectl get pods -n dev -w

查看rs，发现原来的rs依然存在，只是pod的数量变为0，而后又产生了一个新的rs。新的rs产生后原有rs依然保留是为了进行版本回退。

版本回退

Deployment支持版本升级过程的暂停、继续以及版本回退等诸多功能。

kubectl rollout: 支持以下选项：

  • status 显示当前升级状态

  • history 显示升级历史记录

  • pause 暂停版本升级过程

  • resume 继续版本升级过程

  • restart 重启版本升级过程

  • undo 回滚到上一个版本（可以使用–to-revision回滚到指定版本）

查看当前升级版本的状态

kubectl rollout status deploy deploy-nginx-acc -n dev

kubectl rollout status deploy deploy-nginx-acc -n dev
deployment “deploy-nginx-acc” successfully rolled out

查看升级历史记录

kubectl rollout history deploy deploy-nginx-acc -n dev

kubectl rollout history deploy deploy-nginx-acc -n dev
deployment.apps/deploy-nginx-acc
REVISION CHANGE-CAUSE
1
2

说明

CHANGE-CAUSE为空是因为在启动的时候使用如下命令

kubectl create -f deploy-nginx-acc.yaml --record=true，时其中的–record=true没有加

版本回退

kubectl rollout undo deploy deploy-ngxin-acc --to-revision=1 -n dev

金丝雀发布

Deployment支持更新过程中的控制，如暂停（pause），继续（resume）。

比如有一批新的pod资源创建完成之后立即暂停更新过程，此时仅存在一部分新版本应用，主题部分还是旧的版本。然后，再筛选一小部分的用户请求路由到新版本的pod应用，继续观察是否稳定的按期望的方式运行。确定没有问题之后再继续完成余下的pod资源滚动更新，否则立即回退更新操作。这就是所谓的金丝雀发布。

更新deployment版本，并配置暂停deployment

kubectl set image deploy deploy-nginx-acc nginx=nginx:1.22.1 -n dev && kubectl rollout pause deploy deploy-nginx-acc -n dev

观察更新状态

kubectl rollout status deploy deploy-nginx-acc -n dev

继续更新操作

kubectl rollout resume deploy deploy-nginx-acc -n dev

4.6.3 Horizonal Pod Autoscalar(HPA)

HPA控制器通过监控pod的使用情况，实现pod数量的自动调整。

HPA控制器可以获取每个pod的利用率，然后和HPA中的指标做对比，同时计算出需要伸缩的具体值，周后实现pod数量的调整。其实HPA和Deployment都属于Kubenetes的资源对象，它通过分析目标pod的负载情况，来确定是否需要针对性调整目标pod的副本数。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6Vv4te4G-1680596600521)(file://E:\OneDrive\ebook\kubernetes\Kubernetes-20230301\horizontal_pod_autoscale-1.png?msec=1680573118483)]

1）安装metrics-server

metrics-server可以用来收集集群中的资源使用情况；

下载并解压metrics-server-0.3.6

git clone -b v0.3.6 https://github.com/kubernetes-incubator/metrics-server

编辑metrics-server-deployment.yaml

cd /opt/kubernetes/metrics-server-0.3.6/deploy/1.8+
vim metrics-server-deployment.yaml

  template:
    metadata:
      name: metrics-server
      labels:
        k8s-app: metrics-server
    spec:
      hostNetwork: true # 添加 hostNetwork
      serviceAccountName: metrics-server
      volumes:
      # mount in tmp so we can safely use from-scratch images and/or read-only containers
      - name: tmp-dir
        emptyDir: {}
      containers:
      - name: metrics-server
        # 修改镜像拉取地址为阿里云
        image: registry.cn-hangzhou.aliyuncs.com/google_containers/metrics-server-amd64:v0.3.6
        imagePullPolicy: Always
        # 添加args参数
        args:
        - --kubectl-insecure-tls
        - --kubectl-preferred-address-types=InternalIP,Hostname,InternalDNS,ExternalDNS,ExternalIP
        volumeMounts:
        - name: tmp-dir
          mountPath: /tmp

执行安装

kubectl apply -f ./ # 注意，是在metrics-server-0.3.6/deploy/1.8+目录下

查看pod运行情况（实验失败 metrics-server-6555956f7b-xtxrz 没有起来，未找到原因）

kubectl get pods -n kube-system

查看node资源使用情况

kubectl top node

查看pod资源使用情况

kubectl top pod -n kube-system

2）准备deployment, service

kubectl run nginx --image=nginx:1.18.0 --requests=cpu=100m -n dev

kubectl expose deployment nginx --type=NodePort --port=80 -n dev

3）部署HPA

hpa-nginx.yaml

apiVersion: autoscaling/v1
kind: HorizonalPodAutoscaler
metadata:
  name: hpa-nginx
  namespace: dev
spec:
  minReplicas: 1 # hpa控制的最小pod数量
  maxReplicas: 10 # hpa控制的最大pod数量
  targetCPUUtilizationPercentage: 3 # CPU使用率指标，即3%
  scaleTargetRef: # 指定要控制的ngin信息
    apiVersion: apps/v1
    kind: Deployment
    name: deploy-nginx # hpa要控制的deployment名称

4）创建hpa

kubectl apply -f hpa-nginx.yaml

5）查看

6）测试

4.6.4 DaemonSet

DaemonSet类型的控制器可以保证集群中每一台（或指定）节点上都运行一个副本，一般用于日志收集，节点监控。

4.6.5 Job

TODO

4.6.6 CronJob

TODO

5 Namespace

Namespace是kubernetes系统中一种非常重要的资源，主要用来实现多套环境的资源隔离或者多租户的资源隔离

kubenetes的默认命名空间

如果删除命令空间卡主了，可以使用下面方法解决

NAMESPACE=dev
kubectl get namespace $NAMESPACE -o json > $NAMESPACE.json
sed -i -e 's/"kubernetes"//' $NAMESPACE.json
kubectl replace --raw "/api/v1/namespaces/$NAMESPACE/finalize" -f ./$NAMESPACE.json

7 Service

7.1 Service介绍

通过Deployment可以创建一组Pod，但每个Pod中的每一个容器都会分配一个IP，会存在以下问题：

  • IP会随着Pod的重建而产生变化

  • IP仅仅是集群内可见的虚拟IP，外部无法访问

因此，Kubernetes设计了Service来解决这个问题。

Service可以看作一组同类Pod对外访问的入口，借助Service，应用可以方便的实现服务的发现和负载均衡。Service相当于四层负载。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ssUitKxZ-1680596600521)(file://E:\OneDrive\ebook\kubernetes\Kubernetes-20230301\service.png?msec=1680573118678)]

Service在很多情况下只是一个概念，真正起作用的是kube-proxy服务进程，每个node节点上都运行着一个kube-proxy服务进程。当创建service时会通过api-server向etcd写入创建service的信息，而kube-proxy会基于监听机制发现这种service变动，然后将最新的service信息转换成对应的访问规则。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-SnHKsjFM-1680596600522)(file://E:\OneDrive\ebook\kubernetes\Kubernetes-20230301\kube-proxy.png?msec=1680573118489)]

10.97.97.97:80是service提供的访问入口

当访问这个入口的时候，发现后面有三个pod的服务在等待调用

kube-proxy会基于rr(轮询)的策略，将请求分发到其中一个pod上

这个规则会在集群内的所有节点上都生效，所以任何一个节点上访问都可以

kube-proxy目前支持三种工作模式

  • userspace

    在userspace模式下，kubernets会为每个service创建一个监听端口，发向Cluster IP(即：Service IP)的请求会被iptables规则重定向到kube-proxy监听的端口上，kube-proxy根据LB算法选择一个pod建立连接提供服务。

在该模式下，kube-proxy充当四层负载角色。由于kube-proxy运行在userspace中，在进行转发处理时会增加内核和用户空间直接的数据拷贝，虽然比较稳定，但效率较低；

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-5n89RwKW-1680596600522)(file://E:\OneDrive\ebook\kubernetes\Kubernetes-20230301\service-userspace.png?msec=1680573118588)]

  • iptables

    在iptables模式下，kube-proxy为service后端的每个pod创建对应的iptables规则，直接将发向Cluster IP(即：Service IP)的请求重定向到Pod IP。

该模式下kube-proxy不承担四层负载的角色，只负责创建iptables规则。该模式的优点是较userpace模型效率更高，但不能提供LB策略，当后端pod不可用时也无法进行重试。

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-cI6qL6Qk-1680596600522)(file://E:\OneDrive\ebook\kubernetes\Kubernetes-20230301\service-iptables.png?msec=1680573118595)]

  • ipvs（当前流行的模式）

    ipvs和iptables模式类似，kube-proxy监听pod的变化并创建相应的ipvs规则。ipvs相对iptables转发效率更高，支持更多LB算法。

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-oTnM8Q62-1680596600523)(file://E:\OneDrive\ebook\kubernetes\Kubernetes-20230301\service-ipvs.png?msec=1680573118591)]

    创建过程

    1）当apiserver获取到创建service的请求发送给kube-proxy；

    2）kube-proxy会根据请求生成ipvs策略；

    3）当请求从Client尽量，会根据策略负载到后端的pod；

    此模式必须安装ipvs内核模块，否则会降级为iptables。

    安装后开启ipvs

    kubectl edit cm kube-proxy -n kube-system

    把里面的mode修改为ipvs

    ipvs:
      excludeCIDRs: null
      minSyncPeriod: 0s
      scheduler: ""
      strictARP: false
      syncPeriod: 0s
      tcpFinTimeout: 0s
      tcpTimeout: 0s
      udpTimeout: 0s
    kind: KubeProxyConfiguration
    metricsBindAddress: ""
    mode: "ipvs"

    删除已存在的pod(其实是kube-proxy)并重新创建

    kubectl delete pod -l k8s-app=kube-proxy -n kube-system

    查看ipvsadm

    ipvsadm -Ln

IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn

TCP 192.168.1.111:32285 rr

TCP 10.96.0.1:443 rr

->    192.168.1.111:6443    Masq    1    0    0

TCP 10.96.0.10: 9153 rr

1）创建集群内部可以访问的Service

type为ClusterIP的Service只能在集群内部访问

暴露Service

kubectl expose deploy nginx-dep --name nginx-svc --type=ClusterIP --port=80 --target-port=80 -n dev

查看Service

kubectl get svc nginx-svc -n dev -o wide

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
nginx-svc ClusterIP 10.96.187.99 80/TCP 79s run=nginx-label

2）创建集群外部可以访问的Service

type为NodePort的Service可以在集群外部访问

kubectl expose deploy nginx-dep --name nginx-svc --type=NodePort --port=80 --target-port=80 -n dev

查看Service

kubectl get svc nginx-svc -n dev -o wide

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
nginx-svc-2 NodePort 10.101.239.1 80:30250/TCP 49s run=nginx-label

删除Service

kubectl delete svc nginx-svc -n dev

使用配置方式

nginx-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
  namespace: dev
spec:
  clusterIP: 192.168.1.11
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    run: nginx-label
  type: NodePort

7.2 Service类型

Service资源清单

apiVersion: v1
kind: Service
metadata:
  name: svc-nginx
  namespace: dev
spec:
  clusterIP: 10.96.0.11 # 虚拟服务的IP地址
  sessionAffinity: None # session亲和性(类似iphash负载)，支持ClientIP, None两个选项
  type: NodePort # Service的类型：ClusterIP, NodePort, LoadBalancer, ExternalName
  ports: # 端口信息
  - port: 80 # service端口
    targetPort: 80 # pod端口
    nodePort: 31122 # 主机端口
    protocol: TCP
  selector: # 标签选择器，用于确定当前service代理哪些pod
    run: nginx-acc

service的类型(type)

  • ClusterIP: 默认值，Kubernetes自动分配的虚拟IP，只能在集群内访问；

  • NodePort: 将Service通过指定Node上的端口暴露给外部，通过此方法，就可以在集群外部访问服务；

  • LoadBalancer: 使用外接负载均衡器完成到服务的负载均衡，注意此模式需要外部云环境支持；

  • ExternalName: 把集群外部的服务引入集群内部，直接使用；

7.2.1 ClusterIP类型

apiVersion: v1
kind: Service
metadata:
  name: svc-nginx-acc
  namespace: dev
spec:
  selector:
    app: nginx-acc
  clusterIP: 10.96.0.11 # 如果不写会自动生成一个
  type: ClusterIP
  ports:
  -  port: 80 # service端口
     targetPort: 80 # pod端口

查看

[root@node1 service]# kubectl get svc -n dev -o wide
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
svc-nginx-acc ClusterIP 10.96.0.11 80/TCP 37s app=nginx-acc

查看service的描述

Name: svc-nginx-acc
Namespace: dev
Labels:
Annotations:
Selector: app=nginx-acc
Type: ClusterIP
IP Families:
IP: 10.96.0.11
IPs: 10.96.0.11
Port: 80/TCP
TargetPort: 80/TCP
Endpoints: 172.16.0.33:80,172.16.0.34:80,172.16.0.36:80
Session Affinity: None
Events:

Endpoint:

Endpoint是kubernetes中的一个资源对象，存储在etcd中，用来记录一个service对应所有pod的访问地址，它是根据service配置文件中selector描述产生的。

一个Service对应一组Pod，这些Pod通过Endpoints暴露出来，Endpoints是实现实际服务的端点集合。换句话说service和pod之间的联系是通过endpoints实现的。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-cpGmxasg-1680596600523)(file://E:\OneDrive\ebook\kubernetes\Kubernetes-20230301\service-endpoint.png?msec=1680573118599)]

负载分发策略

对Service的访问被分发到后端Pod上去，目前kubernetes提供两种负载策略：

  • 如果不定义，默认使用kube-proxy策略，如随机，轮询；

  • 如果需要客户端地址保持，可以使用sessionAffinity: ClientIP选项；

7.2.2 HeadLiness类型

在某些场景，开发人员不想使用Service提供的负载均衡功能，希望自己来控制负载均衡策略，针对这种情况，kubernetes提供了HeadLiness Service。这类Service不会分配ClusterIP，如果想要访问service，只能通过service域名进行查询。

apiVersion: v1
kind: Service
metadata:
  name: svc-nginx-acc-2
  namespace: dev
spec:
  selector:
    app: nginx-acc
  clusterIP: None # 将clusterIP设置None，即可创建headliness类型的service 
  type: ClusterIP 
  ports:
  -  port: 80 # service端口
     targetPort: 80 # pod端口

查看

[root@node1 service]# kubectl get svc -n dev
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
svc-nginx-acc ClusterIP None 80/TCP 8s

查看域名解析情况

先进入到一个pod

kubectl exec -it deploy-nginx-acc-5c7c9ccff-5ksg4 -n dev /bin/bash

再查看域名解析

cat /etc/resolv.conf

nameserver 10.96.0.10
search dev.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

可以看到域名解析服务器是 10.96.0.10

访问（实验无法访问）

dig @10.96.0.10 svc-nginx-acc-2.dev.svc.cluster.local

7.2.3 NodePort类型

如果希望将Service暴露给集群外部访问，就使用NodPort类型的Service。工作原理是将Servie的端口映射到Node上的一个端口，然后可以通过NodeIP:NodePort来访访问。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0qsXgEav-1680596600524)(file://E:\OneDrive\ebook\kubernetes\Kubernetes-20230301\service-nodetype.png?msec=1680573118487)]

service nodetype 示例

apiVersion: v1
kind: Service
metadata:
  name: svc-nginx-acc-3 
  namespace: dev
spec:
  clusterIP: 10.96.0.13 
  ports:
  - port: 80 # service 端口
    targetPort: 80 # pod端口
    nodePort: 30000 # 指定绑定到node上的端口（默认的取值范围：30000~32767），如果不指定，会默认分配
  selector:
    run: nginx-acc
  type: NodePort

7.2.4 LoadBalancer类型

LoadBalancer类型和NodePort类型相似，目的都是向外部暴露一个端口区别于LoadBalancer会在集群外部再来做一个负载均衡，而这个需要外部支持，外部服务发送到这个外部负载的请求，会被转发到集群中去。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-T9CMGkeB-1680596600524)(file://E:\OneDrive\ebook\kubernetes\Kubernetes-20230301\service-loadbalancer.png?msec=1680573118602)]

7.2.5 ExternalName类型

ExternalName类型的Service用于引入集群外部的服务，它通过externalName属性指定外部一个服务的地址，然后在集群内访问此Service就可以访问到外部服务了。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-UBf5uJuI-1680596600524)(file://E:\OneDrive\ebook\kubernetes\Kubernetes-20230301\service-externalname.png?msec=1680573118483)]

apiVersion: v1
kind: Service
metadata:
  name: svc-externalname
  namespace: dev
spec:
  type: ExternalName # service类型
  externalName: www.baidu.com # 外部地址

域名解析

dig @10.96.0.10 svc-externalname.dev.svc.cluster.local

8 Ingress介绍

Service对集群之外暴露服务的主要方式有两种：NodePort和LoadBalancer，但这两种有一定的缺陷：

  • NodePort方式会占用很多集群机器的端口，当集群服务很多时，这种缺点愈发明显；

  • LoadBalancer的缺点是每个Service需要一个LB，浪费、麻烦，并且需要Kubernetes之外的设备支持。

基于这种现状，kubernetes提供Ingress资源对象，Ingress只需要一个NodePort或者一个LB就可以满足暴露多个Service的需求。工作机制大概如下：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NCNFQW2i-1680596600525)(file://E:\OneDrive\ebook\kubernetes\Kubernetes-20230301\ingress.png?msec=1680573118758)]

实际上，Ingress相当于一个7层负载均衡器，是kubernetes对反向代理的一个抽象，它的工作原理类似Nginx，可以理解成在Ingress里建立诸多映射，Ingress Controller通过监听这些配置规则并转换成Nginx的配置，然后对外提供服务。这里有两个概念：

1）ingress：kubernetes中的一个资源对象，作用是定义请求如何转发到service的规则；

2）ingress controller：具体实现反向代理以及负载均衡的程序，对ingress定义的规则进行解析，根据配置的规则来实现请求转发，实现方式有很多，如Nginx, Haproxy, Contour等；

Ingress（以Nginx为例）的工作原理：

1）用户编写Ingress规则，说明哪个域名对应kubernetes集群中的哪个Service；

2）Ingress控制器动态感知Ingress服务规则变化，然后生成一段对应的的Nginx配置；

3）Ingress控制器会将生成的Nginx配置写入一个运行着Nginx的服务中，并动态更新；

4）到此为止，其实真正工作的就是一个Nginx，内部配置了用户定义的请求转发规则；

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-lmurQqeB-1680596600525)(file://E:\OneDrive\ebook\kubernetes\Kubernetes-20230301\ingress-process.png?msec=1680573118813)]

8.1 Ingress使用

8.1.1 环境准备

搭建ingress环境(未完成)

有三种方式可以安装Ingress + Nginx

  • 通过Helm安装

  • 通过kubectl apply安装

  • 通过插件安装

1）通过kubectl

登录Github，搜索ingress-nginx，可以搜索到kubernetes/ingress-nginx，查看其支持的kubernetes版本。

下载deploy.yaml

https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.1.1/deploy/static/provider/cloud/deploy.yaml

如果使用kubectl apply -f deploy.yaml直接安装会碰到拉取下面两个镜像

registry.k8s.io/ingress-nginx/kube-webhook-certgen:v1.1.1

registry.k8s.io/ingress-nginx/controller:v1.2.0

失败问题，需要自己单独下载

docker pull liangjw/kube-webhook-certgen:v1.1.1
docker pull bitnami/nginx-ingress-controller:1.2.0

修改deploy.yaml

  • 注释掉 externalTrafficPolicy: Local

  • 修改controller/deploy/的image

      image: bitnami/nginx-ingress-controller:1.2.0

  • 修改ingress-nginx-admission-create的image

      image: liangjw/kube-webhook-certgen:v1.1.1

  • 修改ingress-nginx-admission-patch的image

      image: liangjw/kube-webhook-certgen:v1.1.1

  • 修改deploy.yaml种Service的类型LoadBalancer为NodePort

apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/component: controller
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
    app.kubernetes.io/version: 1.1.1
  name: ingress-nginx-controller
  namespace: ingress-nginx
spec:
  #externalTrafficPolicy: Local
  ports:
  - appProtocol: http
    name: http
    port: 80
    protocol: TCP
    targetPort: http
    nodePort: 30080 # nodePort端口修改为30080
  - appProtocol: https
    name: https
    port: 443
    protocol: TCP
    targetPort: https
    nodePort: 30443 # nodePort端口修改为300443 
  selector:
    app.kubernetes.io/component: controller
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/name: ingress-nginx
  type: NodePort # 类型修改为NodePort

执行

kubectl apply -f deploy.yaml

查看pod

kubectl get pods -n ingress-nginx

查看Service

kubectl get svc -n ingress-nginx -o wide
# 结果如下
NAME                                 TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
ingress-nginx-controller             LoadBalancer   10.106.143.19   <pending>     80:31177/TCP,443:32501/TCP   47h
ingress-nginx-controller-admission   ClusterIP      10.110.36.165   <none>        443/TCP                      47h

8.1.2 创建ingress

1）准备3个nginx pod和3个tomcat pod

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deploy-nginx
  namespace: dev
spec:
  replicas: 3
  selector:
    matchLabels:
      app: pod-nginx
  template:
    metadata:
      labels:
        app: pod-nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.18.0
        ports:
        - containerPort: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deploy-tomcat
  namespace: dev
spec:
  replicas: 3
  selector:
    matchLabels:
      app: pod-tomcat
  template:
    metadata:
      labels:
        app: pod-tomcat
    spec:
      containers:
      - name: tomcat 
        image: tomcat:8.5-jre10-slim
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: svc-nginx
  namespace: dev
spec:
  selector:
    app: pod-nginx
  clusterIP: None
  type: ClusterIP
  ports:
  - port: 80
    targetPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: svc-tomcat
  namespace: dev
spec:
  selector:
    app: pod-tomcat
  clusterIP: None
  type: ClusterIP
  ports:
  - port: 8080
    targetPort: 8080

2）创建ing-nginx-tomcat.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ing-nginx
  namespace: dev
spec:
  rules:
  - host: mynginx.alisls.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: svc-nginx
            port: 
              number: 80
  - host: mytomcat.alisls.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: svc-tomcat
            port: 
              number: 8080

如果创建ingress出现如下错误：

Internal error occurred: failed calling webhook “validate.nginx.ingress.kubernetes.io”: Post “https://ingress-nginx-controller-admission.ingress-nginx.svc:443/networking/v1/ingresses?timeout=10s”: dial tcp 10.102.20.133:443: connect: connection refused

先查询 ValidatingWebhookConfiguration

kubectl get ValidatingWebhookConfiguration
# 结果如下
NAME                        WEBHOOKS        AGE
ingress-nginx-admission        1             5m

再将其删除

kubectl delete -A ValidatingWebhookConfiguration ingress-nginx-admission

查看ingress

kubectl get ing ingress-http -n dev
# 结果
NAME            HOSTS                                    ADRESS        PORTS        AGE
ingress-http    mynginx.alisls.com,mytomcat.alisls.com                 80           15s

查看详细ingress

kubectl describe ing ingress-http -n dev

访问（在hosts中配置域名）

192.168.1.111 mynginx.alisls.com

192.168.1.111 mytomcat.alisls.com

在浏览器里输入

http://mynginx.alisls.com:30080 # 注意：端口是ingress-nginx的端口

9. 数据存储

为了持久化容器数据，kubernetes引入了volume的概念。

Volume是Pod中能够被多个容器共享访问的目录，它定义在Pod之上，然后被一个Pod里的多个容器挂载到具体的目录下，Kubernetes通过Volume实现同一个Pod中不同容器之间共享数据以及数据持久化存储。

Volume的生命周期不与Pod中单个容器的生命周期相关，当容器终止或启动时，Volume中的数据也不会丢失。

Kubernetes的Volume支持多种类型：

  • 基本存储：EmptyDir, HostPath, NFS

  • 高级存储：PV, PVC

  • 配置存储：ConfigMap, Secret

9.1 基本存储

9.1.1 EmptyDir

EmptyDir是最基础的Volume类型，一个EmptyDir就是Host上的一个空目录。

EmptyDir是Pod分配到Node时创建，它的初始内容为空，并且无需指定宿主机上对应的目录，因为Kubernetes会自动分配一个目录，当Pod销毁时，EmptyDir的数据也会被永久删除。

EmptyDir的用途：

  • 临时空间，某些应用程序运行时所需要的临时目录，且无需永久保存；

  • 一个容器需要从另外一个容器中获取数据目录

示例1

在一个pod中准备两个容器nginx和busibox，生命一个volume分别挂载到两个容器的目录中，nginx容器负责向volume中写数据，busibox负责从volume中读数据到控制台；

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ykvxSS20-1680596600526)(file://E:\OneDrive\ebook\kubernetes\Kubernetes-20230301\volume-emptydir.png?msec=1680573118603)]

apiVersion: v1
kind: Pod
metadata:
  name: pod-nginx-busibox
  namespace: dev
spec:
  containers:
  - name: nginx
    image: nginx:1.18.0
    ports:
    - containerPort: 80
    volumeMounts:
    - name: logs-volume # 所挂载volume的名称
      mountPath: /var/log/nginx # 容器路径
  - name: busibox
    image: busibox:1.30
    ports:
    - containerPort: 81
    volumeMounts:
    - name: logs-volume # 所挂载volume的名称
      mountPath: /logs # 容器路径
    command: ["/bin/bash", "-c", "tail -f /logs/access.log"] # 初始命令，动态读取指定文件内容
  volumes: # 声明volume
  - name: logs-volume
    emptyDir: {} # 存储卷的类型

查看指定容器标准输出

kubectl logs -f volume-nginx-busibox -n dev -c busibox

9.1.2 HostPath

HostPath是将node中一个实际的目录挂载到pod中，以供pod使用，这样当pod销毁时数据依然保存在node目录中。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bsGaf1vA-1680596600526)(file://E:\OneDrive\ebook\kubernetes\Kubernetes-20230301\volume-hostpath.png?msec=1680573118605)]

apiVersion: v1
kind: Pod
metadata:
  name: pod-nginx-volume-hostpath
  namespace: dev
spec:
  containers:
  - name: nginx
    image: nginx:1.18.0
    ports:
    - containerPort: 80
    volumeMounts:
    - name: logs-volume # 所挂载volume的名称
      mountPath: /var/log/nginx # 容器路径
    - name: html-volume
      mountPath: /usr/share/nginx/html
  volumes: # 声明volume
  - name: logs-volume
    hostPath:
      path: /opt/kubernetes/volume/nginx/log
      type: DirectoryOrCreate # 目录存在就使用，不存在就创建
  - name: html-volume
    hostPath:
      path: /opt/kubernetes/volume/nginx/html

type取值：

  • DirectoryOrCreate 目录存在就使用，不存在就先创建后使用

  • Directory 目标必须先存在

  • FileOrCreate 文件存在就使用，不存在就先创建后使用

  • File 文件必须实现存在

  • Socket unix套接字必须存在

  • CharDevice 字符设备必须存在

  • BlockDevice 块设备必须存在

创建pod后查看其所调度的的node

[root@node1 volume]# kubectl get pods -n dev -o wide
NAME                        READY   STATUS    RESTARTS   AGE   IP            NODE    NOMINATED NODE   READINESS GATES
pod-nginx-volume-hostpath   1/1     Running   0          3s    172.16.0.43   node4   <none>           <none>

该pod调度到node4上，查看node4对应目录如下：

[root@node4 log]# pwd
/opt/kubernetes/volume/nginx/log
[root@node4 log]# ll
total 4
-rw-r–r-- 1 root root 0 Mar 22 16:07 access.log
-rw-r–r-- 1 root root 2040 Mar 22 16:03 error.log

9.1.3 NFS

HostPath可以解决数据持久化问题，但当一个Node节点故障，Pod转移到其它节点，其它不能共享之前Node中HostPath目录中的数据，又会出现问题，此时需要准备网络存储系统，比如常见的NFS, CIFS。

NFS是一个网络存储系统，可以搭建一个NFS服务器，然后将Pod中的存储直接连接到NFS系统，这样的化，无论Pod在节点上如何转移，只要Node跟NFS没有问题，数据据可以成功访问。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-z9pMSzeg-1680596600527)(file://E:\OneDrive\ebook\kubernetes\Kubernetes-20230301\volume-nfs.png?msec=1680573118598)]

安装NFS服务器

1）为了简单，只在master节点创建nfs服务器

yum install nfs-utils -y

2）准备一个共享目录

mkdir -p /opt/kubernetes/volume/data/nfs -pv

3）将共享目录以读写权限暴露给192.168.1.0/24网段中的所有主机

vim /etc/exports
/opt/kubernetes/volume/data/nfs    192.168.1.0/24(rw,no_root_squash)

4）启动nfs服务

systemctl start nfs

5）在两个node节点(node4, node5)上也安装nfs

yum install nfs-utils -y

安装完之后注意不需要启动，这样的目的是为了node节点可以驱动nfs设备

示例

apiVersion: v1
kind: Pod
metadata:
  name: pod-nginx-volume-nfs
  namespace: dev
spec:
  containers:
  - name: nginx
    image: nginx:1.18.0
    ports:
    - containerPort: 80
    volumeMounts:
    - name: logs-volume # 所挂载volume的名称
      mountPath: /var/log/nginx # 容器路径
  volumes: # 声明volume
  - name: logs-volume
    nfs:
      server: 192.168.1.111 # nfs服务器地址
      path: /opt/kubernetes/volume/data/nfs # 共享文件路径

9.2 高级存储

由于kubernetes支持的存储系统很多，为了屏蔽不同存储系统的底层实现，引入了pv, pvc两种资源对象。

PV(Persistence Volume) 是持久化卷的意思，是对底层的共享存储的一种抽象。一般情况下PV由kubernetes管理进行创建和配置，它与底层具体的共享存储技术有关，并通过插件完成与共享存储的对接。

PVC(Persistence Volume Claim)是存储卷声明的意思，是用户对存储需求的一种声明。换句话说，PVC其实就是用户向Kubernetes系统发出的一种资源需求申请。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QnG9oBwv-1680596600527)(file://E:\OneDrive\ebook\kubernetes\Kubernetes-20230301\pvc&pv.png?msec=1680573118686)]

使用了PV和PVC之后，工作可以进一步细分：

  • 存储：存储工程师维护

  • PV：kubernetes管理员维护

  • PVC：kubernetes用户维护

9.2.1 pv

PV是存储资源的抽象，资源清单如下：

apiVersion: v1
kind: PersistenceVolume
metadata:
  name: pv
spec:
  nfs: # 存储类型，与底层真正存储对应
  capacity: # 存储能力，目前只支持存储空间设置
    storage: 2Gi
  accessModes: # 访问模式
  storageClassName: # 存储类别
  persistenceVolumeReclaimPolicy: # 回收策略

PV的关键配置参数说明：

  • 存储类型

    底层实际存储的类型，kubernetes支持多种存储类型，每种存储类型的配置都有所差异；

  • 存储能力（capacity）

    目前只支持存储空间的设置（storage=1Gi），不过未来可能加入IOPS，吞吐量等指标；

  • 访问模式（accesModes）

    用于描述用户对存储资源的访问权限，访问权限包括

    • ReadWriteOnce（RWO）：读写权限，但只能被单个节点挂载；

    • ReadOnlyMany（ROX）：只读权限，可以被多个节点挂载；

    • ReadWriteMany（RWX）：读写权限，可以被多个节点挂载；

      `需要注意的是，底层不同的存储类型可能支持的访问模式不同`

  • 回收策略（persistentVolumeReclaimPolicy）

    当PV不再被使用后，对其处理的方式：

    • Retain（保留）保留数据，需要管理员手工清理数据；

    • Recycle（回收）清除PV中的数据，相当于执行rm -rf /thevolume/*；

    • Delete（删除）与PV相连的后端存储完成Volume的删除操作，这是常见于云服务商的存储服务；

  • 存储类别

    PV可以通过storageClassName参数指定一个存储类别

    • 具有特定类别的PV只能与请求了该类别的PV进行绑定；

    • 未设定类别的PV则只能与不请求任何类别的PV进行绑定；

  • 状态（status）

    一个PV的生命周期中，可能会处于4中不同的阶段：

    • Availabel（可用）：表示可用状态，还未被任何PVC绑定；

    • Bound（已绑定）：表示PV已经被PVC绑定；

    • Released（已释放）：表示PV被删除，但是资源还未被

    • Failed（失败）：表示该PV的自动回收失败；

示例

使用NFS做为存储，创建3个PV，对应NFS中的3个暴露路径

1）NFS环境准备

# 创建目录
mkdir -p /opt/kubernetes/volume/data/{pv1,pv2,pv3} -pv
# 暴露服务
vim /ect/exports
/opt/kubernetes/volume/data/pv1 192.168.1.0/24(rw,no_root_squash)
/opt/kubernetes/volume/data/pv2 192.168.1.0/24(rw,no_root_squash)
/opt/kubernetes/volume/data/pv3 192.168.1.0/24(rw,no_root_squash)
# 重启服务
systemctl restart nfs

2）创建volume-pv.yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv1
spec:
  capacity:
    storage: 1Gi
  accessModes:
  - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  nfs:
    path: /opt/kubernetes/volume/data/pv1
    server: 192.168.1.111
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv2
spec:
  capacity:
    storage: 1Gi
  accessModes:
  - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  nfs:
    path: /opt/kubernetes/volume/data/pv2
    server: 192.168.1.111
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv3
spec:
  capacity:
    storage: 1Gi
  accessModes:
  - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  nfs:
    path: /opt/kubernetes/volume/data/pv3
    server: 192.168.1.111

创建PV

kubectl create -f volume-pv.yaml

查看PV

kubectl get pv -o wide
# 结果如下
NAME   CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE   VOLUMEMODE
pv1    1Gi        RWX            Retain           Available                                   74s   Filesystem
pv2    1Gi        RWX            Retain           Available                                   74s   Filesystem
pv3    1Gi        RWX            Retain           Available                                   74s   Filesystem

9.2.2 pvc

PVC就是对资源的申请，用来声明对存储空间，访问模式，存储类别需求信息。

资源清单

apiVersion: v1
kind: PersistentVolumnClaim
metadata:
  name: pvc1
  namespace: dev
spec:
  accessModes: # 访问模式
  selector: # 采用标签对PV选择
  storageClassName: # 存储类别
  resources: # 请求空间
    requests:
      storage: 5Gi

PVC的关键配置参数说明：

  • 访问模式（accessModes）

    用于描述用户应用对存储资源的访问权限；

  • 选择条件（selector）

    通过Label Selector的设置，可使PVC对系统中已存在的PV进行筛选；

  • 存储类别（storageClassName）

    PVC在定义时可用设定后端存储的类别，只有设置了该class的pv才能被系统选出；

  • 资源请求（Resources）

    描述对存储资源的请求

示例

1）创建volume-pvc.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc1
  namespace: dev
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 1Gi
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc2
  namespace: dev
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 1Gi
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc3
  namespace: dev
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 1Gi

kubectl create -f volume-pvc.yaml 
# 结果如下
persistentvolumeclaim/pvc1 created
persistentvolumeclaim/pvc2 created
persistentvolumeclaim/pvc3 created

查看pvc

kubectl get pvc -n dev -o wide
# 结果如下
NAME   STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE    VOLUMEMODE
pvc1   Bound    pv1      1Gi        RWX                           2m1s   Filesystem
pvc2   Bound    pv2      1Gi        RWX                           2m1s   Filesystem
pvc3   Bound    pv3      1Gi        RWX                           2m1s   Filesystem

2）创建pods使用pvc

apiVersion: v1
kind: Pod
metadata:
  name: pod-nginx-pvc1
  namespace: dev
spec:
  containers:
  - name: nginx
    image: nginx:1.18.0
    volumeMounts:
    - name: volume
      mountPath: /var/log/nginx
  volumes:
  - name: volume
    persistentVolumeClaim:
      claimName: pvc1
      readOnly: false # 对空间可读可写
---
apiVersion: v1
kind: Pod
metadata:
  name: pod-nginx-pvc2
  namespace: dev
spec:
  containers:
  - name: nginx
    image: nginx:1.18.0
    volumeMounts:
    - name: volume
      mountPath: /var/log/nginx
  volumes:
  - name: volume
    persistentVolumeClaim:
      claimName: pvc2
      readOnly: false # 对空间可读可写

kubectl create -f pod-nginx-pvc.yaml

9.3 配置存储

9.3.1 ConfigMap

TODO

9.3.2 Secret

Secret主要用于存储敏感信息，例如密码，密钥，证书等；

1）首先使用base64对数据进行编码

echo -n 'admin' | base64 # 用户名
echo -n '123456' | base64 # 密码

2）编写secret.yaml，并创建Secret

apiVersion: v1
kind: Secret
metadata:
  name: secret
  namespace: dev
type: Opaque
data:
  username: YWRtaW4=
  password: MTIzNDU2

创建secret

kubectl create -f secret.yaml

3）创建pod，挂载secret

apiVersion: v1
kind: Pod
metadata:
  name: pod-secret
  namespace: dev
spec:
  containers:
  - name: nginx
    image: nginx:1.18.0
    volumeMounts:
    - name: config
      mountPath: /secret/config
  volumes:
  - name: config
    secret:
      secretName: secret

进入容器，查看secret信息，其已经解码

kubectl exec -it pod-secret /bin/sh -n dev
ls /secret/config
# 结果显示
password  username
# 再查看 password和username
more /secret/config/username
# 结果显示
admin

10. 安全认证

对Kubernetes的各种客户端进行认证和鉴权操作。

客户端

在kubernetes集群种，有两种类型：

  • User Account: 一般是独立于kubernetes之外其他服务管理的用户账号；

  • Service Account: kubernetes管理的账号，用于为Pod中的服务进程在访问Kubernetes时提供身份标识；

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hoRuuq9c-1680596600528)(file://E:\OneDrive\ebook\kubernetes\Kubernetes-20230301\account-type.png?msec=1680573118690)]

认证、授权、准入控制

ApiServer是访问以及管理资源对象的唯一入口，任何一个请求访问ApiServer，都需要经过下面三个流程：

1）Authentication（认证）：身份鉴别，只有正确的账号才能通过认证；

2）Authorization（授权）：判断用户是否有权限对访问的资源执行特定的操作；

3）Admission Control（准入控制）：用于补充授权机制以实现更加精细的的访问控制；

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-OGcDrXng-1680596600528)(file://E:\OneDrive\ebook\kubernetes\Kubernetes-20230301\authentication-flow.png?msec=1680573118604)]

10.1 认证管理

Kubenetes集群安全的最关键点在于如何识别客户端身份，它提供了3种客户端身份认证方式：

1）HTTP Base认证：通过用户名 + 密码的方式认证

这种认证方式是把“用户名:密码”用BASE64算法进行编码后的字符串放在HTTP请求的Header Authorization域发给服务端。服务端收到后进行解密，获取用户名和密码，然后进行身份认证。

2）HTTP Token认证：通过一个Token来识别合法用户

这种方式是一个一个很长的字符串（Token）来表明客户身份的一种方式。每个Token对应一个用户名，当客户端发起API调用请求时，要在HTTP的请求Header里放入Token，API Server接收到Token后会跟服务器中保留的token进行比对，然后进行用户身份认证的过程。

3）HTTPS证书认证：基于CA根证书签名的双向数字证书认证方式

`这种方式是安全性最高的一种方式，但同时也是操作起来最麻烦的一种方式`

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-oA5UfmYa-1680596600529)(file://E:\OneDrive\ebook\kubernetes\Kubernetes-20230301\authentication-https.png?msec=1680573118688)]

HTTPS认证大体分为3个过程：

1）证书申请和下发

HTTPS通信双方的服务器向CA机构申请证书，CA机构下发根证书、服务端证书以及私钥给申请者；

2）客户端和服务端双向认证

a.客户端向服务器端发起请求，服务器端下发自己的证书给客户端；

 客户端接收到证书后，通过私钥解密证书，在证书中获得服务端的公钥

    客户端利用服务器端的公钥认证证书中的信息，如果一致，则认可这个服务器

b.客户端发起自己的证书给服务端，服务端接收到证书后，通过私钥解密证书，

    在证书中获得客户端的公钥，并用公钥认证证书信息，确认客户端是否合法

3）服务端和客户端进行通信

服务器端和客户端协商好加密方案后，客户端会产生一个随机的密钥加密，然后发送到服务端，服务端接收到这个密钥后，双方接下来通信的所有内容都通过该随机密钥加密；

Kubernetes运行同时配置多种认证方式，只要其中任意一个方式认证通过即可

10.2 授权管理

授权发生在认证之后，通过认证就可以知道访问得用户是谁，然后Kubernetes会根据事先定义的授权策略来决定用户是否有权限访问，这个过程称为授权。

每个发送到ApiServer的请求都带上了用户和资源信息：比如发送请求的用户、请求的路径、请求的动作等，授权就是根据这些信息和授权策略进行比较，如果符合策略，则认为授权通过，否则返回失败；

ApiServer目前支持以下授权策略：

  • AlwaysDeny：表示拒绝所有请求，一般用于测试；

  • AlwaysAllow：允许接收所有请求，相当于集群不需要授权流程（Kubernetes默认的策略）

  • ABAC：基于属性的访问控制，表示使用用户配置的授权规则对用户请求进行匹配和控制；

  • Webhook：通过调用外部REST服务对用户进行授权；

  • Node：是一种专用模式，用于对kubelet发出请求进行访问控制；

  • RBAC：基于角色的访问控制（kubeadm安装方式下默认的选项）

RBAC（Role-Based Access Control）基于角色的访问控制，主要在描述一件事：给哪些角色授予了哪些权限，涉及到以下几个概念：

  • 用户：User, Groups, ServiceAccount；

  • 角色：代表着一组定义在资源上可操作的权限集合；

  • 绑定：将定义好的角色和用户绑定在一起；

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-cYEgoyNA-1680596600529)(file://E:\OneDrive\ebook\kubernetes\Kubernetes-20230301\authorization-rbac.png?msec=1680573118688)]

Kubernetes的RBAC授权引入了4个顶级资源对象：

  • Role，ClusterRole：角色，用于指定一组权限；

  • RoleBinding，ClusterRoleBinding：角色绑定，用于将角色赋予用户；

Role, RoleCluster

一个角色就是一组权限的集合，这里的权限都是许可形式的（白名单）。

# Role只能对命名空间内的资源进行授权，需要指定namespace
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
  name: role-dev-pods
  namespace: dev
rules:
- apiGroups: [""] # 支持的API组列表，""表示空字符串，表示核心API组
  resources: ["pods"] # 支持的资源对象列表
  verbs: ["get", "watch", "list"] # 允许对资源对象的操作方法列表

上面表示在dev命名空间定义了一个角色 role-dev-pods，对核心组的pods资源可以进行get, watch, list操作。

# ClusterRole可以对集群范围内资源、跨namespace的范围资源，非资源类型进行授权
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: cluster-role-pod
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

需要详细说明的是：

  • apiGroups: 支持的API组列表

    “”, “apps”, “autoscaling”, “batch”

  • resources: 支持的资源对象列表

    “services”, “endpoints”, “pods”, “secrets”, “configmaps”, “crontabs”, “deployments”, “jobs”, “nodes”, “rolebindings”, “clusterroles”, “daemonsets”, “replicasets”, “statefuls”, “horizontalpodautoscalers”, “replicationcontrollers”, “cronjobs”

  • verbs: 对资源对象的操作方法列表

    “get”, “list”, “watch”, “create”, “update”, “patch”, “delete”, “exec”

RoleBinding ClusterRoleBinding

角色绑定用来把一个角色绑定到一个目标对象上，绑定目标可以是User, Group或者ServiceAcount

# RoleBinding可以将同一namespace中subject绑定到某个Role下，则此subject即具有该Role定义的权限
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
  name: authorization-role-binding
  namespace: dev
subjects:
- kind: User
  name: mux
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: authorization-role
  apiGroup: rbac.authorization.k8s.io

上述配置表明：将用户mux绑定到角色authorization-role

# ClusterRoleBinding在整个集群级别和所有namespace将特定的subject与ClusterRole绑定，授予权限
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: authorization-clusterrole-binding
subjects:
- kind: User
  name: mux
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: authorization-clusterrole
  apiGroup: rbac.authorization.k8s.io

RoleBinding引用ClusterRole进行授权

RoleBinding可以引用ClusterRole，对属于同一命名空间内（ClusterRole）,然后再多个命名空间中重复使用这些ClusterRole。这样可以大幅提高授权管理工作效率，也使得各个命名空间下的基础授权规则和使用体验保持一致。

# 虽然authorization-clusterrolehi一个集群角色，但是因为使用了RoleBinding,
# 所以mux只能读取dev命令空间中的资源
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: authorization-role-binding-ns
  namespace: dev
subjects:
- kind: User
  name: mux
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: authorization-clusterrole
  apiGroup: rbac.authorization.k8s.io

示例：创建一个只能管理dev空间下pods资源的账号

1）创建账号

# 1）创建证书
cd /etc/kubernetes/pki/
(umask 077;openssl genrsa -out devman.key 2048)
# 2）用apiserver的证书去签署
# 2-1）签名申请，申请的用户是devman，组是devgroup
openssl req -new -key devman.key -out devman.csr -subj "/CN=devman/O=devgroup"
# 2-2）签署证书
openssl x509 -req -in devman.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out devman.crt -days 3650
# 3）设置集群、用户、上下文信息
kubectl config set-cluster kubernetes --embed-certs=true --certificate-authority=/etc/kubernetes/pki/ca.crt --server=https://192.168.1.111:6443

kubectl config set-credentials devman --embed-certs=true --client-certificate=/etc/kubernetes/pki/devman.crt --client-key=/etc/kubernetes/pki/devman.key

kubectl config set-context devman@kubernetes --cluster=kubernetes --user=devman

# 切换账号
kubectl config use-context devman@kubernetes

测试，切换到用户devman@kubernetes后，查询dev命名空间下的pod提示没有权限

kubectl get pods -n dev
# 结果如下
Error from server (Forbidden): pods is forbidden: User "devman" cannot list resource "pods" in API group "" in the namespace "dev"

切回管理员账号

kubectl config use-context kubernetes-admin@kubernetes

2）创建Role，创建RoleBinding

apiVersion: rbac.authorization.k8s.io/v1 
kind: Role
metadata:
  name: role-dev
  namespace: dev
rules:
- apiGroups: [""] # 支持的API组列表，""表示空字符串，表示核心API组
  resources: ["pods"] # 支持的资源对象列表
  verbs: ["get", "watch", "list"] # 允许对资源对象的操作方法列表

---
apiVersion: rbac.authorization.k8s.io/v1 
kind: RoleBinding
metadata:
  name: authorizaiton-role-binding
  namespace: dev
subjects:
- kind: User
  name: devman
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: role-dev
  apiGroup: rbac.authorization.k8s.io

3）为devman授权

kubectl create -f role-rolebinding.yaml

再切换到devman账号，查询dev下的pod

[root@node1 role]# kubectl config use-context devman@kubernetes
Switched to context "devman@kubernetes".
[root@node1 role]# kubectl get pods -n dev
NAME                            READY   STATUS    RESTARTS   AGE
deploy-myapp-754f5c8b88-4hjqp   1/1     Running   1          19h
deploy-myweb-67ffff5c49-f6qgg   1/1     Running   1          19h

10.3 准入控制

通过前面的认证和授权之后，还需要经过准入控制通过之后，apiserver才会处理这个请求。

准入控制一个可配置的控制器列表，可以通过在Api-Server上通过命令行设置选择进入执行哪些准入控制器；

--admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,DefaultStorageClass,ResourceQuota,DefaultTolerationSeconds

只有当所有准入控制器都检查通过后，apiserver才执行该请求，否则返回拒绝。

当前可配置的Admission Control准入控制如下：

  • AlwaysAdmit: 允许所有请求

  • AlwaysDeny: 禁止所有请求，一般用于测试

  • AlwaysPullImages: 在启动容器之前总是去下载镜像

  • DenyExecOnPrivileged: 它会拦截所有想在Privileged Container上执行命令的请求

  • ImagePolicyWebHook: 这个插件将允许后端的一个Webhook程序来完成admission controller的功能。

  • Service Account：实现ServiceAccount实现了自动化；

  • SecurityContextDeny: 这个插件将使用SecurityContext的Pod中定义全部失效；

  • ResourceQuota：用于资源配额管理，观察所有请求，确保在namespace上配额不会超标；

  • LimitRanger: 用于资源限制管理，作用于namespace上，确保对Pod进行资源限制；

  • InitalResources：为设置资源请求与限制Pod，根据其镜像的历史资源的使用情况进行设置；

  • NamespaceLifecycle：如果尝试在一个不存在的namespace中创建资源对象，则该创建请求将被拒绝，

  • DefaultStorageClass: 为了实现共享存储的动态供应，为未指定StorageClass或PV的PVC尝试匹配默认的StorageClass，尽可能减少用户在申请PVC时所需了解的后端存储细节；

  • DefaultTolerationSeconds: 这个插件为那些没有设置forgiveness tolerations并具有notready:NoExecute和unreachable:NoExecute两种taints的Pod设置默认的“容忍”时间，为5min

  • PodSecurityPolicy: 这个插件用于在创建或修改Pod时决定是否根据Pod的security context和可用的

11. Helm

Helm是kubernetes一个包管理工具

# 官网
https://helm.sh/
# 下载
https://github.com/helm/helm/releases/tag/v3.1.2

11.1 安装helm

解压 helm

tar -zxvf helm-v3.1.2-linux-amd64.tar.gz
mv linux-amd64 helm-3.1.2

11.2 Helm命令

  • helm version

  • helm repolist 查看helm仓库

  • helm help

11. Dashboard

Dashboard是kubernetes基于Web界面部署容器化应用，监控应用状态，执行故障排查以及管理Kubernetes的各种资源。

11.1 部署Dashboard

下载yaml（实验无法下载）

wget https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0/aio/deploy/recommended.yaml

修改kubernetes-dashboard的service类型

apiVersion: v1
kind: Service
metadata:
  name: kubernetes-dashboard
  namespace: kubernetes-dashboard
  labels:
    k8s-app: kubernetes-dashboard
spec:
  type: NodeType
  ports:
  - port: 443
    targetPort: 443
    nodePort: 30009
  selector:
    k8s-app: kubernetes-dashboard

部署

kubectl create -f recommended.yaml

查看kubernetes-dashboard的资源

kubectl get svc,pod -n kubernetes-dashboard

创建访问账号

kubectl create serviceaccount dashboard-admin -n kubernetes-dashboard

授权

kubectl create clusterrolebinding dashboard-admin-rb --cluster-role=cluster-admin --servcieaccount=kubernetes-dashboard:dashboard-admin

获取token

kubectl get secrets -n kubernetes-dashboard | grep dashboard-admin

kubectl describe secrets dashboard-admin-token-xbqhh -n kubernetes-dashboard

访问

https://192.168.1.111:30009

12. 其它

12.1 MyWeb完整示例

# MyWeb Ingress
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ing-myweb
  namespace: dev
spec:
  rules:
  - host: myweb.alisls.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: svc-myapp
            port:
              number: 80

---

# MyWeb Service
apiVersion: v1
kind: Service
metadata:
  name: svc-myweb
  namespace: dev
spec:
  selector:
    app: myweb-1.0.0
  clusterIP: None
  type: ClusterIP  
  ports:
  - port: 80 # service 端口
    targetPort: 80 # pod端口

---

# MyWeb Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deploy-myweb
  namespace: dev
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myweb-1.0.0 
  template:
    metadata:
      labels:
        app: myweb-1.0.0 
    spec:
      containers:
      - name: myweb
        image: myweb:1.0.0 
        ports:
        - containerPort: 80
          protocol: TCP
        volumeMounts:
        - name: vol-myweb
          mountPath: /var/log/nginx
      volumes:
      - name: vol-myweb
        persistentVolumeClaim:
          claimName: pvc-myweb
          readOnly: false
      nodeName: node4

---

# MyWeb PVC
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-myweb
  namespace: dev
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 1Gi

---

# MyWeb PV
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-myweb 
spec:
  capacity:
    storage: 1Gi
  accessModes:
  - ReadWriteMany
  persistentVolumeReclaimPolicy: Recycle 
  nfs:
    path: /home/wangke/web-apps/myweb/logs  
    server: 192.168.1.111

12.2 MyApp完整示例

# MyApp Ingress
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ing-myapp
  namespace: dev
spec:
  rules:
  - host: myapp.alisls.com
    http:
      paths:
      - path: /user
        pathType: Prefix
        backend:
          service:
            name: svc-myapp
            port:
              number: 9001

---

# MyApp Service
apiVersion: v1
kind: Service
metadata:
  name: svc-myapp
  namespace: dev
spec:
  selector:
    app: myapp-1.0.0
  clusterIP: None
  type: ClusterIP  
  ports:
  - port: 9001 # service 端口
    targetPort: 9001 # pod端口
  
---

# MyApp Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deploy-myapp
  namespace: dev
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myapp-1.0.0 
  template:
    metadata:
      labels:
        app: myapp-1.0.0 
    spec:
      containers:
      - name: myapp
        image: myapp:1.0.0 
        ports:
        - containerPort: 9001 
          protocol: TCP
        volumeMounts:
        - name: vol-myapp
          mountPath: /var/log/app
      volumes:
      - name: vol-myapp
        persistentVolumeClaim:
          claimName: pvc-myapp
          readOnly: false
      nodeName: node4

---

# MyApp PVC
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-myapp
  namespace: dev
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 1Gi

---

# MyApp PV
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-myapp
spec:
  capacity:
    storage: 1Gi
  accessModes:
  - ReadWriteMany
  persistentVolumeReclaimPolicy: Recycle 
  nfs:
    path: /home/wangke/svc-apps/myapp/log  
    server: 192.168.1.111

你可能感兴趣的:(kubernetes,docker,容器)

  • helm 部署 Kube-Prometheus + Grafana + 钉钉告警部署 Kube-Prometheus zxj19880502 grafanaprometheus
    背景角色IPK8S版本容器运行时k8s-master-1172.16.16.108v1.24.1containerd://1.6.8k8s-node-1172.16.16.109v1.24.1containerd://1.6.8k8s-node-2172.16.16.110v1.24.1containerd://1.6.8安装kube-prometheusmkdir-p/data/yaml/kub
  • docker怎么端口映射 Lance_mu docker容器运维
    1、默认固定的端口#Web服务器：WebApache或Nginx通常使用80端口HTTP：80HTTPS：443#数据库服务器MySQL：3306PostgreSQL：5432MongoDB：27017Redis：6379#邮件服务器SMTP：25POP3：110IMAP：143#其他服务SSH：22FTP：21DNS（域名解析）：53代理服务器Squid：3128版本控制系统Git：9418(S
  • docker基础（一） 运维搬运工 容器-dockerdocker容器运维
    相关概念介绍Docker是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖到一个可移植的容器中，然后发布到任何流行的linux机器上，也可以实现虚拟化，容器是完全使用沙箱机制，互相之间不会有任何接口。Docker有几个重要概念：dockerfile，配置文件，用来生成dockerimagedockerimage，交付部署的最小单元docker命令与API，定义命令与接口，支持第三方系统集
  • linux安装docker及docker-compose 部署spring boot项目 时而有事儿 dockerlinuxdockerlinuxspringboot
    linux系统环境：centos5.14本篇描述的是在centos系统版本下安装docker，如果是ubuntu版本，请看这篇文章：linuxubuntu20安装docker和docker-compose-CSDN博客正文：安装docker和docker-compose安装docker---------运行命名等待安装完成遇到选择直接输入yyuminstall-yyum-utilsdevice-m
  • k8s入门到实战（十）—— CronJob详细介绍及使用示例 一弓虽 k8s学习kubernetes容器云原生
    CronJob什么是CronJob在k8s中，CronJob是一种用于定期执行任务的资源对象。它基于Cron表达式，允许您在指定的时间间隔内自动运行容器化的任务。CronJob可以定义以下属性：schedule：指定任务执行的时间表，使用标准的Cron表达式语法。例如，“0****”表示每小时执行一次任务。jobTemplate：定义要执行的任务的模板，通常是一个Pod模板。这个模板包含了任务所需
  • Qlib-Server部署 宋志辉 flaskpythonqlib量化
    Qlib-Server部署介绍构建Qlib服务器，用户可以选择：一键部署Qlib服务器逐步部署Qlib服务器一键部署Qlib服务器支持一键部署，用户可以选择以下两种方法之一进行一键部署：使用docker-compose部署在Azure中部署使用docker-compose进行一键部署按照以下步骤使用docker-compose部署Qlib服务器：安装docker，请参考Docker安装。安装doc
  • 【科学小论文】水的物质形态的三种变化 橄榄树松
    水的物质形态的三种变化张岩松众所周知，水这种物质有三个形态变化：第一个是固体，也就是冰块；第二个是液体，也就是普通的水；还有一种是气体，它存在于空气中，一般情况下是肉眼看不到的。今天，我就来给大家讲讲水的三种形态变化的原因。有人问了，水蒸气是气体还是液体？主张是气体的人说，反正名字里有一个气字，而且把水加热也有气，能从容器里面冒出来。但是主张是液体的人说气是看不见的，如果你把手对着水蒸气，你的手一
  • 了解什么是Docker 黑风风 DevOps学习dockereureka容器
    了解什么是DockerDocker是一个开源的容器化平台，它使得开发者可以将应用程序及其依赖项打包到一个轻量级的、可移植的容器中。这些容器可以在任何支持Docker的系统上运行，确保了应用程序在不同环境之间的一致性和可移植性。，同时享受隔离性和轻量级的优势。Docker的核心组件Docker引擎Docker引擎是一个客户端-服务器应用程序，包括一个长期运行的守护进程（dockerd）、一个REST
  • 部署es集群 liushaojiax elasticsearchjava大数据
    我们会在单机上利用docker容器运行多个es实例来模拟es集群。不过生产环境推荐大家每一台服务节点仅部署一个es的实例。部署es集群可以直接使用docker-compose来完成，但这要求你的Linux虚拟机至少有4G的内存空间创建es集群首先编写一个docker-compose文件，内容如下：version:'2.2'services:es01:image:elasticsearch:7.12
  • Elasticsearch8 - Docker安装Elasticsearch8.12.2 王谷雨_ ElasticSearchelasticsearchdocker
    前言最近在学习ES，所以需要在服务器上装一个单节点的ES服务器环境：centos7.9安装下载镜像目前最新版本是8.12.2dockerpulldocker.elastic.co/elasticsearch/elasticsearch:8.12.2创建配置新增配置文件elasticsearch.ymlhttp.host:0.0.0.0http.cors.enabled:truehttp.cors.
  • mineadmin使用docker启动方式 qq_38812523 dockerphp容器
    找个目录,git下来mineadmin代码,在根目录,创建文件名docker-compose.yml然后复制下面代码version:'3'services:#首先下载前端，https://gitee.com/mineadmin/mineadmin-vue#在后端根目录建立mine-ui目录，把前端文件复制过来。#容器内访问宿主机的地址用：host.docker.internal#宿主机也可以在ho
  • RabbitMQ的安装 白泽27 rabbitmq分布式
    典型应用场景：异步处理。把消息放入消息中间件中，等到需要的时候再去处理。流量削峰。例如秒杀活动，在短时间内访问量急剧增加，使用消息队列，当消息队列满了就拒绝响应，跳转到错误页面，这样就可以使得系统不会因为超负载而崩溃Linux下安装#拉取镜像dockerpullrabbitmq:3.8-management#创建容器启动dockerrun-d--restart=always-p5672:5672-
  • 今天简单聊聊容器化 第十个灵魂 dockerK8S云原生数字化转型云原生容器docker
    什么是容器化容器化（Containerization）是一种软件开发和部署的方法，其核心思想是将应用程序及其所有依赖项打包到一个独立的运行环境中，这个环境被称为容器。容器化技术使得应用程序可以在不同的计算环境中以一致的方式运行，从而提供了更高的可移植性、可靠性和可扩展性。容器化的优势可移植性:容器可以轻松地在不同的环境中运行，而无需进行任何修改。资源隔离:每个容器都拥有自己的资源，并与其他容器隔离
  • 【Docker】【nginx】docker安装nginx并映射宿主机配置文件地址 小丛的知识窝 nginxdocker运维
    dockerrun-d-p80:80-v/root/docker/docker-nginx/nginx.conf:/etc/nginx/nginx.conf-v/root/docker/docker-nginx/html:/usr/share/nginx/html-v/root/docker/docker-nginx/logs:/var/log/nginx--namenginxnginx
  • 【WPF应用4】WPF界面对象编辑 白话Learning WPFwpf
    简介WPF（WindowsPresentationFoundation）是.NET框架的一部分，它为开发人员提供了一个用于构建桌面应用程序用户界面的强大平台。WPF界面对象编辑是指在WPF应用程序中创建、设计和修改用户界面元素的过程。这些界面对象不仅包括基本的控件如按钮、文本框和标签，还包括更复杂的布局容器如面板和堆叠面板，以及自定义控件和视觉效果。WPF界面对象编辑的功能和灵活性使得它成为开发富
  • Docker(一)：Docker入门教程 蓝胖子的白日梦丶
    如今Docker的使用已经非常普遍，特别在一线互联网公司。使用Docker技术可以帮助企业快速水平扩展服务，从而到达弹性部署业务的能力。在云服务概念兴起之后，Docker的使用场景和范围进一步发展，如今在微服务架构越来越流行的情况下，微服务+Docker的完美组合，更加方便微服务架构运维部署落地。本文详细解释介绍Docker入门相关内容，后期重点关注Docker在微服务体系中的使用。在了解Dock
  • Docker 安装mysql 主从复制 dylan_2017 Docker高级dockermysql容器
    目录1MySql主从复制简介1.1主从复制的概念1.2主从复制的作用2.搭建主从复制2.1pullmysql镜像2.2新建主服务器容器实例33072.2.1master创建my.cnf2.2.2重启master2.2.3进入mysql容器，创建同步用户2.3新建从服务器容器实例33082.3.1slave创建my.cnf2.3.2重启slave实例2.3.3在master中查看主从同步状态2.3.
  • 突破编程_C++_面试（STL 编程 stack） breakthrough_01 突破编程_C++_面试c++面试
    1请简述std::stack在C++STL中的基本功能和使用场景std::stack在C++STL（标准模板库）中是一个容器适配器，专门用于实现后进先出（LIFO，Last-In-First-Out）的数据结构。其基本功能和使用场景如下：基本功能：push(element)：向栈顶添加元素。pop()：移除栈顶元素。如果栈为空，则此操作可能会导致未定义行为。top()：返回栈顶元素的引用，但不移除
  • 渔夫码头密语: 记录使用 Docker 安装 Wordpress shelby_loo docker容器运维
    最近在阿贝云的免费服务器上试水,配置虽小(1核CPU、1G内存、10G硬盘、5M带宽),但对此次任务正合适。作为国内首家提供这样不错的免费云服务器的阿贝云,给我们开源界添增不少乐子,在这里对Docker和Wordpress去搞一搞,总比呆在办公室曱甴better!今天与你分享一下如何在Ubuntu系统上使用Docker快速搭建Wordpress博客环境。Wordpress作为全球最大同类型开源内容
  • 使用 Redux 管理 React 应用状态 JudithHuang React从入门到放弃react.jsjavascript前端
    使用Redux管理React应用状态在复杂的React应用中，管理组件状态变得越来越复杂，这时候引入Redux可以帮助我们更好地管理状态。Redux是一个可预测状态容器，它可以帮助我们统一管理应用的状态，使得状态变化更加可控。本文将介绍如何在React应用中使用Redux。Redux简介Redux是一个状态管理库，它提供了一种可预测的状态管理方案。Redux的核心思想是将应用的状态存储在一个单一的
  • 高可用系统有哪些设计原则 没有女朋友的程序员 架构师架构
    1.降级主动降级：开关推送被动降级：超时降级异常降级失败率熔断保护多级降级2.限流nginx的limit模块gatewayredis+Lua业务层限流本地限流gua分布式限流sentinel3.弹性计算弹性伸缩—K8S+docker主链路压力过大的时候可以将非主链路的机器给主链路的应用用上4.流量切换多机房环境：DNS端域名切换入口Clien端流量调度虚IPHaProxyLVS负载均衡应用层Ngi
  • 使用 BPF 监控 Kubernetes 集群(k8s BPF 工具 kubectl-trace认知 山河已无恙 K8s&kubelct插件BPFkubernetes容器云原生
    写在前面学习中遇到，整理分享，博文内容涉及：kubectl-trace安装，在节点，容器中如何使用需要注意的问题：job闪完成，一直Pending状态解决理解不足小伙伴帮忙指正不必太纠结于当下，也不必太忧虑未来，当你经历过一些事情的时候，眼前的风景已经和从前不一样了。——村上春树kubectl-trace安装┌──[[email protected]]-[~/ansi
  • docker构建镜像命令 你是理想 dockerdocker容器运维
    编写dockerfile文件例子1;FROMoraclelinux:7-slimENVrelease=19ENVupdate=13RUNcurl-o/etc/yum.repos.d/public-yum-ol7.repohttps://yum.oracle.com/public-yum-ol7.repo&&\yum-config-manager--enableol7_oracle_instantc
  • docker-ce安装 蚁景网络安全 dockereureka容器
    安装docker-ce使用清华镜像源加速安装docker-ce原文：docker-ce|镜像站使用帮助|清华大学开源软件镜像站|TsinghuaOpenSourceMirror#方法一exportDOWNLOAD_URL="https://mirrors.tuna.tsinghua.edu.cn/docker-ce"#如果使用curl，执行如下命令curl-fsSLhttps://get.dock
  • Docker进阶教程 - 3 虚悬镜像 山石岐渡 Docker进阶教程docker容器运维
    更好的阅读体验：点这里（www.doubibiji.com）3虚悬镜像什么是虚悬镜像（danglingimage）？镜像名、标签都是的镜像。通常在构建的过程中，取消构建、构建出现问题的时候，会出现异常的镜像，这种镜像没有名称和标签。因此，这些镜像被称为虚悬镜像，因为它们“悬浮”在Docker中，没有被任何容器所使用，也不会被Docker清理工具删除。虚悬镜像的产生概率不高，但一旦生成，可能会对系统
  • 05. spring-boot对spring-mvc的自动配置 马晓钧
    spring-mvc的自动配置viewResolver：视图解析器：根据方法的返回值得到视图对象(View)。//会将容器中已有的ViewResolver和自己定义的ViewResolver全部add进去ContentNegotiatingViewResolver自定义视图解析器：//需要实现ViewResolver，并注入进容器@ConfigurationpublicclassViewConfi
  • Docker搭建mysql8的主从复制 优秀的颜 云原生docker
    Docker通过Docker部署Mysql主从复制，Docker安装在前篇有，直接演示：拉取镜像#获取有哪些镜像dockersearchmysql#拉取MySQL镜像dockerpullmysql:8.0.32#查看镜像dockerimages主节点的配置创建数据存储目录mkdir-p/docker/mysql/master/data创建日志目录mkdir-p/docker/mysql/maste
  • Docker 命令大全 箭头大人 docker容器运维
    Docker命令大全容器生命周期管理runstart/stop/restartkillrmpause/unpausecreateexec容器操作psinspecttopattacheventslogswaitexportportstats容器rootfs命令commitcpdiff镜像仓库loginpullpushsearch本地镜像管理imagesrmitagbuildhistorysavelo
  • docker jdk1.8+字体镜像 wcy10086 dockerjdk字体
    FROMcentos:7MAINTAINERwcy# 修改成东八区RUNln-sf/usr/share/zoneinfo/Asia/Shanghai/etc/localtime&&echo'Asia/Shanghai'>/etc/timezoneRUNyum-yinstallkde-l10n-Chinesetelnet&&\yum-yreinstallglibc-common&&\yumclean
  • docker批量删除容器或镜像 wcy10086 docker容器运维
    删除容器停止所有容器删除所有容器，需要先停止所有运行中的容器dockerstop`dockerps-a-q`dockerps-a-q，意思是列出所有容器(包括未运行的)，只显示容器编号，其中-a:显示所有的容器，包括未运行的。-q:静默模式，只显示容器编号。1.删除所有处于停止状态的容器使用以下命令删除所有处于停止状态的容器：dockercontainerprune该命令将删除所有未运行的容器，释
  • 分享100个最新免费的高匿HTTP代理IP mcj8089 代理IP代理服务器匿名代理免费代理IP最新代理IP
      推荐两个代理IP网站：   1. 全网代理IP：http://proxy.goubanjia.com/   2. 敲代码免费IP：http://ip.qiaodm.com/     120.198.243.130:80,中国/广东省 58.251.78.71:8088,中国/广东省 183.207.228.22:83,中国/
  • mysql高级特性之数据分区 annan211 java数据结构mongodb分区mysql
    mysql高级特性 1 以存储引擎的角度分析，分区表和物理表没有区别。是按照一定的规则将数据分别存储的逻辑设计。器底层是由多个物理字表组成。 2 分区的原理 分区表由多个相关的底层表实现，这些底层表也是由句柄对象表示，所以我们可以直接访问各个分区。存储引擎管理分区的各个底层 表和管理普通表一样(所有底层表都必须使用相同的存储引擎)，分区表的索引只是
  • JS采用正则表达式简单获取URL地址栏参数 chiangfai js地址栏参数获取
    GetUrlParam:function GetUrlParam(param){ var reg = new RegExp("(^|&)"+ param +"=([^&]*)(&|$)"); var r = window.location.search.substr(1).match(reg); if(r!=null
  • 怎样将数据表拷贝到powerdesigner (本地数据库表) Array_06 powerDesigner
    ================================================== 1、打开PowerDesigner12，在菜单中按照如下方式进行操作 file->Reverse Engineer->DataBase 点击后，弹出 New Physical Data Model 的对话框 2、在General选项卡中 Model name:模板名字，自
  • logbackのhelloworld 飞翔的马甲 日志logback
    一、概述 1.日志是啥？ 当我是个逗比的时候我是这么理解的：log.debug()代替了system.out.print(); 当我项目工作时，以为是一堆得.log文件。 这两天项目发布新版本，比较轻松，决定好好地研究下日志以及logback。 传送门1：日志的作用与方法： http://www.infoq.com/cn/articles/why-and-how-log 上面的作
  • 新浪微博爬虫模拟登陆 随意而生 新浪微博
    转载自：http://hi.baidu.com/erliang20088/item/251db4b040b8ce58ba0e1235     近来由于毕设需要，重新修改了新浪微博爬虫废了不少劲，希望下边的总结能够帮助后来的同学们。      现行版的模拟登陆与以前相比，最大的改动在于cookie获取时候的模拟url的请求
  • synchronized 香水浓 javathread
        Java语言的关键字，可用来给对象和方法或者代码块加锁，当它锁定一个方法或者一个代码块的时候，同一时刻最多只有一个线程执行这段代码。当两个并发线程访问同一个对象object中的这个加锁同步代码块时，一个时间内只能有一个线程得到执行。另一个线程必须等待当前线程执行完这个代码块以后才能执行该代码块。然而，当一个线程访问object的一个加锁代码块时，另一个线程仍然
  • maven 简单实用教程 AdyZhang maven
    1. Maven介绍  1.1. 简介 java编写的用于构建系统的自动化工具。目前版本是2.0.9，注意maven2和maven1有很大区别，阅读第三方文档时需要区分版本。 1.2. Maven资源 见官方网站；The 5 minute test，官方简易入门文档；Getting Started Tutorial，官方入门文档；Build Coo
  • Android 通过 intent传值获得null aijuans android
    我在通过intent 获得传递兑现过的时候报错，空指针,我是getMap方法进行传值，代码如下 1 2 3 4 5 6 7 8 9 public void getMap(View view){            Intent i =
  • apache 做代理 报如下错误：The proxy server received an invalid response from an upstream baalwolf response
    网站配置是apache＋tomcat,tomcat没有报错，apache报错是： The proxy server received an invalid response from an upstream server. The proxy server could not handle the request GET /. Reason: Error reading fr
  • Tomcat6 内存和线程配置 BigBird2012 tomcat6
    1、修改启动时内存参数、并指定JVM时区 （在windows server 2008 下时间少了8个小时） 在Tomcat上运行j2ee项目代码时，经常会出现内存溢出的情况，解决办法是在系统参数中增加系统参数：  window下， 在catalina.bat最前面 set JAVA_OPTS=-XX:PermSize=64M -XX:MaxPermSize=128m -Xms5
  • Karam与TDD bijian1013 KaramTDD
    一.TDD         测试驱动开发（Test-Driven Development,TDD）是一种敏捷（AGILE）开发方法论，它把开发流程倒转了过来，在进行代码实现之前，首先保证编写测试用例，从而用测试来驱动开发（而不是把测试作为一项验证工具来使用）。         TDD的原则很简单： a.只有当某个
  • [Zookeeper学习笔记之七]Zookeeper源代码分析之Zookeeper.States bit1129 zookeeper
    public enum States { CONNECTING, //Zookeeper服务器不可用，客户端处于尝试链接状态 ASSOCIATING, //？？？ CONNECTED, //链接建立，可以与Zookeeper服务器正常通信 CONNECTEDREADONLY, //处于只读状态的链接状态，只读模式可以在
  • 【Scala十四】Scala核心八：闭包 bit1129 scala
    Free variable A free variable of an expression is a variable that’s used inside the expression but not defined inside the expression. For instance, in the function literal expression (x: Int) => (x
  • android发送json并解析返回json ronin47 android
    package com.http.test; import org.apache.http.HttpResponse; import org.apache.http.HttpStatus; import org.apache.http.client.HttpClient; import org.apache.http.client.methods.HttpGet; import
  • 一份IT实习生的总结 brotherlamp PHPphp资料php教程php培训php视频
    今天突然发现在不知不觉中自己已经实习了 3 个月了，现在可能不算是真正意义上的实习吧，因为现在自己才大三，在这边撸代码的同时还要考虑到学校的功课跟期末考试。让我震惊的是，我完全想不到在这 3 个月里我到底学到了什么，这是一件多么悲催的事情啊。同时我对我应该 get 到什么新技能也很迷茫。所以今晚还是总结下把，让自己在接下来的实习生活有更加明确的方向。最后感谢工作室给我们几个人这个机会让我们提前出来
  • 据说是2012年10月人人网校招的一道笔试题-给出一个重物重量为X,另外提供的小砝码重量分别为1，3，9。。。3^N。 将重物放到天平左侧，问在两边如何添加砝码 bylijinnan java
    public class ScalesBalance { /** * 题目： * 给出一个重物重量为X,另外提供的小砝码重量分别为1，3，9。。。3^N。 （假设N无限大，但一种重量的砝码只有一个） * 将重物放到天平左侧，问在两边如何添加砝码使两边平衡 * * 分析： * 三进制 * 我们约定括号表示里面的数是三进制，例如 47=(1202
  • dom4j最常用最简单的方法 chiangfai dom4j
    要使用dom4j读写XML文档,需要先下载dom4j包,dom4j官方网站在 http://www.dom4j.org/目前最新dom4j包下载地址:http://nchc.dl.sourceforge.net/sourceforge/dom4j/dom4j-1.6.1.zip 解开后有两个包,仅操作XML文档的话把dom4j-1.6.1.jar加入工程就可以了,如果需要使用XPath的话还需要
  • 简单HBase笔记 chenchao051 hbase
     一、Client-side write buffer 客户端缓存请求 描述：可以缓存客户端的请求，以此来减少RPC的次数，但是缓存只是被存在一个ArrayList中，所以多线程访问时不安全的。 可以使用getWriteBuffer()方法来取得客户端缓存中的数据。 默认关闭。 二、Scan的Caching 描述： next( )方法请求一行就要使用一次RPC,即使
  • mysqldump导出时出现when doing LOCK TABLES daizj mysqlmysqdump导数据
    　　执行　mysqldump -uxxx -pxxx -hxxx -Pxxxx database tablename > tablename.sql　 导出表时，会报 mysqldump: Got error: 1044: Access denied for user 'xxx'@'xxx' to database 'xxx' when doing LOCK TABLES 解决
  • CSS渲染原理 dcj3sjt126com Web
      从事Web前端开发的人都与CSS打交道很多，有的人也许不知道css是怎么去工作的，写出来的css浏览器是怎么样去解析的呢？当这个成为我们提高css水平的一个瓶颈时，是否应该多了解一下呢？          一、浏览器的发展与CSS           
  • 《阿甘正传》台词 dcj3sjt126com
    Part Ⅰ: 《阿甘正传》Forrest Gump经典中英文对白 Forrest: Hello! My names Forrest. Forrest Gump. You wanna Chocolate? I could eat about a million and a half othese. My momma always said life was like a box ochocol
  • Java处理JSON dyy_gusi json
    Json在数据传输中很好用，原因是JSON 比 XML 更小、更快，更易解析。 在Java程序中，如何使用处理JSON，现在有很多工具可以处理，比较流行常用的是google的gson和alibaba的fastjson，具体使用如下： 1、读取json然后处理 class ReadJSON { public static void main(String[] args)
  • win7下nginx和php的配置 geeksun nginx
    1.  安装包准备 nginx :  从nginx.org下载nginx-1.8.0.zip php： 从php.net下载php-5.6.10-Win32-VC11-x64.zip， php是免安装文件。 RunHiddenConsole: 用于隐藏命令行窗口   2. 配置 # java用8080端口做应用服务器，nginx反向代理到这个端口即可 p
  • 基于2.8版本redis配置文件中文解释 hongtoushizi redis
    转载自： http://wangwei007.blog.51cto.com/68019/1548167        在Redis中直接启动redis-server服务时, 采用的是默认的配置文件。采用redis-server   xxx.conf 这样的方式可以按照指定的配置文件来运行Redis服务。下面是Redis2.8.9的配置文
  • 第五章 常用Lua开发库3-模板渲染 jinnianshilongnian nginxlua
    动态web网页开发是Web开发中一个常见的场景，比如像京东商品详情页，其页面逻辑是非常复杂的，需要使用模板技术来实现。而Lua中也有许多模板引擎，如目前我在使用的lua-resty-template，可以渲染很复杂的页面，借助LuaJIT其性能也是可以接受的。   如果学习过JavaEE中的servlet和JSP的话，应该知道JSP模板最终会被翻译成Servlet来执行；而lua-r
  • JZSearch大数据搜索引擎 颠覆者 JavaScript
    系统简介： 大数据的特点有四个层面：第一，数据体量巨大。从TB级别，跃升到PB级别；第二，数据类型繁多。网络日志、视频、图片、地理位置信息等等。第三，价值密度低。以视频为例，连续不间断监控过程中，可能有用的数据仅仅有一两秒。第四，处理速度快。最后这一点也是和传统的数据挖掘技术有着本质的不同。业界将其归纳为4个“V”——Volume，Variety，Value，Velocity。大数据搜索引
  • 10招让你成为杰出的Java程序员 pda158 java编程框架
    如果你是一个热衷于技术的  Java 程序员， 那么下面的 10 个要点可以让你在众多 Java 开发人员中脱颖而出。 　　 1. 拥有扎实的基础和深刻理解 OO 原则 　　对于 Java 程序员，深刻理解 Object Oriented Programming（面向对象编程）这一概念是必须的。没有 OOPS 的坚实基础，就领会不了像 Java 这些面向对象编程语言
  • tomcat之oracle连接池配置 小网客 oracle
    tomcat版本7.0 配置oracle连接池方式： 修改tomcat的server.xml配置文件： <GlobalNamingResources> <Resource name="utermdatasource" auth="Container" type="javax.sql.DataSou
  • Oracle 分页算法汇总 vipbooks oraclesql算法.net
        这是我找到的一些关于Oracle分页的算法，大家那里还有没有其他好的算法没？我们大家一起分享一下！ -- Oracle 分页算法一 select * from ( select page.*,rownum rn from (select * from help) page -- 20 = (currentPag
按字母分类： ABCDEFGHIJKLMNOPQRSTUVWXYZ其他