...
For testing purpose, we grant the cluster admin role to the serviceaccount created. Save the file and proceed with apply.
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
kind: ServiceAccount
apiVersion: v1
metadata:
name: octavia-ingress-controller
namespace: kube-system
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: octavia-ingress-controller
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- kind: ServiceAccount
name: octavia-ingress-controller
namespace: kube-system |
...
As announced in the introduction, the octavia-ingress-controller needs to communicate with OpenStack cloud to create resources corresponding to the Kubernetes Ingress resource, so the credentials of an OpenStack user (doesn't need to be the admin user) need to be provided in openstack section. Additionally, in order to differentiate the Ingresses between kubernetes clusters, cluster-name needs to be unique. Once you have filled in the fields appropriately (see below how), run the apply here too.
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
kind: ConfigMap
apiVersion: v1
metadata:
name: octavia-ingress-controller-config
namespace: kube-system
data:
config: |
cluster-name: <cluster_name>
openstack:
# domain-name: <domain_name> # Choose between domain-name or domain-id (do not use together)
domain-id: <domain_id>
username: <username>
# user-id: <user_id> # Choose between user-id or username (do not use together)
password: <user_id>
project-id: <project_id>
auth-url: <auth_url>
region: <region>
octavia:
subnet-id: <subnet_id>
floating-network-id: <public_net_id>
manage-security-groups: <boolean_value> # If true, creates automatically SecurityGroup |
...