-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(eks): control plane logs #8497
feat(eks): control plane logs #8497
Conversation
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we want to implement this at a low level, I think that core.CustomResource
should inject a special property to the custom resource which indicates that values are encoded and then automatically decode these automatically in core.CustomResourceProvider
and custom-resources.Provider
.
If this is too much, I am okay with just doing this at the EKS level for now.
Ping? |
pong. sorry i will continue working on this |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
I believe I covered all the code from the runtimes that you mentioned. Please, have a look. |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
* Enable or disable exporting the Kubernetes control plane logs for your cluster to CloudWatch Logs. | ||
* | ||
* @default false Cluster control plane logs are not exported to CloudWatch Logs. | ||
*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens if I enabled logs and then set to undefined (remove it). Would it set all the logging to false?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it will send an empty value for logging in the call to updateClusterConfig()
, and it would result in setting the default value from AWS
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have you tested this? My intuition is that if I send an updateClusterConfig
request with an empty value for logging
it will not perform any changes to my logging configuration, which is not what users expect if they enable logs and then remove this property in their CDK app.
I suspect that we may either need to always send the two enabled/disable lists or add heuristics to the UPDATE handler to calculate the "diff" from the previous value and produce an appropriate update.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i will try this out and let you know, but this diff is being done in the runtime code here:
updateLogging: JSON.stringify(newProps.logging) !== JSON.stringify(oldProps.logging), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This only determines that there was a change, not which log types should now be enabled/disabled based on that change.
For example, say, "oldProps" included two enabled types (say ["typeA", "typeB"]
) and now "newProps" include only a single type (say ["typeB"]
). Then, the request we need to send to updateClusterConfig
is only to disable (we can, if we want also include an "enable" for typeB
, but technically it's not required because it is already enabled).
LMK if this makes sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i believe we will need to send the whole configuration explicitly, including the disabled one. i am getting the following error when sending the exact same configuration to updateClusterConfig
:
Failed to update resource. Error: No changes needed for the logging config provided
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suspect this is a bit more involved... See my comment about updates. I also still don't like the boolean encoding stuff.
Let's try to simplify. Instead of passing the convoluted EKS logging structure through the Config
property to the custom resource provider, let's pass a separate logging configuration:
{
Config: <no change>,
EnabledLogTypes: string[],
DisabledLogTypes: string[]
}
Then, in the provider, always produce a logging
configuration based on these two arrays (no booleans(!)) and pass then to createCluster
or updateClusterConfig
.
Please also add unit tests to any changes made to the custom resource provider handler.
If you feel this is too much (and sorry for the hassle), feel free to abandon this PR and we will pick this up shortly. It is an important feature, so we will prioritize in the coming weeks.
* Enable or disable exporting the Kubernetes control plane logs for your cluster to CloudWatch Logs. | ||
* | ||
* @default false Cluster control plane logs are not exported to CloudWatch Logs. | ||
*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have you tested this? My intuition is that if I send an updateClusterConfig
request with an empty value for logging
it will not perform any changes to my logging configuration, which is not what users expect if they enable logs and then remove this property in their CDK app.
I suspect that we may either need to always send the two enabled/disable lists or add heuristics to the UPDATE handler to calculate the "diff" from the previous value and produce an appropriate update.
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
I do think this is a lot more complex than I expected, so I would rather abandon this PR (or the CDK can just pick from where I left off). Just a few things to consider:
|
@eduardomourar the helm boolean flags for helm charts are being fixed by @pahud as part of #8787 Do we have other flags? |
I don’t believe we currently have any other flag, unless we introduce more parameters for the helm command. |
@eladb I have a slightly different approach that I've just implemented in our company. Would like to get your pre-approval on the approach before preparing a PR, if this is possible. import { AwsCustomResource, AwsCustomResourcePolicy } from "@aws-cdk/custom-resources";
const SUPPORTED_CONTROL_PLANE_LOGGING = ['api', 'audit', 'authenticator', 'controllerManager', 'scheduler'] as const;
type SUPPORTED_CONTROL_PLANE_LOGGING = typeof SUPPORTED_CONTROL_PLANE_LOGGING[number];
export interface EksControlPlaneLoggingProps {
/**
* Control Plane Logging according to https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html
* If the `types` parameter is not explicitly provided, all the available Control Plane logging types will be enabled.
*
* @default false
*/
readonly enabled: boolean;
/**
* Allows the enablement of only specific Control Plane Logging types
*/
readonly types?: SUPPORTED_CONTROL_PLANE_LOGGING[];
}
export interface EksClusterProps {
.............................
/**
* EKS Control Plane Logging Configuration
*/
readonly controlPlaneLogging?: EksControlPlaneLoggingProps,
.............................
}
/**
* Base PPB Class for creating EKS CLusters
*/
export class EksCluster extends cdk.Construct {
constructor(scope: cdk.Construct, id: string, props: EksClusterProps) {
super(scope, id);
.............................
// instantiate the EKS Cluster
this.cluster = this.createCluster(props, this.vpc);
// add the NodeGroup according to user specifications
this.nodeGroup = this.addNodeGroup(props.nodeGroup);
// enable EKS Control Plane Logging if defined by user
this.enableControlPlaneLogging(props.controlPlaneLogging);
.............................
}
private enableControlPlaneLogging(props?: EksControlPlaneLoggingProps) {
if (props?.enabled) {
const enabled_types = props.types ?? SUPPORTED_CONTROL_PLANE_LOGGING;
const disabled_types = SUPPORTED_CONTROL_PLANE_LOGGING.filter(item => enabled_types.indexOf(item) < 0);
new AwsCustomResource(this, "ClusterLogsEnabler", {
policy: AwsCustomResourcePolicy.fromSdkCalls({
resources: [`${this.cluster.clusterArn}/update-config`],
}),
onUpdate: {
physicalResourceId: { id: `${this.cluster.clusterArn}/LogsEnabler` },
service: "EKS",
action: "updateClusterConfig",
region: this.region,
parameters: {
name: this.cluster.clusterName,
logging: {
clusterLogging: [
{
enabled: true,
types: enabled_types,
},
{
enabled: false,
types: disabled_types,
}
],
},
},
},
onDelete: {
physicalResourceId: { id: `${this.cluster.clusterArn}/LogsEnabler` },
service: "EKS",
action: "updateClusterConfig",
region: this.region,
parameters: {
name: this.cluster.clusterName,
logging: {
clusterLogging: [
{
enabled: false,
types: SUPPORTED_CONTROL_PLANE_LOGGING,
},
],
},
},
},
});
}
} It was tested in the following scenarios:
controlPlaneLogging: {
enabled: true,
},
controlPlaneLogging: {
enabled: true,
types: ['api', 'audit'],
},
controlPlaneLogging: {
enabled: true,
}, followed by completely removing the controlPlaneLogging: {
enabled: false,
}, Looking forward for your response, cheers! |
This creates an option to enable the control plane logs during creation of EKS cluster. For more information, see documentation here.
Due to a limitation in the CloudFormation custom resources, we will allow booleans values to be encoded into special strings (
true
into'TRUE:BOOLEAN'
andfalse
into'FALSE:BOOLEAN'
).closes #4159
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license