0

I am trying to install calico on an existing single-node kubernetes cluster (installed through kubeadm). The two manifests are tigera-operator and custom-resources. This works fine if I manually install it through kubectl:

kubectl -f apply tigera-operator.yaml
customresourcedefinition.apiextensions.k8s.io/bgpconfigurations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/bgppeers.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/blockaffinities.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/clusterinformations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/felixconfigurations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/globalnetworkpolicies.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/globalnetworksets.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/hostendpoints.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ipamblocks.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ipamconfigs.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ipamhandles.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ippools.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/kubecontrollersconfigurations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/networkpolicies.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/networksets.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/apiservers.operator.tigera.io created
customresourcedefinition.apiextensions.k8s.io/imagesets.operator.tigera.io created
customresourcedefinition.apiextensions.k8s.io/installations.operator.tigera.io created
customresourcedefinition.apiextensions.k8s.io/tigerastatuses.operator.tigera.io created
namespace/tigera-operator created
Warning: policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
podsecuritypolicy.policy/tigera-operator created
serviceaccount/tigera-operator created
clusterrole.rbac.authorization.k8s.io/tigera-operator created
clusterrolebinding.rbac.authorization.k8s.io/tigera-operator created
deployment.apps/tigera-operator created

When I try to install it through the ansible kubernetes module (core or community, it's the same), I get the following error:

fatal: [work-pve]: FAILED! => {"changed": false, "msg": "Failed to find exact match for operator.tigera.io/v1.Installation by [kind, name, singularName, shortNames]"}

The manifest is of course a mixture of all sorts of resources and it's more than 5k-lines long. I'm not sure how to solve the problem, but I'm looking forward to any suggestions. I'm guessing this problem occurs also with other manifests, so I don't think this is a calico-specific problem.

The ansible task is:

- name: apply manifest tigera-operator manifest
  kubernetes.core.k8s:
    src: "/tmp/tigera-operator.yaml"
    state: present
    kubeconfig: /etc/kubernetes/admin.conf

On the host I run ansible 4.4 (apple m1, installed through brew).
On the server I'm running Ubuntu 20.04.3.
Pip libraries: openshift (0.12.1), kubernetes (12.0.1).

0

1 Answer 1

1

I was able to solve it quite easily in the end. I needed to add the apply directive to the task. So now it looks like this (I'm also adding the second related task):

- name: apply manifest tigera-operator manifest
  kubernetes.core.k8s:
    src: "/tmp/tigera-operator.yaml"
    state: present
    apply: yes
    kubeconfig: /etc/kubernetes/admin.conf

- name: apply manifest Calico custom-resources
  kubernetes.core.k8s:
    src: "/tmp/custom-resources.yaml"
    state: present
    apply: yes
    kubeconfig: /etc/kubernetes/admin.conf

Reference: https://docs.ansible.com/ansible/latest/collections/community/kubernetes/k8s_module.html

apply compares the desired resource definition with the previously supplied resource definition, ignoring properties that are automatically generated apply works better with Services than 'force=yes'

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .