iis 新建网站没有文件夹权限,淘宝客怎么自己做网站,网络口碑营销的特点,郑州做网页的公司文章目录 一、什么是Ingress-Nginx二、故障排除1.1Ingress-Controller日志和事件检查 Ingress 资源事件检查 Nginx 配置检查使用的服务是否存在调试日志 1.2对 Kubernetes API 服务器的认证服务认证服务账户Kube-Config 1.3使用GDB和Nginx1.4在 Nginx 4.2.5 或其他版本#xf… 文章目录 一、什么是Ingress-Nginx二、故障排除1.1Ingress-Controller日志和事件检查 Ingress 资源事件检查 Nginx 配置检查使用的服务是否存在调试日志 1.2对 Kubernetes API 服务器的认证服务认证服务账户Kube-Config 1.3使用GDB和Nginx1.4在 Nginx 4.2.5 或其他版本Helm 图表版本上遇到的图像相关问题1.5无法监听端口80/443创建一个测试pod 1.6使用root创建测试pod 一、什么是Ingress-Nginx
Ingress-nginx 是 Kubernetes 的一个 Ingress 控制器它可以将外部的 HTTP 和 HTTPS 流量路由到集群内部的服务。Ingress 是 Kubernetes 中的一个 API 对象它管理外部访问到集群服务的规则。Ingress 可以提供负载均衡、SSL 终结和基于名称的虚拟主机等功能。 Ingress-nginx 控制器是 Ingress 资源的一种实现它根据定义在 Ingress 资源中的规则动态地配置 Nginx 服务器以路由流量。这使得你可以很方便地在 Kubernetes 集群中实现复杂的流量路由规则。
二、故障排除
1.1Ingress-Controller日志和事件
有许多方法可以对 ingress-controller 进行故障排除。以下是获取更多信息的基本故障排除方法。
检查 Ingress 资源事件
$ kubectl get ing -n namespace-of-ingress-resource
NAME HOSTS ADDRESS PORTS AGE
cafe-ingress cafe.com 10.0.2.15 80 25s$ kubectl describe ing ingress-resource-name -n namespace-of-ingress-resource
Name: cafe-ingress
Namespace: default
Address: 10.0.2.15
Default backend: default-http-backend:80 (172.17.0.5:8080)
Rules:Host Path Backends---- ---- --------cafe.com/tea tea-svc:80 (none)/coffee coffee-svc:80 (none)
Annotations:kubectl.kubernetes.io/last-applied-configuration: {apiVersion:networking.k8s.io/v1,kind:Ingress,metadata:{annotations:{},name:cafe-ingress,namespace:default,selfLink:/apis/networking/v1/namespaces/default/ingresses/cafe-ingress},spec:{rules:[{host:cafe.com,http:{paths:[{backend:{serviceName:tea-svc,servicePort:80},path:/tea},{backend:{serviceName:coffee-svc,servicePort:80},path:/coffee}]}}]},status:{loadBalancer:{ingress:[{ip:169.48.142.110}]}}}Events:Type Reason Age From Message---- ------ ---- ---- -------Normal CREATE 1m ingress-nginx-controller Ingress default/cafe-ingressNormal UPDATE 58s ingress-nginx-controller Ingress default/cafe-ingress检查 Nginx 配置
$ kubectl get pods -n namespace-of-ingress-controller
NAME READY STATUS RESTARTS AGE
ingress-nginx-controller-67956bf89d-fv58j 1/1 Running 0 1m$ kubectl exec -it -n namespace-of-ingress-controller ingress-nginx-controller-67956bf89d-fv58j -- cat /etc/nginx/nginx.conf
daemon off;
worker_processes 2;
pid /run/nginx.pid;
worker_rlimit_nofile 523264;
worker_shutdown_timeout 240s;
events {multi_accept on;worker_connections 16384;use epoll;
}
http {
....检查使用的服务是否存在
$ kubectl get svc --all-namespaces
NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
default coffee-svc ClusterIP 10.106.154.35 none 80/TCP 18m
default kubernetes ClusterIP 10.96.0.1 none 443/TCP 30m
default tea-svc ClusterIP 10.104.172.12 none 80/TCP 18m
kube-system default-http-backend NodePort 10.108.189.236 none 80:30001/TCP 30m
kube-system kube-dns ClusterIP 10.96.0.10 none 53/UDP,53/TCP 30m
kube-system kubernetes-dashboard NodePort 10.103.128.17 none 80:30000/TCP 30m调试日志
通过使用标志 --vXX可以增加日志的级别。这是通过编辑部署来完成的。
$ kubectl get deploy -n namespace-of-ingress-controller
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
default-http-backend 1 1 1 1 35m
ingress-nginx-controller 1 1 1 1 35m$ kubectl edit deploy -n namespace-of-ingress-controller ingress-nginx-controller
# Add --vX to - args, where X is an integer–v2 显示了关于 nginx 配置更改的详细信息这些信息是通过 diff 显示的 –v3 显示了关于服务、Ingress规则、端点更改的详细信息并且它会以 JSON 格式输出 nginx 配置 –v5 将 NGINX 配置为调试模式
1.2对 Kubernetes API 服务器的认证
许多组件参与了认证过程第一步是确定问题的来源即问题是出在服务认证上还是出在 kubeconfig 文件上。 这两种认证都必须有效
服务认证
Ingress 控制器需要从 apiserver 获取信息。因此需要进行认证这可以通过几种方式实现
服务账户这是推荐的方式因为无需进行任何配置。Ingress 控制器将使用系统提供的信息与 API 服务器进行通信。详见 ‘服务账户’ 部分。Kubeconfig 文件在一些 Kubernetes 环境中服务账户可能不可用。在这种情况下需要手动配置。可以使用 --kubeconfig 标志启动 Ingress 控制器二进制文件。该标志的值是一个文件路径该文件指定了如何连接到 API 服务器。使用 --kubeconfig 不需要 --apiserver-host 标志。文件的格式与 kubectl 用于连接 API 服务器的 ~/.kube/config 相同。详见 ‘kubeconfig’ 部分。使用 --apiserver-host 标志使用这个标志 --apiserver-hosthttp://localhost:8080 可以指定一个未加密的 API 服务器或者使用 kubectl proxy 访问远程 Kubernetes 集群。请不要在生产环境中使用这种方法。 在下面的图表中你可以看到所有选项的完整认证流程从左下角的浏览器开始。
服务账户
如果使用服务账户连接 API 服务器ingress-controller 期望文件 /var/run/secrets/kubernetes.io/serviceaccount/token 存在。它提供了一个秘密令牌该令牌是与 API 服务器进行身份验证所必需的。 可以使用以下命令进行验证
# start a container that contains curl
$ kubectl run -it --rm test --imagecurlimages/curl --restartNever -- /bin/sh# check if secret exists
/ $ ls /var/run/secrets/kubernetes.io/serviceaccount/
ca.crt namespace token
/ $# check base connectivity from cluster inside
/ $ curl -k https://kubernetes.default.svc.cluster.local
{kind: Status,apiVersion: v1,metadata: {},status: Failure,message: forbidden: User \system:anonymous\ cannot get path \/\,reason: Forbidden,details: {},code: 403
}/ $# connect using tokens
}/ $ curl --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt -H Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token) https://kubernetes.default.svc.cluster.localecho
{paths: [/api,/api/v1,/apis,/apis/,... TRUNCATED/readyz/shutdown,/version]
}
/ $# when you type exit or ^D the test pod will be deleted.如果它不起作用可能有两个原因 令牌的内容无效。使用 kubectl get secrets | grep service-account 找到秘密名称并使用 kubectl delete secret 删除它。它将自动重新创建。 您的 Kubernetes 安装非标准包含令牌的文件可能不存在。API 服务器将挂载包含此文件的卷但前提是 API 服务器配置为使用 ServiceAccount 准入控制器。如果您遇到此错误请验证您的 API 服务器是否正在使用 ServiceAccount 准入控制器。如果您手动配置 API 服务器可以使用 --admission-control 参数设置此项。 请注意您也应使用其他准入控制器。在配置此选项之前您应阅读关于准入控制器的信息。
Kube-Config
如果你想使用 kubeconfig 文件进行认证请遵循部署程序并在部署的 args 部分添加标志 --kubeconfig/etc/kubernetes/kubeconfig.yaml。
1.3使用GDB和Nginx
我们可以使用 gdb 和 nginx 一起执行配置的转储。这使我们能看到正在使用的配置以及旧的配置。 注意以下内容基于 nginx 的文档。
SSH 连接到工作节点
$ ssh userworkerIP获取运行nginx的Docker容器
$ docker ps | grep ingress-nginx-controller
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
d9e1d243156a registry.k8s.io/ingress-nginx/controller /usr/bin/dumb-init … 19 minutes ago Up 19 minutes k8s_ingress-nginx-controller_ingress-nginx-controller-67956bf89d-mqxzt_kube-system_079f31ec-aa37-11e8-ad39-080027a227db_0执行进入容器
$ docker exec -it --user0 --privileged d9e1d243156a bash确保nginx在–with-debug模式下运行
$ nginx -V 21 | grep -- --with-debug获取容器上运行的进程列表
$ ps -ef
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 20:23 ? 00:00:00 /usr/bin/dumb-init /nginx-ingres
root 5 1 0 20:23 ? 00:00:05 /ingress-nginx-controller --defa
root 21 5 0 20:23 ? 00:00:00 nginx: master process /usr/sbin/
nobody 106 21 0 20:23 ? 00:00:00 nginx: worker process
nobody 107 21 0 20:23 ? 00:00:00 nginx: worker process
root 172 0 0 20:43 pts/0 00:00:00 bash将gdb附加到nginx主进程
$ gdb -p 21
....
Attaching to process 21
Reading symbols from /usr/sbin/nginx...done.
....
(gdb)复制并粘贴以下内容
set $cd ngx_cycle-config_dump
set $nelts $cd.nelts
set $elts (ngx_conf_dump_t*)($cd.elts)
while ($nelts-- 0)
set $name $elts[$nelts]-name.data
printf Dumping %s to nginx_conf.txt\n, $name
append memory nginx_conf.txt \$elts[$nelts]-buffer.start $elts[$nelts]-buffer.end
end通过按CTRLD退出GDB打开nginx_conf.txt
cat nginx_conf.txt注意从GitHub和BitBucket Server源SCMs迁移依赖于从GitLab目标发出的传入IngressREST API连接。 ./congregate.sh list 是一个命令它从源系统收集元数据为迁移的后续步骤做准备。列表操作会从这些系统中提取所有的元数据通常需要管理员令牌或只读所有凭据才能成功。要设置这些请运行 ./congregate.sh configure或者修改由客户提供的SCM和/或CI源主机名和凭据的data/congregate.conf。如果你直接编辑 .conf 文件一定要参考 congregate 配置模板以正确格式化它。 列表操作可能需要相当长的时间这直接取决于源系统中的数据量。要调整列表的并发性你可以在列表命令中添加 --processes16仅适用于GitHub。如果不设置这个它将使用基于硬件的进程数的 processesnproc。当进程超过16个时要小心因为这将增加对源系统造成不必要伤害的机会如果他们的API速率限制没有设置可能会导致稳定性问题。 如果你需要重新列出并且不想覆盖之前列出的任何数据可以使用 --partial 运行它。额外的 --skip-* 参数允许你跳过用户、组、项目和 ci。 如果你正在从带有SCM源的CI源迁移数据列表操作也会执行一个映射功能将CI任务映射到SCM仓库。这个功能将定位构建配置XML的迁移到仓库以备将来转换为 gitlab-ci.yml。 为迁移准备数据的过程与使用基于git的工作流准备数据的过程相同。现在我们已经运行了./congregate.sh list命令将所有数据获取到本地文件系统本地MongoDB和.json文件的组合我们需要选择要迁移的用户项目和组。任何形式的stage命令的输出将会是data目录中的staged_groups.jsonstaged_projects.json和staged_users.json文件。 在shell中运行stage无UI时我们需要确定当前迁移范围内的项目和组ID。我们可以通过几种不同的方式进行分阶段。 stage-projects 要从项目的名称客户应该已经提供获取项目ID你可以运行 cat data/projects.json | grep ProjectName -A10 -B10 命令其中ProjectName是要迁移的存储库github和bitbucket或项目gitlab的名称。从那里你将看到可以为以下命令记下的ID ./congregate.sh stage-projects 13 78 951 446。注意你可以在stage-projects动词后面空格分隔地列出多个项目id。要强制此命令写入staged_projects.json和其他staged json文件请使用–commit标志。 stage-groups 这个过程与stage-projects非常相似但你需要在groups.json文件中搜索组id。运行 cat data/projects.json | grep GroupName -A10 -B10 命令。然后运行 ./congregate.sh stage-groups 78 651 997 --commit 来生成staged_*.json文件。
stage-wave 对于大型迁移客户通常希望在电子表格中定义迁移波次以便congregate可以读取并同时分阶段多个不同的组和项目而无需进行项目和组id的初步调查。要设置这个我们需要在data/congregate.conf中添加几行看起来像模板中的那些。此配置模板引用waves.csv文件。关于此配置如何工作的更详细描述在下面的配置部分。 一旦我们有了这个你可以运行 ./congregate.sh stage-wave WaveName --commit 来分阶段所有由电子表格定义的项目和组。 使用UI进行分阶段 如果你是在完整的桌面环境中运行congregate没有SSH或BASH进入在集群上运行的容器你可以使用UI在列出数据后进行分阶段方法是使用 ./congregate.sh ui 。这将让你有能力选择你想要为迁移分阶段的特定组项目和用户。一旦你选中了所有的框你可以点击stage来生成迁移的最后一步所需的staged_*.json文件。
1.4在 Nginx 4.2.5 或其他版本Helm 图表版本上遇到的图像相关问题
如果你在使用 helm 图表安装 Nginx 时遇到以下错误无论是通过 helm 命令或 helm_release terraform 提供程序
Warning Failed 5m5s (x4 over 6m34s) kubelet Failed to pull image registry.k8s.io/ingress-nginx/kube-webhook-certgen:v1.3.0sha256:549e71a6ca248c5abd51cdb73dbc3083df62cf92ed5e6147c780e30f7e007a47: rpc error: code Unknown desc failed to pull and unpack image registry.k8s.io/ingress-nginx/kube-webhook-certgensha256:549e71a6ca248c5abd51cdb73dbc3083df62cf92ed5e6147c780e30f7e007a47: failed to resolve reference registry.k8s.io/ingress-nginx/kube-webhook-certgensha256:549e71a6ca248c5abd51cdb73dbc3083df62cf92ed5e6147c780e30f7e007a47: failed to do request: Head https://eu.gcr.io/v2/k8s-artifacts-prod/ingress-nginx/kube-webhook-certgen/manifests/sha256:549e71a6ca248c5abd51cdb73dbc3083df62cf92ed5e6147c780e30f7e007a47: EOF请按照以下步骤操作。
在故障排查过程中你也可以执行以下命令来测试你的本地机器与仓库详情的连通性。
curl registry.k8s.io/ingress-nginx/kube-webhook-certgensha256:549e71a6ca248c5abd51cdb73dbc3083df62cf92ed5e6147c780e30f7e007a47 /dev/nullcurl -I https://eu.gcr.io/v2/k8s-artifacts-prod/ingress-nginx/kube-webhook-certgen/manifests/sha256:549e71a6ca248c5abd51cdb73dbc3083df62cf92ed5e6147c780e30f7e007a47在代理中实现了重定向以确保拉取图像。
这是建议将以下图像仓库列入白名单的解决方案
*.appspot.com
*.k8s.io
*.pkg.dev
*.gcr.io关于上述仓库的更多详细信息a. *.k8s.io - 为了确保你能从registry.k8s.io拉取任何图像 b. *.gcr.io - GCP服务用于图像托管。这是GCP建议允许并确保用户可以从他们的容器注册服务拉取图像的域的一部分。c. *.appspot.com - 这是Google的域用于GCR的域的一部分。
1.5无法监听端口80/443
这个错误的一个可能原因是缺乏绑定到端口的权限。端口80443和任何其他 1024的端口是Linux特权端口历史上只能由root绑定。ingress-nginx-controller使用CAP_NET_BIND_SERVICE linux能力来允许作为普通用户www-data / 101绑定这些端口。这涉及两个组件1. 在镜像中/nginx-ingress-controller文件添加了cap_net_bind_service能力例如通过setcap2. 在部署的containerSecurityContext中将NET_BIND_SERVICE能力添加到容器中。 个/某些节点上遇到这个问题而其他节点没有尝试在受影响的节点上清除并拉取镜像的新副本以防底层层次的损坏导致可执行文件失去能力。
创建一个测试pod
当遇到这个错误时/nginx-ingress-controller进程会退出/崩溃这使得很难排查容器内部发生的情况。为了解决这个问题启动一个运行sleep 3600的等效容器并进入它进行进一步的排查。 例如
apiVersion: v1
kind: Pod
metadata:name: ingress-nginx-sleepnamespace: defaultlabels:app: nginx
spec:containers:- name: nginximage: ##_CONTROLLER_IMAGE_##resources:requests:memory: 512Micpu: 500mlimits:memory: 1Gicpu: 1command: [sleep]args: [3600]ports:- containerPort: 80name: httpprotocol: TCP- containerPort: 443name: httpsprotocol: TCPsecurityContext:allowPrivilegeEscalation: truecapabilities:add:- NET_BIND_SERVICEdrop:- ALLrunAsUser: 101restartPolicy: NevernodeSelector:kubernetes.io/hostname: ##_NODE_NAME_##tolerations:- key: node.kubernetes.io/unschedulableoperator: Existseffect: NoSchedule如果适用/需要请更新命名空间 将 ##NODE_NAME## 替换为有问题的节点如果问题不仅限于一个节点则删除 nodeSelector 部分 将 ##CONTROLLER_IMAGE## 替换为您的 ingress-nginx 部署中使用的相同镜像 确认 securityContext 部分与您的集群中用于 ingress-nginx-controller pods 的设置匹配 应用这个 YAML 并打开一个连接到 pod 的 shell。尝试手动运行控制器进程
$ /nginx-ingress-controller你应该会从 ingress 控制器 pod 的日志中获取到相同的错误。 确认 capabilities 是否正确应用到 pod 中
$ grep CapBnd /proc/1/status
CapBnd: 0000000000000400上述值只启用了 net_bind_service根据 YAML 中的 security context它添加了该功能并丢弃了所有其他功能。如果你得到一个不同的值那么你可以在另一个 Linux 箱子上解码它这个容器中没有 capsh如下所示然后找出为什么指定的 capabilities 没有传播到 pod/容器中。
$ capsh --decode0000000000000400
0x0000000000000400cap_net_bind_service1.6使用root创建测试pod
注意这可能会受到 PodSecurityPolicy、PodSecurityAdmission/Standards、OPA Gatekeeper 等的限制如果是这种情况你将需要进行适当的测试工作例如在没有这些限制的新命名空间中部署。为了进一步测试你可能需要安装额外的工具等。通过以下方式修改 pod yaml 将 runAsUser 从 101 改为 0 从 capabilities 中删除 “drop…ALL” 部分。 在进入此容器后尝试以下操作 尝试以 www-data101用户身份运行控制器
$ chmod 4755 /nginx-ingress-controller
$ /nginx-ingress-controller检查错误看看是否仍然存在在端口监听的问题或者是否已经通过了这个问题转而出现了由于运行上下文耗尽导致的其他预期错误。 安装 libcap 包并检查文件上的 capabilities
$ apk add libcap
(1/1) Installing libcap (2.50-r0)
Executing busybox-1.33.1-r7.trigger
OK: 26 MiB in 41 packages
$ getcap /nginx-ingress-controller
/nginx-ingress-controller cap_net_bind_serviceep如果缺失参见上文关于在服务器上清除图像并重新拉取的部分 使用 strace 跟踪可执行文件查看当它失败时正在执行的系统调用
$ apk add strace
(1/1) Installing strace (5.12-r0)
Executing busybox-1.33.1-r7.trigger
OK: 28 MiB in 42 packages
$ strace /nginx-ingress-controller
execve(/nginx-ingress-controller, [/nginx-ingress-controller], 0x7ffeb9eb3240 /* 131 vars */) 0
arch_prctl(ARCH_SET_FS, 0x29ea690) 0
...
