标签: kubernetes

我遵循本教程是为了在 Docker 容器中本地运行 kubernetes 集群。当我运行时kubectl get nodes，我得到：

与服务器 localhost:8080 的连接被拒绝 - 您是否指定了正确的主机或端口？

我注意到一些由 kubelet 启动的容器，比如 apiserver，被退出了。这是输出docker ps -a：

CONTAINER ID        IMAGE                                             COMMAND                  CREATED             STATUS                       PORTS               NAMES
778bc9a9a93c        gcr.io/google_containers/hyperkube-amd64:v1.2.2   "/hyperkube apiserver"   3 seconds ago       Exited (255) 2 seconds ago                       k8s_apiserver.78ec1de_k8s-master-sw-ansible01_default_4c6ab43ac4ee970e1f563d76ab3d3ec9_de6ff8f9
12dd99c83c34        gcr.io/google_containers/hyperkube-amd64:v1.2.2   "/setup-files.sh IP:1"   3 seconds ago       Exited (7) 2 seconds ago                         k8s_setup.e5aa3216_k8s-master-sw-ansible01_default_4c6ab43ac4ee970e1f563d76ab3d3ec9_3283400b
ef7383fa9203        gcr.io/google_containers/hyperkube-amd64:v1.2.2   "/setup-files.sh IP:1"   4 seconds ago       Exited (7) 4 seconds ago                         k8s_setup.e5aa3216_k8s-master-sw-ansible01_default_4c6ab43ac4ee970e1f563d76ab3d3ec9_87beca1b
b3896f4896b1        gcr.io/google_containers/hyperkube-amd64:v1.2.2   "/hyperkube scheduler"   5 seconds ago       Up 4 …

我正在尝试使服务器上的 docker 更安全。主要问题是大多数人说“如果一个人可以访问 docker，他们也可以是 root”，对于少数管理员来说，这不是您想要的。

详细地说，他们可以使用-v并挂载/etc到/mnt容器中并更改影子文件并获得对主机的访问权限。他们也可以使用-d, 或特权选项来做更多的事情。

所以基本上，我想“尝试”和限制一些事情。

1. 卷绑定挂载
2. 特权
3. --add-cap
4. -d （某些项目？）

到目前为止我的想法：

• docker bash 脚本的别名，在其上使用 sudo 并正则表达式他们不应该做的所有事情。
• 打开远程 api，保护它，也许用 nginx 和 nginx 中的正则表达式反向代理它不应该做的事情。
• 使用其他工具？Mesos/马拉松/Swarm/造船厂/随便什么

可选项目是在提交到 git 代码时制作容器，并让“检查器”验证内容Dockerfile并为它们创建图像。然后对该映像进行签名并自动部署它。（但这不会再给他们太多自由）

此外，删除绑定卷并不是最好的。如果我们有一个 docker 插件，上面写着“你只能/data以用户 X 的身份挂载”，其中USERinDockerfile是那个用户 X，那就简单多了。

像docker-novolume-plugin这样的东西对于卷来说已经是一个不错的开始，虽然不限制绑定卷。

最后的问题是，我如何让用户以他们自己的用户/docker 身份构建/拉取/运行 docker 映像，而无法根系统。只要它有效，就不必完美。

[用调查结果的详细信息重写了问题。]

我正在运行一个包含大约 100 个容器的 Google Container Engine 集群，每天执行大约 100,000 个 API 调用。一些 pod 开始在 DNS 解析中失败 50%。我深入研究了这一点，它只发生在正在运行的节点上的 pod 上kube-dns。我还注意到，这只发生在系统中的节点因内存不足而关闭之前。

后台 resque 作业附加到 Google API，然后将数据上传到 S3。当我看到失败的作业时，它们会因“名称解析暂时失败”而失败。这发生在“accounts.google.com”和“s3.amazonaws.com”上。

当我登录到服务器，并尝试以连接到这些（或其他主机）host，nslookup或dig它似乎工作就好了。当我连接到 rails 控制台并运行在队列中失败的相同代码时，我不会发生故障。然而，正如我所说，这些后台故障似乎是间歇性的（大约 50% 的时间运行在节点上运行的工作程序kube-dns）。

到目前为止，我的临时修复是删除失败的 pod，并让 kubernetes 重新安排它们，并继续这样做，直到 kubernetes 将它们安排到一个没有运行的节点kube-dns。

顺便说一下，删除故障节点并没有解决这个问题。它只是导致 kubernetes 将所有内容移动到其他节点并移动了问题。

我正在尝试
使用映射到 DNS 地址的单个 API 网关服务创建 Kubernetes 环境。

我做了什么：
1）我去了 AWS Route53 服务并创建了一个子域。
2) 该子域似乎有一个静态 IP。我通过ping域名获得了这个IP。
3) 我已经在 AWS 上使用 kops设置了一个Kubernetes 集群。
4）我有一个网关服务，它的端点在 k8s 基础设施中访问微服务。
此服务的类型为LoadBalancer，其中loadBalancerIP等于上面的静态 IP。

问题：
使用上述设置，服务无法使用Failed to ensure load balancer for service default/gateway-service: LoadBalancerIP cannot be specified for AWS ELB.

然后我去阅读关于K8s Ingress ( Also ) 和Nginx 反向代理服务的非常好的资源。（最后是这个）（也是这个）。

之前也有人问过我的错误，答案似乎又在我的 API 网关和外部世界之间放置了另一层。
然后在阅读了很多关于 Nginx Ingress 控制器的内容后，我真的很困惑。

我的问题
a) 除了兼容性之外，是否有更大的理由在网关和外部世界之间设置另一层？
b) 我尝试在谷歌云平台上工作（这是一个 …

我试图更多地了解 Kubernetes 网络。这就是为什么我在谷歌云中部署了一个集群并检查了网络：gcloud container clusters describe cluster0 | grep -i cidr

clusterIpv4Cidr: 10.20.0.0/14        # --cluster-cidr
nodeIpv4CidrSize: 24
servicesIpv4Cidr: 10.23.240.0/20     # --service-cluster-ip-range

所以第一个是针对 pod IP 的：

First IP: 10.20.0.1
Last IP: 10.23.255.254

服务

First IP: 10.23.240.1
First IP: 10.23.255.254

pod 范围包含服务IP 范围总是这样吗？他们使用相同的网络层吗？

我有一个部署运行一个由一个独特容器组成的 pod。部署当前已启动并正在运行，我想修改其 pod 模板以向容器添加端口。

以下是当前定义的端口：

$ kubectl get deployment -o yaml spark-master | yq -r -y '.spec.template.spec.containers[] | select(.name=="spark-master").ports'
- containerPort: 7077
  protocol: TCP
- containerPort: 8080
  protocol: TCP

这是我尝试添加端口的补丁6066：

$ kubectl patch deployment spark-master -p '{"op": "add", "path": "/spec/template/spec/containers/0/ports/-", "value": {"containerPort": 6066}}'
deployment "spark-master" not patched
$ kubectl get deployment -o yaml spark-master | yq -r -y '.spec.template.spec.containers[] | select(.name=="spark-master").ports'
- containerPort: 7077
  protocol: TCP
- containerPort: 8080
  protocol: TCP

……没有成功。

另一个尝试，这次指定端口协议：

$ kubectl patch deployment spark-master …

如何配置 EKS 集群以自动允许从工作程序节点访问 S3？

我已经按照入门指南设置了一个 EKS 集群并运行了示例留言簿应用程序。现在我想使用Snakemake在集群上运行生物信息学管道，这需要对工作节点进行 S3 访问。

我在 IAM 控制台中尝试了一些无效的方法：

1. 向用于创建集群的 EKS 服务角色添加 AmazonS3FullAccess 权限。
2. 创建具有 AmazonS3FullAccess 权限（以及其他权限）的 CloudFormation 角色，并将此角色分配给工作线程节点堆栈。
3. 将 AmazonS3FullAccession 权限分配给我的用户账户（并将工作节点堆栈 IAM 角色留空——在这种情况下它应该使用我的用户账户权限）。

在所有这些情况下，工作节点没有 S3 访问权限（我 ssh 来检查）。有什么建议吗？

首先我很抱歉，因为我是开发人员，试图了解一些服务器的东西。如果这个问题在这里没有任何意义，我请求版主不要太苛刻。

根据我的理解，我们在 docker hub 中有 docker 镜像，用于运行容器。所以对我来说 docker hub 镜像是镜像包。为了管理容器，我们使用 kubernates。现在 helm 是 kubernates 的包管理器。Helm charts 是 docker-images 或 kubernate clusers 的包还是什么？

我StorageClass为aws eks集群（3 个节点）定义了以下内容

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: aws-gp2
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2
  zones: us-west-2a, us-west-2b, us-west-2c, us-west-2d
  fsType: ext4
reclaimPolicy: Retain
allowVolumeExpansion: true

并让eks节点在us-west-2a, us-west-2b, us-west-2c区域中运行。

当我尝试mysql使用动态持久卷进行部署时

---

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: mysql-pv-claim
  namespace: default
  labels:
    app: mysql
    env: prod
spec:
  storageClassName: aws-gp2
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi

---

kind: Deployment
apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 …

更新 Arch Linux (sudo pacman -Syu) 并重启系统后，由于 kube-proxy 导致 Minikube 无法启动。日志显示它正在尝试修改，/proc/sys/net/netfilter/nf_conntrack_max但遇到了权限被拒绝的问题。

我试图运行，sudo chmod 777 /proc/sys/net/netfilter/nf_conntrack_max但系统不允许我。我也删除~/.minikube并重新开始，但它仍然拒绝工作。启动时同样的问题kind。谁能告诉我如何解决这个问题？

$ kubectl get pods -n kube-system

NAME                               READY   STATUS    RESTARTS   AGE
coredns-74ff55c5b-2hkpd             0/1     Running   0          22s
etcd-minikube                      0/1     Running   0          30s
kube-apiserver-minikube            1/1     Running   0          30s
kube-controller-manager-minikube   0/1     Running   0          30s
kube-proxy-qhhx9                   0/1     Error     2          22s
kube-scheduler-minikube            0/1     Running   0          30s
storage-provisioner                1/1     Running   0          35s

kubectl logs kube-proxy-qhhx9 -n kube-system

I0511 04:47:08.189373       1 node.go:172] Successfully retrieved …