标签: google-kubernetes-engine

我试图找出在我的 GKE Kubernetes 集群上运行 Grafana/Heapster/InfluxDB 的最佳方式。

据我所知，kube-system除非我希望谷歌一段时间后覆盖这些设置，否则我无法修改命名空间。因此，更改在 kube-system 中运行的 heapster 可能不是一种选择。

这是否意味着我的默认命名空间中需要另一个 heapster 以及 grafana 和 InfluxDB pods？

我在 Kubernetes 上部署的 SFTP 服务器遇到了一个奇怪的问题。我怀疑这个问题与 sshd_config 有关，所以我想我会在这里问（已经研究了一段时间的文档，也只是盲目地尝试，但没有任何效果）。

我已经在 Kubernetes 集群中设置了一个 SFTP 服务器，使用与这里隐藏的配置类似的配置：https : //github.com/mikeghen/kubernetes-gcs-sftp

它实际上在 minikube 本地工作得很好！

当我将它部署到我在 Google Kubernetes Engine 上的集群时，我遇到了一些问题。但我认为这与 K8S 无关，我认为与 SSH 相关。

不幸的是，当我尝试从外部 IP 访问 SFTP 服务器时，我被迫使用公钥身份验证（我只想使用密码身份验证）。我用

sftp -vvv -P 22 partner2@35.xx.xx.xx

并得到

OpenSSH_7.5p1, LibreSSL 2.5.4
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 52: Applying options for *
debug2: resolving "34.xx.xx.xx" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 34.xx.xx.xx [34.xx.xx.xx] port 22.
debug1: Connection established.
debug1: identity file /Users/mikeghen/.ssh/id_rsa type 1
debug1: …

我有一个 GCE Ingress 配置并在端口 443 上使用 SSL。我试图让端口 28080 指向我的独立可操作服务器。

我目前为我的 Ingress yaml 准备了这个：

# web-ingress.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: gke-ingress
  annotations:
    kubernetes.io/ingress.class: "gce"
    ingress.kubernetes.io/ssl-redirect: "true"
    kubernetes.io/ingress.allow-http: "false"
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /ws
        backend:
          serviceName: websocket
          servicePort: 28080
  tls:
  - secretName: gkecert
    hosts:
    - example.com
  backend:
    serviceName: web
    servicePort: 443

如果我将 websocket 服务的路径设置为 /，它会破坏根路径（错误 503）。从我读过的内容来看，入口无法处理一条路径上的 2 个端口。那么人们如何将他们的前端连接到 websocket 服务器而不用路径分隔呢？

我们的应用程序需要在两个文件存储中存在数据。在我们当前的 Kubernetes 配置中，我们使用一个持久卷，如下所示：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: fileserver-input
spec:
  capacity:
    storage: 1T
  accessModes:
  - ReadWriteMany
  nfs:
    path: /mypath
    server: XX.XXX.XXX.XXX

然后我们将其作为一个卷添加到我们的部署中：

    volumeMounts:
      - mountPath: /mypath
        name: my-path

如何做到这一点Cloud Run on GKE？我们已经尝试运行命令将文件存储挂载到 docker 容器中，但是我们没有成功，因为容器没有以特权方式运行。

有没有办法像常规那样指定一个volumeMount GKE，或者在特权模式下运行容器Cloud Run on GKE？

我有一个 VPC 网络设置，其中有一个连接到本地网络的 VPN。云路由器用于在内部以及与 VPN 网络之间创建路由 (BGP)。其中一个项目是托管具有内部和外部 IP（具有别名 IP 范围）的公共 Kubernetes 集群。它被配置为 VPC 网络的一部分（使用其子网之一）。

我正在尝试将 Kubernetes 上运行的服务连接到内部网络中的资源（通过 Cloud VPN）。不幸的是，这似乎不可能。连接超时。

Cloud VPN、Cloud Router 设置正确，网络之间存在访问/通信。唯一的问题是，我无法从 Kubernetes 容器访问本地资源

我目前正在 n1 standard1 节点（1vCPU 和 3.75GB 内存）上运行 Kubernetes 集群。我尝试部署 4 个工作负载。

我已将每个部署的资源请求和限制设置为 100m 和 128Mi（对于容器），但是当我尝试部署第三个 Pod 时，即使节点同时仅使用 9% CPU，我仍然没有足够的 CPU 可用性。

有谁知道会发生什么？任何回应将不胜感激！

我正在尝试在 Kubernetes 集群上卸载并重新安装 cert-manager。他们的卸载文档提到：

在继续之前，请确保用户创建的所有 cert-manager 资源均已删除。您可以使用以下命令检查任何现有资源：

$ kubectl get Issuers,ClusterIssuers,Certificates,CertificateRequests,Orders,Challenges --all-namespaces

该命令输出数百个资源，分布在二十几个命名空间中。

如何有效地删除它们，而不删除命名空间中的其他任何内容？

该kubectl delete命令在删除所有特定类型时需要指定命名空间，如下所示：kubectl delete certificates -n example-ns，所以这在这里不好。

在指定的同时按名称删除每个循环-A也不起作用，因为我需要指定名称空间：

$ kubectl delete -A order.certmanager.k8s.io/fcfa95477bc0149dbc16c99c54faa82e-cert-1862418815
error: a resource cannot be retrieved by name across all namespaces

这里正确的 cli 魔法是什么？

我遵循的步骤：

1.创建VPC网络

gcloud compute networks create stg-vpc \ --subnet-mode custom

2. 为这个网络的 VPC Peering 创建 IP 范围

gcloud beta compute addresses create google-managed-services-stg-vpc \ --global \ --purpose=VPC_PEERING \ --description="peering range for psql" \ --addresses=10.20.0.0 \ --prefix-length=16 \ --network=stg-vpc

3. 为 Cloud SQL Postgres 实例分配私有 IP

在 Cloud SQL Web 控制台中，我创建了一个新的 Postgres 实例。在连接选项中，我启用了私有 IP，并将其配置stg-vpc为 IP 范围google-managed-services-stg-vpc。

这将创建具有 IP 的 Cloud SQL Postgres 实例10.20.0.3。

4.为GKE集群创建子网

gcloud compute networks subnets create stg-vpc-us-central1 \ …

我需要内核头文件，但没有/lib/modules/[kernel version]/build或/usr/src/[kernel version]。我猜想他们把这些东西撕掉是为了缩小图像。

我的用例：我使用bpftracekprobes 和跟踪点来跟踪内核，它需要知道某些结构定义才能知道 args/ret 值的内存布局。

有没有一种简单的方法可以下载我正在运行的内核的标头？我在跑步1.10.7-gke.6 ALPHA (linux 4.14.65+)。

我在 Google Kubernetes Engine 上有一个集群，它使用 Calico 启用了网络策略。
到目前为止，我已经编写了 12 个网络策略作为 YAML 文件的形式。
我似乎无法弄清楚的一件事是，这些网络策略的创建顺序是否重要。
例如，假设我有这两个策略：
Pol#1- 拒绝所有入口连接

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Ingress

Pol#2- 允许后端访问数据库：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-db-to-be-accessed-by-backend
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: mysql
      release: production
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend
          release: production
    ports:
    - protocol: TCP
      port: 3306

如果我先应用 Pol#1，然后应用 Pol#2，与先应用 Pol#2，然后应用 Pol#1 相比，我会得到不同的结果吗？