Hi, I encounter the below error while using the install script. The default script uses https to get repomd.xml. If I manually use http, it works. Any workarounds ? Rgds.

09:23:53 root@T7910-k3sm1 ~ → curl -sfL <http://get.k3s.io> | INSTALL_K3S_VERSION=v1.24.10+k3s1 sh -
[INFO]  Using v1.24.10+k3s1 as release
[INFO]  Downloading hash <https://github.com/k3s-io/k3s/releases/download/v1.24.10+k3s1/sha256sum-amd64.txt>
[INFO]  Skipping binary downloaded, installed k3s matches hash
Rancher K3s Common (stable)                                         0.0  B/s |   0  B     00:00
Errors during downloading metadata for repository 'rancher-k3s-common-stable':
  - Curl error (35): SSL connect error for <https://rpm.rancher.io/k3s/stable/common/centos/8/noarch/repodata/repomd.xml> [OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to <http://rpm.rancher.io:443|rpm.rancher.io:443> ]
Error: Failed to download metadata for repo 'rancher-k3s-common-stable': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried

is it possible to build k3s binary without using docker ?

Hello, I'm running a 5 node k3s cluster, 2 master and 3 worker nodes. I am getting an issue with intermittent DNS failure across several namespaces. The DNS failures I am noticing are for local records that the host machines are all able to resolve. Like I said its intermittent, so ~80% of the time they are able to resolve local DNS just fine, but the rest of the time they aren't. I've updated the k3s config on each node to use a custom

resolv.conf

that points to my local DNS server. The nodes are all running

v1.24.6+k3s1

. Has anyone ever experiened similar issues or have any troubleshooting advice?

already posted to the general channel, but here it might be suited better: does anyone has a hint on how to add additional ports to the traefik helm chart, if traefik was not disabled during the installation? the additional ip for kubevip or the tls store are picket up, but additional ports are not working

Hi, everyone. Question regarding this doc. Manifest below:

apiVersion: v1
kind: Service
metadata:
  name: test-service
  labels:
    <http://svccontroller.k3s.cattle.io/lbpool|svccontroller.k3s.cattle.io/lbpool>: pool1
spec:
  selector:
    app: myapp
  ports:
    - port: 80
      targetPort: 80
  type: LoadBalancer
---
apiVersion: v1
kind: Service
metadata:
  name: test-service-1
  labels:
    <http://svccontroller.k3s.cattle.io/lbpool|svccontroller.k3s.cattle.io/lbpool>: pool2
spec:
  selector:
    app: myapp
  ports:
    - port: 80
      targetPort: 80
  type: LoadBalancer

node has labels but still first service taking all IP. why is that?

Hello, i have installed k3s with the simple command:

curl -sfL <https://get.k3s.io> | sh -

. Now i would like to change the config to the embedded cluster k3s version (--cluster-init). Is it possible to do it without reinstall completely k3s ? thanks

How can I debug crash loop back off on traefik and coredns pods? Nothing stands out when doing logs or describe

Hello! By default Traefik uses a default certificate. I try to supply my own with

kubectl create secret tls mycert -n myns --cert=mychain.pem --key=mykey.key

and refer to it in

/var/lib/rancher/k3s/server/manifests/traefik-config.yaml

apiVersion: <http://helm.cattle.io/v1|helm.cattle.io/v1>
kind: HelmChartConfig
metadata:
  name: traefik
  namespace: kube-system
spec:
  valuesContent: |-
    extraVolumeMounts:
      - name: ssl
        mountPath: /ssl
    extraVolumes:
      - name: ssl
        secret:
          secretName: mycert

Does this look fine? Do you know working examples for k3s + custom traefik certificates?

👋 Hello, team! I would like to ask for a small hand. I am using k8s installed/configured with kubeadm and then when I try to upgrade from 1.21 to 1.23 with flannel 0.21.0. Then, I am facing network issues with flannel config where: the pods do not go up , I see problems creating volumes (

MountVolume.SetUp failed for volume “flannel-cfg” : failed to sync configmap cache: timed out waiting for the condition

) . In the flannel logs I am checking

W0206 13:37:12.951287   1 client_config.go:617] Neither --kubeconfig nor --master was specified. Using the inClusterConfig. This might not work

. Anyone have a thought about that? How can I pass the kubeconfig for flannel? Btw, really thank you for all your help and attention 🙂 Following the logs:

Hi,

I would like to check if its feasible to setup a HA K3S as a stretched cluster across 2 zones. Due to a lack of a odd number of zones, I was wondering if this could be done using an external datastore that would have to be sync-ed across the 2 zones. Any recommendations or shared experience is greatly appreciated.

hi all

I do have a quick question: if I use rewriting via registries.yaml and rewrite from public to a private repository, will it automatically use the matching imagePullSecret ?

Hey! I just upgraded k3s from

v1.24.3+k3s1

to

v1.26.1+k3s1

and now my pods are not using the proxy anymore a.k.a. cannot reach anything online. DNS resolution works and setting the proxy manually inside a test pod solves the issue. How can I solve this issue generally. I have the proxy settings in the

/etc/systemd/system/k3s.service.env

which worked for the previous version but now it doesn't seem to set the proxy properly. Any hints/pointers would be highly appreciated 🙂

I had a quick question regarding the versions recommended on the k3s airgap image list. I see these versions don't align with the upstream k8s ones mentioned with kubeadm constants. For eg. v1.26.1 k3s, pause version mentioned in k3s airgap list is 3.6 and the one on upstream k8s is 3.9. Similar for coredns k3s 1.9.4 and k8s upstream is 1.9.3. Q1) Is there any specific reason behind this? May be related to performance/issues observed with k3s binary. Q2) Should we align to k3s airgap versions or to the upstream k8s versions? If anyone of k3s folks can comment on this. Would be great. Thanks!

Hey guys. So i understand per github issues https://github.com/k3s-io/k3s/issues/2850 and https://github.com/k3s-io/k3s/issues/6297 you can't have another server over the internet. I have an OCI cluster and some Raspberry PI 4 available. Initially I wanted 2 servers on OCI and 1 on RPI4, but as that is not ok, at least I ask, is it possible over my OCI cluster (1 server and 3 workers, all ARM) to add another 4 RPI4 workers from my home, they are over NAT. Thanks

Hello guys, I want to ask to fix my problem. I have one baremetal server and 2 VPC on AWS, i want create K3S cluster with master in AWS and worker/ nodes in baremetal. First, I installed K3S (default pod CIDR 10.42.0.0/16 and service CIDR 10.43.0.0/16) without wireguard (using vxlan), i have problem the baremetal01 cannot telnet 10.43.0.1 port 443. on master:

curl -sfL <https://get.k3s.io> | INSTALL_K3S_EXEC="server --disable traefik" sh -s - --docker

on worker:

curl -sfL <https://get.k3s.io> | K3S_URL=<https://10.10.1.60:6443> K3S_TOKEN={{ Token }} sh -s - --docker --node-ip 10.116.212.4 --node-external-ip 10.116.212.4 --flannel-iface eth1

- I installed K3S using wireguard with following this guideline https://www.inovex.de/de/blog/how-to-set-up-a-k3s-cluster-on-wireguard/ and K3S running well: on master:

curl -sfL <https://get.k3s.io> | INSTALL_K3S_EXEC="server --disable traefik" sh -s - --docker --advertise-address 10.222.0.1 --node-external-ip 10.10.1.60 --flannel-iface=wg0 --flannel-backend=wireguard-native --flannel-external-ip

on worker:

curl -sfL <https://get.k3s.io> | K3S_URL=<https://10.10.1.60:6443> K3S_TOKEN={{ Token }} sh -s - --docker --node-ip 10.116.212.4 --node-external-ip 10.116.212.4 --flannel-iface eth1

- Baremetal01 (10.116.1.2) can connect to VPC A & VPC B via IPSec Site to Site - All instances in VPC A & B can connect to baremetal01 But i have one problem, the pods in baremetal01, cannot connect to VPC A and VPC B, only connect to IP internal baremetal01. Any advice would be appreciated. Thank you

Iam trying to create a multi region k3s HA cluster on bare metall. did anyone tried to do the same?

Hi Team, We have setup provision x2 master nodes (with etcd datastore - https://docs.k3s.io/installation/ha-embedded*)* and x4 worker nodes for our cluster and the k3s were provision using Rancher UI > Custom cluster settings. At the moment all the servers are up running, but when we try check HA availability by shutting down we get following errors when we issue kubectl commands; • Error from server (ServiceUnavailable): apiserver not ready • Error from server (Timeout): the server was unable to return a response in the time allotted, but may still be processing the request (get nodes) Our requirement is to setup HA for control plane (master node). I.e: if one control plane server goes down / not available, Kubenetes API /CLI commands should run from other (available) node(s). If we are to achieve our requirement; • Via etcd datastote, Do we need setup x3 master nodes - enabling control plane and etcd in all 3 ? • If not use external datastore : https://docs.k3s.io/installation/ha If enabling external db, is it sufficient to pass --datastore-endpoint when provisioning master node via rancher Below state k3s configuration for master nodes; Master Node 0 [Sample ip: x.x.x.0]:

cat /etc/rancher/k3s/config.yaml.d/50-rancher.yaml
{
  "agent-token": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
  "disable-apiserver": false,
  "disable-cloud-controller": false,
  "disable-controller-manager": false,
  "disable-etcd": false,
  "disable-kube-proxy": false,
  "disable-network-policy": false,
  "disable-scheduler": false,
  "docker": false,
  "etcd-expose-metrics": false,
  "etcd-snapshot-retention": 5,
  "etcd-snapshot-schedule-cron": "0 */5 * * *",
  "kube-controller-manager-arg": [
    "cert-dir=/var/lib/rancher/k3s/server/tls/kube-controller-manager",
    "secure-port=10257"
  ],
  "kube-scheduler-arg": [
    "cert-dir=/var/lib/rancher/k3s/server/tls/kube-scheduler",
    "secure-port=10259"
  ],
  "node-label": [
    "<http://cattle.io/os=linux|cattle.io/os=linux>",
    "<http://rke.cattle.io/machine=b89290bb-5f82-47e7-96bc-9cc16f126a5c|rke.cattle.io/machine=b89290bb-5f82-47e7-96bc-9cc16f126a5c>"
  ],
  "node-taint": [
    "<http://node-role.kubernetes.io/control-plane:NoSchedule|node-role.kubernetes.io/control-plane:NoSchedule>",
    "<http://node-role.kubernetes.io/etcd:NoExecute|node-role.kubernetes.io/etcd:NoExecute>"
  ],
  "private-registry": "/etc/rancher/k3s/registries.yaml",
  "protect-kernel-defaults": false,
  "secrets-encryption": false,
  "selinux": false,
  "server": "<https://x.x.x.1:6443>",
  "token": "YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY"

Master Node 1 [Sample ip: x.x.x.1]:

cat /etc/rancher/k3s/config.yaml.d/50-rancher.yaml
{
  "agent-token": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
  "cluster-init": true,
  "disable-apiserver": false,
  "disable-cloud-controller": false,
  "disable-controller-manager": false,
  "disable-etcd": false,
  "disable-kube-proxy": false,
  "disable-network-policy": false,
  "disable-scheduler": false,
  "docker": false,
  "etcd-expose-metrics": false,
  "etcd-snapshot-retention": 5,
  "etcd-snapshot-schedule-cron": "0 */5 * * *",
  "kube-controller-manager-arg": [
    "cert-dir=/var/lib/rancher/k3s/server/tls/kube-controller-manager",
    "secure-port=10257"
  ],
  "kube-scheduler-arg": [
    "cert-dir=/var/lib/rancher/k3s/server/tls/kube-scheduler",
    "secure-port=10259"
  ],
  "node-label": [
    "<http://cattle.io/os=linux|cattle.io/os=linux>",
    "<http://rke.cattle.io/machine=77f5f3c6-a380-48b0-8b74-c7c3da330ff6|rke.cattle.io/machine=77f5f3c6-a380-48b0-8b74-c7c3da330ff6>"
  ],
  "node-taint": [
    "<http://node-role.kubernetes.io/control-plane:NoSchedule|node-role.kubernetes.io/control-plane:NoSchedule>",
    "<http://node-role.kubernetes.io/etcd:NoExecute|node-role.kubernetes.io/etcd:NoExecute>"
  ],
  "private-registry": "/etc/rancher/k3s/registries.yaml",
  "protect-kernel-defaults": false,
  "secrets-encryption": false,
  "selinux": false,
  "token": "YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY"
}

On testing the issue when Master Node1 goes down. When Master Node0 goes down, sometimes kubectl works (not 100%). We assume kube-api-server and related pods are distributed among both Master nodes alng with etcd datastore sync when w provision from Rancher UI Any insights/feedback on how to correctly achieve HA for Rancher UI provisioned k3s when one of master node goes down is highly appreciated.

Good day to all, Sorry if it's not the right place to ask for help. I want to run Rancher as a single node (basically, separately from other clusters, in a separate VM) and with its help create k8s clusters. For testing purposes in two different environments: Mac pc and RHEL8 VM, I have installed the same rancher v2.7.1 image in the docker container. However, the output was different: Mac (everything works fine): INFO: Running k3s server --cluster-init --cluster-reset 2023/02/15 134709 [INFO] Rancher version v2.7.1 (bb1c35fc4) is starting 2023/02/15 134709 [INFO] Rancher arguments {ACMEDomains:[] AddLocal:true Embedded:false BindHost: HTTPListenPort:80 HTTPSListenPort:443 K8sMode:auto Debug:false Trace:false NoCACerts:false AuditLogPath:/var/log/auditlog/rancher-api-audit.log AuditLogMaxage:10 AuditLogMaxsize:100 AuditLogMaxbackup:10 AuditLevel:0 Features: ClusterRegistry:} 2023/02/15 134709 [INFO] Listening on /tmp/log.sock 2023/02/15 134709 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.16444 connect: connection refused 2023/02/15 134711 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.16444 connect: connection refused 2023/02/15 134713 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.16444 connect: connection refused 2023/02/15 134715 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.16444 connect: connection refused 2023/02/15 134723 [INFO] Running in single server mode, will not peer connections 2023/02/15 134723 [INFO] Applying CRD features.management.cattle.io 2023/02/15 134751 [INFO] Applying CRD navlinks.ui.cattle.io On RHEL8 VM: INFO: Running k3s server --cluster-init --cluster-reset 2023/02/15 150513 [INFO] Rancher version v2.7.1 (bb1c35fc4) is starting 2023/02/15 150513 [INFO] Rancher arguments {ACMEDomains:[] AddLocal:true Embedded:false BindHost: HTTPListenPort:80 HTTPSListenPort:443 K8sMode:auto Debug:false Trace:false NoCACerts:false AuditLogPath:/var/log/auditlog/rancher-api-audit.log AuditLogMaxage:10 AuditLogMaxsize:100 AuditLogMaxbackup:10 AuditLevel:0 Features: ClusterRegistry:} 2023/02/15 150513 [INFO] Listening on /tmp/log.sock 2023/02/15 150513 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.16444 connect: connection refused 2023/02/15 150515 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.16444 connect: connection refused 2023/02/15 150517 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.16444 connect: connection refused 2023/02/15 150519 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.16444 connect: connection refused 2023/02/15 150521 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.16444 connect: connection refused 2023/02/15 150523 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.16444 connect: connection refused 2023/02/15 150530 [FATAL] k3s exited with: exit status 2 My question is why in one case it automatically switched to the "single server mode" and in another, it didn't? Thanks in advance,

When using docker does the cluster cidr need to match the docker0 bridge's IP range?

i got some issues when i following get started guide from rancher.com, my rancher version is 2.7,

λ  kubectl get pods -A
NAMESPACE       NAME                      READY   STATUS              RESTARTS      AGE
cattle-system   helm-operation-229zl      0/2     ContainerCreating   0             23m
cattle-system   helm-operation-58tk4      0/2     ContainerCreating   0             4m52s
cattle-system   helm-operation-5fgf4      0/2     ImagePullBackOff    0             37m
cattle-system   helm-operation-5fml2      0/2     ImagePullBackOff    0             38m
cattle-system   helm-operation-6dlgv      0/2     ContainerCreating   0             3m50s
cattle-system   helm-operation-7fgf4      0/2     ContainerCreating   0             24m
cattle-system   helm-operation-8cm54      0/2     ImagePullBackOff    0             39m
cattle-system   helm-operation-dc45v      0/2     ContainerCreating   0             17m
cattle-system   helm-operation-dslxw      0/2     ContainerCreating   0             21m
cattle-system   helm-operation-f7blm      0/2     ImagePullBackOff    0             36m
cattle-system   helm-operation-fqf8j      0/2     ContainerCreating   0             13m
cattle-system   helm-operation-gbt25      0/2     ImagePullBackOff    0             41m
cattle-system   helm-operation-jlvb5      0/2     ContainerCreating   0             18m
cattle-system   helm-operation-jpqgq      0/2     ContainerCreating   0             6m57s
cattle-system   helm-operation-jxdkh      0/2     ContainerCreating   0             26m
cattle-system   helm-operation-kn6mz      0/2     ContainerCreating   0             22m
cattle-system   helm-operation-l9x8z      0/2     ImagePullBackOff    0             40m
cattle-system   helm-operation-lljpq      0/2     ContainerCreating   0             106s
cattle-system   helm-operation-lpfp5      0/2     ContainerCreating   0             14m
cattle-system   helm-operation-m5jpb      0/2     ContainerCreating   0             20m
cattle-system   helm-operation-p2cbz      0/2     ContainerCreating   0             9m1s
cattle-system   helm-operation-pgvx8      0/2     ContainerCreating   0             44s
cattle-system   helm-operation-pxvtn      0/2     ContainerCreating   0             12m
cattle-system   helm-operation-pzq64      0/2     ContainerCreating   0             11m
cattle-system   helm-operation-rcfl8      0/2     ContainerCreating   0             15m
cattle-system   helm-operation-rqx9l      0/2     ContainerCreating   0             2m48s
cattle-system   helm-operation-thdwv      0/2     ContainerCreating   0             7m59s
cattle-system   helm-operation-vf7nq      0/2     ContainerCreating   0             5m54s
cattle-system   helm-operation-vswpd      0/2     ContainerCreating   0             10m
cattle-system   helm-operation-vvzmr      0/2     ContainerCreating   0             16m
cattle-system   helm-operation-wz2m6      0/2     ImagePullBackOff    0             35m

What is the minimum Linux kernel version required for K3S and Rancher?

Hi, I have put a helm chart in the static/charts dir and then a manifest deploying it. The deploy job in k3s fails by saying a secret already exists. A secret that is a part of the helm package i created. When i do manual deploy / undeploy of the helm package i do not get this error.

Seems to be working now. Im building Hyper-V VM with Packer. I added a call to k3s-killall.sh in the end that seemed to fix it. Perhaps it went in to a bad state when not stopping in a controlled way

Disclaimer: I have been trying to look in documentation if I could figure this out prior to deciding to ask a grown up in here 🙂 Hi everyone and sorry for barging in like this, I have a quick question about k3s. In a development environment I maintain I accidentally upgraded a server node to k3s version to v1.25.6+k3s1 when the intended target was v1.24.4+k3s1 (that still included kubernetes resources that the application I am running are using). This cluster was initially a single master quick and dirty development cluster but now it contains relatively big amount of services/resources being the target of a CD pipeline. my question is really, Can I undo the master update to use version v1.24.4+k3s1 without a lot of headache or is it time for me to recreate the cluster?

Hi , where I can find which k3s versions are supported on Ubuntu 22.04 ?

k3s can use helm values in

valuesContent

How can I use a

values.yaml

file when I autodeploy helm charts? https://docs.k3s.io/helm#customizing-packaged-components-with-helmchartconfig

Hi, I found this git issue that has been closed https://github.com/k3s-io/k3s/issues/6611. According to this k3s is compatible with Rhel 9 version. Even when I tried to setup k3s over rhel 9.1 it worked. Could you please let me know when the support matrix will include Rhel 9 user like us to upgrade to Rhel 9 from 8 with K3S GitHub Support for RedHat 9 · Issue #6611 · k3s-io/k3s Is your feature request related to a problem? Please describe. Cannot install on RedHat 9 because of missing k3s-common repo (requirement for k3s-selinux). Describe the solution you'd like Prov...

Hi community, I have successfully deployed Rancher single node in the docker container. In the UI for now there is only one cluster: local (Provider: K3S). However, if I check its workloads in the namespace “cattle-system” there is a lot of failed pods “helm-operation-xxxxx”. As I understood, it is trying to pull an image “rancher/shell:v0.1.6”, but my VM doesn’t have direct access to the internet. I’m using Artifactory, but not quite sure how to integrate it with Rancher. Some of the logs from the Rancher container:

E0220 13:04:57.268766     26 remote_image.go:113] PullImage "rancher/shell:v0.1.6" from image service failed: rpc error: code = Unknown desc = failed to pull and unpack image "<http://docker.io/rancher/shell:v0.1.6|docker.io/rancher/shell:v0.1.6>": failed to resolve reference "<http://docker.io/rancher/shell:v0.1.6|docker.io/rancher/shell:v0.1.6>": failed to do request: Head <https://registry-1.docker.io/v2/rancher/shell/manifests/v0.1.6>: dial tcp: lookup <http://registry-1.docker.io|registry-1.docker.io>: no such host
E0220 13:04:57.268808     26 kuberuntime_image.go:50] Pull image "rancher/shell:v0.1.6" failed: rpc error: code = Unknown desc = failed to pull and unpack image "<http://docker.io/rancher/shell:v0.1.6|docker.io/rancher/shell:v0.1.6>": failed to resolve reference "<http://docker.io/rancher/shell:v0.1.6|docker.io/rancher/shell:v0.1.6>": failed to do request: Head <https://registry-1.docker.io/v2/rancher/shell/manifests/v0.1.6>: dial tcp: lookup <http://registry-1.docker.io|registry-1.docker.io>: no such host
E0220 13:04:57.268865     26 kuberuntime_manager.go:801] container start failed: ErrImagePull: rpc error: code = Unknown desc = failed to pull and unpack image "<http://docker.io/rancher/shell:v0.1.6|docker.io/rancher/shell:v0.1.6>": failed to resolve reference "<http://docker.io/rancher/shell:v0.1.6|docker.io/rancher/shell:v0.1.6>": failed to do request: Head <https://registry-1.docker.io/v2/rancher/shell/manifests/v0.1.6>: dial tcp: lookup <http://registry-1.docker.io|registry-1.docker.io>: no such host
E0220 13:04:57.269670     26 pod_workers.go:191] Error syncing pod f7002f13-3f4a-477d-b38e-b31a86854c8f ("helm-operation-d6b4f_cattle-system(f7002f13-3f4a-477d-b38e-b31a86854c8f)"), skipping: [failed to "StartContainer" for "helm" with ErrImagePull: "rpc error: code = Unknown desc = failed to pull and unpack image \"<http://docker.io/rancher/shell:v0.1.6\|docker.io/rancher/shell:v0.1.6\>": failed to resolve reference \"<http://docker.io/rancher/shell:v0.1.6\|docker.io/rancher/shell:v0.1.6\>": failed to do request: Head <https://registry-1.docker.io/v2/rancher/shell/manifests/v0.1.6>: dial tcp: lookup <http://registry-1.docker.io|registry-1.docker.io>: no such host", failed to "StartContainer" for "proxy" with ImagePullBackOff: "Back-off pulling image \"rancher/shell:v0.1.6\""]
E0220 13:05:00.264620     26 pod_workers.go:191] Error syncing pod 7f461430-9fa9-40a0-9292-b232999d4c68 ("helm-operation-csqtv_cattle-system(7f461430-9fa9-40a0-9292-b232999d4c68)"), skipping: [failed to "StartContainer" for "helm" with ImagePullBackOff: "Back-off pulling image \"rancher/shell:v0.1.6\"", failed to "StartContainer" for "proxy" with ImagePullBackOff: "Back-off pulling image \"rancher/shell:v0.1.6\""]
E0220 13:05:01.263203     26 pod_workers.go:191] Error syncing pod b36eedc8-bfaa-40fe-a347-7afe191c4806 ("helm-operation-zpkh5_cattle-system(b36eedc8-bfaa-40fe-a347-7afe191c4806)"), skipping: [failed to "StartContainer" for "helm" with ImagePullBackOff: "Back-off pulling image \"rancher/shell:v0.1.6\"", failed to "StartContainer" for "proxy" with ImagePullBackOff: "Back-off pulling image \"rancher/shell:v0.1.6\""]
W0220 13:05:01.348877     26 iptables.go:550] Could not set up iptables canary mangle/KUBE-PROXY-CANARY: error creating chain "KUBE-PROXY-CANARY": exit status 3: iptables v1.8.3 (legacy): can't initialize iptables table `mangle': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
E0220 13:05:02.263542     26 pod_workers.go:191] Error syncing pod cfa1b9ea-6f54-4486-b72c-516d85758097 ("helm-operation-qlplj_cattle-system(cfa1b9ea-6f54-4486-b72c-516d85758097)"), skipping: [failed to "StartContainer" for "helm" with ImagePullBackOff: "Back-off pulling image \"rancher/shell:v0.1.6\"", failed to "StartContainer" for "proxy" with ImagePullBackOff: "Back-off pulling image \"rancher/shell:v0.1.6\""]
E0220 13:05:05.262470     26 pod_workers.go:191] Error syncing pod 5c049d76-8ee5-42d6-b64d-da0715a58253 ("helm-operation-s9w8x_cattle-system(5c049d76-8ee5-42d6-b64d-da0715a58253)"), skipping: [failed to "StartContainer" for "helm" with ImagePullBackOff: "Back-off pulling image \"rancher/shell:v0.1.6\"", failed to "StartContainer" for "proxy" with ImagePullBackOff: "Back-off pulling image \"rancher/shell:v0.1.6\""]
E0220 13:05:07.264113     26 pod_workers.go:191] Error syncing pod ea230264-a67c-4829-a04f-e1cca0a26858 ("helm-operation-qdcft_cattle-system(ea230264-a67c-4829-a04f-e1cca0a26858)"), skipping: [failed to "StartContainer" for "helm" with ImagePullBackOff: "Back-off pulling image \"rancher/shell:v0.1.6\"", failed to "StartContainer" for "proxy" with ImagePullBackOff: "Back-off pulling image \"rancher/shell:v0.1.6\""]
E0220 13:05:07.264202     26 pod_workers.go:191] Error syncing pod e3db70fb-dc2e-4b8e-b70c-58c77fce33c3 ("helm-operation-6dx7j_cattle-system(e3db70fb-dc2e-4b8e-b70c-58c77fce33c3)"), skipping: [failed to "StartContainer" for "helm" with ImagePullBackOff: "Back-off pulling image \"rancher/shell:v0.1.6\"", failed to "StartContainer" for "proxy" with ImagePullBackOff: "Back-off pulling image \"rancher/shell:v0.1.6\""]
E0220 13:05:09.262982     26 pod_workers.go:191] Error syncing pod f7002f13-3f4a-477d-b38e-b31a86854c8f ("helm-operation-d6b4f_cattle-system(f7002f13-3f4a-477d-b38e-b31a86854c8f)"), skipping: [failed to "StartContainer" for "helm" with ImagePullBackOff: "Back-off pulling image \"rancher/shell:v0.1.6\"", failed to "StartContainer" for "proxy" with ImagePullBackOff: "Back-off pulling image \"rancher/shell:v0.1.6\""]
E0220 13:05:12.941958     26 proxier.go:833] Failed to ensure that filter chain KUBE-EXTERNAL-SERVICES exists: error creating chain "KUBE-EXTERNAL-SERVICES": exit status 3: iptables v1.8.3 (legacy): can't initialize iptables table `filter': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
I0220 13:05:12.941981     26 proxier.go:825] Sync failed; retrying in 30s

If it uses by default https://registry-1.docker.io/v2/rancher/shell/manifests/v0.1.6 how can I change it and add a link to the remote repository in my Artifactory? Why it’s reporting that something is wrong with iptables? Thanks in advance,