TL;DR
The core consideration is whether defects affect team capacity in other areas. If so, then you need to represent them somehow on the main kanban. If not, you should definitely evaluate whether they are truly part of the same fundamental process.
Work-Flow Assumptions
In general, on-going or operational support should be part of a different process than development. This is not always the case, and may certainly not be true in your organization. Nevertheless, it is worth considering whether these issues should be part of your current process or not.
Kanban and Queues
Kanban often works best when batch sizes are somewhat standardized. @Zolt has a blog entry on optimal batch sizes that provides some technical detail on this key issue. However, the Kanban process can certainly handle variation in the size of user stories, both through adjustments to WIP limits and in queue management.
If your defects are handled by the same team that handles features or product development, then your team capacity remains the same regardless of the type of stories being queued. Throughput and cycle time of defects may be different, but they still require resources from your team, and will therefore impact your overall team capacity. In other words, don't ignore or discount these user stories unless they are performed by a different team or within a separate process.
Note, however, that there is no requirement that defects enter the same queue as other types of work. It is certainly worth evaluating the addition of a separate queue (or queues) for defects, bugs, and other issues to enable differentiation in the prioritization and pull processes.
Some Possible Solutions
Because Kanban is fundamentally a pull-queue framework, you have some options in how you organize your queues and how you determine when work should be pulled from a given queue into an in-progress state. Some options include:
Having swim lanes dedicated to the alternate queues.
Note that this works best when your in-progress sub-queues (columns, if you prefer) are fundamentally the same as the stages for your other stories.
Having columns dedicated to certain types of stories.
The benefit of having optional columns, or having user stories that may skip columns that are not relevant, may be outweighed by the added complexity or cognitive load needed to track flow on the kanban. This should be carefully evaluated by the entire team.
Having different team members pull from different queues.
This somewhat violates the principle of collective ownership that agile methodologies promote, but is certainly in line with the core pull principles around which Kanban is based. If your team is organized in such a way that different people have non-overlapping core responsibilities, rather than being fully cross-functional, this may be a useful work-flow.
Adjust WIP limits.
If defects generally have a faster cycle time than other types of work, it may make sense to increase your WIP limits to account for the increased throughput you expect of the team. Alternatively, you can have separate WIP limits for different swim lanes or columns. This may greatly increase the complexity of the kanban, and makes at-a-glance assessment of the board more difficult, but it is certainly an option worth considering.
There really isn't a single right answer to the issue you describe, nor is the list above meant to be exhaustively canonical. Nevertheless, the point is that the Kanban framework is flexible enough to address this type of issue in a variety of ways.
