k8s-bigip-ctlr
k8s-bigip-ctlr copied to clipboard
Ability to set logging profile to use on a virtual service via an ingress definition
Title
Ability to set logging profile to use on a virtual service via an ingress definition
Description
Want to set logging profile on a virtual server using an ingress definition.
Actual Problem
The virtual server that is created for an ingress doesn't have a logging profile set, we won't to get this set to an existing profile.
Solution Proposed
Change code somewhere to make this happen :-)
Suggest use CRDs
Hi @trinaths using a CRD I don't think is possible nor desirable.
Use case: I have a helm chart (not developed by me) that deploys everything including an ingress which is pretty standard.
I now want to configure the logging profile on the generated VS that the ingress resource created.
Is this possible?
I thought with a CRD then I wouldn't be able to use the ingress resource and that would be a pain as I want to have as little code as possible
@sorrison Can you try VS CRD with Policy CRD ? See https://github.com/F5Networks/k8s-bigip-ctlr/blob/master/docs/config_examples/customResource/Policy/sample-policy.yaml
Hi @trinaths I'm not really sure what I'm doing but I have created a policy using
apiVersion: cis.f5.com/v1
kind: Policy
metadata:
labels:
f5cr: "true"
name: nectar-logging
namespace: rctest
spec:
profiles:
logProfiles:
- /Common/nectar-rsyslog
But I don't see any of the virtual servers created by the ingress resources change to use that logging profile. Is there something else I need to do?
Hello @trinaths, Any chance we could add a logging profile by using an annotation in an Ingress Manifest?
@writemike for Ingress you can use AS3 override configmap. CIS will merge the global settings with the Ingress.
Example
https://clouddocs.f5.com/containers/latest/userguide/config-map.html?highlight=override#override-as3-configmap
However the easiest way would be to use a Policy-CRD with logging etc. At this time we dont want to add additional annotations to Ingress
Hi @mdditt2000 thanks for the pointers. I think I'm almost there but haven't quite got it yet.
I have a virtual server already created based off an ingress resource, its name is ingress_115_146_83_40_443. I have created the following configmap
apiVersion: v1
kind: ConfigMap
metadata:
name: f5-logoverride
labels:
f5type: virtual-server
overrideAS3: "true"
data:
template: |
{
"declaration": {
"test": {
"Shared": {
"ingress_115_146_83_40_443": {
"profileTrafficLog": "/Common/nectar-rsyslog-test"
}
}
}
}
}
And restarted the bigip-ctrl with it pointing to the configmap. I know this is working as I had a syntax error in the template and it errored which I have now fixed.
However I don't see the virtual server changing to specify a logging profile.
From the example I'm not sure what
"test": {
"Shared": {
means? Is this important?
I see no errors on the pod nor any related logs in debug mode
OK made a bit more progress, realised "test" is meant to be the partition so have fixed this up and now I get:
declaration.Shared.profileTrafficLog: Invalid type. Expected: object, given: string
I took the quotes away but I get a different error
Error processing configmap f5-logoverride in namespace: kube-system with err: invalid character 'e' in literal null (expecting 'u')
The docs don't give any examples on what format this is meant to be.
https://clouddocs.f5.com/products/extensions/f5-appsvcs-extension/latest/refguide/schema-reference.html#service-https
Figured it out
for anyone else this is how you set it, replace
apiVersion: v1
kind: ConfigMap
metadata:
name: <name of config map>
labels:
f5type: virtual-server
overrideAS3: "true"
data:
template: |
{
"declaration": {
"<Name of partition>": {
"Shared": {
"<name of virtual server>": {
"profileTrafficLog": {"bigip": "<name of logging profile>"}
}
}
}
}
}
I can do what I want now although setting a logging profile by an annotation would be ideal I think. Although maybe not possible as what if 2 ingresses use same virtual server and different logging annotations are set. Maybe this is why this hasn't been implemented. Happy for this to be closed